> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/de/backup-dr/rhel9-boot-failure-clone-snapshot-restore.md).

# VMs der RHEL-9-Familie starten nach Klonen oder Snapshot-Wiederherstellung nicht

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.

{% hint style="info" %}
**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
  {% endhint %}

{% hint style="info" %}
**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](/knowledge-base/de/virtual-machines/import-rhel-centos-vm.md) für Anweisungen, die das Anpassen der VM-Konfiguration und das Neuerzeugen des initramfs mit virtio-Treibern umfassen.
{% endhint %}

{% hint style="info" %}
**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](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/limiting-lvm-device-visibility-and-usage_configuring-and-managing-logical-volumes) zu den Geräten-Dateien.
{% endhint %}

## 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.

{% hint style="warning" %}
**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.
{% endhint %}

### 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`

  <div data-gb-custom-block data-tag="hint" data-style="success" class="hint hint-success"><p><strong>RHEL-9-Installationen verwenden typischerweise LVM, wobei das logische Root-Volume unter <code>/dev/mapper/rhel-root</code> (oder <code>almalinux-root</code>, <code>rocky-root</code>).</strong></p></div>
* Ü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:

  ```bash
  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

{% hint style="warning" %}
**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.
{% endhint %}

{% hint style="warning" %}
**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.
  {% endhint %}

## Zusätzliche Ressourcen

* [LVM-Gerätesichtbarkeit und -verwendung einschränken (Red Hat)](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/limiting-lvm-device-visibility-and-usage_configuring-and-managing-logical-volumes)
* [Logische Volumes konfigurieren und verwalten (Red Hat)](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/index)
* [Linux-VMs importieren — Allgemeiner Leitfaden](/knowledge-base/de/virtual-machines/import-rhel-centos-vm.md)
* [Best Practices für VMs](/run-the-platform/virtual-machines/vm-best-practices.md)

{% hint style="info" %}
**Brauchen Sie Hilfe?**

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/knowledge-base/de/backup-dr/rhel9-boot-failure-clone-snapshot-restore.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.