Wie kehre ich zu einem bekannten stabilen Kernel zurück, nachdem ein Update den Neustart meiner EC2-Instance blockiert hat?

Kurzbeschreibung

Wenn du ein Kernel-Update für die EC2-Linux-Instance durchgeführt hast, der Kernel aber jetzt beschädigt ist, kann die Instance nicht neu gestartet werden. Du kannst SSH auch nicht verwenden, um eine Verbindung zur betroffenen Instance herzustellen.

Um dieses Problem zu beheben, greife mit der seriellen EC2-Konsole auf das Root-Volume zu. Erstelle eine temporäre Rettungs-Instance und mounte dann das Amazon Elastic Block Store (Amazon EBS)-Volume erneut auf der Rettungs-Instance. Konfiguriere das GNU GRUB so, dass es den vorherigen Kernel verwendet und starte dann die Instance neu.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Zugriff auf das Root-Volume der Instance

Verwende die serielle EC2-Konsole oder eine Rettungs-Instance, um auf das Root-Volume zuzugreifen.

Verwenden der seriellen EC2-Konsole

Voraussetzungen: Du musst den Zugriff auf die serielle EC2-Konsole bereits konfiguriert haben. Wenn die Instance nicht erreichbar ist und du den Zugriff noch nicht konfiguriert hast, musst du eine Rettungs-Instance verwenden, um auf das Root-Volume zuzugreifen. Stelle außerdem sicher, dass du die Voraussetzungen für die serielle Konsole erfüllst.

Wenn du die serielle EC2-Konsole für Linux aktiviert hast, verwende sie für Nitro-basierte Instance-Typen, um Probleme bei Start-, Netzwerkkonfiguration und SSH-Konfiguration zu beheben.

Du kannst die serielle Konsole verwenden, um eine Verbindung zu der Instance ohne eine funktionierende Netzwerkverbindung herzustellen.

Bevor du die serielle Konsole verwendest, gewähre ihr auf AWS-Kontoebene Zugriff. Erstelle anschließend AWS Identity and Access Management (IAM)-Richtlinien, die den IAM-Benutzern Zugriff gewähren. Außerdem muss jede Instance, die die serielle Konsole verwendet, mindestens einen passwortbasierten Benutzer enthalten.

Eine Rettungs-Instance verwenden

Wichtig: Führe dieses Verfahren nicht auf einer vom Instance-Speicher unterstützten Instance durch. Das Wiederherstellungsverfahren erfordert ein Stoppen und Starten der Instance, sodass du die Daten der Instance verlierst.

Gehe wie folgt vor, um mit einer Rettungs-Instance auf das Root-Volume zuzugreifen:

1. Erstelle einen Amazon EBS-Snapshot des Root-Volumes.

2. Stoppe die betroffene Instance.

3. Trenne das Amazon EBS-Root-Volume (/dev/xvda oder /dev/sda1) von der betroffenen Instance. Notiere dir den Gerätenamen des Root-Volumes.
   Hinweis: Um das EBS-Volume in späteren Schritten leichter identifizieren zu können, kennzeichne das Volume, bevor du es trennst. Das Root-Gerät unterscheidet sich je nach Amazon Machine Image (AMI). Amazon Linux 2 (AL2) und Amazon Linux 2023 (AL2023) verwenden beispielsweise /dev/xvda. Ubuntu 14, 16, 18, CentOS 7 und Red Hat Enterprise Linux (RHEL) 7.5 verwenden jedoch /dev/sda1.

4. Starte eine EC2-Rettungs-Instance in derselben Availability Zone wie der Snapshot.
   Hinweis: Überprüfe den Produktcode der Instance. Bei einigen Produktcodes musst du eine EC2-Instance mit demselben Betriebssystemtyp (OS) starten. Wenn es sich bei der betroffenen-Instance beispielsweise um ein kostenpflichtiges RHEL-AMI handelt, musst du dann ein AMI mit demselben Produktcode starten. Wenn du eine AL2-Instance hast, musst du eine AL2-Rettungs-Instance erstellen, um Fehler zu vermeiden.

5. Schließe den Datenträger als sekundäres Gerät (/dev/sdf) an die Rescue-Instance an.

6. Verwende SSH, um eine Verbindung zu der Rettungs-Instance herzustellen.

