mkinitramfs stürzt beim Erzeugen von neuen Boot-Dateien ab

[udo80]

Hallo zusammen,
ich möchte gern mit Eurer Hilfe folgendes Problem lösen: Ich habe versucht, die aktuelle Proxmox-Version auf einem neuen Mini-PC (MINIS FORUM Mini PC NPB7, Intel Core i7-13700H, Win11 Pro installiert) zu installieren. Diese Installation schlug leider fehl, da der PC am Ende der Installation bootete, noch bevor (oder während?) die boot-Dateien korrekt geschrieben werden konnten. In meiner Verzweiflung (und zum Test der Hardware), installierte ich danach ein reines Debian 12 - mit Erfolg! Also installierte ich darauf nach der Anleitung aus der Proxmox-Dokumentation mein Proxmox VE 8.

Danach funktionierte Proxmox problemlos, ich habe inzwischen einige Container und VMs installiert und war mit dem System soweit zufrieden. Nun scheint mich aber mein ursprüngliches Problem wieder eingeholt zu haben: Ein Update des Proxmox Kernels von der installieren 6.2.16-19 zur 6.5.11-4 stand an und während dieses Updates geschah (vermutlich) dasselbe Problem: Beim Erzeugen der Boot-Dateien via update-initramfs bootet der PC neu und das gewünschte Image (initrd.img-6.2.16-19-pve) ist nicht auf der Platte zu finden, wohl aber ein leeres initrd.img-6.2.16-19-pve.new. Zum Glück ist das alte Image noch da, so dass der PC noch bootet, ich komme aber nicht über das Update hinweg.

Hier der Inhalt des /boot-Verzeichnisses nach meinem Update-Versuch:

root@minis:/boot# ls -lA
insgesamt 157692
-rw-r--r-- 1 root root   275468 24. Okt 14:07 config-6.2.16-19-pve
-rw-r--r-- 1 root root   279416 20. Nov 11:19 config-6.5.11-4-pve
drwx------ 3 root root     4096  1. Jan 1970  efi
drwxr-xr-x 5 root root     4096 27. Nov 20:24 grub
-rw-r--r-- 2 root root 59047066 11. Nov 02:02 initrd.img-6.2.16-19-pve
-rw-r--r-- 2 root root 59047066 11. Nov 02:02 initrd.img-6.2.16-19-pve.dpkg-bak
-rw-r--r-- 1 root root        0 26. Nov 23:52 initrd.img-6.2.16-19-pve.new
-rw-r--r-- 1 root root        0 27. Nov 20:15 initrd.img-6.5.11-4-pve.new
drwxr-xr-x 2 root root     4096 26. Nov 23:13 pve
-rw-r--r-- 1 root root  7688348 24. Okt 14:07 System.map-6.2.16-19-pve
-rw-r--r-- 1 root root  7969247 20. Nov 11:19 System.map-6.5.11-4-pve
-rw-r--r-- 1 root root 13621376 24. Okt 14:07 vmlinuz-6.2.16-19-pve
-rw-r--r-- 1 root root 13520520 20. Nov 11:19 vmlinuz-6.5.11-4-pve

Im Journal habe ich nichts finden können, was auf eine Lösung hinweist, deswegen wende ich mich jetzt an Euch mit der Bitte um Tipps, wie ich mein Problem eingrenzen und im besten Falle lösen kann. Wenn alle Stricke reißen, wüsste ich wenigstens gern, wie ich das Kernel-Update im dpkg zurückstellen kann, da bis dahin keine weiteren Updates oder Installationen via apk auf dem Proxmox möglich sind...

 

[j.palm]

Hallo, also Kernel-Downgrade musste ich bei meiner Installtion auch machen weil die VMs irgendwie nicht mehr auf den Shared-Storage zugreifen konnten .. der Proxmoxhost allerdings schon ..

geht recht einfach:

nano /etc/default/grub

Dort dann den bestehenden Eintrag GRUB_DEFAULT auskommentieren und danach folgendes einfügen

GRUB_DEFAULT="Advanced options for Proxmox VE GNU/Linux>Proxmox VE GNU/Linux, with Linux 6.2.16-19-pve"

das ganze speichern und danach einfach Grub updaten mit:

update-grub

danach rebooten und schon biste wieder auf der älteren Kernel-Version

mfg Joe

 

[udo80]

Vielen Dank für den Tipp, Joe. Den alten Kernel habe ich im Grub schon fixiert, mir fehlt noch die Möglichkeit, entweder auch die angefangene Installation des neuen Kernels wieder rückgängig zu machen, oder dpkg in anderer Weise aus seiner "Schmollecke" zu holen:

root@minis:~# apt remove pve-kernel-6.5.11-4-pve
E: Der dpkg-Prozess wurde unterbrochen; Sie müssen manuell »dpkg --configure -a« ausführen, um das Problem zu beheben.

Sobald ich die Konfiguration laufen lasse, startet dpkg auch ein update-initramfs und ich bin wieder am selben Punkt...

 

[udo80]

Hier noch ein paar Logausgaben von verschiedenen Versuchen, das System wieder zur Mitarbeit zu bewegen:

