Oracle Cloud Infrastructure - Dokumentation

Beschädigte Boot-Volumes für Linux-basierte Instanzen wiederherstellen

Wenn Ihre Instanz nicht erfolgreich oder mit schreibgeschütztem Boot-Volume bootet, ist das Boot-Volume der Instanz möglicherweise beschädigt. In seltenen Fällen kann das Boot-Volume in den folgenden Szenarios beschädigt werden:

  • Wenn mit der API das Herunterfahren einer Instanz erzwungen wird.

  • Wenn bei einer Instanz ein System aufgrund eines Betriebssystem- oder Softwarefehlers hängt, ein ordnungsgemäßes Neustarten bzw. Herunterfahren der Instanz wegen Timeout abgebrochen und das Herunterfahren der Instanz erzwungen wird.

  • Wenn ein Fehler oder Ausfall in der zugrunde liegenden Infrastruktur auftritt und kritische Datenträgerschreibzugriffe im System ausstehen.

Wichtig

In den meisten Fällen werden Probleme mit beschädigten Boot-Volumes durch einen einfachen Neustart behoben. Führen Sie daher als erste Maßnahme zur Fehlerbehebung einen Neustart aus.

In diesem Thema wird beschrieben, wie Sie überprüfen können, ob das Boot-Volume Ihrer Linux-basierten Instanz beschädigt ist, und welche Schritte Sie zur Fehlerbehebung und Wiederherstellung des beschädigten Boot-Volumes ausführen müssen. Weitere Informationen über Windows-Instanzen finden Sie unter Beschädigte Boot-Volumes für Windows-basierte Instanzen wiederherstellen.

Boot-Volume-Beschädigung erkennen

Eine Beschädigung des Boot-Volumes kann dazu führen, dass eine Instanz nicht erfolgreich gebootet wird. Dadurch können Sie also möglicherweise keine SSH-Verbindung zur Instanz herstellen. Stattdessen können Sie eine Instanzkonsolenverbindung zu einer fehlerhaften Instanz herstellen. Weitere Informationen zur Verwendung dieses Features finden Sie unter Fehlerbehebung bei Instanzen mit Instanzkonsolenverbindungen.

In diesem Abschnitt wird beschrieben, wie Sie mit einer seriellem Konsolenverbindung überprüfen, ob das Boot-Volume beschädigt ist.

Tipp

Wenn Sie bereits eine Beschädigung des Boot-Volumes Ihrer Instanz festgestellt haben oder ein importiertes benutzerdefiniertes Image verwenden, fahren Sie mit dem Abschnitt Boot-Volume wiederherstellen fort. In diesem Abschnitt wird beschrieben, wie Sie eine zweite Instanz zusammen mit Standard-Dateisystemtools verwenden, um eine Beschädigung des Boot-Volumes zu erkennen und zu beheben.
  1. Erstellen Sie eine serielle Konsolenverbindung für die Instanz.

  2. Stellen Sie über die serielle Konsole eine Verbindung zur Instanz her.

    An dieser Stelle ist es normal, dass die serielle Konsole zu hängen scheint, da das System möglicherweise bereits abgestürzt ist.

  3. Starten Sie die Instanz über die Konsole neu.

  4. Wenn der Neustart ausgeführt wird, wechseln Sie zurück zum Terminalfenster. Dort werden Systemmeldungen von der Instanz angezeigt.

  5. Überwachen Sie die Meldungen, die beim Hochfahren des Systems angezeigt werden. Bei den meisten Betriebssystemen wird das Boot-Volume in den schreibgeschützten Modus versetzt, sobald eine Beschädigung des Datenträgers ermittelt wird, damit das Volume nicht durch Schreibvorgänge weiter beschädigt wird. Achten Sie daher auf Meldungen, die angeben, dass sich das Boot-Volume im schreibgeschützten Modus befindet. Beispiele:

    • An eine Instanz mit iSCSI-angehängten Boot-Volumes kann iscsiadm ein Volume nicht erfolgreich anhängen, da sich das Volume im schreibgeschützten Modus befindet. Dadurch wird in der Regel verhindert, dass Instanzen weiter booten. In der seriellen Konsole wird möglicherweise etwa folgende Meldung angezeigt:

      iscsiadm: Maybe you are not root?
