☰

Nach dem Ändern einer Systemfestplattenpartition bootet das System nicht und wechselt in die „Dracut Emergency Shell“. Wie bekomme ich es zum Booten?

tag-icon • tag-icon boot uuid dracut
Nach dem Ändern einer Systemfestplattenpartition bootet das System nicht und wechselt in die „Dracut Emergency Shell“. Wie bekomme ich es zum Booten?

Hintergrund

Ich hatte ein neues System, bei dem ich viel Zeit damit verbracht hatte, die Software so zu konfigurieren, dass alle möglichen Dienste ausgeführt wurden, und dann entdeckte ich, dass das Laufwerk möglicherweise fehlerhaft war. Also beschloss ich, die Festplatte auszutauschen und den Inhalt für die neue Festplatte aufzubewahren.

Die Systemfestplatte hatte auch ein Problem beim Booten in die richtige Version kernel, das ich nicht zu beheben schien (ich habe alle grubAnweisungen befolgt, aber standardmäßig wurde die richtige Version einfach nicht gebootet kernel, sondern nur, wenn man die richtige Version manuell auswählte). Also dachte ich, der beste Weg wäre, einfach eine Neuinstallation auf Fedora Serverder neuen Festplatte durchzuführen und das Bootproblem nebenbei zu beheben.

Was ist passiert

Die neue Festplatte war viel größer, also habe ich sie während des Installationsvorgangs etwas anders partitioniert. Dann habe ich das Laufwerk entfernt und sowohl die neue als auch die alte Systemfestplatte in einen anderen Server in meiner Nähe eingebaut. Aus übertriebener Vorsicht habe ich die fstabvon der neuen Systemfestplatte aufbewahrt, da ich wusste, dass sie die Partition hatte UUIDs.

Es gibt viele Möglichkeiten, Dinge zu verschieben, und ich entschied, dass ich eine saubere Root-Partition auf der neuen Systemfestplatte haben wollte. Ich dachte, dddas könnte vielleicht funktionieren, aber ich bin es gewohnt, es zu verwenden, wenn die Partitionen gleich groß sind, und war mir etwas unsicher, also formatierte ich stattdessen einfach die Root-Partition ("/") mit gparted. Dann verschob ich die Dateien mit normalen Betriebssystemtools. Dann schnitt ich das UUIDZeug aus der neuen Installation aus, fügte es in die sehr nicht vorrätige Version fstabdes Servers ein, den ich reparierte.

Das hat gut geklappt.

Dann habe ich versucht, das System zu booten. Es hat einen Fehler gemeldet, ist dann zum grubBootloader gekommen, hat automatisch den richtigen Kernel ausgewählt und los ging es! ... Bis es nicht mehr funktionierte!

Es kam zu „Plymouth-Startbildschirm anzeigen“ oder so ähnlich, pausierte und gab dann viele Timeout-Warnungen von etwas aus, das sich selbst aufrief dracut. Von hier aus habe ich mit meinem Telefon einen Screenshot gemacht. Er lautet:

Warning: Could not boot.
Starting Dracut Emergency Shell...
Warning: /dev/disk/by-uuid/<a uuid> does not exist
Generating "/run/initramfs/rdsosreport.txt"

gefolgt von einem Vorschlag zur Verwendung journalctlund eventuellen Speicherung rdsosreport.txtfür die Fehlerberichterstattung.

ACK! Was soll ich tun? Ich habe überall danach und nach dem oben zitierten Zeug gesucht Warning [...] does not exist. dracut emergency shellNichts!

Antwort1

Aktualisieren Sie die Fstab-Datei

Man muss /etc/fstabDateien mit der richtigen UUID der Partition aktualisieren

Crypttab aktualisieren

Wenn Ihre vorherige Partition verschlüsselt war, müssen Sie den Eintrag entfernen aus/etc/crypttab

Wenn Ihre neue Partition verschlüsselt ist, müssen Sie den entsprechenden Eintrag in der/etc/crypttab

Initramfs neu generieren

Nach dem Aktualisieren der /etc/fstabDatei /etc/crypttabmüssen Sie das Initramfs-Image mit Dracut aktualisieren.

Sie können das Dracut-Image aus der Dracut-Notfall-Shell aktualisieren, indem Sie Folgendes ausführen:

# dracut --hostonly --regenerate-all --force
Verweise

Antwort2

Die Nachricht:

Warning: /dev/disk/by-uuid/<uuid> does not exist

ist ein wichtiger Hinweis.

Es stellt sich heraus, dass die Root-Partition UUIDan zwei Stellen im grub2Teil der Partition des modernen Fedora-Servers gespeichert ist /boot. In diesem Szenario gibt es jedoch tatsächlich drei UUIDProbleme.

Durch die Neuformatierung der Root-Partition ("/") wurde tatsächlich die geändert UUID.UUIDDas Neue muss also erst entdeckt und dann an die richtigen Stellen gebracht werden. Es gibt viele Möglichkeiten, das zu finden UUIDs, aber ein Kommandozeilentool dafür ist blkid- wie in diesem Beispiel:

# blkid
/dev/sda1: UUID="64bbac09-1a12-4bea-8873-212ffb56f2a8" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="8a09913a-fdb2-42a0-98e3-6b89e16374d2"

Beachten Sie, dass dieses Tool für jede Partition zwei anzeigt UUIDs. Sie benötigen die erste davon. Beachten Sie auch, dass nicht privilegierte Benutzer nicht ausführen können blkid.

Dies sind die drei Orte, an denen sich die Root-Partition UUIDbefinden muss:

  1. In /etc/fstabder Zeile, in der die Einbindung der Root-Partition beschrieben wird, und;
  2. In /boot/grub2.cfgder Zeile „Kerneloptionen festlegen“. Am schnellsten finden Sie es, indem Sie nach ersterem suchen, UUIDfalls Sie es noch haben. Oder suchen Sie nach "set kernelopts="root=UUID=", und;
  3. In /boot/grub2/grubenveiner Zeile, die der in der Datei zitierten Zeile ähnelt /boot/grub2.cfg. Suchen Sie nach:kernelopts=root=UUID=

Denken Sie daran, nur die neue UUID zu ändern und alles andere so zu lassen, wie es war. Erstellen Sie vor dem Bearbeiten vorsichtshalber eine Sicherungskopie der Datei!

verwandte Informationen