Fehlermeldung bei Upgrade von 10.11 auf 10.12

[Oystercatcher]

Hallo,

als ich heute ein "apt-get update" gefolgt von einem "apt-get full-upgrade" durchführte, bekam ich beim Installieren des aktuellen Kernels folgende Fehlermeldung:

Code: Alles auswählen

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-4.19.0-20-amd64 with 1.
dpkg: Fehler beim Bearbeiten des Paketes initramfs-tools (--configure):
 »installiertes initramfs-tools-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

Trotz der Fehlermeldung lieferte ein anschließendes "uname -a":

Code: Alles auswählen

Linux PC1 4.19.0-20-amd64 #1 SMP Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux

Ich habe per "apt-get autoremove" Platz geschaffen und das Paket "linux-image-4.19.0-18-amd64" entfernt. Danach habe ich "apt-get update" und "apt-get full-upgrade" nochmals durchlaufen lassen, wobei aber keine neuen Pakete installiert wurden.

Wieso wurde der Kernel trotz der Fehlermeldung bzw. des fehlenden freien Speichers anscheinend doch korrekt installiert? Oder verstehe ich die Fehlermeldung falsch?

Danke!

[Livingston]

Der Fehler erfolgte bei Erzeugung der Datei /boot/initrd.img-4.19.0-20-amd64, nachdem der Kernel gerade noch Platz in /boot gefunden hatte.

[Oystercatcher]

Erstellt wurde die Datei, "ls" sagt:

Code: Alles auswählen

203 config-4.19.0-19-amd64         12 lost+found
  203 config-4.19.0-20-amd64       3361 System.map-4.19.0-19-amd64
    1 grub                         3361 System.map-4.19.0-20-amd64
55645 initrd.img-4.19.0-19-amd64   5198 vmlinuz-4.19.0-19-amd64
55588 initrd.img-4.19.0-20-amd64   5198 vmlinuz-4.19.0-20-amd64

Sie ist allerdings kleiner als die ältere -19 Version. Ob das so normal ist kann ich nicht sagen.
Wenn ich richtig gegoogelt habe, sind die initrd.* Dateien relativ elementar, mein Debian lässt sich aber einwandfrei starten und zeigt auch so keine Auffälligkeiten.
Wie sollte ich jetzt weiter vorgehen?

[rhHeini]

Check mal den Platz auf Deinen Partitionen mit

Code: Alles auswählen

# df -H

Rolf

[Oystercatcher]

Platz ist da:

Code: Alles auswählen

Dateisystem                      Größe Benutzt Verf. Verw% Eingehängt auf
udev                              4,1G       0  4,1G    0% /dev
tmpfs                             825M    9,6M  815M    2% /run
/dev/mapper/oyster--deb--vg-root  483G     83G  379G   18% /
tmpfs                             4,2G       0  4,2G    0% /dev/shm
tmpfs                             5,3M    4,1k  5,3M    1% /run/lock
tmpfs                             4,2G       0  4,2G    0% /sys/fs/cgroup
/dev/sda1                         247M    146M   89M   63% /boot
tmpfs                             825M     17k  825M    1% /run/user/1000

Wie oben schon erwähnt: Ich habe nach der Fehlermeldung einen alten Kernel entfernt.

[rhHeini]

Na, Dein /boot ist sehr sparsam ausgestattet, ich sach mal zu klein für heutige Speicherplatzverhältnisse. Da geht gerade noch ein Kernel rein, dann musst Du schon wieder aufräumen. Wenns geht mach den mal mindestens 512M gross.

Ich hab hier mit den 6 neuesten Kerneln knapp 500MB belegt, aber keine Platzprobleme weil ich vorausschauend /boot 2048M gegönnt habe.

Rolf

[MSfree]

Da geht gerade noch ein Kernel rein,

Das kann man so nicht verallgemeinern. Der 5.10er Kernel von Bullseye belegt bei mir etwa 40MB in /boot, 35MB davon sind initrd. Der 4.19er von Buster hat meiner Erinnerung nach etwas mehr Platz benötigt. Die Größe der initrd hängt aber auch davon ab, welche Kernelmodule integriert werden, proprietäre Graphikmodule können die initrd aufblähen.

Ich hab hier mit den 6 neuesten Kerneln knapp 500MB belegt

Und wozu braucht man 6 Kernel? Natürlich wird bei der Installation eines neuen Kernels der zum Zeitpunkt der Installation laufende Kernel aufgehoben, alle anderen kann man löschen. Sollte der neue Kernel dann nicht booten, hat man die Rückfallmöglichkeit, den vorherigen Kernel zu booten. Es ergibt aber keine Sinn, noch mehr Kernel aufzuheben, zumal jeder Kernel auch noch rund 300MB in /lib/moduiles belegt, also 1.8GB in deinem Fall.

Man braucht temporär Platz für drei Kernel in /boot: den Vorgänger des aktuell laufenden, den laufenden selbst und den neu zu installierenden, und dafür müßten 250MB auch heutzutage noch reichen.

[rhHeini]

Du kannst Deinem Minimalismus gerne weiter frönen. Die Kernel "brauche" ich nicht unbedingt, die sammeln sich halt im Laufe der Updates so an. Und da ich den Platz auf meiner SSD großzügig geplant habe muss ich auch nicht nach jedem Update sofort mit Besen und Schaufel jedem überflüssigen Bit hinterherjagen. Ich mach das dann wenn ich Zeit und Muße dazu habe. So ist das Leben einfach entspannter ....

Schönen Sonntag, Rolf