iscsiadm: Could not lock discovery DB: /var/lock/iscsi/lock.write: Read-only file system
touch: cannot touch `/var/lock/subsys/iscsid': Read-only file system
touch: cannot touch `/var/lock/subsys/iscsi': Read-only file system

    • Auf einer Instanz mit paravirtualisiert angehängten Boot-Volumes kann das System den Boot-Prozess möglicherweise fortsetzen; der Status lautet jedoch "Heruntergestuft", da keine Schreibvorgänge auf dem Boot-Laufwerk möglich sind. In der seriellen Konsole werden möglicherweise etwa folgende Fehlermeldungen angezeigt:

      [FAILED] Failed to start Create Volatile Files and Directories.
See 'systemctl status systemd-tmpfiles-setup.service' for details.
...
[   27.160070] cloud-init[819]:     os.chmod(path, real_mode)
[   27.166027] cloud-init[819]: OSError: [Errno 30] Read-only file system: '/var/lib/cloud/data'

    Diese Fehlermeldungen und das hier beschriebene Systemverhalten treten bei Beschädigungen des Boot-Volumes häufig auf. Je nach Betriebssystem können jedoch andere Fehlermeldungen und abweichendes Systemverhalten auftreten. Wenn Sie die hier beschriebenen Symptome nicht beobachten, finden Sie in der Dokumentation Ihres Betriebssystems weitere Informationen zur Fehlerbehebung.

Boot-Volume wiederherstellen

Zur Fehlerbehebung und Wiederherstellung des beschädigten Boot-Volumes müssen Sie die Zuordnung des Boot-Volumes zur Instanz aufheben und das Boot-Volume dann als Daten-Volume einer zweiten Instanz zuordnen.

Zuordnung des Boot-Volumes aufheben

Wenn Sie festgestellt haben, dass das Boot-Volume der Instanz beschädigt ist, müssen Sie die Zuordnung des Boot-Volumes zur Instanz aufheben, bevor Sie mit den Schritten zur Fehlerbehebung und Wiederherstellung beginnen können.

  1. Instanz stoppen.
  2. Heben Sie die Zuordnung des Boot-Volumes zur Instanz auf.

Boot-Volume als Daten-Volume einer zweiten Instanz zuordnen

Für die zweite Instanz wird empfohlen, dass Sie eine Instanz mit einem Betriebssystem verwenden, das dem Betriebssystem für die Instanz des Boot-Volumes am ehesten entspricht. Sie sollten Boot-Volumes für Linux-basierte Instanzen nur anderen Linux-basierten Instanzen zuordnen. Die zweite Instanz muss sich in derselben Availability-Domain und Region wie die Instanz des Boot-Volumes befinden. Wenn keine vorhandene Instanz verfügbar ist, erstellen Sie eine neue Linux-Instanz mit den unter Instanzen erstellen beschriebenen Schritten. Stellen Sie nach der zweiten Instanz sicher, dass Sie sich auf der Instanz anmelden können und dass sie funktionstüchtig ist, bevor Sie mit den Recovery-Schritten fortfahren. Die Schritte für den Zugriff auf die Instanz finden Sie unter Verbindungen zu Linux-Instanzen herstellen. Nachdem Sie überprüft haben, ob die Instanz funktionstüchtig ist, führen Sie die folgenden Schritte aus.

  1. Führen Sie den Befehl lsblk aus, und notieren Sie die Laufwerke, die sich derzeit in der Instanz befinden. Beispiel:

    lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]
