Bootfehler nach Ausprägungsänderung auf OCI Linux-Instanzen beheben

Einführung

In diesem Tutorial erfahren Sie, wie Sie Bootfehler bei benutzerdefinierten Oracle Cloud Infrastructure-(OCI-)Images beheben, die nach einer Ausprägungsänderung oder sogar einem einfachen Neustart aufgrund von Änderungen in zugrunde liegenden Gerätezuordnungen auftreten können.

Bevor wir in die Lösung eintauchen, sollten wir zunächst verstehen, was ein benutzerdefiniertes Bild ist.

Ein benutzerdefiniertes Image in OCI ist ein Snapshot des Boot-Volumes einer Instanz, in dem die Betriebssystemkonfiguration, die installierte Software und die Umgebungseinstellungen erfasst werden. Benutzerdefinierte Images werden häufig verwendet, um vorkonfigurierte Umgebungen über mehrere Instanzen oder Regionen hinweg zu replizieren und so eine skalierbare Konsistenz sicherzustellen.

Diese Images können jedoch Risiken bergen, insbesondere wenn sie eng mit der ursprünglichen Hardware der Instanz gekoppelt sind. Wenn das Design nicht auf Portabilität ausgerichtet ist, können Probleme beim Ändern von Ausprägungen auftreten (z.B. Wechsel von einer VM.Standard3 zu einer VM.Standard4-Instanz), da sich zugrunde liegende Hardwareänderungen auf die Zuordnung von Geräten auswirken können.

In diesem Blog wird ein realistisches Bootfehlerszenario beschrieben, das ein Kunde mit einem Rocky Linux-Image aus Oracle Cloud Marketplace vorfindet. Während dieses Beispiel für Rocky Linux spezifisch ist, gelten die Ursache und Auflösung weitgehend für jedes benutzerdefinierte Linux-basierte Image, das statische Gerätenamen in seiner Konfiguration verwendet.

Ziele

In diesem Handbuch können OCI-Benutzer Bootfehler in benutzerdefinierten Linux-Images identifizieren und beheben, die durch Ausprägungsänderungen oder Neustarts verursacht werden, indem Mountkonfigurationen korrigiert und die Imageportabilität verbessert wird.

Voraussetzungen

Aufgabe 1: Problem verstehen

  1. Prüfen Sie, wie sich Änderungen der OCI-Ausprägung auf die zugrunde liegende Hardware- und Gerätebenennung auswirken.
  2. Erkennen Sie, dass statische Gerätenamen in /etc/fstab (z.B. /dev/sdX) nach einer Ausprägungsänderung oder sogar nach einem Neustart ungültig werden können.
    • Wenn sich die Ausprägung ändert, kann das BS angehängten Block-Volumes neue Namen zuweisen. Beispiel: Eine Festplatte, die /dev/sdb war, wird jetzt als /dev/sdc angezeigt.
    • Wenn /etc/fstab auf diesen statischen Namen basiert, können die Volumes beim Booten möglicherweise nicht eingehängt werden.
    • Um diese Situation zu vermeiden, verwenden Sie persistente IDs, wie die Pfade UUID oder /dev/disk/by-uuid/ des Volumes in /etc/fstab.

Aufgabe 2: Symptome und Fehler identifizieren

  1. Prüfen Sie die serielle Konsole oder die Systemlogs (journalctl -xb) auf Fehler wie:

    • Welcome to emergency mode! After logging in, type “journalctl -xb”...
    • Failed to mount /mnt/data: No such device
    • Duplicate mount point /mnt/data detected
    • Cannot mount /dev/sdX: No such file or directory
    • systemd[1]: Failed to mount /mnt/data.
    • systemd[1]: Dependency failed for Local File Systems.
    • systemd[1]: Job local-fs.target/start failed with result ‘dependency’.

Aufgabe 3: Im Rettungs-/Notfallmodus starten

  1. Rufen Sie die serielle Konsole der Instanz auf.
  2. Booten Sie in den Rettungs- oder Notfallmodus, um Diagnosen und Korrekturmaßnahmen durchzuführen.

Aufgabe 4: Korrekte Gerätenamen identifizieren

  1. Führen Sie die Befehle blkid oder lsblk aus, um aktuelle Block-Devices und ihre UUIDs aufzulisten.

Aufgabe 5: Boot-Volume manuell mounten

  1. Hängen Sie das Boot-Volume mit dem richtigen Gerätenamen ein:

    • mount /dev/sdXn /mnt
    • chroot /mnt

Aufgabe 6: /etc/fstab bearbeiten

  1. Öffnen Sie /etc/fstab mit einem Editor (Beispiel: vi /etc/fstab)

    • Ersetzen Sie alle /dev/sdX-Einträge durch entsprechende persistente UUID-Werte aus blkid.
    • Entfernen Sie alle doppelten Mounteinträge. Hinweis: Dies ist ein einmaliger Fix, wenn persistente IDs verwendet werden, sollten zukünftige Ausprägungsänderungen dieses Problem nicht verursachen.

Aufgabe 7: Beenden und neu starten

  1. Beenden Sie die chroot-Umgebung: exit.
  2. Hängen Sie Volumes gegebenenfalls aus.
  3. Starten Sie die Instanz neu.

Tipps zur Vermeidung von Bootfehlern nach Änderungen der OCI-Ausprägung

  1. Persistente IDs verwenden: Geben Sie Datenträger immer in /etc/fstab an, indem Sie UUID= oder LABEL= anstelle von Gerätenamen wie /dev/sdX verwenden. Dadurch wird sichergestellt, dass die Einhängepunkte trotz Hardwareänderungen konsistent bleiben.
  2. Blkid-Audits ausführen: Führen Sie blkid vor und nach einer Ausprägungsänderung aus, um zu prüfen, ob Geräte-zu-UUID-Zuordnungen korrekt bleiben.
  3. Backup vor Änderungen: Sichern Sie Ihre Instanz oder Ihr Boot-Volume immer vor Ausprägungsänderungen, um das Recovery bei Problemen zu aktivieren.
  4. Ausprägungsänderungen in Nicht-Produktion testen: Testen Sie Ausprägungsänderungen zuerst in einer Nicht-Produktionsumgebung, wenn Sie Marketplace- oder benutzerdefinierte Images verwenden, die hartcodierte Mounts aufweisen.

Schlussfolgerung

Während dieses Problem unter Rocky Linux beobachtet wurde, kann es sich möglicherweise auf jedes Linux-basierte benutzerdefinierte Image auswirken, wenn Best Practices zum Einhängen von Datenträgern nicht befolgt werden. Die gute Nachricht ist, dass dies eine einmalige Korrektur ist. Nachdem /etc/fstab aktualisiert wurde, um persistente IDs wie UUIDs oder LABELs zu verwenden, sollten zukünftige OCI-Ausprägungsänderungen oder sogar Neustarts nicht zu Bootfehlern führen. Die proaktive Validierung Ihrer Konfiguration gewährleistet reibungslose, zuverlässige Übergänge über verschiedene Formen hinweg.

Bestätigungen

Weitere Lernressourcen

Sehen Sie sich weitere Übungen zu docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube-Kanal zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um ein Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.