"end Kernel panic - not syncing .... "auf jedem Kernel

[PerAstraAdDeum]

Hallo,

ich habe hier den Rechner eines Freundes (KDE Neon) stehen, der sich nicht mehr starten lässt. Beim normalen Boot endet der Vorgang mit der Fehlermeldung: "end Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block (0,0)"

Habe den Fehler recherchiert und auch diverse Fixes dafür gefunden, problematisch ist allerdings daß die alle einen funktionierenden Kernel voraussetzen. Allerdings bekomme ich diesen Fehler bei jedem Kernel, den ich für den Boot auswähle!

Jemand ne Idee, wie ich das beheben kann?

 

[MadMax_87]

Moin,

per live-cd booten
überprüfen ob die platte grundsätzlich lesbar ist (root partition einhängen)
die /etc/fstab (des installierten Systems) prüfen welche partition eingehangen werden soll
Speicherplatz überprüfen, häufiger als ich dachte kommt es vor das die zu 100% voll ist, und dann geht natürlich nichts mehr
per chroot ins installierte System wechseln und den Kernel einmal "neu" machen

 

[GrumpyCat]

Der Kernel wird ja gestartet, er gibt die Meldung aus.

Das Problem ist, dass der Kernel das Root-Dateisystem, das er mounten soll, nicht findet.

Entweder ist der root=...-Parameter, der dem Kernel von Grub mitgegeben wird, falsch (fstab spielt da erstmal noch keine Rolle), oder im initrd fehlen die Treiber für das Gerät, auf dem das root liegt.

Ersteres kann trivial behoben werden, indem man im Grub an den Parametern spielt ("e" für Edit im Bootmenü).

 

[PerAstraAdDeum]

Moin,

per live-cd booten
überprüfen ob die platte grundsätzlich lesbar ist (root partition einhängen)
die /etc/fstab (des installierten Systems) prüfen welche partition eingehangen werden soll
Speicherplatz überprüfen, häufiger als ich dachte kommt es vor das die zu 100% voll ist, und dann geht natürlich nichts mehr
per chroot ins installierte System wechseln und den Kernel einmal "neu" machen

Die Festlatte ist mit LUKS verschlüsselt. Lässt sie sich trotzdem einbinden?

Der Kernel wird ja gestartet, er gibt die Meldung aus.

Das Problem ist, dass der Kernel das Root-Dateisystem, das er mounten soll, nicht findet.

Entweder ist der root=...-Parameter, der dem Kernel von Grub mitgegeben wird, falsch (fstab spielt da erstmal noch keine Rolle), oder im initrd fehlen die Treiber für das Gerät, auf dem das root liegt.

Ersteres kann trivial behoben werden, indem man im Grub an den Parametern spielt ("e" für Edit im Bootmenü).

Die Festplatte ist eine Samsung Evo 850. Bis vor einigen Wochen startete er von dieser Platte ganz normal, an den Treibern sollte es also nicht liegen.
Wie spiele ich den an den Parametern rum? Also was muss ich da eingeben?

 

[GrumpyCat]

Ah, mit LUKS ist das natürlich nochmal etwas anders, da die Partition erst entschlüsselt wird bzw. für die entschlüsselte Ansicht der Partition ein eigenes Device angelegt wird. Schlägt das evtl. schon fehl? Das zu überprüfen geht auch per Live-CD, ist halt ggf. Handarbeit.

Ein Prompt könntest Du evtl. auch so bekommen, indem Du in Grub dem Kernel den Parameter "init=/bin/bash" mitgibst. Soweit ich mich erinnere geht das auch nur mit initrd (ohne die "echte" root-Partition).

Zu technischen Details ist das ArchWiki immer ganz gut, auch wenn einzelne Dinge natürlich immer von Distro zu Distro unterschiedlich sind.
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system

 

[PerAstraAdDeum]

Ah, mit LUKS ist das natürlich nochmal etwas anders, da die Partition erst entschlüsselt wird bzw. für die entschlüsselte Ansicht der Partition ein eigenes Device angelegt wird. Schlägt das evtl. schon fehl? Das zu überprüfen geht auch per Live-CD, ist halt ggf. Handarbeit.

Ein Prompt könntest Du evtl. auch so bekommen, indem Du in Grub dem Kernel den Parameter "init=/bin/bash" mitgibst. Soweit ich mich erinnere geht das auch nur mit initrd (ohne die "echte" root-Partition).

Zu technischen Details ist das ArchWiki immer ganz gut, auch wenn einzelne Dinge natürlich immer von Distro zu Distro unterschiedlich sind.
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system

Beim Start spielt das noch keine Rolle. Bin noch nicht bis zur Passwortabfrage gekommen, der Fehler tritt vorher auf.

Meinst du dieser Paramter lässt den Kernel starten? Ich versuche es gleich mal und gebe dann ein Update.

Edit: das hat leider nichts geändert.

 

[GrumpyCat]

Das kann eigentlich nicht sein. Der Kernel startet, initialisiert Hardware, startet dann den init-Prozess aus der initrd, der dann normalerweise Treiber lädt und root mountet. Wenn Du mit dem o.g. Parameter den init-Prozess direkt durch bash ersetzt, bekommst Du eine Shell (und die initrd als /). Wenn das nicht passiert, hast Du den Parameter nicht richtig oder nicht an der richtigen Stelle gesetzt. Was genau hast Du denn gemacht? Bilder bitte im Zweifelsfall.

Wobei das alles jetzt auch nur Fingerübung ist, denn auch mit Shell will das eigentliche Problem ja auch gefunden und repariert werden; das ist aus einer initrd-Shell nicht so einfach, da ja erst eben Treiber geladen und Dateisysteme gemountet werden wollen.

 

[PerAstraAdDeum]

Ich habe den Zusatz "init=/bin/bash" ganz ans Ende des Paramters gehängt, also nach " ... quiet splash $vt_handoff".

 

[GrumpyCat]

quiet und splash wegmachen und detaillierter auf den Bootvorgang schauen (im Zweifelsfall Video mit Smartphone machen, falls es zu schnell geht) wäre schonmal eine Maßnahme.

 

[PerAstraAdDeum]

quiet und splash wegmachen und detaillierter auf den Bootvorgang schauen (im Zweifelsfall Video mit Smartphone machen, falls es zu schnell geht) wäre schonmal eine Maßnahme.

Probier ich gleich mal aus. Das "init=/bin/bash" bleibt bestehen?

Ergänzung (25. Dezember 2020)

Folgende Fehlermeldungen sind jetzt sichtbar:
VFS: Cannot open root device "mapper/neon--vg-root" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions: [danach kommt nichts]
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.4.0-56-generic #62-Ubuntu

 

[lokon]

Cannot open root device "mapper/neon--vg-root" or unknown-block(0,0):

da fehlt doch ein /dev/ vor "mapper/neon--vg-root"
Das rootfs scheint außerdem ein LVM (vg=Volume Group) zu sein - dafür muss auch Grub bzw. initrd vorbereitet sein afaik

edit: vgl zB hier ein "normaler" output

 

[PerAstraAdDeum]

Da der besagte Freund seinen Rechner schnellstmöglich wieder verwenden wollte, haben wir uns entschieden einfach neu zu installieren.
Nicht die eleganteste Lösung, aber immerhin kann er ihn jetzt wieder benutzen. Glücklicherweise hatte er umfangreiche Backups, so daß sich der Datenverlust auf ein paar Lesezeichen im Browser beschränkt hatte.