Kernel Panic

Aus TippvomTibb
Zur Navigation springen Zur Suche springen

Kernel Panic Failed to execute /init (error -2)

Heute war es mal wieder soweit. Nach einem Kernelupdate (openSUSE Leap 15.2 12/2020) ist der Rechner nicht mehr hochgefahren und zeigte folgte Fehlermeldung.

Da es ja Kernel Panic und nicht User Panic heißt, hier die Auflösung:

Schritt 1: CD/DVD Boot in das rescue System

Geht natürlich auch mit jedem anderen Livesystem. Hauptsache man kann irgendwie auf die Boot-Festplatte zugreifen.

Schritt 2: root einloggen

Bei openSUSE gibt es für 'root' kein Passwort. Erst mal umschauen und die (Boot-)Partition der Boot-Festplatte finden. Das ist die Partition in der sich das Verzeichnis /boot befindet. In der Regel befindet sich dieses Verzeichnis im 'normalen' root-Verzeichnis. Es besteht aber auch die Möglichkeit, dass /boot sich in einer eigenen Partition befindet. Der Grund soll hier einmal außen vor bleiben.

Schritt 3: mount Partition

lsblk

Als Ergebnis erhält man eine Übersicht aller Laufwerke, die z.Z. am System angeschlossen sind. Es empfiehlt sich zumindest alle USB-Laufwerke für die nachfolgenden Schritte abzuziehen. Wer ganz auf Nummer sicher gehen will sollte auch an alle internen Festplatten außer der Bootplatte den Stromstecker ziehen. Damit braucht man sich erst mal keine Gedanken darüber zu machen wie die Bootreihenfolge im BIOS oder Grub hinterlegt ist. Nicht dass man aus lauter Panic auf der falschen Festplatte arbeitet. Bei meinen System liegt /boot im root-Verzeichnis der Hauptpartition (/dev/sda2). Für das Mounten kann man sich ein eigenes Verzeichnis (z.B. /hauptplatte ) anlegen oder einfach /mnt nehmen.

mount /dev/sda2 /mnt

Nach dem Mount mit

cd /mnt

ins Verzeichnis wechsel und sich mit ll (ls -l) den Inhalt anzeigen lassen. Wenn der Mount erfolgreich war sieht man jetzt den Inhalt der Hauptpartition, also etwa sowas

Schritt 4: chroot

Jetzt muss man das System 'austricksen' und so tun als wäre das Verzeichnis unter /mnt das Hauptverzeichnis. Dies kann man mit dem Befehl 'chroot' erreichen. Bevor man aber aber loslegt noch ein paar Orientierungshilfen. Mit dem Befehl 'cd /' gelangt man ins Root-Verzeichnis. Nicht zu verwechseln mit dem Heimatverzeichnis des Users 'root' unter /root. Zur Kontrolle kann man mit

cd /
ll

sich nochmal das Hauptverzeichnis des Rescue/Live-System anschauen. Jetzt kommen noch ein paar Befehle der Vorbereitung von chroot.

mount -t proc --bind /proc /mnt/proc/
mount --rbind /sys /mnt/sys/
mount --rbind /dev /mnt/dev/

Manchmal findet man in anderen Anleitungen auch die mount-Option --bind anstatt --rbind. rbind hat aber den Vorteil das auch alle eventuellen Submounts gleich mit neu verbunden werden. Archlinux spricht hierzu eine Warnung aus. Die Angabe des Filesystem-Typs -t proc wird normal automatisch richtig erkannt und kann entfallen. Wenn man ein anderes Verzeichnis zum Mount der Bootplatte erstellt hat muss natürlich /mnt entsprechend angepasst werden. Allgemein also

mount -t proc --bind /proc /<verzeichnis>/proc/
mount --rbind /sys /<verzeichnis>/sys/
mount --rbind /dev /<verzeichnis>/dev/

