[Gelöst] Probleme mit mkinitramfs nach Update auf Bookworm

[Felix]

Moin,

meine Linuxkenntnisse sind in letzter Zeit etwas eingerostet, daher verzeiht mir bitte offensichtliche Fehler. Ich habe gerade mein Notebook von der aktuellsten Bullseye Version auf Bookworm geupgraded und das lief im Wesendlichen auch alles sauber durch. Einzig beim Kernel Update gab es ein Problem. Bei der Installation von linux-image-6.1.0-17-amd64 beschwert sich mkinitramfs, dass kein Speicherplatz mehr übrig wäre:

Code: Alles auswählen

Setting up linux-image-6.1.0-17-amd64 (6.1.69-1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-17-amd64
cpio: write error: No space left on device
E: mkinitramfs failure cpio 2
update-initramfs: failed for /boot/initrd.img-6.1.0-17-amd64 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-6.1.0-17-amd64 (--configure):
 installed linux-image-6.1.0-17-amd64 package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-6.1.0-17-amd64 (= 6.1.69-1); however:
  Package linux-image-6.1.0-17-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-6.1.0-17-amd64
 linux-image-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up linux-image-6.1.0-17-amd64 (6.1.69-1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-17-amd64
cpio: write error: No space left on device
E: mkinitramfs failure cpio 2
update-initramfs: failed for /boot/initrd.img-6.1.0-17-amd64 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-6.1.0-17-amd64 (--configure):
 installed linux-image-6.1.0-17-amd64 package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-6.1.0-17-amd64 (= 6.1.69-1); however:
  Package linux-image-6.1.0-17-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-6.1.0-17-amd64
 linux-image-amd64

Ich habe eine verschlüsselte /root Partition, daher habe ich auch eine separate und nicht verschlüsselte /boot Partition. /root ist 462MB groß und aktuell nur mit 59MB belegt (nur der alte Bullseye Kernel mit Ramdisk, sowie Grub). Ansonsten ist die Installation mehr oder weniger Standard. Ich verstehe nicht so ganz das Problem, denn die knapp 400MB sollten für eine Ramdisk ja wohl ausreichen. Ich habe auch testweise den gerade laufenden Kernel deinstalliert (jaja, riskant, aber LiveCD zur Rettung lag bereit und Backup habe ich auch) und dann in der fast leeren Boot-Partition das gleiche Problem gehabt. Anschließend konnte ich auch fehlerfrei den Bullseye Kernel wieder per dpkg -i installieren. Es liegt also auch kein generelles Zugriffsproblem vom Paketmanager auf die Bootpartition vor. Die einzige sinnvolle Erklärung die ich hätte, ist dass die Ramdisk des neuen Kernels beim Erstellen kurzzeitig viel mehr Speicher als final benötigt. Kann das das Problem sein? Dann wundert mich aber, dass ich darüber nichts bei Google finde. Darüber sollten dann ja auch andere mit einer verschlüsselten /root Partition stolpern. Hat jemand eine andere Idee was hier die Ursache sein kann? Ich würde mich über Anregungen sehr freuen.

Gruß, Felix

[schwedenmann]

Hallo


Wie groß genau ist / ?


was sagt ls -l /boot


mfg
schwedenmann

[Felix]

/ ist 375GB groß, davon sind 43GB in Benutzung.

Code: Alles auswählen

root@grobi:~# ls -l /boot
total 48883
-rw-r--r-- 1 root root   236364 Dec 31 16:46 config-5.10.0-27-amd64
-rw-r--r-- 1 root root   259420 Dec 30 10:31 config-6.1.0-17-amd64
drwxr-xr-x 5 root root     1024 Jan 10 17:11 grub
-rw-r--r-- 1 root root 34347422 Jan 10 17:11 initrd.img-5.10.0-27-amd64
drwx------ 2 root root    12288 Oct 22  2019 lost+found
-rw-r--r-- 1 root root       83 Dec 31 16:46 System.map-5.10.0-27-amd64
-rw-r--r-- 1 root root       83 Dec 30 10:31 System.map-6.1.0-17-amd64
-rw-r--r-- 1 root root  7047936 Dec 31 16:46 vmlinuz-5.10.0-27-amd64
-rw-r--r-- 1 root root  8147424 Dec 30 10:31 vmlinuz-6.1.0-17-amd64

[rhHeini]

Wenn dann ist Dein Problem auf Deiner unverschlüsselten /boot-Partition. Da landen die Kernel.

Was sagt df -H?

[thunder11]

Bitte mal die Ausgabe von:

Code: Alles auswählen

~$ du -h /boot

Code: Alles auswählen

df -h

Code: Alles auswählen

lsblk -f

Code: Alles auswählen

ls -l /boot

[schwedenmann]

Hallo



Ist /var eine seperate Partition ?


Ich würde auch estmal

apt autoremove
apt clean

durchführen

mfg
schwedenmann

[MSfree]

No space left on device heißt halt, daß da irgendein Dateisystem voll ist.

Die initrd wird beim Erstellen auch nicht unter /boot erstellt sondern alles relevante wird temporär unter /tmp (soweit ich weiß) angelgt, als cpio-Archiv erstellt und dann komprimiert und erst dann nach /boot kopiert. Man braucht temporär etwa den 6-fachen Plattenplatz, den die eigentliche initrd belgt, in deinem Fall also rund 200MB.

Wie ist denn deine Platteplatzbelegung?

Code: Alles auswählen

df

[Felix]

No space left on device heißt halt, daß da irgendein Dateisystem voll ist.

Die initrd wird beim Erstellen auch nicht unter /boot erstellt sondern alles relevante wird temporär unter /tmp ...

Da dämmert mir was. Danke für die Anregung. Ich habe vor Jahren bei der Umstellung auf eine SSD /tmp und /var/tmp als virtuelle Partitionen im Ram angelegt. Wie ich jetzt sehe sind beide voll ausgelastet. Vermutlich liegt das am zuvor durchgeführten Dist-Upgrade. Ich mach da mal Platz und probiere es dann erneut. Ich melde mich gleich nochmal - vermutlich mit einer Erfolgsmeldung.

Gruß, Felix

[Felix]

So einfach war es dann doch nicht. Ich antworte nachher auf die anderen Vorschläge. Ich muss jetzt erstmal die Kinder ins Bett bringen.

[Felix]

Was sagt df -H?

Bitte mal die Ausgabe von:

Code: Alles auswählen

~$ du -h /boot

Code: Alles auswählen

df -h

Code: Alles auswählen

lsblk -f

Code: Alles auswählen

ls -l /boot

Code: Alles auswählen

root@grobi:~# du -h /boot
12K	/boot/lost+found
4.2M	/boot/grub/locale
2.3M	/boot/grub/fonts
2.1M	/boot/grub/i386-pc
11M	/boot/grub
59M	/boot
root@grobi:~# df -h
Filesystem              Size  Used Avail Use% Mounted on
udev                    7.7G     0  7.7G   0% /dev
tmpfs                   1.6G  9.0M  1.6G   1% /run
/dev/mapper/sda2_crypt  375G   43G  313G  12% /
tmpfs                   7.7G     0  7.7G   0% /dev/shm
tmpfs                   5.0M     0  5.0M   0% /run/lock
tmpfs                   1.0G  116K  1.0G   1% /tmp
tmpfs                   512M  120K  512M   1% /var/log
/dev/sda1               462M   59M  375M  14% /boot
tmpfs                   512M     0  512M   0% /var/spool
tmpfs                   256M     0  256M   0% /var/tmp
tmpfs                   1.6G   32K  1.6G   1% /run/user/1000
root@grobi:~# lsblk -f
NAME           FSTYPE      FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                        
├─sda1         ext4        1.0         b3c5bb2e-17c7-4c15-b554-f49c347431b1  374.4M    13% /boot
└─sda2         crypto_LUKS 2           d2cedf55-392c-4204-aa7c-33efeee26303                
  └─sda2_crypt ext4        1.0         20005d64-a03b-4e4f-b4d9-f0d31e4d64a1  312.7G    11% /
root@grobi:~# ls -l /boot
total 48883
-rw-r--r-- 1 root root   236364 Dec 31 16:46 config-5.10.0-27-amd64
-rw-r--r-- 1 root root   259420 Dec 30 10:31 config-6.1.0-17-amd64
drwxr-xr-x 5 root root     1024 Jan 10 17:11 grub
-rw-r--r-- 1 root root 34347422 Jan 10 17:11 initrd.img-5.10.0-27-amd64
drwx------ 2 root root    12288 Oct 22  2019 lost+found
-rw-r--r-- 1 root root       83 Dec 31 16:46 System.map-5.10.0-27-amd64
-rw-r--r-- 1 root root       83 Dec 30 10:31 System.map-6.1.0-17-amd64
-rw-r--r-- 1 root root  7047936 Dec 31 16:46 vmlinuz-5.10.0-27-amd64
-rw-r--r-- 1 root root  8147424 Dec 30 10:31 vmlinuz-6.1.0-17-amd64

Ich sehe da nix Auffälliges.

Hallo

Ist /var eine seperate Partition ?

Ich würde auch estmal

apt autoremove
apt clean

durchführen

mfg
schwedenmann

/var ist selbst keine eigene Partition, aber /var/tmp und einige andere Unterordner, wie du der Ausgabe von df -h entnehmen kannst. Ein apt autoremove hatte ich direkt nach dem Upgrade bereits ausgeführt. Ich habe es erneut gestartet, aber da gab es nichts zu tun. Wie man an den Ausgaben sehen kann, ist ja offensichtlich auch auf allen Partitionen genug Platz. Ich bin bis hierhin etwas ratlos.

No space left on device heißt halt, daß da irgendein Dateisystem voll ist.

Die initrd wird beim Erstellen auch nicht unter /boot erstellt sondern alles relevante wird temporär unter /tmp (soweit ich weiß) angelgt, als cpio-Archiv erstellt und dann komprimiert und erst dann nach /boot kopiert. Man braucht temporär etwa den 6-fachen Plattenplatz, den die eigentliche initrd belgt, in deinem Fall also rund 200MB.
...

Das ist eine interessante Zusatzinformation. Sowas in der Richtung hatte ich auch vermutet, aber mir war nicht bekannt wo das temporär angelegt wird und auch nicht mehr bewusst, dass ich /tmp und co. als tmpfs im Ram angelegt hatte. /tmp sollte mit 1GB ja groß genug sein, aber /var/tmp ist mit 256MB vielleicht etwas knapp für diese Operation. Ich werde da mal etwas testweise etwas mehr vergeben und mich wieder melden.

Gruß, Felix

[Felix]

Jap, das war's. Vielen Dank für eure Anregungen. /var/tmp war als Partition mit 256MB im RAM etwas zu knapp dimensioniert. Jetzt mit 512MB baut die RamDisk und die Kernelinstallation funktioniert.

@MSfree Vielen Dank für deinen entscheidenden Hinweis!

Gruß, Felix

[dirk11]

Mal eine Frage: Warum macht man das? Ich sehe da exakt keinen Vorteil, außer irgendein "mtbf-voodoo".

[Felix]

Kannst du deine Frage exakter stellen? Warum macht man was? Ich antworte dir gern, aber ich verstehe die Frage nicht.

[cosinus]

/var/tmp sollte keine ramdisk sein, denn es kann vorkommen, dass da Dateien drin landen, die einen Reboot überleben sollen. /tmp kannst du als ramdisk nutzen, aber nicht /var/tmp.

Und /var/log hätte ich auch nicht als ramdisk genommen.

[Felix]

Ich bin vor vielen Jahren auf eine SSD umgestiegen, als das noch gar nicht so richtig üblich war. Damals war das eine der ersten erschwinglichen SSDs von Intel. Ich meine ich habe mich damals einfach an die Empfehlungen von https://wiki.debian.org/SSDOptimization gehalten. Jetzt haben diese sich offensichtlich geändert und man macht nur noch /tmp als reine RamDisk und einige andere Verzeichnisse ggf. als persistente RamDisk. Das ist ein guter Hinweis. Ich werde diese Seite bei Gelegenheit mal durcharbeiten und meine Einstellungen ggf. entsprechend ändern. Andererseits hatte ich jedoch nie ein Problem damit /var/tmp und /var/log nicht persistent zu haben. Klar, wenn ein Problem über einen Reset hinaus besteht, kann es knifflig werden. In diese Lage kam ich allerdings schon locker 10 Jahre nicht mehr und dann habe ich immer noch die Option das kurzzeitig wieder abzuschalten.

Gruß, Felix

[cosinus]

Naja letzenendes musst du da wissen und wenn du das was in /var/log steht nach einem reboot nicht brauchst und keine Fehler hast kannst das auch so lassen.
Andererseits: aktuelle SSDs halten schon sehr viel aus. Wir haben in einer Kiste ne Intel-SSD mit 180 GB seit 6 Jahren Dauerbetrieb, ca. 60 TB wurden geschrieben und das Ding rennt und rennt

[Felix]

Ja, auch meine anfängliche Skepsis gegenüber SSDs ist verflogen. Allerdings habe ich meine 40GB Intel SSD nach mehr als 10 Jahren durch eine viel schnellere von Samsung ersetzt, nicht nur weil sie zu langsam und zu klein war, sondern weil sie tatsächlich anfing Daten zu verlieren. Aber gut, das war eine der ersten kommerziell erhältlichen SSDs, eine Intel X25-M die ich um 2010 herum gekauft haben muss. Ich wette sie hätte schneller aufgegeben, wenn ich nicht von Anfang an auf geringe temporäre Dateizugriffe geachtet hätte. Die Samsung jetzt wird damit sicher schon besser umgehen können.

Gruß, Felix

[MSfree]

Aber gut, das war eine der ersten kommerziell erhältlichen SSDs

Nicht wirklich.

Meine erste SSD hatte noch eine IDE-Schnittstelle und 4GB Größe. Die lief 13 Jahre in meinem Router inklusive Logging und Squid-Cache. Da gab es nie irgendwelche Datenverluste. Irgenwann sind dann ein paar Elkos auf dem Mainboard gestorben und ich mußte auf neue Hardware umsteigen, diesmal mit SATA-SSD.

Allerdings hat man SSDs vor 20 Jahren noch nicht als SSD bezeichnet sondern als CF-Karte.

[Felix]

Gut, dann waren das eben die ersten von mir als sinnvoller Ersatz für eine herkömmliche Festplatte wahrgenommenen SSDs. Wie auch immer. Damals machte man noch viel Panik wegen möglicher Datenverluste bei zu vielen Schreiboperationen. Ich hatte das damals so als Vorsichtsmaßnahme eingerichtet und dann beim Festplattenwechsel einfach die Debian Installation auf die neue SSD gespiegelt oder auch neu installiert und die Einstellungen übernommen. Ich weiß es schlicht nicht mehr, ist ja aber auch egal. Ich schau mir bei Gelegenheit an ob diese Vorsichtsmaßnahmen allen noch nötig und sinnvoll sind. Danke für eure Hinweise!

Gruß, Felix

[MSfree]

Ich schau mir bei Gelegenheit an ob diese Vorsichtsmaßnahmen allen noch nötig und sinnvoll sind.

Meiner Meinung nach waren diese "Vorsichtsmaßnahmen" noch nie nötig. OK, ich hatte vor 20 Jahren meine erste SSD auch noch mit noatime gemountet und /proc/sys/vm/laptop_mode auf 1 gestellt. Mehr "Optimierungen" habe ich aber nie vorgenommen.

[dirk11]

Kannst du deine Frage exakter stellen? Warum macht man was? Ich antworte dir gern, aber ich verstehe die Frage nicht.

Guten Morgen! Na klar kann ich das präzisieren:
- Warum erstellt man die im RAM, gut, das ist klar, aber notwendig war es im Grunde noch nie.
Wichtiger für mich:
- Warum erstellt man die getrennt und dann noch die eine so klein?
Wenn ich eines vor 20 Jahren bei Linux gelernt habe, dann ist das, dass man meiner Ansicht nach nicht so klein-klein partitioniert. Damals hat man auch noch /usr, /home und diverses anderes Zeug in separate Partitionen gelegt. Das hat eigentlich ständig dazu geführt, dass irgendeine Partition zu klein war. Wenn nicht im laufenden Betrieb, dann doch spätestens bei einem Release-Upgrade.

[Felix]

Tja, damals ist halt ca. 14 Jahre her. Da waren die Dimensionen noch etwas kleiner. Wahrscheinlich habe ich damals einen Kompromiss zwischen verfügbarem Ram und den Empfehlungen von wiki.debian.org gewählt. Ich habe das halt nie wieder angepasst und tatsächlich bin ich jetzt das erste Mal über ein Problem damit gestolpert. So schlimm kann die Dimensionierung also nicht gewesen sein.

Ich schwanke gerade noch zwischen ändern dieses Verhaltens und einfach alles so lassen. Alles so lassen hat mehr als 1 Jahrzehnt funktioniert, andererseits wird man zwangsweise irgendwann wieder auf ein Größenproblem stoßen. Daher tendiere ich dazu diese RamDisks rauszuwerfen und wieder zum Standardweg zurückzukehren. Ich frage mich nur, ob es damit getan ist, die entsprechenden 4 Einträge aus /etc/fstab zu entfernen. Kann mir vielleicht jemand noch die Frage beantworten, wie Debian heute die sich anhäufenden Daten in /tmp /var/tmp, /var/spool und /var/log managed? Muss ich mich darum selbst kümmern, oder sollte da schon irgendein Job laufen, der die 4 Ordner regelmäßig aufräumt? Ich hab das halt schon Ewigkeiten so laufen und davor war ja alles anders als heute.

Gruß, Felix

[MSfree]

Tja, damals ist halt ca. 14 Jahre her. Da waren die Dimensionen noch etwas kleiner. Wahrscheinlich habe ich damals einen Kompromiss zwischen verfügbarem Ram und den Empfehlungen von wiki.debian.org gewählt.

Ich habe diese Empfehlungen nie verstanden, die waren in meinem Augen schon immer Unfug. Auf eine Festplatte bzw. SSD gehören meiner Meinung nach maximal zwei Partitionen. Eine für die EFI-Partition, die Debian mit 500MB auch schwachsinnig groß vorgibt, das Minumum von 50MB reicht für die 4MB, die darauf gespeichert werden, mehr als aus. Der Rest ist eine große Partition, die auf / gemountet wird. Die Daten können sich so am besten den Speicherort suchen und man bekommt keine Probleme mit einzeln vollgelaufenen Partitionen. Natürlich kann so eine einzige Partition auch voll laufen, es ist aber einfacher, nur eine Partition zu überwachen und ggfls. zu bereinigen, als sich um ein Haufen Partitionen zu kümmern.

Im Multiuserbetrieb hilft eine eigene /home-Partition auch nicht gegen undisziplinierte Benutzer. Da gibt es bessere Mittel, z.B. Quota und das Reservieren von typischerweise 5% der Partitionsgröße für root.

Ramdisks halte ich für entbehrlich. Einerseits cacht der Kernel alle Plattezugriffe, so daß durch den Cache ähnlich hohe Zugriffsgeschwindigkeiten erzielbar sind wie mit einer RAM-Disk. Andererseits beschränkt man den Hauptspeicher, so daß der Kernel schneller in den furchtbar lahmen Swapspace auslagern muß.

Es mag ja ganz vereinzelt Sonderfälle geben, wo RAM-Disks die Geschwindigkeit erhöhen können. Der Normalfall ist das aber nicht.

Daher tendiere ich dazu diese RamDisks rauszuwerfen und wieder zum Standardweg zurückzukehren. Ich frage mich nur, ob es damit getan ist, die entsprechenden 4 Einträge aus /etc/fstab zu entfernen.

Ja, das reicht aus. Wenn du auf die Verzeichnisse keine RAM-Disks mountest, wird halt direkt auf das Dateisystem zugegriffen.

[Felix]

Ich stimme dir bei allem zu. Aber ich bin auch immer ganz gut damit gefahren mich an die offiziellen Empfehlungen zu halten und nicht anzunehmen, dass ich alles besser wüsste. Gerade bei offiziellen Debian Seiten habe ich schon viel Vertrauen, dass die Informationen da fundiert sind. Wie auch immer, heute wissen wir es dann doch besser und geschadet hat es in meinem Fall ja auch nicht wirklich. Ok, ich werde das aus der fstab werfen. Dass dann automatisch wieder alles auf der /root Partition gemacht wird, hatte ich vermutet, danke für die Bestätigung. Meine Frage war aber auch, ob sich dann auch sofort automatisch jemand darum kümmert, dass die Daten sich da nicht ewig anhäufen. Meinem Verständnis nach sollten veraltete Daten aus /tmp /var/tmp und /var/log in halbwegs regelmäßigen Abständen gelöscht werden. Ich könnte das einfach in meinem Skript zum monatlichen Backup als Vorbereitungsschritt vorsehen, aber das wäre ja unnötig, wenn zum Beispiel logrotate oder so sich schon um alles kümmert.

Gruß, Felix

[MSfree]

Meine Frage war aber auch, ob sich dann auch sofort automatisch jemand darum kümmert, dass die Daten sich da nicht ewig anhäufen. Meinem Verständnis nach sollten veraltete Daten aus /tmp /var/tmp und /var/log in halbwegs regelmäßigen Abständen gelöscht werden.

Was /tmp und /var/tmp angeht, da gibt es systemd-tmpfiles-clean.timer. Der sorgt meines Wissens dafür, daß aufgeräumt wird.

/var/log läßt sich mit logrotate ganz gut im Zaum halten. Das sorgt dafür, daß Logdateien nach einer gewissen Zeit oder nach erreichen einer gewissen Größe umbenannt werden und neue Dateien angelegt werden. Die alten Dateien werden überlicherweise noch komprimiert und die Anzahl der Dateien, die vorgehalten werden ist auch begrenzt. Das läßt sich auch gut auf die eigenen Bedürfnisse anpassen (die Defaults gefallen mir nicht).