Archiv verlassen und diese Seite im Standarddesign anzeigen : Frisch installiertes Ubuntu und schon ist /boot randvoll
Ich habe gestern Ubuntu (15.10, AMD64) installiert, ein paar Pakete installiert und upgedatet. Beim Updaten zeigten sich aber Warnungen das /boot voll sei und tatsächlich passt kaum noch etwas rein:
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 32353716 0 32353716 0% /dev
tmpfs 6474840 9888 6464952 1% /run
/dev/mapper/ubuntu--vg-root 3780001104 10112564 3577852496 1% /
tmpfs 32374192 188 32374004 1% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 32374192 0 32374192 0% /sys/fs/cgroup
/dev/sda2 241965 212114 17359 93% /boot
cgmfs 100 0 100 0% /run/cgmanager/fs
tmpfs 6474840 32 6474808 1% /run/user/119
tmpfs 6474840 0 6474840 0% /run/user/1000
Bleibt da nur neu installieren und manuell zu partitionieren? :confused:
schau doch mal nach, was in /boot liegt, also wie viele Kernel Du installiert hast.
Ist das System so wirklich aus einer frischen Neuinstallation heraus entstanden ohne bestehende Partitionen auf der HD?
250 MB für /boot ist jetzt auch nicht besonders viel - speziell bei Ubuntu. Da kommen öfters mal neue Updates der Kernelpakete raus und das sammelt sich halt so alles unter /boot an. Bei mir ist /boot immer mindestens 1 GB gross - auch trotz der Tatsache, dass ich die alten Kernel automatisch aufräumen lasse.
Also in /boot liegen ein paar Dateien:
abi-4.2.0-16-generic config-4.2.0-16-generic grub lost+found System.map-4.2.0-36-generic vmlinuz-4.2.0-36-generic
abi-4.2.0-36-generic config-4.2.0-36-generic initrd.img-4.2.0-16-generic memtest86+.bin System.map-4.2.0-36-lowlatency vmlinuz-4.2.0-36-lowlatency
abi-4.2.0-36-lowlatency config-4.2.0-36-lowlatency initrd.img-4.2.0-36-generic memtest86+.elf System.map-4.4.0-22-generic vmlinuz-4.4.0-22-generic
abi-4.4.0-22-generic config-4.4.0-22-generic initrd.img-4.2.0-36-lowlatency memtest86+_multiboot.bin System.map-4.4.0-22-lowlatency vmlinuz-4.4.0-22-lowlatency
abi-4.4.0-22-lowlatency config-4.4.0-22-lowlatency initrd.img-4.4.0-22-generic System.map-4.2.0-16-generic vmlinuz-4.2.0-16-generic
Und die Partitionierung ist so:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 3,7T 0 disk
sda1 8:1 0 1M 0 part
sda2 8:2 0 244M 0 part /boot
sda3 8:3 0 3,7T 0 part
sda3_crypt 252:0 0 3,7T 0 crypt
ubuntu--vg-root 252:1 0 3,6T 0 lvm /
ubuntu--vg-swap_1 252:2 0 62,8G 0 lvm [SWAP]
Aber die automatische Partitionierung von Ubuntu ist Murks, da /boot schon voll ist, denn ich verwende eine 4 TB große SSHD.
Nur 250 MB für /boot ist doch maßlos zu klein, bringt Fehler wie:
dpkg: error processing package linux-lowlatency (--configure):
dependency problems - leaving unconfigured
Setting up gnu-fdisk (1.3.0a-2) ...
Processing triggers for initramfs-tools (0.122ubuntu8) ...
update-initramfs: Generating /boot/initrd.img-4.4.0-22-generic
gzip: stdout: No space left on device
Da ich da keine Möglichkeit sehe die Partitionsgrößen zu verändern muss ich wohl neu installieren.
Auch 62,8 GB Swap passt nicht, denn a) würde das Swappen bei der Größe lange dauern, insbesondere auch weil die Partition verschlüselt ist, und b) habe ich 64 GiB RAM; da könnte ich auf Swap verzichten.
Da muss ich manuell partitionieren.
Wofür macht Ubuntu denn die nicht-gemountete Partition sda1? :confused:
Ein "file -s /dev/sda1" zeigt nur data, also kein Dateisytem.
BetterWorld
24.05.16, 21:30
...Aber die automatische Partitionierung von Ubuntu ist Murks, das /boot schon voll ist, denn ich verwende eine 4 TB große SSHD.weil es bei dir nicht passt, heißt das noch lange nicht, dass es Murks ist.
Kannst ja mal ein richtiges Linux probieren.
Nur 250 MB für /boot ist doch maßlos zu klein. Da ich da keine Möglichkeit sehe die Partitionsgrößen zu verändern muss ich wohl neu installieren.Nein, musst du nicht. Man kann alle Partitinonen nach Gusto vergrößern oder verkleinern.
Der Einfachheit halber boote ein Gparted, oder sowas.
Auch 62,8 GB Swap passt nicht, denn a) würde das Swappen bei der Größe lange dauern, insbesondere auch weil die Partition verschlüselt ist, Quark. Das ist immer noch schnell genug für dich und dein System.
Du wirst es nur nicht ausprobieren können, weil 64GB RAM schon ziemlich viel für Normaluser ist. Da reichen 8GB dicke.
und b) habe ich 64 GiB RAM; da könnte ich auf Swap verzichten.Auch wenn kein Swapen nötig ist, lagert der kernel dennoch auf die Swappartition aus. Nämlich Datenstrukturen und bestimmte Routinen, die er einfach nicht wieder einsetzen wird.
(Das sind aber höchstens ein paar Kilobyte, also eher Erbsenzählerei, denn Argument)
Du kannst also auf Swap verzichten, oder nicht.
Aber nicht so argumentieren.
Wofür macht Ubuntu denn die nicht-gemountete Partition sda1?Ich kenne kein *buntu. Ich nehm echtes Linux.
Aber oft sind das einfach Lückenfüller, um bessere Perfomance durch besseres Alignment zu erreichen.
Dafür wäre aber 1M verdammt viel.
Mounte sie doch mal einfach und guck nach.
Auch wenn kein Swapen nötig ist, lagert der kernel dennoch auf die Swappartition aus. Nämlich Datenstrukturen und bestimmte Routinen, die er einfach nicht wieder einsetzen wird.
(Das sind aber höchstens ein paar Kilobyte, also eher Erbsenzählerei, denn Argument)
Nein, ich habe einen Messrechner mit Echtzeit-Kernel gemacht und damit der nicht Swapt läuft er mit Swappiness 0. Damit zeigt mir top zu Swap immer "0 used".
250MB für boot sollte mehr als ausreichend sein - man sieht ja auch (da würde mich eher interessieren, warum - äh, nein, bei *buntu nicht) Du schon 5 Kernel installiert hast - wenn ich mich nicht verzählt habe.
(da würde mich eher interessieren, warum - äh, nein, bei *buntu nicht) Du schon 5 Kernel installiert hast - wenn ich mich nicht verzählt habe.
Einfach weil ich upgedatet habe und auch den Lowlatency-Kernel installiert habe.
Außerdem mache ich machmal eingene Kernel, denn einen Preempt-RT-Kernel kann ich nur unter Debian einfach als Paket installieren.
Und wenn ich einen Kernel mit einem eigenen Patch mache, gibt das einen weiteren Kernel.
Deshalb lege ich die Partitionen neu an mit 8 GB /boot und dem Rest mit verschlüsseltem Root-Dateisytem und mit 8 GB Swap weil die SSHD 8 GB NAND-Flash hat und ich die Swappiness auf 1 einstelle.
Hier ist mal mein lua-Script, dass ich auf meinen Ubuntu-Servern laufen lasse, um die Kernel regelmässig aufräumen zu lassen per cron.
An jeden der es verwenden will: Es ist schon länger her, dass ich das geschrieben habe, also:
Verwendung des Scriptes auf eigene Gefahr!
Wer das Script verwendet ohne ein Backup seines Systems zu haben, dem ist nicht zu helfen
Die Zeile, die die Pakete löscht, habe ich auch erst einmal auskommentiert. Damit das aufräumen stattfindet, müsst Ihr den Kommentar von der vorletzten Zeile des Codes entfernen.
http://debianforum.de/forum/pastebin.php?mode=view&s=39322
Hier ist mal mein lua-Script, dass ich auf meinen Ubuntu-Servern laufen lasse, um die Kernel regelmässig aufräumen zu lassen per cron.
Danke, aber ich müsste das schon jede Stunde laufen laufen lassen um mit nur 250 MB /boot auszukommen.
Und auf der 4 TB SSHD möchte ich auch ältere Kernel haben; dafür habe ich ja eine große SSHD gekauft; da muss man ja /boot nicht 250 MB = 0,00625 % von 4 TB klein machen.
Da hätte man in das Installationssytem zumindest 0,1 % packen können, was bei mir dann 4 GB wären.
Das Script läuft bei mir 1 x die Woche. Das grösste Boot-Verzeichnis ist 62 MB gross.
Ansonsten hilft auch ein regelmaessiges apt-get autoremove bei dieser Problematik evtl auch schon.
DrunkenFreak
25.05.16, 08:22
Da hätte man in das Installationssytem zumindest 0,1 % packen können, was bei mir dann 4 GB wären.
Ich hab n RAID mit 100TB. Das wären dann 100GB für /boot...
Woher soll das System wissen, dass du sowas willst, wenn du es ihm nicht sagst? Vergrößer die Partition, lass sie ganz weg oder leg sie gleich vernünftig an. Das ist kein Problem.
Automatismen gehen immer davon aus, dass man sich innerhalb der "Philosophie" der Entwickler bewegt, die sich den Automatismus ausgedacht haben.
Ich würde mal davon ausgehen, wenn man sich rein auf die *buntu-Kernel beschränkt, die bei der Standard-Installation (und den nachfolgenden Standard-Updates) installiert werden, daß dann die Partition ausreichend groß ist. Wer "mutwillig" zusätzliche Kernel installiert, die das System per default nicht vorsieht - tja, muss auch damit rechnen, daß der vom System vorgegebene Platz nicht ausreicht - und muss halt ggf. bei der Installation drauf achten, das entsprechend anzupassen.
Ich würde mal davon ausgehen, wenn man sich rein auf die *buntu-Kernel beschränkt, die bei der Standard-Installation (und den nachfolgenden Standard-Updates) installiert werden, daß dann die Partition ausreichend groß ist. Wer "mutwillig" zusätzliche Kernel installiert, die das System per default nicht vorsieht - tja, muss auch damit rechnen, daß der vom System vorgegebene Platz nicht ausreicht - und muss halt ggf. bei der Installation drauf achten, das entsprechend anzupassen.
Ich verwende Ubuntu auf einigen Servern bei mir. Durch die regelmässigen Kernelupdates wird die 500 MB Grenze meiner /boot - Partition regelmässig erreicht, ohne dass ich irgendwelche zusätzliche Kernel installiere.
Manches ist halt nicht perfekt.
ok, daß man gelegentlich mal alte Kernel löschen muss sollte - bei eigener /boot-Partition - klar sein.
Aber "per default" (hab kein *buntu hier gerade, daher nur Vermutung) sollte sich die Anzahl der installierten Kernel nach der Installation (von DVD / Stick, also nicht über Netzwerk) und dem danach folgenden Update des Systems irgendwo im Bereich von "2" befinden - evtl. auch 3, falls es einen ded. Rescue-Kernel gibt (sieht aber nicht so aus).
... wer vom Default-Weg abweicht muss eben mehr Augen auf das System werfen als jemand, der dies nicht tut. So oder so - *buntu vorzuwerfen, /boot "maßlos zu klein" einzurichten trifft mMn. den falschen.
... ich bin mir übrigens sicher, daß das Geheule genau so groß wäre, wenn *buntu einfach x% nehmen würde, weil das wäre dann ja sicher Verschwendung und völlig an der Praxis und Realität vorbei...
Schreibtroll
25.05.16, 11:43
In Mint werden die alten Kernel automatisch gelöscht - die letzten dreie bleiben stehen. Was da nicht gelöscht wird, sind die Header und die schlagen auch ganz schön zu Buche.
Wie das jetzt in Ubu ist - und wie sich das mit selbstgebackenen Kerneln verhält, weiss ich gar nicht. Aber hier in Mint 17.3 funzt der Wurm aus dem Ubu-Wiki immer noch:
# dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge
Vorsicht - es bleibt exakt der laufende stehen. Alle anderen sind futsch.
Was da nicht gelöscht wird, sind die Header und die schlagen auch ganz schön zu Buche.
Da die aber nicht in /boot liegen, hat das wenig bis nichts mit dem aktuellen Problem hier zu tun.
BetterWorld
25.05.16, 16:28
Wer mit kernels spielt, sollte längst die Patitionierungsorgie aus dem Effeff beherrschen
und auch schon einen Plan haben, was er wo wie zu tun gedenkt.
Eher ein "Feind" von *buntu, finde ich den Vorwurf auch ziemlich albern.
Es ist substanzlos und unberechtigt.
kann es sein dass die 1mb partition aufgrund von uefi und gpt boot gemacht wurde?
kann es sein dass die 1mb partition aufgrund von uefi und gpt boot gemacht wurde?
Ja, denn der Partitionierer zeigt beim Intallieren den Typ "biosgrub" an, fdisk "BIOS Boot".
Ich habe jetzt manuell partitioniert und kein Swap, weil 64 GiB RAM ausreichen sollten.
Das /boot liegt in einer separaten Partition weil / verschlüsselt ist.
ohne swap kannst Du halt kein Suspend2Disk nutzen.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.