Platzbedarf Arch Linux?

    Wie breit macht sich Arch Linux x86_64 auf euren SSDs bei folgender Ausstattung?

    • KDE
    • LibreOffice
    • Gimp
    • Inkscape
    • Firefox
    • Thunderbird
    • MPlayer oder VLC Media Player
    • Audacity
    • Updates enabled


    Wie groß ist also sinnvollerweise eine Partition (alles außer /boot kommt in eine Partition) für Arch Linux x86_64 auf einer SSD. Als Datenhalde für alle installierten Betriebssysteme dient eine HDD. Da auf der SSD noch ein oder mehrere andere Betriebssysteme (Windows 7 SP1 64-Bit, in einigen Fällen noch eine aktuelle Slackware64) liegen, kann der Platz für Arch nicht beliebig groß ausfallen, also z.B. die komplette SSD füllen.

    Windows 7 müllt sich durch die Updates ja immer mehr voll. Macht Arch das auch oder wird da nach Updates alter Ballast intelligent entsorgt?

    Die genannten Platzbedarfe von ca. 5 GB sind völlig unkritisch. Es kommt mir aber verdächtig wenig vor. Die Slackware64 14.1 mit vergleichbarer Ausstattung kommt schnell über 10 GB, was aber auch unkritisch wäre. Na gut, /usr/src füllt sich über die Zeit bei einer Slackware wahrscheinlich etwas mehr als bei vielen anderen Distros, die viel Software "aus der Tüte" mitbringen.

    Das Arch-Wiki gibt unter 1 GB für das Basissystem (von dem man je nach Bedarf noch einige Pakete weglassen kann) vor, in diesem Thread wurden soweit sinnvolle Überschläge genannt, wie viel die genannte Software auf der Root-Partition belegen wird. Üblicherweise ist jede Installation bei mir ohne Benutzerdaten weit unter den 15 GB geblieben, die das Wiki zur Partitionierung empfiehlt.

    Ansonsten hast du als primären Platzverbrauch nur noch /boot (wo in der Regel nur ein einzelner Kernel mit 2 Initcpios und evtl. Bootloader liegt), Swappartition (welche du, falls vorhanden, mit Slackware teilen kannst) und /var. Letzteres ist primär von Logdateien (bzw. dem systemd-Journal, welches man durch Konfigurationsdateien sehr gut in der Größe einschränken kann) und dem Paket-Cache von Pacman bevölkert, welchen du aber bei Platzmangel in /etc/pacman.conf von /var/cache/pacman/pkg an einen Ort deiner Wahl umbiegen kannst. Eventuell noch etwa 100 MB für das Arch Build System unter /var/abs, falls du mal ein mitgeliefertes Paket mit eigenen Optionen neu kompilieren willst.

    Zitat von Arnulf zu Linden


    Macht Arch das auch oder wird da nach Updates alter Ballast intelligent entsorgt?

    Automatisch wird wie z. B. auch auf Debian nichts entsorgt, aber wenn dein System zufriedenstellend läuft, kannst du regelmäßig nach einem Upgrade pacman -Sc ausführen, um nicht mehr installierte Pakete (i. d. R. ältere Versionen von Paketen, die aktualisiert wurden) aus dem Paket-Cache zu entfernen. Wenn man ansonsten die üblichen verdächtigen Verzeichnisse (~/.cache, /var/tmp) gelegentlich säubert, müllt da nichts zu.

  • Beitrag von clik!84 (21. September 2016 um 06:57)

    Dieser Beitrag wurde gelöscht, Informationen über den Löschvorgang sind nicht verfügbar.

  • Beitrag von mrshadowtux (21. September 2016 um 08:06)

    Dieser Beitrag wurde gelöscht, Informationen über den Löschvorgang sind nicht verfügbar.

  • Beitrag von Der Doktor (21. September 2016 um 08:46)

    Dieser Beitrag wurde gelöscht, Informationen über den Löschvorgang sind nicht verfügbar.

    Nach der Lektüre des erwähnten Wiki wird es auf 40 GB für / (inkl. /var) hinaus laufen.

    Was schmeißt Arch eigentlich alles nach /boot ?
    Bei Slackware liegen da nur 'n paar Kernel und 'ne gute Hand voll Dateien im kB-Bereich, weshalb für /boot 64 MB völlig ausreichen. Das erwähnte Wiki empfiehlt für /boot jedoch deutlich mehr (200 MB).

    64 MB sollten langen:

    21:25 afeld@feldibook /home/afeld% ls -1 /bootgrubinitramfs-linux-fallback.imginitramfs-linux.imgvmlinuz-linux

    21:25 afeld@feldibook /home/afeld% du -sh /boot 42M /boot

    Kommt halt darauf an, wie viele alten Kernel du aufheben willst um sie bei Bedarf zu starten. In meinem Ubuntu benötigt /boot momentan 147 MB (mit 3 Kernels) und am Debian-Server werden gerademal 31 MB belegt.
    Sehe die 200 MB schon als guten Richtwert, wenn man mit verschiedenen Kernels experementieren möchte ;)

    Zitat von Benjamin92


    Kommt halt darauf an, wie viele alten Kernel du aufheben willst um sie bei Bedarf zu starten. In meinem Ubuntu benötigt /boot momentan 147 MB (mit 3 Kernels) und am Debian-Server werden gerademal 31 MB belegt.
    Sehe die 200 MB schon als guten Richtwert, wenn man mit verschiedenen Kernels experementieren möchte ;)

    Standard sind bei mir bisher je Distro drei Kernel:

    • vmlinuz ist der normalerweise genutzte, selbst kompilierte Kernel.
    • vmlinuz-old ist der bis zur Umstellung auf vmlinuz genutzte selbst kompilierte Kernel als Notfallkernel, falls beim Kompilieren von vmlinuz mal etwas schief geht.
    • vmlinuz-shipped ist der installierte unveränderte Distro-Kernel, falls weder vmlinuz noch vmlinuz-old starten (z.B. wegen Änderungen an der Hardware), oder falls die installierte Distro mal auf einen anderen PC mit anderer Hardware geklont wird.

    Auf /boot sind auf meinem Arbeitsrechner (zwei Slackware-Versionen installiert, also sechs Kernel) ca. 30 MB von 64 MB belegt. Zukünfitg 128 MB für /boot sollten eigentlich reichen. 256 MB dafür ist eine Überlegung nur für den Software-Ausprobier-Rechner. Ubuntu mag ich nicht und ist daher für mich kein Maßstab. Mit nur einer Distro und nur drei Kernels sind 147 MB auf /boot ganz schön happig.

    Zitat von Benjamin92


    Kommt halt darauf an, wie viele alten Kernel du aufheben willst um sie bei Bedarf zu starten.

    Wohlgemerkt hat man durch das absolute KISS-Prinzip von Arch von jeder „Geschmackssorte“ (ARCH, lts, grsec oder ggf. andere aus dem AUR) von Linux-Kernel maximal einen installiert, da beim Upgrade die vorherige Version inklusive Kernel-Modulen vollständig ersetzt wird. Das hat wie öfters hier angesprochen natürlich den Nachteil, dass dann für den laufenden Kernel ohne Reboot die Module nicht mehr vorliegen, falls man z. B. einen USB-Massenspeicher anschließt.

    Zitat von tk1908

    Wenn man LVM und LUKS macht, braucht man doch ne separate /boot, oder?

    Nun, GRUB2 kann dm-crypt (LVM bin ich mir nicht sicher), aber dann hat man halt GRUB. GRUB ist doof.

    PGP-Key E384 009D 3B54 DCD3 21BF  9532 95EE 94A4 3258 3DB1 | S/MIME-Key 0x1A33706DAD44DA
    G d-@ s+:- a--- C+++ UB+L++ P--- L++@ E-@>++ W+ N o? K? w>++ !O !M !V PS+++ PE-- Y+>++ PGP++>+++ !t 5? X? !R tv b+++>++++ DI !D G>+ e>+++ h !r>++ !z
    „Die Aachener gelten als Erfinder des 4. Hauptsatzes der Thermodynamik: ‚Thermo schreibt man zweimal.“‘
    “Saying that Java is good because it works on all platforms is like saying oral sex is good because it works on all sexes.”
    „Es gibt 10 Sorten von Leuten: Die einen verstehen das Binärsystem, die anderen nicht.“
    „Manche Männer lieben Männer, Manche Frauen eben Frauen; Da gibt's nix zu bedauern und nichts zu staunen; Das ist genau so normal wie Kaugummi kauen; Doch die meisten werden sich das niemals trauen“

    Anderer Grund: /boot als UEFI ESP Partition. Die ist dann FAT32 anstatt ext4/btrfs und enthält nebst dem Kernel die ganzen EFI Boot Loader.

    Einmal editiert, zuletzt von gandro (22. September 2016 um 11:46)

    Ich hab hier am Thinkpad T460 den ganzen EFI-Krams deaktiviert und ganz normal GRUB installiert.

    Mein Partitionslayout könnte einfacher nicht sein:

    Krass kompliziert ist mein Parititonsschema auch nicht:

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!

Benutzerkonto erstellen Anmelden