Bei proc ist --bind scheinbar ausreichend. Die 'normale' mount-Situation sieht so aus. Jetzt sind die für den Kernel die wichtigen Arbeits-Verzeichnisse umgebogen und jetzt können wir mit

chroot /mnt/

das ganze System so umstellen (change root Verzeichnis), dass das neue Root-Verzeichnis bei /mnt/sda2 beginnt. Das kann man auch leicht überprüfen wenn man jetzt ein 'cd / && ll' macht sind man den Inhalt der Root-Verzeichnisses der Boot-Partition. Das Rescuesystem ist jetzt 'unsichtbar'.

Schritt 5: mkinitrd

Jetzt wechseln wir in das /boot-Verzeichnis. Dort findet man alle derzeit verfügbaren Kernels und deren Begleitdateien. Bei mir sieht man derzeit 4 verschiedene Kernels

ll /boot

worker:/boot # ll total 183308 -rw-r--r-- 1 root root 65 Nov 11 18:46 .vmlinuz-5.3.18-lp152.50-default.hmac -rw-r--r-- 1 root root 65 Nov 11 18:34 .vmlinuz-5.3.18-lp152.50-preempt.hmac -rw-r--r-- 1 root root 65 Dec 5 09:58 .vmlinuz-5.3.18-lp152.57-default.hmac -rw-r--r-- 1 root root 65 Dec 5 10:41 .vmlinuz-5.3.18-lp152.57-preempt.hmac -rw-r--r-- 1 root root 4610647 Nov 11 17:53 System.map-5.3.18-lp152.50-default -rw-r--r-- 1 root root 4612190 Nov 11 17:50 System.map-5.3.18-lp152.50-preempt -rw-r--r-- 1 root root 4605295 Dec 5 09:12 System.map-5.3.18-lp152.57-default -rw-r--r-- 1 root root 4606747 Dec 5 09:40 System.map-5.3.18-lp152.57-preempt -rw-r--r-- 1 root root 1725 Aug 26 22:47 boot.readme -rw-r--r-- 1 root root 228385 Nov 11 17:30 config-5.3.18-lp152.50-default -rw-r--r-- 1 root root 228416 Nov 11 17:29 config-5.3.18-lp152.50-preempt -rw-r--r-- 1 root root 228385 Dec 5 08:59 config-5.3.18-lp152.57-default -rw-r--r-- 1 root root 228416 Dec 5 09:00 config-5.3.18-lp152.57-preempt drwxr-xr-x 2 root root 4096 Nov 24 23:36 dracut drwxr-xr-x 5 root root 4096 Jan 4 15:04 grub2 lrwxrwxrwx 1 root root 30 Dec 31 10:13 initrd -> initrd-5.3.18-lp152.57-default -rw------- 1 root root 8767144 Nov 15 13:20 initrd-5.3.18-lp152.19-default -rw------- 1 root root 12011868 Jul 16 22:11 initrd-5.3.18-lp152.26-default.bak -rw------- 1 root root 12166716 Jan 4 14:55 initrd-5.3.18-lp152.50-default -rw------- 1 root root 12165192 Jan 4 14:55 initrd-5.3.18-lp152.50-preempt -rw------- 1 root root 12166528 Jan 4 14:55 initrd-5.3.18-lp152.57-default -rw------- 1 root root 12165256 Jan 4 14:56 initrd-5.3.18-lp152.57-preempt -rw-r--r-- 1 root root 1255444 Nov 11 17:56 symtypes-5.3.18-lp152.50-default.gz -rw-r--r-- 1 root root 1256334 Nov 11 17:53 symtypes-5.3.18-lp152.50-preempt.gz -rw-r--r-- 1 root root 1255444 Dec 5 09:15 symtypes-5.3.18-lp152.57-default.gz -rw-r--r-- 1 root root 1256334 Dec 5 09:46 symtypes-5.3.18-lp152.57-preempt.gz -rw-r--r-- 1 root root 432816 Nov 11 17:56 symvers-5.3.18-lp152.50-default.gz -rw-r--r-- 1 root root 433040 Nov 11 17:53 symvers-5.3.18-lp152.50-preempt.gz -rw-r--r-- 1 root root 432948 Dec 5 09:14 symvers-5.3.18-lp152.57-default.gz -rw-r--r-- 1 root root 433173 Dec 5 09:45 symvers-5.3.18-lp152.57-preempt.gz -rw-r--r-- 1 root root 484 Nov 11 17:56 sysctl.conf-5.3.18-lp152.50-default -rw-r--r-- 1 root root 377 Nov 11 17:53 sysctl.conf-5.3.18-lp152.50-preempt -rw-r--r-- 1 root root 484 Dec 5 09:14 sysctl.conf-5.3.18-lp152.57-default -rw-r--r-- 1 root root 377 Dec 5 09:45 sysctl.conf-5.3.18-lp152.57-preempt -rw-r--r-- 1 root root 13903220 Nov 11 18:00 vmlinux-5.3.18-lp152.50-default.gz -rw-r--r-- 1 root root 13997555 Nov 11 17:56 vmlinux-5.3.18-lp152.50-preempt.gz -rw-r--r-- 1 root root 13883322 Dec 5 09:19 vmlinux-5.3.18-lp152.57-default.gz -rw-r--r-- 1 root root 13977866 Dec 5 09:51 vmlinux-5.3.18-lp152.57-preempt.gz lrwxrwxrwx 1 root root 31 Dec 31 10:13 vmlinuz -> vmlinuz-5.3.18-lp152.57-default -rw-r--r-- 1 root root 9048240 Nov 11 18:46 vmlinuz-5.3.18-lp152.50-default -rw-r--r-- 1 root root 9109680 Nov 11 18:34 vmlinuz-5.3.18-lp152.50-preempt -rw-r--r-- 1 root root 9035952 Dec 5 09:58 vmlinuz-5.3.18-lp152.57-default -rw-r--r-- 1 root root 9093296 Dec 5 10:41 vmlinuz-5.3.18-lp152.57-preempt