├─sda3   8:3    0 38.4G  0 part /
└─sda1   8:1    0  200M  0 part /boot/efi
  2. Ordnen Sie das Boot-Volume der zweiten Instanz als Daten-Volume zu. Weitere Informationen finden Sie unter Boot-Volumes anhängen.
    So ordnen Sie das Boot-Volume als Daten-Volume zu
    1. Öffnen Sie das Navigationsmenü , und wählen Sie Compute aus. Wählen Sie unter Compute die Option Instanzen aus.
    2. Wählen Sie die Instanz aus, an die Sie ein Volume anhängen möchten.
    3. Wählen Sie unter Ressourcen Angehängte Block-Volumes aus.
    4. Wählen Sie Block-Volume anhängen aus.

    5. Wählen Sie den Volume-Zuordnungstyp aus. Wenn für diese Instanz paravirtualisierte Anhänge verfügbar sind, wird empfohlen, diesen Zuordnungstyp für dieses Verfahren auszuwählen.

      Wenn Sie iSCSI als Volume-Zuordnungstyp auswählen, müssen Sie eine Verbindung zum Volume herstellen. Weitere Informationen finden Sie unter Verbindungen zu Block-Volumes herstellen.

    6. Wählen Sie in der Dropdown-Liste Block-Volume-Compartment das Compartment aus.
    7. Wählen Sie die Option Volume auswählen und dann im Abschnitt Boot-Volume der Dropdown-Liste Block-Volume das Volume aus.
    8. Wählen Sie Lesen/Schreiben als Zugriffstyp aus.

    9. Wählen Sie Anhängen aus.

      Wenn für das Volume nicht mehr das Symbol Angehängt angezeigt wird, fahren Sie mit den nächsten Schritten fort.

  3. Führen Sie den Befehl lsblk erneut aus, um zu überprüfen, ob das Boot-Volume jetzt als an die Instanz angehängtes Volume angezeigt wird. In dieser Beispielausgabe für lsblk wird das als Daten-Volume angehängte Boot-Volume als sdb angezeigt:
    lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb      8:16   0 46.6G  0 disk
├─sdb2   8:18   0    8G  0 part
├─sdb3   8:19   0 38.4G  0 part
└─sdb1   8:17   0  200M  0 part
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]
├─sda3   8:3    0 38.4G  0 part /
└─sda1   8:1    0  200M  0 part /boot/efi

  4. Führen Sie den Befehl fsck in der Root-Partition des Volumes aus. Die Root-Partition ist üblicherweise die größte Partition auf dem Volume.

    Das folgende Beispiel für den Befehl fsck zeigt die Ausgabe, wenn keine Fehler oder Beschädigung in den Partitionen für eine Oracle 7.6-Instanz vorhanden sind:

    sudo fsck -V /dev/sdb1
fsck from util-linux 2.23.2
[/sbin/fsck.vfat (1) -- /boot/efi] fsck.vfat /dev/sdb1
fsck.fat 3.0.20 (12 Jun 2013)
/dev/sdb1: 17 files, 2466/51145 clusters

sudo fsck -V /dev/sdb2
fsck from util-linux 2.23.2

sudo fsck -V /dev/sdb3
fsck from util-linux 2.23.2
[/sbin/fsck.xfs (1) -- /] fsck.xfs /dev/sdb3
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).

    Wenn Fehler in einer Partition vorhanden sind, werden Sie normalerweise aufgefordert, die Fehler zu beheben. Nachfolgend finden Sie ein Beispiel einer interaktiven Reparatursession eines beschädigten ext4-Boot-Volumes für eine Ubuntu-Instanz:

    sudo fsck -V /dev/sdb1
fsck from util-linux 2.31.1
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 /dev/sdb1
e2fsck 1.44.1 (24-Mar-2018)
One or more block group descriptor checksums are invalid.  Fix<y> yes
Group descriptor 92 checksum is 0xe9a1, should be 0x1f53.  FIXED.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: Group 92 block bitmap does not match checksum.
FIXED.

cloudimg-rootfs: ***** FILE SYSTEM WAS MODIFIED *****
cloudimg-rootfs: 75336/5999616 files (0.1% non-contiguous), 798678/12181243 blocks
    Hinweis

    XFS-Dateisysteme reparieren ihre Inhalte in der Regel automatisch, wenn das System hochgefahren wird, wobei eventuelle Beschädigungen während des Boot-Prozesses korrigiert werden. Mit dem Befehl xfs_repair können Sie eine Reparatur für Szenarios erzwingen, in denen eine Beschädigung des Boot-Volumes eine automatische Reparatur verhindert. Beispiel:

    sudo xfs_repair /dev/sdb3
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
...
Phase 7 - verify and correct link counts...
done