[Oystercatcher]

Entschuldigt bitte die späte Rückmeldung, ich war diese Woche offline.

Man braucht temporär Platz für drei Kernel in /boot: den Vorgänger des aktuell laufenden, den laufenden selbst und den neu zu installierenden, und dafür müßten 250MB auch heutzutage noch reichen.

Das war eigentlich auch mein Ansatz, hat aber komischerweise bei diesem Update mal nicht funktioniert.

Was ich mich jetzt aber immer noch frage: Es ist ja anscheinend beim Erstellen von /boot/initrd.img-4.19.0-20-amd64 etwas schief gelaufen. Trotzdem startet und läuft mein Debian bislang einwandfrei. Kann ich /boot/initrd.img-4.19.0-20-amd64 auf korrekten Inhalt prüfen? Falls nicht, kann / sollte ich den Vorgang wiederholen um sicher zu gehen, dass hier nicht doch irgendwo etwas klemmt?

[Blackbox]

Falls nicht, kann / sollte ich den Vorgang wiederholen um sicher zu gehen, dass hier nicht doch irgendwo etwas klemmt?

Was bezweckst du damit?
Oder findest du die Meldung so schön und möchtest diese noch einmal präsentiert bekommen?

Du könntest alte Kernel deinstallieren, um Platz auf deiner /boot/ Partition zu schaffen.
Erst danach wird es dir möglich sein, einen neueren Kernel zu installieren.

[Oystercatcher]

Du könntest alte Kernel deinstallieren, um Platz auf deiner /boot/ Partition zu schaffen.
Erst danach wird es dir möglich sein, einen neueren Kernel zu installieren.

Kann es sein, dass Du den bisherigen Gesprächsverlauf nicht gelesen hast?
Der aktuelle Kernel läuft, der vorletzte Kernel wurde deinstalliert. Es geht mir hier um die Konsistenz von /boot/initrd.img-4.19.0-20-amd64

[rhHeini]

Bei Bedarf neu bauen lassen mit:

Code: Alles auswählen

# update-initramfs -u -k all

[Blackbox]

Es geht mir hier um die Konsistenz von /boot/initrd.img-4.19.0-20-amd64

Das neu bauen der initramdisk wird die Platzprobleme innerhalb von /boot/ nicht lösen.
Helfen würde aber die Partition /boot/ zu vergrößern.
Dann klappt auch das Kernelupdate, ohne das, das Erstellen der initramdisk wegen Platzmangels abgebrochen wird.

[Oystercatcher]

Bei Bedarf neu bauen lassen mit:

Code: Alles auswählen

# update-initramfs -u -k all

Danke, werde ich bei Bedarf so umsetzten. Nun müsste ich nur noch wissen wie ich herausfinden kann, ob Bedarf besteht
Wenn ich das Prinzip von initramfs richtig verstanden habe, handelt es sich dabei um ein komprimiertes Archiv. Für den Fall das bei dessen Erstellung plötzlich der Speicher ausgehen sollte (was ja hier laut Fehlermeldung so passiert ist) und das Archiv somit nicht vollständig geschrieben werde konnte, sollte es doch eigentlich überhaupt nicht zu öffnen sein, oder etwa doch?

Das neu bauen der initramdisk wird die Platzprobleme innerhalb von /boot/ nicht lösen.
Helfen würde aber die Partition /boot/ zu vergrößern.
Dann klappt auch das Kernelupdate, ohne das, das Erstellen der initramdisk wegen Platzmangels abgebrochen wird.

Es gibt doch gar keine Platzprobleme mehr. Diese bestanden als ich zwei alte Kernel inkl. der beiden dazugehörigen initramfs innerhalb /boot/ hatte und dann einen dritten hinzufügen wollte. Wie ich bereits erwähnte: ich haben nach der Fehlermeldung den ältesten Kernel entfernt. Momentan habe ich also den aktuellen Kernel inkl. (möglicherweise nicht vollständiger) initramfs sowie den vorherigen inkl. initramfs.
Dass das Speicherplatz Problem bei einem zukünftigen Update auf den dann aktuellen Kernel erneut auftreten kann steht natürlich auf einem anderen Blatt.

[rhHeini]

Wenn der Rechner bootet hast Du kein Problem. Dann ist die initrd ok.

[Oystercatcher]

Das war auch meine Vermutung, danke für die Bestätigung!

Eine Frage noch interessenshalber zur /boot Größe:
Die Installation ist jetzt schon relativ alt und ich kann mich nicht mehr allzu genau an den Installationsvorgang erinnern. Ich meine jedoch, dass ich damals für /boot die vorgeschlagene Größe übernommen habe. Woran macht der Installer diese fest? Oder anders gefragt: ist der Platzbedarf der Kernel seit 10.0 so dramatisch gewachsen, dass jetzt drei Kernel parallel schon knapp sind?

[rhHeini]

Der Installer macht die Partitionen automatisch zu klein für heutige Verhältnisse. Im Laufe der Zeit wurden auch die Kernel grösser, und der Installer macht das immer noch genauso wie vor vielen Jahren.

Ich installiere von Anfang an mit manueller Partitionierung, weil mir die Automatismen noch nie sympatisch waren. Das hab ich eigentlich über meine ganze PC-Historie so gehalten. Einem separaten /boot spendiere ich seit Jahren immer 2048MByte, und hab noch nie Platzprobleme gehabt. Die Minimalisten schreien natürlich Aua. Das ist mir aber egal, es gibt keine reelen Grund bei den heutigen Mediengrößen und -preisen da zu sparen.