7. Führe den folgenden Befehl aus, um die verfügbaren Festplattengeräte anzuzeigen:

   lsblk

   Beispielausgabe:

   NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
   xvda    202:0     0   15G  0 disk
   └─xvda1 202:1     0   15G  0 part /
   xvdf    202:0     0   15G  0 disk
       └─xvdf1 202:1 0   15G  0 part

   Hinweis: Nitro-basierte Instances zeigen EBS-Volumes als NVMe-Blockgeräte mit dem Festplattennamen nvme[0-26]n1 an. Beispielausgabe auf einer Nitro-basierten Instance:

   NAME           MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
   nvme0n1        259:0    0    8G  0 disk
   └─nvme0n1p1    259:1    0    8G  0 part /
   └─nvme0n1p128  259:2    0    1M  0 part
   nvme1n1        259:3    0  100G  0 disk
   └─nvme1n1p1    259:4    0  100G  0 part /

8. Führe den folgenden Befehl aus, um Root-Benutzer zu werden:

   sudo -i

9. Führe den folgenden Befehl aus, um die Root-Partition des bereitgestellten Volumes in /mnt zu mounten:

   mount -o nouuid /dev/xvdf1 /mnt

   Hinweis: Ersetze /dev/xvdf1 durch die Root-Partition des Volumes. Wenn /mnt in der Konfiguration nicht existiert, führe die folgenden Befehle aus, um ein Mount-Verzeichnis zu erstellen und hänge dann die Root-Partition in das neue Verzeichnis ein:

   mkdir /mnt
   mount -o nouuid /dev/xvdf1 /mnt

   Hinweis: Wenn du beim Ausführen des vorherigen Mount-Befehls eine Fehlermeldung erhältst, führe stattdessen den folgenden Befehl aus:

   mount /dev/xvdf1 /mnt

   Verwende als Nächstes das Mount-Verzeichnis, um auf die Daten der betroffenen Instance zuzugreifen.

10. Führe den folgenden Befehl aus, um /dev, /run, /proc und /sys der Rettungs-Instance in dieselben Pfade wie das eingehängte Volume einzuhängen:

for m in dev proc run sys; do mount -o bind {,/mnt}/$m; done

11. Wenn du eine separate /boot-Partition hast, hänge sie in /mnt/boot ein.
12. Um in das Mount-Verzeichnis zu wechseln, führe den folgenden Befehl aus:

chroot /mnt

Den Standard-Kernel im GRUB-Bootloader aktualisieren

Du findest den korrupten Kernel an Position 0 in der Liste und den letzten stabilen Kernel an Position 1. Um den korrupten Kernel durch den stabilen Kernel zu ersetzen, führe je nach Verteilung die folgenden Schritte aus.

GRUB1 (Legacy GRUB) für Red Hat 6

Um den korrupten Kernel durch den stabilen Kernel in der Datei /boot/grub/grub.conf zu ersetzen, führe den folgenden Befehl aus:

sed -i '/^default/ s/0/1/' /boot/grub/grub.conf

GRUB2 für Ubuntu 14 LTS, 16.04 und 18.04

Führe die folgenden Schritte aus:

1. Um den korrupten Standardmenüeintrag GRUB_DEFAULT=0 durch den stabilen Wert GRUB_DEFAULT=Saved in der Datei /etc/default/grub zu ersetzen, führe den folgenden Befehl aus:

   sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub

2. Um sicherzustellen, dass GRUB die Änderung erkennt, führe den folgenden Befehl aus:

   update-grub

   Hinweis: Möglicherweise erhältst du den Fehler „device-mapper: reload ioctl on osprober-linux-xvdaX failed: Device or resource busy Command failed“ beim Neuaufbau der Grub-Konfigurationsdatei. Um dieses Problem zu beheben, füge der Datei /etc/default/grub den Parameter GRUB_DISABLE_OS_PROBER=true hinzu und führe den vorherigen Befehl erneut aus.

3. Um sicherzustellen, dass Amazon EC2 den stabilen Kernel beim nächsten Neustart lädt, führe den folgenden Befehl aus:

   grub-set-default 1

GRUB2 für RHEL 7 und AL2

Führe die folgenden Schritte aus:

1. Um den korrupten Standardmenüeintrag GRUB_DEFAULT=0 durch den stabilen Wert GRUB_DEFAULT-saved in der Datei /etc/default/grub zu ersetzen, führe den folgenden Befehl aus:

   sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub

2. Führe den folgenden Befehl aus, um GRUB so zu aktualisieren, dass die Datei /boot/grub2/grub.cfg neu generiert wird:

   grub2-mkconfig -o /boot/grub2/grub.cfg

   Hinweis: Möglicherweise erhältst du den Fehler „device-mapper: reload ioctl on osprober-linux-xvdaX failed: Device or resource busy Command failed“ beim Neuaufbau der Grub-Konfigurationsdatei. Um dieses Problem zu beheben, füge der Datei /etc/default/grub den Parameter GRUB_DISABLE_OS_PROBER=true hinzu und führe den vorherigen Befehl erneut aus.