root@minis:~# apt install -f
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 5 nicht aktualisiert.
5 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
proxmox-kernel-6.5.11-4-pve-signed (6.5.11-4) wird eingerichtet ...
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 6.5.11-4-pve /boot/vmlinuz-6.5.11-4-pve
update-initramfs: Generating /boot/initrd.img-6.5.11-4-pve

Fortschritt: [  9%] [########.......................................................................................]

Abbruch per Reboot...

Danach noch ein Versuch, die Konfiguration zu beenden:

udo@minis:~$ sudo dpkg --configure -a
[sudo] Passwort für udo:
proxmox-kernel-6.5.11-4-pve-signed (6.5.11-4) wird eingerichtet ...
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 6.5.11-4-pve /boot/vmlinuz-6.5.11-4-pve
update-initramfs: Generating /boot/initrd.img-6.5.11-4-pve
Running hook script 'zz-proxmox-boot'..
Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..
No /etc/kernel/proxmox-boot-uuids found, skipping ESP sync.
run-parts: executing /etc/kernel/postinst.d/proxmox-auto-removal 6.5.11-4-pve /boot/vmlinuz-6.5.11-4-pve
run-parts: executing /etc/kernel/postinst.d/zz-proxmox-boot 6.5.11-4-pve /boot/vmlinuz-6.5.11-4-pve
Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..
No /etc/kernel/proxmox-boot-uuids found, skipping ESP sync.
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 6.5.11-4-pve /boot/vmlinuz-6.5.11-4-pve
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.5.11-4-pve
Found initrd image: /boot/initrd.img-6.5.11-4-pve
Found linux image: /boot/vmlinuz-6.2.16-19-pve
Found initrd image: /boot/initrd.img-6.2.16-19-pve
Adding boot menu entry for UEFI Firmware Settings ...
done
shim-signed:amd64 (1.39+pmx1+15.7-1+pmx1) wird eingerichtet ...
No DKMS packages installed: not changing Secure Boot validation state.
proxmox-kernel-6.5 (6.5.11-4) wird eingerichtet ...
proxmox-default-kernel (1.0.1) wird eingerichtet ...
proxmox-ve (8.1.0) wird eingerichtet ...
Trigger für initramfs-tools (0.142) werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-6.5.11-4-pve

Auch hier: Abbruch per Reboot... Währenddessen erschien im dpkg-Log:

2023-11-29 11:20:56 startup packages configure
2023-11-29 11:20:56 configure proxmox-kernel-6.5.11-4-pve-signed:amd64 6.5.11-4 <none>
2023-11-29 11:20:56 status half-configured proxmox-kernel-6.5.11-4-pve-signed:amd64 6.5.11-4

Das Journal schweigt sich aus:

Nov 29 11:20:56 minis sudo[6573]:      udo : TTY=pts/2 ; PWD=/home/udo ; USER=root ; COMMAND=/usr/bin/dpkg --configure -a
Nov 29 11:20:56 minis sudo[6573]: pam_unix(sudo:session): session opened for user root(uid=0) by udo(uid=1000)

 

[fabian]

irgendetwas besonders an deinem system? liegt /boot auf / oder auf einer eigenen partition?

 

[udo80]

Nein, es gibt keine Besonderheiten, die mir bekannt wären. /boot hat keine eigene Partition, und Platz sollte auch noch genügend sein:

root@minis:/usr/sbin# df -k
Dateisystem                   1K-Blöcke    Benutzt  Verfügbar Verw% Eingehängt auf
udev                           32747964          0   32747964    0% /dev
tmpfs                           6556228       1676    6554552    1% /run
/dev/nvme0n1p2                981876212  106479824  825446080   12% /
tmpfs                          32781136      28080   32753056    1% /dev/shm
tmpfs                              5120          0       5120    0% /run/lock
/dev/nvme0n1p1                   523248       5972     517276    2% /boot/efi
/dev/fuse                        131072         28     131044    1% /etc/pve
tmpfs                           6556224          0    6556224    0% /run/user/1000

 

[fabian]

das klingt sehr mysteriös .. du bist lokal eingeloggt, nicht über SSH oder ähnliches? (nur um sicherzugehen dass der output vollständig ist..)

 

[udo80]

Aktuell bin ich per SSH auf der Kiste, kann sie aber auch gern an die Tastatur hängen.

Ich habe mich mit "echo"-Kommandos jetzt langsam bis zur mkinitramfs vorgearbeitet. Dort kommt der Vorgang nicht über den compress-Befehl hinweg. Der Befehl, der an der Stelle ausgeführt wird, lautet (die Shell-Variablen mal expandiert):

zstd -q -9 -T0 -c /var/tmp/mkinitramfs-MAIN_puyCFt

Interessanterweise ist die Datei im tmp-Verzeichnis leer.

 

[fabian]

kannst du mal versuchen eine beliebige datei mit ein bisschen inhalt mit zstd mit denselben flags (achtung, output auf stdout, also z.b. auf /dev/null umleiten ) zu komprimieren? das klingt fast so als wuerde die CPU last dein system zum abstuerzen bringen..

 

[udo80]

Das scheint es nicht zu sein. Ich habe jetzt ein 2GB-File mit urandom erstellt und mit den Parametern komprimiert. Alles lief glatt...

udo@minis:/var/tmp$ head -c 2G < /dev/urandom > myfile
udo@minis:/var/tmp$ ls -lA
insgesamt 2097164
-rw-r--r-- 1 udo  udo  2147483648 29. Nov 15:25 myfile
udo@minis:/var/tmp$ zstd -q -9 -T0 -c myfile > myfile.zstd
udo@minis:/var/tmp$ ls -lA
insgesamt 4194372
-rw-r--r-- 1 udo  udo  2147483648 29. Nov 15:25 myfile
-rw-r--r-- 1 udo  udo  2147532814 29. Nov 15:25 myfile.zstd

 

[fabian]

könntest du vielleicht noch "updateinitramfs -u -k all -v" machen? das sollte sehr detaillierten output geben (eventuell in ein file umleiten!). sonst bleibt dann schon fast nur mehr mit "strace" schauen was das letzte ist was passiert (also z.b., "strace -ff -o initramfs_ update-initramfs ...." -> das generiert dann trace files mit dem prefix initramfs_ in denen alle syscalls stehen die gemacht werden, darueber lassen sich dann file access oder andere binaries die ausgefuehrt werden nachvollziehen..)

 

[udo80]

Ausprobiert habe ich "update-initramfs -c -k all -v -b /root/tmp" (ich habe die Files jetzt erstmal in einem Extra-Verzeichnis erzeugen lassen, um mir die (noch) funktionierende Konfiguration nicht endgültig zu zerschießen). Der Log ist leider zu lang, um ihn in das Forum zu posten, auf den groben Blick habe ich aber keine suspekten Meldungen sehen können.

strace werde ich als nächstes ausprobieren. Vielen Dank für die Unterstützung!

 

[udo80]

"strace" ist leider nicht auf meinem System installiert, und "apt" lässt sich nicht nutzen, solange dpkg noch halb installierte Pakete vorfindet. Komme ich an der Meldung Der dpkg-Prozess wurde unterbrochen; Sie müssen manuell »dpkg --configure -a« ausführen, um das Problem zu beheben. irgendwie vorbei?

 

[fabian]

vermutlich kannst du strace (und gegebenenfalls libunwind8) einfach haendisch entpacken, die pakete sind sehr klein und brauchen meines wissens keine besondere integration. oder du passt temporaer /usr/sbin/update-initramfs an und knallst ganz oben nen early return rein damit das upgrade mal durch laeuft..

 

[udo80]

Der Tipp mit dem early return war schon mal eine sehr gute Sache. Immerhin habe ich jetzt das "apt" wieder zurück. Habe natürlich sofort "strace" installiert und das update-initramfs damit laufen lassen. Das Ergebnis: Ein Reboot und 6275 "initramfs_.*" Dateien, die allesamt eine Länge von 0 haben. Vermutlich kommt der Reboot so "unerwartet", dass das Filesystem die Inhalte noch nicht auf die Platte schreiben konnte.

Die positive Seite ist im Moment für mich, dass "apt" wieder läuft und ich so zumindest den Rest des Systems aktuell halten kann. Mich würde aber immer noch sehr interessieren, woran es denn jetzt liegt, dass "update-initramfs" nicht mitspielt. Das Toolset ist ja nun keine Spezialität vom Proxmox, sondern gehört zum Debian - und zumindest bei der Erstinstallation des Betriebssystems hat ja alles funktioniert.

 

[fabian]

hmm, du kannst strace auch ohne -o starten (dann kommt der output auf stdout, achtung, sehr lang ) und dann aus deinem terminal kopieren (wenn du ueber SSH drauf bist).

 

[udo80]

Also aktuell hat "strace" schon mal geholfen: Zusammen mit der Ausgabe auf der Konsole liefen alle Updates durch und das System ist nun wieder auf dem neuesten Stand. Es gab vermutlich irgendwo ein Timing-Problem, und durch die parallele Ausgabe auf stdout wurde der Prozess soweit verlangsamt, dass alles durchlief.

Das ist einerseits eine gute Nachricht, immerhin ist das System jetzt aktualisiert, andererseits war es ja eher das Ziel herauszufinden, was jetzt wirklich schief gelaufen war. Das lässt sich natürlich nicht nachvollziehen, wenn der Fehler beim Überwachen nicht mehr auftritt. (Wir nennen das auch "Heisen-Bug"...) Ich habe zumindest für die Zukunft eine Möglichkeit, das System auch zu aktualisieren, wenn das Update weiter spinnt.

Sollten sich noch weitere Erkenntnisse ergeben, werde ich sie in diesem Thread posten. Fürs Erste vielen Dank für die Unterstützung!

 

[fabian]

mein bauchgefuehl sagt immer noch irgendeine art last-induzierte instabilitaet.. aber ja, gut dass es so erstmal funktioniert hat - vielleicht trotzdem nochmal in einer ruhigen minute memory (memtest) und system (z.b. mit stress-ng) abklopfen - dann schlaeft es sich auch besser