update-initramfs & No space left on device

[empty_string]

Hallo,

seit dem letzten upgrade bzw. dist-upgrade erhalte ich bei jeglicher apt Operation den Fehler

Code: Alles auswählen

apt upgrade
Summary:                                            
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
  2 nicht vollständig installiert oder entfernt.
  Space needed: 0 B / 22,3 GB available

Continue? [J/n] y
plymouth (24.004.60-2) wird eingerichtet ...
update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
zstd: error 70 : Write error : cannot write block : No space left on device 
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
dpkg: Fehler beim Bearbeiten des Paketes plymouth (--configure):
 »installiertes post-installation-Skript des Paketes plymouth«-Unterprozess gab den Fehlerwert 1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von plymouth-label:
 plymouth-label hängt ab von plymouth (= 24.004.60-2); aber:
  Paket plymouth ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes plymouth-label (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
 plymouth
 plymouth-label
Error: Sub-process /usr/bin/dpkg returned an error code (1)

Code: Alles auswählen

df -h
Dateisystem              Größe Benutzt Verf. Verw% Eingehängt auf
udev                      7,6G       0  7,6G    0% /dev
tmpfs                     1,6G    1,7M  1,6G    1% /run
/dev/mapper/dux--vg-root   28G    5,2G   21G   20% /
tmpfs                     7,7G       0  7,7G    0% /dev/shm
efivarfs                  268K    222K   41K   85% /sys/firmware/efi/efivars
tmpfs                     5,0M       0  5,0M    0% /run/lock
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-journald.service
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-udev-load-credentials.service
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-tmpfiles-setup-dev-early.service
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-sysctl.service
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-tmpfiles-setup-dev.service
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-cryptsetup@nvme0n1p3_crypt.service
/dev/nvme0n1p2            456M    366M   66M   85% /boot
tmpfs                     7,7G    4,0K  7,7G    1% /tmp
/dev/mapper/dux--vg-home  887G    342G  501G   41% /home
/dev/nvme0n1p1            511M    4,4M  507M    1% /boot/efi
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-tmpfiles-setup.service
tmpfs                     1,6G     56K  1,6G    1% /run/user/1000
tmpfs                     1,0M       0  1,0M    0% /run/credentials/getty@tty1.service

Code: Alles auswählen

ls -lsa /boot/
insgesamt 361039
     1 drwxr-xr-x  5 root root      1024 24. Jul 20:18 .
     4 drwxr-xr-x 18 root root      4096 19. Jul 16:35 ..
   273 -rw-r--r--  1 root root    275522  7. Jul 20:58 config-6.9.8-amd64
   273 -rw-r--r--  1 root root    275522 13. Jul 17:45 config-6.9.9-amd64
     4 drwx------  3 root root      4096  1. Jan 1970  efi
     1 drwxr-xr-x  5 root root      1024 21. Jul 19:24 grub
 84353 -rw-r--r--  1 root root  86036687 17. Jul 17:54 initrd.img-6.9.8-amd64
257336 -rw-r--r--  1 root root 262480818 21. Jul 19:04 initrd.img-6.9.9-amd64
    12 drwx------  2 root root     12288 16. Okt 2022  lost+found
     1 -rw-r--r--  1 root root        83  7. Jul 20:58 System.map-6.9.8-amd64
     1 -rw-r--r--  1 root root        83 13. Jul 17:45 System.map-6.9.9-amd64
  9392 -rw-r--r--  1 root root   9578432  7. Jul 20:58 vmlinuz-6.9.8-amd64
  9388 -rw-r--r--  1 root root   9574336 13. Jul 17:45 vmlinuz-6.9.9-amd64

Ich habe versuchsweise den 6.9.8 Kernel verschoben und update-initramfs -u ergibt dieselbe Fehlermeldung.

Es werden diverse alte Kernel angezeigt:

Code: Alles auswählen

dpkg -l | grep linux-image
rc  linux-image-5.19.0-1-amd64        5.19.6-1                             amd64        Linux 5.19 for 64-bit PCs (signed)
rc  linux-image-5.19.0-2-amd64        5.19.11-1                            amd64        Linux 5.19 for 64-bit PCs (signed)
rc  linux-image-6.0.0-2-amd64         6.0.3-1                              amd64        Linux 6.0 for 64-bit PCs (signed)
ic  linux-image-6.0.0-3-amd64         6.0.7-1                              amd64        Linux 6.0 for 64-bit PCs (signed)
ic  linux-image-6.0.0-4-amd64         6.0.8-1                              amd64        Linux 6.0 for 64-bit PCs (signed)
ic  linux-image-6.0.0-5-amd64         6.0.10-1                             amd64        Linux 6.0 for 64-bit PCs (signed)
ic  linux-image-6.0.0-6-amd64         6.0.12-1                             amd64        Linux 6.0 for 64-bit PCs (signed)
rc  linux-image-6.1.0-1-amd64         6.1.4-1                              amd64        Linux 6.1 for 64-bit PCs (signed)
rc  linux-image-6.1.0-2-amd64         6.1.7-1                              amd64        Linux 6.1 for 64-bit PCs (signed)
rc  linux-image-6.1.0-3-amd64         6.1.8-1                              amd64        Linux 6.1 for 64-bit PCs (signed)
rc  linux-image-6.1.0-5-amd64         6.1.12-1                             amd64        Linux 6.1 for 64-bit PCs (signed)
rc  linux-image-6.1.0-6-amd64         6.1.15-1                             amd64        Linux 6.1 for 64-bit PCs (signed)
rc  linux-image-6.1.0-7-amd64         6.1.20-2                             amd64        Linux 6.1 for 64-bit PCs (signed)
rc  linux-image-6.1.0-8-amd64         6.1.25-1                             amd64        Linux 6.1 for 64-bit PCs (signed)
rc  linux-image-6.1.0-9-amd64         6.1.27-1                             amd64        Linux 6.1 for 64-bit PCs (signed)
rc  linux-image-6.3.0-1-amd64         6.3.7-1                              amd64        Linux 6.3 for 64-bit PCs (signed)
rc  linux-image-6.4.0-1-amd64         6.4.4-2                              amd64        Linux 6.4 for 64-bit PCs (signed)
rc  linux-image-6.4.0-2-amd64         6.4.4-3                              amd64        Linux 6.4 for 64-bit PCs (signed)
rc  linux-image-6.4.0-3-amd64         6.4.11-1                             amd64        Linux 6.4 for 64-bit PCs (signed)
rc  linux-image-6.5.0-1-amd64         6.5.3-1                              amd64        Linux 6.5 for 64-bit PCs (signed)
rc  linux-image-6.5.0-2-amd64         6.5.6-1                              amd64        Linux 6.5 for 64-bit PCs (signed)
rc  linux-image-6.5.0-3-amd64         6.5.8-1                              amd64        Linux 6.5 for 64-bit PCs (signed)
rc  linux-image-6.5.0-4-amd64         6.5.10-1                             amd64        Linux 6.5 for 64-bit PCs (signed)                                                                                                      
rc  linux-image-6.5.0-5-amd64         6.5.13-1                             amd64        Linux 6.5 for 64-bit PCs (signed)                                                                                                      
rc  linux-image-6.6.13-amd64          6.6.13-1                             amd64        Linux 6.6 for 64-bit PCs (signed)                                                                                                      
rc  linux-image-6.6.15-amd64          6.6.15-2                             amd64        Linux 6.6 for 64-bit PCs (signed)                                                                                                      
rc  linux-image-6.7.12-amd64          6.7.12-1                             amd64        Linux 6.7 for 64-bit PCs (signed)                                                                                                      
rc  linux-image-6.8.12-amd64          6.8.12-1                             amd64        Linux 6.8 for 64-bit PCs (signed)                                                                                                      
rc  linux-image-6.9.7-amd64           6.9.7-1                              amd64        Linux 6.9 for 64-bit PCs (signed)                                                                                                      
ii  linux-image-6.9.8-amd64           6.9.8-1                              amd64        Linux 6.9 for 64-bit PCs (signed)                                                                                                      
ii  linux-image-6.9.9-amd64           6.9.9-1                              amd64        Linux 6.9 for 64-bit PCs (signed)                                                                                                      
ii  linux-image-amd64                 6.9.9-1                              amd64        Linux for 64-bit PCs (meta-package)   

Aber leider kann ich kein apt purge linux-image-XXX ausführen, ebenso dieselbe Fehlermeldung.

Über einen Lösungsvorschlag würde ich mich sehr freuen, vielen Dank!

LG
empty_string

[rhHeini]

Deine /boot-Partition ist zu klein. Minimalisten behaupten zwar es wäre bei diesen 456M Platz für 5 oder 6 Kernel, wie man sieht reicht es aber jetzt nicht mehr. Der Kernel schafft es nicht mehr die 6.9.9 zu komprimieren.

Hast Du noch hinten auf der SSD 2048M=2G Platz für eine neue Boot-Partition? Ich partitiniere nur noch manuell und spendiere derzeit 2G für meine /boot.

[cosinus]

Deine /boot-Partition ist zu klein.

Könnte man in diesem Notfall nicht manuell zB initrd.img-6.9.8-amd64 nach /var/backups verschieben und dann apt upgrade nochmal laufen lassen?

[tobo]

Also dieser Unterschied in der Größe kann ja irgendwie nicht sein:

Code: Alles auswählen

 84353 -rw-r--r--  1 root root  86036687 17. Jul 17:54 initrd.img-6.9.8-amd64
257336 -rw-r--r--  1 root root 262480818 21. Jul 19:04 initrd.img-6.9.9-amd64

Mal unter der Voraussetzung, dass die Größe beim 6.9.9 falsch ist und du den 6.9.8 am Laufen hast: Wenn ja und du den 6.9.9 nicht über die Paketverwaltung löschen kannst, dann verschieb' das Teil halt mal. Dann `apt purge ~c' und `apt --purge autoremove' sehenden Auges und dann den 6.9.9 entfernen und dann das System aktualisieren.

[MSfree]

Mal unter der Voraussetzung, dass die Größe beim 6.9.9 falsch ist ...

Mal zum Vergleich:

Code: Alles auswählen

ls -l /boot/
total 105545
-rw-r--r-- 1 root root   275522 Jul  7 20:58 config-6.9.8-amd64
-rw-r--r-- 1 root root   275522 Jul 13 17:45 config-6.9.9-amd64
drwx------ 3 root root      512 Jan  1  1970 efi
drwxr-xr-x 5 root root     4096 Jul 22 17:12 grub
-rw-r--r-- 1 root root 44181470 Jul 14 11:43 initrd.img-6.9.8-amd64
-rw-r--r-- 1 root root 44164064 Jul 22 17:12 initrd.img-6.9.9-amd64
-rw-r--r-- 1 root root       83 Jul  7 20:58 System.map-6.9.8-amd64
-rw-r--r-- 1 root root       83 Jul 13 17:45 System.map-6.9.9-amd64
-rw-r--r-- 1 root root  9578432 Jul  7 20:58 vmlinuz-6.9.8-amd64
-rw-r--r-- 1 root root  9574336 Jul 13 17:45 vmlinuz-6.9.9-amd64

Bei mir sind die beiden initrds praktisch gleich groß und vor allem nur halb so groß wie die initrd.img-6.9.8-amd64 des OP.

Da würde mich wirklich interessieren, was da alles in die initrd gepackt wurde, daß die 250MB groß wird. Nvidia-Treiber?

[cosinus]

Meine von siduction sind aber auch rel. fett:

Code: Alles auswählen

-rw-r--r--  1 root root 248733451 2024-07-19 02:44 initrd.img-6.9.10-1-siduction-amd64
-rw-r--r--  1 root root 248732672 2024-07-19 02:44 initrd.img-6.9.9-1-siduction-amd64

Die in einem Debian stable auf einem älteren Desktop-PC sind ziemlich schlank:

Code: Alles auswählen

-rw-r--r--  1 root root 40578419 2024-07-01 13:09 initrd.img-6.1.0-22-amd64
-rw-r--r--  1 root root 40585162 2024-07-18 16:08 initrd.img-6.1.0-23-amd64

[KBDCALLS]

Deine /boot-Partition ist zu klein. Minimalisten behaupten zwar es wäre bei diesen 456M Platz für 5 oder 6 Kernel, wie man sieht reicht es aber jetzt nicht mehr. Der Kernel schafft es nicht mehr die 6.9.9 zu komprimieren.

Hast Du noch hinten auf der SSD 2048M=2G Platz für eine neue Boot-Partition? Ich partitiniere nur noch manuell und spendiere derzeit 2G für meine /boot.

Hab ich aber auch schon drauf gehabt, Nur meine initrds sind nur ca. 14 MB groß. Mich hat schon seit langem gestört das die im laufe der Kernelentwicklung immer fetter wurden. Was garnicht notwendig ist.

Standardmäßig steht in der initrd.conf MODULES=most und ich hab das in MODULES=dep geändert

• Code: Alles auswählen

  -rw-r--r-- 1 root root 270K 19. Jul 18:55 config-6.9.10-amd64
  -rw-r--r-- 1 root root 270K 13. Jul 17:45 config-6.9.9-amd64
  drwxr-xr-x 5 root root 1,0K 22. Jul 18:37 grub
  -rw-r--r-- 1 root root  14M 22. Jul 18:37 initrd.img-6.9.10-amd64
  -rw-r--r-- 1 root root  14M 18. Jul 15:19 initrd.img-6.9.9-amd64
  drwx------ 2 root root  12K 25. Sep 2017  lost+found
  -rw-r--r-- 1 root root   83 19. Jul 18:55 System.map-6.9.10-amd64
  -rw-r--r-- 1 root root   83 13. Jul 17:45 System.map-6.9.9-amd64
  -rw-r--r-- 1 root root 9,2M 19. Jul 18:55 vmlinuz-6.9.10-amd64
  -rw-r--r-- 1 root root 9,2M 13. Jul 17:45 vmlinuz-6.9.9-amd64
  

[MSfree]

Standardmäßig steht in der initrd.conf MODULES=most und ich hab das in MODULES=dep geändert

Wenn man eine eigene Boot-Partition hat, spielt es kaum eine Rolle, ob die Partition zu 5% gefüllt wird oder zu 70%. Der Platz ist sowieso für nichts anderes nutzbar. So eine Partition unnötig groß anzulegen, ist verschwendeter Platz. Eine eigene Boot-Partition ist ohnehin nur dann nötig, wenn man das System verschlüsseln will. Bei unverschlüsselten Systemen ist eine eigene /boot-Partition komplett überflüssig.

Bei MODULES=dep ist mir nicht klar, wie bestimmt wird, welche Module in die initrd gesteckt werden. Wird da mit lsmod bestimmt, welche Module der Kernel geladen hat, um die Module zu bestimmen, die in die initrd sollen?

Wie man auf eine 250MB große initrd kommt, ist mir ebenfalls unklar, denn mit der Standardeinstellung MODULES=most, die ich hier verwende, werden meine initrds nur rund 40MB (Bookworm/gzip) bzw. 44MB (Trixie/zstd) groß.

[KBDCALLS]

Bei most werden fasst alle Filesystem und Hardwaremodule reingepackt. Bei dep wird anhand der geladenen Module des laufenden System besimmt was rein kommt. Und selbt 86 MB ist eindeutig zu groß.

[cosinus]

Standardmäßig steht in der initrd.conf MODULES=most und ich hab das in MODULES=dep geändert

Mein du nicht eher diese Datei?

Code: Alles auswählen

/etc/initramfs-tools/initramfs.conf

Hab jetzt mal mit modules=dep ne neue initrd gebaut. Die ist immer noch 200 MB groß

Code: Alles auswählen

-rw-r--r--  1 root root 202475K 2024-07-25 12:59 initrd.img-6.9.10-1-siduction-amd64
-rw-r--r--  1 root root 243309K 2024-07-25 08:50 initrd.img-6.9.10-1-siduction-amd64.backup

[MSfree]

Hab jetzt mal mit modules=dep ne neue initrd gebaut. Die ist immer noch 200 MB groß

Und was steckt da alles drin? lsinitramfs ist dein Freund.

Ich habe ja oben schon die Vermutung geäussert, daß es an Nvidia liegen kann. Das Nvidia-Treiberpaket ist über 200 MB groß.

[cosinus]

Äh ja. Den Part mit lsinitramfs von dir hab ich gekonnt überlesen.
Und ja, du hast wohl Recht, da sind solche Klopper drin wie

Code: Alles auswählen

-rw-r--r--   1 root     root     38061600 Jul 14 22:22 usr/lib/firmware/nvidia/ga103/gsp/gsp-535.113.01.bin
-rw-r--r--   1 root     root     38061600 Jul 14 22:22 usr/lib/firmware/nvidia/ga104/gsp/gsp-535.113.01.bin

[rhHeini]

Wenn man eine eigene Boot-Partition hat, spielt es kaum eine Rolle, ob die Partition zu 5% gefüllt wird oder zu 70%. Der Platz ist sowieso für nichts anderes nutzbar. So eine Partition unnötig groß anzulegen, ist verschwendeter Platz. Eine eigene Boot-Partition ist ohnehin nur dann nötig, wenn man das System verschlüsseln will. Bei unverschlüsselten Systemen ist eine eigene /boot-Partition komplett überflüssig.

Genau das meine ich mit "unnötigem" Minimalismus. Der OP hat offensichtlich zumindest ein LVM, oder auch verschlüsselt, und auch ich setze keinen Rechner mehr auf ohne Verschlüsselung. Deswegen ein separates /boot. Eine 2G grosse /boot ist bei den heutigen Festplattengrößen echt angemessen und keine Verschwendung. Damit geht man eben solchen Problemen auch weitgehend aus dem Weg.

Was ähnliches gilt für die ESP.

[empty_string]

Okay vielen Dank für Eure Antworten, konnte heute erst testen.

Heute hat es mir nach dem apt update den 6.9.10-amd64 Kernel angezeigt, den es aber erwartungsgemäß auch nicht installieren konnte.

Jetzt habe ich alle Dateien vom 6.9.8 und 6.9.9 manuell aus /boot/ raus verschoben und eine /etc/initramfs-tools/conf.d/modules angelegt mit dem einzigen Eintrag MODULES=dep. (Das hatte ich hier gefunden.)
In der /etc/initramfs-tools/initramfs.conf steht allerdings noch MODULES=most.

Bin mir nicht sicher ob das Vorgehen richtig war, aber zum Glück haben apt upgrade & update-initramfs -u & update-grub2 funktioniert und reboot war erfolgreich.
(Es gab eine Meldung: File descriptor 28 (/memfd:pulseaudio (deleted)) leaked on vgs invocation. Parent PID 41788: /usr/sbin/grub-probe)

Boot sieht jetzt auch besser aus.

Code: Alles auswählen

ls -lsah /boot/
insgesamt 36M
1,0K drwxr-xr-x  5 root root 1,0K 25. Jul 17:22 .
4,0K drwxr-xr-x 18 root root 4,0K 25. Jul 17:17 ..
273K -rw-r--r--  1 root root 270K 19. Jul 18:55 config-6.9.10-amd64
4,0K drwx------  3 root root 4,0K  1. Jan 1970  efi
1,0K drwxr-xr-x  5 root root 1,0K 25. Jul 17:22 grub
 26M -rw-r--r--  1 root root  26M 25. Jul 17:22 initrd.img-6.9.10-amd64
 12K drwx------  2 root root  12K 16. Okt 2022  lost+found
1,0K -rw-r--r--  1 root root   83 19. Jul 18:55 System.map-6.9.10-amd64
9,3M -rw-r--r--  1 root root 9,2M 19. Jul 18:55 vmlinuz-6.9.10-amd64

Code: Alles auswählen

df -h
Dateisystem              Größe Benutzt Verf. Verw% Eingehängt auf
udev                      7,6G       0  7,6G    0% /dev
tmpfs                     1,6G    1,7M  1,6G    1% /run
/dev/mapper/dux--vg-root   28G    5,3G   21G   21% /
tmpfs                     7,7G       0  7,7G    0% /dev/shm
efivarfs                  268K    223K   41K   85% /sys/firmware/efi/efivars
tmpfs                     5,0M       0  5,0M    0% /run/lock
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-journald.service
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-udev-load-credentials.service
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-tmpfiles-setup-dev-early.service
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-sysctl.service
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-tmpfiles-setup-dev.service
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-cryptsetup@nvme0n1p3_crypt.service
/dev/nvme0n1p2            456M     49M  383M   12% /boot
tmpfs                     7,7G    4,0K  7,7G    1% /tmp
/dev/mapper/dux--vg-home  887G    342G  500G   41% /home
/dev/nvme0n1p1            511M    4,4M  507M    1% /boot/efi
tmpfs                     1,0M       0  1,0M    0% /run/credentials/systemd-tmpfiles-setup.service
tmpfs                     1,6G     56K  1,6G    1% /run/user/1000
tmpfs                     1,0M       0  1,0M    0% /run/credentials/getty@tty1.service

War das Vorgehen soweit in Ordnung, einfach die alten Kernel raus aus /boot zu verschieben?
Liegt der kleinere Kernel jetzt an den MODULES=dep Eintrag (wobei in der initramfs.conf noch =most steht)? Oder an dem Kernel-update?
Bringt es etwas, die ganzen alten images mit apt purge zu entfernen? Damit werden vermutlich nur die config Dateien gelöscht.
Habe jetzt keinen fallback-Kernel und bin bei solchen Aktionen immer ein bisschen unsicher das System unbootbar zu machen. Wenn 6.9.11 rauskommt, wird dann der 6.9.10 wieder automatisch der zweite Eintrag im Bootmenü?
Und um dem vorzubeugen, würdet ihr dennoch die boot Partition vergrößern?

Vielen Dank!

P.S. Ja die /home Partition ist verschlüsselt

[MSfree]

In der /etc/initramfs-tools/initramfs.conf steht allerdings noch MODULES=most.

Ich hätte es direkt in /etc/initramfs-tools/initramfs.conf eingetragen statt eine neue Daeti unter conf.d anzulegen. Es ist aber beides legitim und die Angaben unter conf.d überschreiben die Option aus initramfs.conf offensichtlich.

War das Vorgehen soweit in Ordnung, einfach die alten Kernel raus aus /boot zu verschieben?

Klar, wenn es nicht anders geht.

Liegt der kleinere Kernel jetzt an den MODULES=dep Eintrag (wobei in der initramfs.conf noch =most steht)? Oder an dem Kernel-update?

Der Kernel ist nicht kleiner geworden. Aber die Initial RAM-Disk (initrd) enthält jetzt nicht mehr soviele Kernelmodule.

Bringt es etwas, die ganzen alten images mit apt purge zu entfernen? Damit werden vermutlich nur die config Dateien gelöscht.

Das bringt dir auf jeden Fall Platz auf der /-Partition. Auf die /boot-Partition hat das keinen Einfluß.

Habe jetzt keinen fallback-Kernel und bin bei solchen Aktionen immer ein bisschen unsicher das System unbootbar zu machen.

Du kannst doch alle Dateien, die du vorher weggeschoben hast, zurück nach /boot schieben. Dann hast du praktisch den Zustand, wie er durch Installation und Upgrades automatisch zustande gekommen ist. Allerdings solltest du nach dem verschieben nochmal

Code: Alles auswählen

update-grub

ausführen, damit du im Bootmenü wieder den aktuellen und den vorletzten Kernel auswählen kannst.

Wenn 6.9.11 rauskommt, wird dann der 6.9.10 wieder automatisch der zweite Eintrag im Bootmenü?

Ja, update-grub steckt einfach alle Kernel, die es findet, in die Grub-Konfiguration.

Und um dem vorzubeugen, würdet ihr dennoch die boot Partition vergrößern?

Jetzt, nachdem du nur noch 1/10 des Platzes pro initrd brauchst, warum solltest du die Partition vergrößern?

[jph]

Wenn man alte Kernel regelmäßig löscht (oder apt das automatisch machen lässt), kommt man mit einer /boot-Partition von um die 500 MB aus. Es sei denn, das Dateisystem hat einen Hau, siehe viewtopic.php?t=190054.

[empty_string]

Vielen Dank und danke @MSfree für deine Hilfe, habe es so durchgeführt und alles funktioniert wieder.
Die /boot Partition belasse ich so wie sie ist und beobachte die initrd Größe mit den kommenden updates.

[MSfree]

Die /boot Partition belasse ich so wie sie ist und beobachte die initrd Größe mit den kommenden updates.

Mit MODULES=dep dürftest du wieder viele Jahre Ruhe haben.

Standardmäßig steht in der initrd.conf MODULES=most und ich hab das in MODULES=dep geändert

Ich habe das auch mal so eingestellt. Aus den ehemals 44MB initrd sind jetzt unter 9.2MB geworden.

[cosinus]

Meine initrd ist nun auch endlich kleiner. Ich musste aber die unnötigen nvidia Module vorher deinstallieren, dann erst kam mit MODULES=dep und nach einer update-initramfs einer kleinere initrd

Code: Alles auswählen

-rw-r--r--  1 root root 242904K 2024-07-24 23:57 initrd.img-6.9.10-1-siduction-amd64.backup
-rw-r--r--  1 root root  69365K 2024-07-26 18:23 initrd.img-6.9.10-1-siduction-amd64.backup2
-rw-r--r--  1 root root  26578K 2024-07-26 18:26 initrd.img-6.9.11-1-siduction-amd64

[empty_string]

Da bin ich beruhigt, danke, die initrd ist jetzt 26MB groß (klein).

[KP97]

@empty_string
Da kannst Du auch ganz beruhigt sein, ich habe in den vielen Jahren _noch nie_ etwas anderes als =dep eingetragen,
und wenn Du noch compress=xz auswählst, wird die initrd nochmal kleiner.

[miwie]

Ein ähnliches Poblem (/boot zu klein) hier vor einiger Zeit habe ich mit folgender Konfiguration in /etc/initramfs-tools/conf.d/driver-policy (Dateiname frei wählbar) alles wunderbar in den Griff bekommen:

Code: Alles auswählen

COMPRESS=xz
MODULES=dep

Michael

[michaa7]

Wenn jemand hier auch noch posten würde wie man eine neu initrd.img baut nachdem man auf "MODULES=dep " umgestellt hat wäre dieser interessante thread auch für weniger Geübte hilfreich.

Danke.

[KBDCALLS]

Genauso wie sonst auch . update-intramfs

[MSfree]

Wenn jemand hier auch noch posten würde wie man eine neu initrd.img baut

Code: Alles auswählen

update-initramfs -u

Details: siehe man update-initramfs.