3. Um sicherzustellen, dass Amazon EC2 den stabilen Kernel beim nächsten Neustart lädt, führe den folgenden Befehl aus:

   grub2-set-default 1

GRUB2 für RHEL 8 und CentOS 8 und AL2023

GRUB2 verwendet blscfg-Dateien und Einträge in /boot/loader für die Boot-Konfiguration anstelle des vorherigen Formats grub.cfg. Es hat sich bewährt, das Grubby-Tool zu verwenden, um die blscfg-Dateien zu verwalten und Informationen aus /boot/loader/entries/ abzurufen. Wenn die blscfg-Dateien fehlen oder beschädigt sind, zeigt Grubby keine Ergebnisse an. Du musst die Dateien neu generieren, um die Funktionalität wiederherzustellen.

Gehe wie folgt vor, um den Standard-Kernel in GRUB2 zu aktualisieren:

1. Um den aktuellen Standard-Kernel zu sehen, führe den folgenden Befehl aus:

   grubby --default-kernel

2. Um alle verfügbaren Kernel und ihre Indizes zu sehen, führe den folgenden Befehl aus:

   grubby --info=ALL

   Beispielausgabe:

   root@ip-172-31-29-221 /]# grubby --info=ALLindex=0
   kernel="/boot/vmlinuz-4.18.0-305.el8.x86_64"
   args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto $tuned_params"
   root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"
   initrd="/boot/initramfs-4.18.0-305.el8.x86_64.img $tuned_initrd"
   title="Red Hat Enterprise Linux (4.18.0-305.el8.x86_64) 8.4 (Ootpa)"
   id="0c75beb2b6ca4d78b335e92f0002b619-4.18.0-305.el8.x86_64"
   index=1
   kernel="/boot/vmlinuz-0-rescue-0c75beb2b6ca4d78b335e92f0002b619"
   args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto"
   root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"
   initrd="/boot/initramfs-0-rescue-0c75beb2b6ca4d78b335e92f0002b619.img"
   title="Red Hat Enterprise Linux (0-rescue-0c75beb2b6ca4d78b335e92f0002b619) 8.4 (Ootpa)"
   id="0c75beb2b6ca4d78b335e92f0002b619-0-rescue"
   index=2
   kernel="/boot/vmlinuz-4.18.0-305.3.1.el8_4.x86_64"
   args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto $tuned_params"
   root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"
   initrd="/boot/initramfs-4.18.0-305.3.1.el8_4.x86_64.img $tuned_initrd"
   title="Red Hat Enterprise Linux (4.18.0-305.3.1.el8_4.x86_64) 8.4 (Ootpa)"
   id="ec2fa869f66b627b3c98f33dfa6bc44d-4.18.0-305.3.1.el8_4.x86_64"

   Notiere dir den Kernel-Pfad, den du als Standard für die Instance festgelegt hast. Im vorherigen Beispiel lautet der Kernelpfad an Index 2 /boot/vmlinuz- 0-4.18.0-80.4.2.el8_1.x86_64.

3. Um den Standard-Kernel der Instance zu ändern, führe den folgenden Befehl aus:

   grubby --set-default=/boot/vmlinuz-4.18.0-305.3.1.el8_4.x86_64

   Hinweis: Ersetze 4.18.0-305.3.1.el8_4.x86_64 durch die Versionsnummer des Kernels.

4. Führe den folgenden Befehl aus, um zu überprüfen, ob du den Standard-Kernel richtig konfiguriert hast:

   grubby --default-kernel

Die Instance erneut starten

Wenn du die serielle EC2-Konsole verwendet hast, lädt Amazon EC2 jetzt den stabilen Kernel. Du kannst die Instance neu starten.

Wenn du eine Rettungs-Instance für den Zugriff auf das Root-Volume verwendet hast, führe die folgenden Schritte aus:

1. Führe den folgenden Befehl aus, um chroot zu verlassen und /dev, /run, /proc und /sys abzusetzen:

   exit
   umount /mnt/{dev,proc,run,sys,}

2. Stoppe die Rettungs-Instance.

3. Trenne das Root-Volume von der Rettungs-Instance.

4. Das Root-Volume als Root-Volume /dev/xvda oder /dev/sda 1 an die ursprüngliche Instance anhängen

5. Starte die ursprüngliche Instance.

6. Amazon EC2 lädt jetzt den stabilen Kernel. Du kannst die Instance neu starten.