RHEL-9-VMs starten nach Klonen oder Snapshot-Wiederherstellung nicht mehr

Wie Sie Startfehler in RHEL-9-VMs (AlmaLinux, Rocky, CentOS Stream) nach dem Klonen oder der Wiederherstellung eines Snapshots in VergeOS beheben, verursacht durch die LVM-Datei system.devices, die die ursprünglichen Datenträger-Seriennummern bindet.

Dieser Leitfaden behandelt einen bestimmten Bootfehler: eine VM der RHEL-9-Familie (RHEL, AlmaLinux 9, Rocky Linux 9 oder CentOS Stream 9), die auf dem Quellsystem problemlos startet, dann aber bei einer geklonten oder aus einem Snapshot wiederhergestellten Instanz fehlschlägt, weil die system.devices-Datei von LVM nicht mehr mit den Laufwerksseriennummern der VM übereinstimmt. Die folgenden Schritte reparieren die VM aus dem Rettungsmodus. Wenn Sie das Klonen oder die Wiederherstellung noch nicht durchgeführt haben, siehe den "Verhindern dieses Problems bei zukünftigen Klonen, Snapshots oder Exporten-Hinweis weiter unten.

Symptome

• Nach der Wiederherstellung einer VM aus einem Snapshot oder nach dem Klonen einer VM lässt sich die RHEL-9-VM nicht starten (sie wechselt in den Notfallmodus oder bleibt beim Start hängen)
• Im Rettungsmodus gibt vgchange -ay keine Ausgabe aus, und lvdisplay zeigt nichts an

Überblick

RHEL 9 und seine Derivate (AlmaLinux 9, Rocky Linux 9, CentOS Stream 9) verwenden eine LVM-Gerätedatei unter /etc/lvm/devices/system.devices die Blockgeräte ausdrücklich anhand ihrer eindeutigen Kennungen auf eine Positivliste setzt — insbesondere anhand von Laufwerksseriennummern. Beim Start berücksichtigt LVM beim Zusammenstellen von Volume Groups nur die in dieser Datei aufgeführten Geräte. Wenn die von ihm erkannten Seriennummern nicht mit den in der Datei gespeicherten übereinstimmen, aktiviert LVM die Root-Volume-Group nicht, und die VM landet in einer dracut-Notfallshell.

Das bedeutet, dass jeder Vorgang, der einer VM neue Laufwerksseriennummern zuweist — also das Klonen einer VM mit neu erzeugten Hardware-Seriennummern oder das Wiederherstellen eines Snapshots auf eine Weise, die Seriennummern ändert — dazu führt, dass der Startvorgang fehlschlägt.

VergeOS 26.1.5 und höher

Ab VergeOS 26.1.5 behalten VM-Klone und Snapshot-Wiederherstellungen standardmäßig die ursprünglichen Laufwerksseriennummern bei, wodurch die Seriennummernabweichung bei den meisten Klon- und Wiederherstellungsvorgängen beseitigt wird. Dieses Problem betrifft am häufigsten:

• Kopien oder Wiederherstellungen, bei denen die Option zum Erzeugen neuer Hardware-Seriennummern ausdrücklich ausgewählt wurde
• Umgebungen mit VergeOS-Versionen vor 26.1.5

Importe von einem anderen Hypervisor

Der gleiche Bootfehler kann auch beim Importieren einer VM von einem anderen Hypervisor auftreten wenn die VM exportiert wurde, ohne ihre ursprünglichen Geräte-Seriennummern beizubehalten. Außerdem können importierte VMs aufgrund fehlender virtio-Treiber für VergeOS-Hardware nicht booten. Siehe Leitfaden zum Importieren einer Linux-VM für Anweisungen, die das Anpassen der VM-Konfiguration und das Neuerzeugen des initramfs mit virtio-Treibern umfassen.

Verhindern dieses Problems bei zukünftigen Klonen, Snapshots oder Exporten

Wenn Sie noch Zugriff auf eine funktionierende Quell-VM haben, können Sie den Bootfehler bei zukünftigen Klonen, Snapshots oder Exporten von einem anderen Hypervisor vermeiden, indem Sie die LVM-Gerätedatei deaktivieren bevor für den Vorgang. Setzen Sie use_devicesfile = 0 in /etc/lvm/lvm.conf auf dem Gast. LVM fällt dann auf das Scannen aller verfügbaren Blockgeräte zurück, unabhängig von der Seriennummer. Die LVM-Gerätedatei wurde hauptsächlich für Hosts entwickelt, die an ein SAN-Fabric angeschlossen sind, wo ein einzelner Rechner viele Blockgeräte sehen kann, die nicht zu ihm gehören; in einer typischen VergeOS-Umgebung sieht eine VM nur die ihr ausdrücklich zugewiesenen virtuellen Laufwerke, sodass der Schutz, den sie bietet, selten benötigt wird. Weitere Informationen zur Gerätedatei finden Sie in Red Hats Einschränken der Sichtbarkeit und Verwendung von LVM-Geräten zu den Geräten-Dateien.

Voraussetzungen

• Zugriff auf die VergeOS-Oberfläche und die VM-Konsole
• Ein Installations-ISO der RHEL-9-Familie, verfügbar in den VergeOS-Medien (nur erforderlich, wenn die VM das GRUB-Menü nicht erreicht)

Schritte

1. In eine Rettungsumgebung booten

Die VM wird wahrscheinlich nicht normal booten. Verwenden Sie eine der folgenden Methoden, um eine funktionierende Shell zu erreichen.

Option A — GRUB-Rettungskernel (bevorzugt)

