[Gelöst] GRUB zerschossen "failed to mount as root file system"

[sebasdf]

Hallo zusammen,

Ich habe mein Produktiv-Debian mit LUKS auf einer Nvme-SSD installiert und ein weiteres Debian zum spielen unverschlüsselt auf einer SATA-SSD.
Ein Update auf letzterem Debian hat (vermutlich) irgendetwas in GRUB zerschossen, weil ich seitdem im GRUB-Menu nicht mehr mein Produktiv-Debian auswählen kann.
Daten sind alle noch da und so weit ich sehen kann in Ordnung.
Im Bootmenü kann ich den Nvme-Datenträger aufrufen und komme auf eine GRUB-Kommandozeile. Suchmaschine hat mich soweit gebracht, dass ich mit

Code: Alles auswählen

linux (hd9,gpt2)/vmlinuz-5.10.0-18-amd64 root=XXX???XXX ro

und

Code: Alles auswählen

initrd (hd9,gpt2)/initrd.img-5.10.0-18-amd64

und

Code: Alles auswählen

boot

etwas booten kann und meine Verschlüsselungsphrase abgefragt und akzeptiert wird. Dann lande ich aber in einer initramfs-Kommandozeile mit "failed to mount XXX???XXX as root file system.

Mich beschleicht das Gefühl, dass der Fehler im XXX???XXX liegt. Durch spicken an einem Laptop habe ich ausprobiert:
/dev/mapper/nvme0n1p3_crypt
/dev/nvme0n1p3
(hd9,gpt3) (die Partition, auf der das LUKS-Volume liegt)

und komme aber mit allen nicht weiter. Hat jemand einen Rat, was die korrekte Syntax hier lauten muss? Es war eine geführte Standardinstallation mit vollständig verschlüsselter Festplatte.

Bin für jede Hilfe dankbar, das surface Go, auf dem ich behelfsmäßig arbeite, bringt mich recht zügig zur Weißglut....

Grüße,
Sebastian

[DeletedUserReAsG]

Hängt davon ab, was zu dem Zeitpunkt genau auf deinem Bildschirm steht. Das Root-Dateisystem manuell mounten und weiterbooten könnte je nach Ausgangslage funktionieren. Anschließend dann die Fehlkonfiguration beheben. Sollte das nicht funktionieren, kann man auch ein Livesystem hernehmen und von da aus agieren.

Mich beschleicht das Gefühl, dass der Fehler im XXX???XXX liegt

XXXX???XXX sieht in der Tat wirklich kaputt aus. Den String habe ich auch noch nie gesehen – vielleicht falscher Charset eingestellt, oder so?

[sebasdf]

XXX???XXX war ein Platzhalter für die darunter aufgelisteten Optionen die ich schon ausprobiert habe. Sorry, schlechter Stil, war schon spät

Hier noch die Ausgabe der Fehlermeldung (abgetippt, daher evtl. Typos)

Code: Alles auswählen

cryptsetup: nvme0n1p3_crypt: set up successfully
done.
Begin: Running /scripts/local-premount ... [  16.614265] Btrfs loaded, crc32c=crc32c-intel
Scanning for Btrfs filesystems
done.
Begin: Will now check root file system ... fsck from util-linux 2.36.1
done.
mount: mounting /dev/mapper/nvme0n1p3_crypt on /root failed: No such device
Failed to mount /dev/mapper/nvme0n1p3_crypt as root file system.

BusyBox v.1.30.1 (Debian 1:1.30.1-6+b3) built in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

[hikaru]

Angenommen, da läuft wirklich nur eine luks-Verschlüsselung und nicht zusätzlich noch ein lvm (wird gern kombiniert), dann sieht /dev/mapper/nvme0n1p3_crypt strukturell ok aus. Irgendetwas unter /dev/mapper sollte es sein und nvme0n1p3_crypt ist zumindest plausibel, aber der konkrete Bezeichner ist natürlich individuell.
Konkrete Infos dazu sollte die zum System gehörende /etc/crypttab liefern.

Ich würde den Weg über ein "Live"-System gehen, die kaputte Installation mounten, chrooten und dann den Bootloader neu schreiben. Ich bin da aber nicht ganz unvoreingenommen, denn meine Grub-Kenntnisse sind eher rudimentär.
Danach solltest du prüfen, was bei dem Testsystem schief gegangen ist. Ich nehme an, dieses kann mangels installierter Pakete nicht mit luks umgehen und/oder hat keinen os-prober und wurde dann auf die falsche SSD installiert (Legacy-Boot) oder hätte besser gar kein eigenes Grub (UEFI-Boot).

[sebasdf]

Das könnte der Schlüssel sein, ich habe, glaube ich LUKS + LVM. Was würde das ändern?




Live-Image lädt gerade im Hintergrund. Das war gestern auch ein Versuch von der noch bootbaren Installation, aber irgendetwas lief dabei auch schief.

[hikaru]

Das könnte der Schlüssel sein, ich habe, glaube ich LUKS + LVM. Was würde das ändern?

Du müsstest halt zusätzlich zur luks-Verschlüsselung noch das lvm "aufmachen". Anleitungen dazu gibt's im Netz.
Konkrete Hilfe dazu kann ich dir leider nicht geben, denn auch wenn ich das Prinzip dahinter verstanden habe, ist mir das im praktischen Einsatz ein Ball zu viel zu jonglieren. Daher verzichte ich persönlich der Übersichtlichkeit halber auf den Zusatzschritt lvm.

