Kernel Panic - Versionsgeschichte

Chris T. Ludwig: Rechtschreibkorrektur (automatisiert)

2026-07-31T15:53:58Z

Rechtschreibkorrektur (automatisiert)

← Nächstältere Version		Version vom 31. Juli 2026, 17:53 Uhr
Zeile 1:		Zeile 1:
	==Kernel Panic Failed to execute /init (error -2)==		==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.		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.

	[[Datei:Kernel Panic Fehler.jpg \|400px]]		[[Datei:Kernel Panic Fehler.jpg \|400px]]

Chris T. Ludwig: /* Schritt 5: mkinitrd */

2021-01-05T08:41:28Z

Schritt 5: mkinitrd

← Nächstältere Version		Version vom 5. Januar 2021, 10:41 Uhr
Zeile 104:		Zeile 104:
	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.		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 '''init'''iale '''R'''am'''D'''isk (initrd) neu anlegen (make). Allerdings kamen hier eine Unmenge an Fehlermeldungen.		Jetzt kann man '''mkinitrd''' ausführen und damit die '''init'''iale '''R'''am'''D'''isk (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:		Für das Erstellen der initrd greift mkinitrd auf das Programm dracut zurück. Die Fehlermeldungen hatten alle das gleiche Muster:

Chris T. Ludwig: /* Kernel Panic Failed to execute /init (error -2) */

2021-01-04T17:18:05Z

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

← Nächstältere Version		Version vom 4. Januar 2021, 19:18 Uhr
Zeile 2:		Zeile 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.		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.

	[Datei:Kernel Panic Fehler.jpg \|400px]		[[Datei:Kernel Panic Fehler.jpg \|400px]]

	Da es ja Kernel Panic und nicht User Panic heißt, hier die Auflösung:		Da es ja Kernel Panic und nicht User Panic heißt, hier die Auflösung:
Zeile 111:		Zeile 111:
	Die Lösung lag in einer nicht vorhanden Verbindung zu bash. Der folgende Screenshot zeigt neben dem Fehler auch gleich die Lösung.		Die Lösung lag in einer nicht vorhanden Verbindung zu bash. Der folgende Screenshot zeigt neben dem Fehler auch gleich die Lösung.

	[Datei:Kernel Panic Loesungsschritt ldd bash.jpg \| 400px]		[[Datei:Kernel Panic Loesungsschritt ldd bash.jpg \| 400px]]

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

Chris T. Ludwig: /* Kernel Panic Failed to execute /init (error -2) */

2021-01-04T17:17:07Z

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

← Nächstältere Version		Version vom 4. Januar 2021, 19:17 Uhr
Zeile 1:		Zeile 1:
	==Kernel Panic Failed to execute /init (error -2)==		==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.		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.

			[Datei:Kernel Panic Fehler.jpg \|400px]

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

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

			[Datei:Kernel Panic Loesungsschritt ldd bash.jpg \| 400px]

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

Chris T. Ludwig: /* Quelle */

2021-01-04T16:54:05Z

Quelle

← Nächstältere Version		Version vom 4. Januar 2021, 18:54 Uhr
Zeile 123:		Zeile 123:
	Mission accomplished!		Mission accomplished!

	==~~Quelle~~==		==Quellen==
	Ähnliches Problem, allerdings etwas komplexer da die Platte verschlüsselt war.[https://forums.opensuse.org/showthread.php/547270-SOLVED-kernel-panic-Failed-to-execute-init-no-working-init-found-after-update-encrypted-luks-lvm]		Ähnliches Problem, allerdings etwas komplexer da die Platte verschlüsselt war.[https://forums.opensuse.org/showthread.php/547270-SOLVED-kernel-panic-Failed-to-execute-init-no-working-init-found-after-update-encrypted-luks-lvm]

Chris T. Ludwig: /* Schritt 5: mkinitrd */

2021-01-04T16:53:53Z

Schritt 5: mkinitrd

← Nächstältere Version		Version vom 4. Januar 2021, 18:53 Uhr
Zeile 116:		Zeile 116:

	mkinitrd lief danach ohne Fehlermeldung durch.		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.		Noch eine Kleinigkeit: Ein 'schutdown -r now' in der chroot-Umgebung gelingt nicht, als erst chroot mit 'exit' verlassen.

Chris T. Ludwig: /* mkinitrd */

2021-01-04T16:53:13Z

mkinitrd

← Nächstältere Version		Version vom 4. Januar 2021, 18:53 Uhr
Zeile 45:		Zeile 45:
	das ganze System so umstellen ('''ch'''ange '''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 ganze System so umstellen ('''ch'''ange '''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'.		Das Rescuesystem ist jetzt 'unsichtbar'.
	===mkinitrd===		===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		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

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

	Mission accomplished!		Mission accomplished!

	==Quelle==		==Quelle==

Chris T. Ludwig: /* Quelle */

2021-01-04T16:52:53Z

Quelle

← Nächstältere Version		Version vom 4. Januar 2021, 18:52 Uhr
Zeile 128:		Zeile 128:
	[https://de.wikipedia.org/wiki/Initrd initrd]		[https://de.wikipedia.org/wiki/Initrd initrd]

	[https://de.wikipedia.org/wiki/Dracut_(initramfs)dracut]		[https://de.wikipedia.org/wiki/Dracut_(initramfs) dracut]

	<comments />		<comments />

Chris T. Ludwig: /* Quelle */

2021-01-04T16:52:32Z

Quelle

← Nächstältere Version		Version vom 4. Januar 2021, 18:52 Uhr
Zeile 123:		Zeile 123:
	==Quelle==		==Quelle==
	Ähnliches Problem, allerdings etwas komplexer da die Platte verschlüsselt war.[https://forums.opensuse.org/showthread.php/547270-SOLVED-kernel-panic-Failed-to-execute-init-no-working-init-found-after-update-encrypted-luks-lvm]		Ähnliches Problem, allerdings etwas komplexer da die Platte verschlüsselt war.[https://forums.opensuse.org/showthread.php/547270-SOLVED-kernel-panic-Failed-to-execute-init-no-working-init-found-after-update-encrypted-luks-lvm]

	[https://wiki.archlinux.de/title/Chroot chroot]		[https://wiki.archlinux.de/title/Chroot chroot]

	[https://de.wikipedia.org/wiki/Initrd initrd]		[https://de.wikipedia.org/wiki/Initrd initrd]

	[https://de.wikipedia.org/wiki/Dracut_(initramfs)dracut]		[https://de.wikipedia.org/wiki/Dracut_(initramfs)dracut]

	<comments />		<comments />

Chris T. Ludwig: /* Schritt 4: chroot */

2021-01-04T16:52:13Z

Schritt 4: chroot

@@ Zeile 28: / Zeile 28: @@
   ll
 sich nochmal das Hauptverzeichnis des Rescue/Live-System anschauen. Jetzt kommen noch ein paar Befehle der Vorbereitung von chroot.
-  mount -t proc /proc /mnt/proc/
+  mount -t proc --bind /proc /mnt/proc/
   mount --rbind /sys /mnt/sys/
-  mount --rbind /dev /mntdev/
+  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.
 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
+Allgemein also