• Schalten Sie die VM ein und öffnen Sie die Konsole in VergeOS.
• Drücken und halten Sie beim Start Shift (BIOS) oder Esc (UEFI), um auf das GRUB-Menü zuzugreifen.
• Wählen Sie Erweiterte Optionen und wählen Sie den Rettungs- Kernel-Eintrag.
• Folgen Sie allen Eingabeaufforderungen — wenn Sie gefragt werden, ob das Root-Dateisystem eingehängt werden soll, wählen Sie Fortfahren.

Option B — Von einem Installations-ISO booten

Wenn das GRUB-Menü nicht erreichbar ist oder die VM so weit nicht startet:

• Hängen Sie in VergeOS ein Installations-ISO der RHEL-9-Familie als CD/DVD-Laufwerk an die VM an.
• Passen Sie die Bootreihenfolge der VM so an, dass zuerst vom ISO gebootet wird, oder verwenden Sie eine einmalige Boot-Option.
• Navigieren Sie im Installationsmenü zu Fehlerbehebung → Ein [Distro]-System retten.
• Wenn Sie gefragt werden, ob das installierte System eingehängt werden soll, wählen Sie Option 1 (einhängen unter /mnt/sysimage).
• Wählen Sie Shell um eine Eingabeaufforderung zu öffnen.

Die ISO-Rettung verwendet einen anderen Einhängepfad

Bei der Verwendung des Installations-Rettungsmodus befindet sich Ihr installiertes System unter /mnt/sysimage statt unter /mnt. Passen Sie die nächsten Schritte entsprechend an.

2. Prüfen Sie, ob die Festplatte sichtbar ist, scannen Sie erneut und überprüfen Sie die Volume Groups

• Blockgeräte anzeigen:

  lsblk

  Notieren Sie den Gerätenamen (z. B. /dev/sda) und die LVM-Partition (z. B. /dev/sda3)
• LVM zum erneuten Scannen aller Blockgeräte zwingen (umgeht die Gerätedatei):

  pvscan --cache vgchange -ay
• Wenn der erneute Scan weiterhin nichts anzeigt, registrieren Sie die LVM-Partition explizit:

  lvmdevices --adddev /dev/sda3 Ersetzen Sie dies durch Ihre tatsächliche LVM-Partition aus lsblk vgchange -ay

  RHEL-9-Installationen verwenden typischerweise LVM, wobei das logische Root-Volume unter /dev/mapper/rhel-root (oder almalinux-root, rocky-root).
• Überprüfen Sie, ob die Volume Groups jetzt sichtbar sind

  lvdisplay

3. Root-Partition einhängen und die Dateisysteme binden

• mount /dev/<device_name> /mnt Ersetzen Sie <device_name> durch Ihre Root-Partition (z. B. sda2, mapper/vg0-root).
• Überprüfen Sie das Einhängen:

  ls /mnt

  Sie sollten Verzeichnisse wie /root, /boot, /home, /etc und /var sehen.
• Dateisysteme binden:

  Verwenden Sie die folgende for-Schleife, um die erforderlichen virtuellen Dateisysteme zu binden:

  for i in proc sys dev run; do mount --rbind /$i /mnt/$i; done

  ODER binden Sie sie einzeln ein:

  mount --rbind /proc /mnt/proc mount --rbind /sys /mnt/sys mount --rbind /dev /mnt/dev mount --rbind /run /mnt/run

  Bei EFI/UEFI-Systemen auch die EFI-Partition einhängen:

  mount /dev/sdX1 /mnt/boot/efi

  Ersetzen Sie /dev/sdX1 durch Ihre tatsächliche EFI-Partition (prüfen Sie mit lsblk oder fdisk -l).

4. Per chroot in das installierte System wechseln und zusätzliche Dateisysteme einhängen

• Wechseln Sie das Wurzelverzeichnis

  chroot /mnt
• Nach dem Wechsel per chroot, hängen Sie alle zusätzlichen Partitionen ein die in fstab definiert sind:

  mount -a

5. Initramfs neu erzeugen

• Erstellen Sie das initramfs neu damit es die bereinigte Gerätekonfiguration übernimmt:

  dracut -f --regenerate-all

6. Neu starten und überprüfen

• Verlassen Sie die chroot-Umgebung:

  exit
• Starten Sie die VM neu:

  reboot
• **Boot prüfen:** Bestätigen Sie, dass die VM erfolgreich startet und alle Laufwerke wie erwartet angezeigt werden.

Fehlerbehebung

GRUB-Menü kann nicht erreicht werden

Wenn die VM GRUB überhaupt nicht anzeigt, verwenden Sie Option B aus Schritt 1, um von einem Installations-ISO in den Rettungsmodus zu booten.

Kein Netzwerk nach dem Start

• Bestätigen Sie, dass die NIC in den VergeOS-VM-Einstellungen auf virtio gesetzt ist.
• Prüfen Sie, dass keine persistenten Netzwerkrichtlinien (70-persistent-net.rules) vorhanden sind, die verhindern würden, dass die neue Schnittstelle korrekt benannt wird.
• Führen Sie ip link show um zu sehen, ob eine NIC vorhanden, aber nicht konfiguriert ist, und prüfen Sie dann /etc/sysconfig/network-scripts/ oder NetworkManager auf die Schnittstellenkonfiguration.

Zusätzliche Ressourcen

• LVM-Gerätesichtbarkeit und -verwendung einschränken (Red Hat)
• Logische Volumes konfigurieren und verwalten (Red Hat)
• Linux-VMs importieren — Allgemeiner Leitfaden
• Best Practices für VMs

Brauchen Sie Hilfe?

Wenn nach Befolgen dieses Leitfadens weiterhin Startprobleme auftreten, wenden Sie sich bitte an den VergeOS-Support, um Unterstützung zu erhalten.