[Tintom]

Hallo zusammen,

Ich habe mein Produktiv-Debian mit LUKS auf einer Nvme-SSD installiert und ein weiteres Debian zum spielen unverschlüsselt auf einer SATA-SSD.
Ein Update auf letzterem Debian hat (vermutlich) irgendetwas in GRUB zerschossen, weil ich seitdem im GRUB-Menu nicht mehr mein Produktiv-Debian auswählen kann.

Wahrscheinlich ist auf dem nicht-verschlüsselten Debian die Datei /etc/crypttab leer(?), denn die Daten daraus werden beim Kernel-Update und anschließendem Neubau der Initrd übernommen.

[sebasdf]

Also ich glaube, ich habe es hingekriegt:

Code: Alles auswählen

user@debian:~$ sudo mkdir /mnt/hdd
user@debian:~$ sudo mount /dev/mapper/dsktp--vg-root /mnt/hdd
user@debian:~$ sudo mount -t ext2 /dev/nvme0n1p2 /mnt/hdd/boot
user@debian:~$ sudo mount -t proc none /mnt/hdd/proc
user@debian:~$ sudo mount -o bind /dev /mnt/hdd/dev
user@debian:~$ sudo mount -o bind /sys /mnt/hdd/sys
user@debian:~$ sudo mount /dev/nvme0n1p1 /mnt/hdd/boot/efi
user@debian:~$ sudo mount /dev/nvme0n1p2 /mnt/hdd/boot
mount: /mnt/hdd/boot: /dev/nvme0n1p2 ist bereits auf /mnt/hdd/boot eingehängt.
user@debian:~$ sudo chroot /mnt/hdd

klappt, aber dann

Code: Alles auswählen

root@debian:/boot/efi# grub-install
i386-pc wird für Ihre Plattform installiert.
grub-install: Fehler: Kein Installationsgerät angegeben.

Ich hab doch kein i386-pc-System??

Nach der Anleitung auf ubuntuusers dann folgendes probiert:

Code: Alles auswählen

root@debian:/boot/efi# apt --reinstall install grub-common grub-efi-amd64 os-prober
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Das folgende Paket wurde automatisch installiert und wird nicht mehr benötigt:
  grub-pc-bin
Verwenden Sie »sudo apt autoremove«, um es zu entfernen.
Die folgenden zusätzlichen Pakete werden installiert:
  efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed mokutil shim-helpers-amd64-signed shim-signed shim-signed-common shim-unsigned
Empfohlene Pakete:
  secureboot-db
Die folgenden Pakete werden ENTFERNT:
  grub-pc
Die folgenden NEUEN Pakete werden installiert:
  efibootmgr grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed mokutil shim-helpers-amd64-signed shim-signed shim-signed-common shim-unsigned
0 aktualisiert, 9 neu installiert, 2 erneut installiert, 1 zu entfernen und 1 nicht aktualisiert.
Es müssen 5.142 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 18,6 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] J

Und im weiteren dann folgendes:

Code: Alles auswählen

grub-efi-amd64 (2.06-3~deb11u2) wird eingerichtet ...
x86_64-efi wird für Ihre Plattform installiert.
grub-install: Warnung: EFI variables are not supported on this system..
installation beendet. Keine Fehler aufgetreten.
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.10.0-18-amd64
Found initrd image: /boot/initrd.img-5.10.0-18-amd64
Found linux image: /boot/vmlinuz-5.10.0-17-amd64
Found initrd image: /boot/initrd.img-5.10.0-17-amd64
Found linux image: /boot/vmlinuz-5.10.0-8-amd64
Found initrd image: /boot/initrd.img-5.10.0-8-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
grub-probe: Fehler: Für /dev/sdd1 konnte kein GRUB-Laufwerk gefunden werden. Überprüfen Sie Ihre device.map.
Found Debian GNU/Linux 11 (bullseye) on /dev/sda2
done

/dev/sdd ist der Live-Stick
zur Sicherheit nochmal update-grub und jetzt bin ich wieder in meinem Produktiv-System.

Ich bin leider noch ziemlicher Anfänger, der nur geringfügig reflektierte Fundstellen aus dem Netz in die Kommandozeile einfügt. Sieht irgendjemand hier etwas, was mir später um die Ohren fliegen könnte? Insbesondere

Code: Alles auswählen

grub-install: Warnung: EFI variables are not supported on this system..

vielleicht?



@tintom:
Vielen Dank für den Tipp, aber sollte nicht ein Update auf einer Festplatte das GRUB auf der anderen in Ruhe lassen? Die Bootreihenfolge im BIOS habe ich nicht angerührt.

Vielen Dank einstweilen,
Sebastian

[Tintom]

@tintom:
Vielen Dank für den Tipp, aber sollte nicht ein Update auf einer Festplatte das GRUB auf der anderen in Ruhe lassen? Die Bootreihenfolge im BIOS habe ich nicht angerührt.

Wenn auf beiden Platten Grub installiert ist und keine von der anderen weiß, konkurrieren die beiden Systeme miteinander. Das kann dann zu solchen Effekten führen wie hier gesehen.

[sebasdf]

Wenn auf beiden Platten Grub installiert ist und keine von der anderen weiß, konkurrieren die beiden Systeme miteinander. Das kann dann zu solchen Effekten führen wie hier gesehen.

Guter Hinweis, danke! Der Problematik werde ich mich mal am Wochenende widmen.