Eigentlich sind es nur 2 Kernels 5.3.18-lp152.50 vom 11. November und der neuere vom 5. Dezember, der jetzt die Probleme verursacht. Die default und Preemp Variante unterscheiden sich nur in einer 'Kleinigkeit':

The kernel for arm64 and x86_64 architectures that supports CONFIG_PREEMPT. Its main purpose is to serve workloads with a higher demand on smaller latencies than the default kernel in average.

Jetzt kann man mkinitrd ausführen und damit die initiale RamDisk (initrd) neu anlegen (make). Allerdings kamen hier eine Unmenge an Fehlermeldungen. Für das Erstellen der initrd greift mkinitrd auf das Programm dracut zurück. Die Fehlermeldungen hatten alle das gleiche Muster:

dracut-install: ERROR: failed to install '/usr/bin/ldd:' for '/bin/sh' for '/usr/bin/udevadm' 

Die Lösung lag in einer nicht vorhanden Verbindung zu bash. Der folgende Screenshot zeigt neben dem Fehler auch gleich die Lösung.

bash liegt in /bin und lld sucht in /usr/bin

Ein Softlink bringt die Lösung.

cd /usr/bin && ln -s /bin/bash bash

mkinitrd lief danach ohne Fehlermeldung durch.

Schritt 6: reboot

Noch eine Kleinigkeit: Ein 'schutdown -r now' in der chroot-Umgebung gelingt nicht, als erst chroot mit 'exit' verlassen.

Mission accomplished!

Quellen

Ähnliches Problem, allerdings etwas komplexer da die Platte verschlüsselt war.[1]

chroot

initrd

dracut


Kommentar hinzufügen
TippvomTibb freut sich über alle Kommentare. Sofern du nicht anonym bleiben möchtest, registriere dich bitte oder melde dich an.