„ALARM! UUID=xxx existiert nicht. Wechsel zu einer Shell!“ Wo/wie kann ich diesen xxx-Wert ändern? Wo ist er in der Grub-Konfiguration gespeichert?

„ALARM! UUID=xxx existiert nicht. Wechsel zu einer Shell!“ Wo/wie kann ich diesen xxx-Wert ändern? Wo ist er in der Grub-Konfiguration gespeichert?

Ich habe ein paar Festplatten auf meinem Server (für RAID) und ein paar Bootpartitionen, um verschiedene Distributionen zu testen. Irgendwann hatte ich ein aktuelles (10 Buster) Debian 32 Bit und ein aktuelles (10 Buster) Debian 64 Bit, und aus irgendeinem Grund habe ich beschlossen, das Debian 64 Bit auf eine niedrigere Partition zu verschieben (mit dd, indem ich eine neue UUID einrichtete und sie in /etc/fstab dieser Partition aktualisierte), und dann habe ich ein aktuelles (20.1 Ulyssa) Linux Mint Cinnamon auf der Partition installiert, auf die sich das Debian befand, das ich zuvor verschoben hatte. Ich habe nicht damit gerechnet, dass es Probleme geben würde, weil die Installation von Linux Mint update-grub ausführen und meine neue Partition für Debian 64 übernehmen würde, aber zu diesem Zeitpunkt funktionierte mein Debian 64 Bit nicht mehr. Dies deutete darauf hin, dass es die Root-Partition nicht finden konnte.

Dazu gibt es ein paar Anmerkungen: Der Debian-Installationsprozess warnt mich ganz nett, dass es möglicherweise nicht UEFI-Partitionen gibt, die möglicherweise nicht mehr funktionieren, wenn ich versuche, Grub im UEFI-Modus zu installieren (und schlägt vor, im BIOS-Kompatibilitätsmodus zu starten) -), was Mint anscheinend nicht besonders interessiert. Und so hat Mint mein Grub im UEFI-Modus konfiguriert. Das Seltsame ist jedoch, dass es mein Debian 64 am Laufen hielt, mein Debian 32 jedoch nicht.

Ich muss zugeben, dass mir der Grub-Prozess nie klar war, aber was ich nicht verstehe, ist, dass der Versuch, Grub von meinem Debian 32 aus neu zu installieren und zu aktualisieren, das Problem nicht gelöst hat, und der Versuch, eine Datei mit der fehlerhaften UUID in /etc & /boot (einschließlich Unterverzeichnissen) auf beiden Partitionen (Debian 32 & 64) zu finden. Schließlich habe ich das Problem gelöst, indem ich die Grub-Befehlszeile meines Debian 64 beim Booten bearbeitet und dann Grub von meinem Debian 64 aus neu installiert und aktualisiert habe.

Was ich jedoch wirklich gerne verstehen würde, ist, wo diese UUID gespeichert war (warum ich sie nicht finden konnte) und warum ich dieses Problem nicht von meiner Debian 32-Partition aus lösen konnte.

BEARBEITEN: Um es klarzustellen: Ich konnte booten, indem ich root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx durch root=/dev/sdxx ersetzte, indem ich die Kernelparameter während des Bootvorgangs im Grub-Menü bearbeitete und initrd im anschließenden Grub-Wiederherstellungsprozess NICHT geändert wurde. Ich konnte diesen UUID-Wert (weder xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx noch xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) jedoch in keiner unkomprimierten Datei in /etc & /boot finden.

EDIT2: Ok... Was ich gesucht habe, war in /boot/grub/grub.cfg (danke an Archemar), aber ich habe es nicht gefunden, weil ich meinen regulären Ausdruck bei der Suche verwechselt habe in

find /boot /etc -type f -print0 | 
    xargs -0 grep -li 'a9c85b02-?751e-?48b5-?b85e-?df60d20b5d3e' 

grep-Regexps erkennen ? nicht. Ich hätte stattdessen {0,1} verwenden sollen... :'(

find /boot /etc -type f -print0 | 
    xargs -0 grep -li 'a9c85b02-\{0,1\}751e-\{0,1\}48b5-\{0,1\}b85e-\{0,1\}df60d20b5d3e' 

Es erklärt jedoch nicht, warum es nicht funktionierte, als ich Grub von meiner Debian 32-Partition neu installierte und neu konfigurierte. Basiert die Erkennung anderer Linux-Partitionen zufällig auf der Analyse dieser /boot/grub/grub.cfgPartitionen??? :-o

Antwort1

Ich hatte ein ähnliches Problem in VMware, als ich die Boot- und Systemfestplatte von einer 800-GB-Festplatte auf eine 16-GB-Festplatte verschoben habe. Das einfache Kopieren von Partition und Datei (von der 800-GB-Festplatte auf die 16-GB-Festplatte) und das Löschen der 800-GB-Festplatte hätte nicht ausgereicht (Kernel-Boot funktioniert, aber /die UUID kann nicht gefunden werden). (Und leider war der Snapshot von VMware in diesem Fall nicht als Rollback-Schutz nützlich.)

  • Einhängepunkte sind drin /etc/fstab, aber es gibt2 fstab
  • schlicht fstabist in/etc
  • Das Geheimnis /etc/fstabbefindet sich initrd.gz(oder etwas Ähnliches) in der /bootPartition der Boot-Festplatte. Diese fstab enthält die UUID, die auf /(Root-FS) des Betriebssystems verweist.

Führen Sie einen Neuaufbau durch initrd, wenn Sie von diesem Betriebssystem gebootet haben.

Oder wenn Sie von einem anderen Betriebssystem gebootet haben und initrd.gzes sich um ein gzipptes CPIO handelt, extrahieren Sie „einfach“ fstabdie Datei, bearbeiten Sie sie und fügen Sie sie wieder ein initrd.gz.

verwandte Informationen