Wie kann ich den Zugriff auf die serielle EC2-Konsole einer Linux-Instance konfigurieren, auf die nicht oder nicht zugegriffen werden kann?

Lesedauer: 9 Minute
0

Meine Amazon Elastic Compute Cloud (Amazon EC2) Linux-Instance ist nicht erreichbar oder nicht zugänglich. Ich habe den Zugriff auf die serielle EC2-Konsole nicht auf Betriebssystemebene konfiguriert.

Kurzbeschreibung

Gehen Sie wie folgt vor, um den Zugriff auf die serielle Konsole zu konfigurieren:

1.Greifen Sie auf das Root-Volume der Instance zu.

2.Legen Sie das Passwort für den Root-Benutzer oder einen anderen Betriebssystembenutzer fest.

3.Überprüfen und aktualisieren Sie die GRUB-Einstellungen für die serielle Konsole.

**Hinweis:**Sie können Schritt 3 überspringen, wenn die serielle EC2-Konsole auf der betroffenen Instance ordnungsgemäß funktioniert und Sie nur das Passwort für Ihren Betriebssystembenutzer festlegen müssen.

Voraussetzungen

Um die serielle Konsole verwenden zu können, stellen Sie sicher, dass Sie die Voraussetzungen erfüllen, mit Ausnahme von Legen Sie ein Betriebssystem-Benutzerkennwort fest. Das Einrichten eines Kennworts wird in der folgenden Behebung behandelt.

Behebung

Greifen Sie mit einer Rescue-Instance auf das Root-Volume der Instance zu

Erstellen Sie eine temporäre Rescue-Instance und mounten Sie dann Ihr Amazon Elastic Block Store (Amazon EBS) -Volume erneut auf der Rescue-Instance. Von der Rescue-Instance aus können Sie die GRUB-Einstellungen für die serielle Konsole überprüfen und ändern. Sie können auch das Passwort für den Root-Benutzer oder einen anderen Betriebssystembenutzer festlegen.

**Wichtig:**Führen Sie dieses Verfahren nicht auf einer Instance Store-Backed Instance durch. Da das Wiederherstellungsverfahren ein Stoppen und Starten Ihrer Instance erfordert, gehen alle Daten auf dieser Instance verloren. Weitere Informationen finden Sie unter Ermitteln des Root-Gerätetyps Ihrer Instance.

1.Erstellen Sie einen EBS-Snapshot des Root-Volumes. Weitere Informationen finden Sie unter Erstellen von Amazon EBS-Snapshots.

2.Öffnen Sie die Amazon-EC2-Konsole.

**Hinweis:**Vergewissern Sie sich, dass Sie sich in der richtigen Region befinden.

3.Wählen Sie im Navigationsbereich Instances aus und wählen Sie dann die beeinträchtigte Instance aus.

4.Wählen Sie Instance State, Stop Instance und dann Stop aus.

5.Wählen Sie auf der Registerkarte Speicher unter Geräte sperren die Volume-ID für /dev/sda1 oder /dev/xvda aus.

**Hinweis:**Das Root-Gerät unterscheidet sich je nach AMI, aber /dev/xvda oder /dev/sda1 sind für das Root-Gerät reserviert. Amazon Linux 1 und 2 verwenden beispielsweise /dev/xvda. Andere Distributionen wie Ubuntu 16, 18, CentOS 7 und RHEL 7.5 verwenden /dev/sda1.

6.Wählen Sie Aktionen, Lautstärke trennen und dannJa, Trennen aus. Beachten Sie die Availability Zone.

**Hinweis:**Sie können das EBS-Volume kennzeichnen bevor Sie es trennen, um es in späteren Schritten leichter identifizieren zu können.

7.Starten Sie eine EC2-Rescue-Instance in derselben Availability Zone.

**Hinweis:**Je nach Produktcode müssen Sie möglicherweise eine EC2-Instance desselben Betriebssystemtyps starten. Wenn es sich bei der beeinträchtigten EC2-Instance beispielsweise um ein kostenpflichtiges RHEL-AMI handelt, müssen Sie ein AMI mit demselben Produktcode starten. Weitere Informationen finden Sie unter Holen Sie sich den Produktcode für Ihre Instance.

Wenn auf der ursprünglichen Instance SELinux ausgeführt wird (z. B. RHEL, CentOS 7 oder 8), starten Sie die Rescue-Instance von einem AMI aus, das SELinux verwendet. Wenn Sie ein AMI auswählen, auf dem ein anderes Betriebssystem ausgeführt wird, z. B. Amazon Linux 2, weist jede geänderte Datei auf der ursprünglichen Instance fehlerhafte SELinux-Labels auf.

8.Wählen Sie nach dem Start der Rescue-Instance im Navigationsbereich die Option Volumes aus und wählen Sie dann das abgetrennte Root-Volume der ursprünglichen Instance aus.

9.Wählen Sie Aktionen, Volume anhängen.

10.Wählen Sie die Rescue-Instance-ID (id-xxxxx) und legen Sie dann ein unbenutztes Gerät fest. In diesem Beispiel /dev/sdf.

11.Verwenden Sie SSH, um eine Verbindung zu Ihrer Rescue-Instance herzustellen.

12.Führen Sie den Befehl lsblk aus, um Ihre verfügbaren Festplattengeräte anzuzeigen:

lsblk

Das Folgende ist ein Beispiel für die Ausgabe:

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 machen EBS-Volumes als NVMe-Blockgeräte verfügbar. Die vom Befehl lsblk auf Nitro-basierten Instances generierte Ausgabe zeigt die Festplattennamen als nvme\ [0-26] n1 an. Weitere Informationen finden Sie unter Amazon EBS und NVMe auf Linux-Instances. Das Folgende ist ein Beispiel für die Ausgabe des Befehls lsblk 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 /

13.Führen Sie den folgenden Befehl aus, um root zu werden:

sudo -i

14.Hängen Sie die Root-Partition des gemounteten Volumes nach /mnt ein. Im vorherigen Beispiel ist /dev/xvdf1 oder /dev/nvme2n1p2 die Root-Partition des gemounteten Volumes. Weitere Informationen finden Sie unter Bereitstellen eines Amazon EBS-Volumes für die Verwendung unter Windows.

**Hinweis:**Ersetzen Sie im folgenden Beispiel /dev/xvdf1 durch die richtige Root-Partition für Ihr Volume.

mount -o nouuid /dev/xvdf1 /mnt

**Hinweis:**Falls /mnt in Ihrer Konfiguration nicht existiert, erstellen Sie ein Mount-Verzeichnis und hängen Sie dann die Root-Partition des gemounteten Volumes in dieses neue Verzeichnis ein.

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

Sie können jetzt über das Mount-Verzeichnis auf die Daten der beeinträchtigten Instance zugreifen.

15.Hängen Sie /dev, /run, /proc, and /sys der Rescue-Instance in dieselben Pfade ein wie das neu gemountete Volume:

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

Rufen Sie die Funktion chroot auf, um in das Mount-Verzeichnis zu wechseln.

**Hinweis:**Wenn Sie über separate /boot- und /etc-Partitionen verfügen, mounten Sie diese in /mnt/boot und /mnt/etc, bevor Sie den folgenden Befehl ausführen.

chroot /mnt

Legen Sie das Passwort für den Root-Benutzer oder einen anderen Betriebssystembenutzer fest.

Verwenden Sie den Befehl passwd, um das Passwort für Ihren Betriebssystembenutzer festzulegen. Im folgenden Beispiel ist der Benutzer root:

passwd root

Überprüfen und aktualisieren Sie die GRUB-Einstellungen für die serielle Konsole.

**Hinweis:**Sie können diesen Schritt überspringen, wenn die serielle EC2-Konsole auf der betroffenen Instance ordnungsgemäß funktioniert und Sie nur das Passwort für Ihren Betriebssystembenutzer festlegen müssen.

Der unterstützte serielle Konsolenport für Linux ist ttyS0. Wenn der Bildschirm beim Herstellen einer Verbindung zur seriellen EC2-Konsole schwarz bleibt, ohne dass eine Ausgabe erfolgt, sollten Sie sicherstellen, dass der Konsoleneintrag in den GRUB-Einstellungen richtig konfiguriert ist. Die folgenden Beispiele stammen aus den AWS Marketplace-AMIs für die verschiedenen Distributionen, in denen die serielle Konsole ordnungsgemäß funktioniert:

GRUB2 für Amazon Linux 2, RHEL und CentOS 7

1.Stellen Sie sicher, dass der Konsolen-Eintrag für ttyS0 in der Zeile GRUB_CMDLINE_LINUX_DEFAULT der Datei /etc/default/grub richtig eingestellt ist:

Amazon Linux 2

GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"

RHEL 7

GRUB_CMDLINE_LINUX="console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau crashkernel=auto"

CentOS 7

GRUB_CMDLINE_LINUX="console=tty0 crashkernel=auto net.ifnames=0 console=ttyS0"
  1. Wenn der Konsoleneintrag für ttyS0 nicht gesetzt ist, fügen Sie ihn in die Zeile GRUB\ _CMDLINE\ _LINUX\ _DEFAULT ein. Aktualisieren Sie anschließend GRUB, um die Datei /boot/grub2/grub.cfg neu zu generieren:
grub2-mkconfig -o /boot/grub2/grub.cfg

GRUB1 (Legacy GRUB) für Red Hat 6 und Amazon Linux 1

1.Stellen Sie sicher, dass der Konsoleneintrag für ttyS0 in der Kernelzeile der Datei /boot/grub/grub.conf richtig gesetzt ist:

Amazon Linux 1

kernel /boot/vmlinuz-4.14.252-131.483.amzn1.x86_64 root=LABEL=/ console=tty1 console=ttyS0 selinux=0 nvme_core.io_timeout=4294967295

Red Hat 6

kernel /boot/vmlinuz-2.6.32-573.el6.x86_64 console=ttyS0 console=ttyS0,115200n8 ro root=UUID=0e6b1614-7bbe-4d6e-bc78-a5556a123ba8 rd_NO_LUKS  KEYBOARDTYPE=pc KEYTABLE=us LANG=en_US.UTF-8 xen_blkfront.sda_is_xvda=1 console=tty0 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_LVM rd_NO_DM

2.Wenn der Konsoleneintrag für ttyS0 nicht gesetzt ist, fügen Sie ihn gemäß den vorherigen Beispielen in die Datei /boot/grub/grub.conf ein.

GRUB2 for Ubuntu 16.04, 18.04 and 20.04

1.Stellen Sie sicher, dass der Konsolen-Eintrag für ttyS0 in der Zeile GRUB_CMDLINE_LINUX_DEFAULT der Datei /etc/default/grub.d/50-cloudimg-settings.cfg richtig eingestellt ist:

GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295"

2.Falls der Konsoleneintrag Console=ttyS0 nicht vorhanden**, ** fügen Sie ihn in die Zeile GRUB_CMDLINE_LINUX_DEFAULT ein. Aktualisieren Sie anschließend die GRUB-Konfiguration mit dem folgenden Befehl:

update-grub

**GRUB2 für RHEL 8, CentOS 8 und Amazon Linux 2023
**

1.Führen Sie den Befehl grubby --default-kernel aus, um den aktuellen Standard-Kernel zu sehen:

grubby --default-kernel

2.Führen Sie den Befehl grubby --info=ALL aus, um alle verfügbaren Kernel, ihre Indizes und ihre Argumente zu sehen:

grubby --info=ALL

3.Stellen Sie sicher, dass der Konsoleneintrag für ttyS0 in der Zeile args für den in Schritt 1 beschriebenen Standard-Kernel richtig gesetzt ist.

RHEL 8:

index=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"

CentOS 8

index=2
kernel="/boot/vmlinuz-4.18.0-193.19.1.el8_2.x86_64"
args="ro console=ttyS0,115200n8 no_timer_check net.ifnames=0 nvme_core.io_timeout=4294967295 nvme_core.max_retries=10 crashkernel=auto $tuned_params"
root="UUID=b437cbaa-8fe5-49e4-8537-0895c219037a"
initrd="/boot/initramfs-4.18.0-193.19.1.el8_2.x86_64.img $tuned_initrd"
title="CentOS Linux (4.18.0-193.19.1.el8_2.x86_64) 8 (Core)"
id="dc49529e359897df0b9664481b009b1f-4.18.0-193.19.1.el8_2.x86_64"

Amazon Linux 2023

[root@ip-172-31-92-173 ~]# grubby --info DEFAULTindex=0
kernel="/boot/vmlinuz-6.1.15-28.43.amzn2023.x86_64"
Acessing serial console on Amazon Linux 2023
root="UUID=7efef47b-a4f8-4b90-9504-8196067a31b6"
initrd="/boot/initramfs-6.1.15-28.43.amzn2023.x86_64.img"
title="Amazon Linux (6.1.15-28.43.amzn2023.x86_64) 2023"
id="02c860b8daad4861b87f9b3603834c8f-6.1.15-28.43.amzn2023.x86_64"

4.Wenn der Konsoleneintrag für ttyS0 nicht gesetzt ist, verwenden Sie den folgenden Grubby-Befehl, um ihn an die args des Standard-Kernels anzuhängen:

grubby --args "console=tty0 console=ttyS0,115200n8" --update-kernel DEFAULT

Hängen Sie das Root-Volume von der Rescue-Instance aus, trennen Sie es von der Rescue-Instance und fügen Sie das Volume dann der beeinträchtigten Instance hinzu

1.Verlassen Sie chroot, und schalten Sie**/dev**, /run, /proc, und /sys aus:

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

2.Wählen Sie in der Amazon EC2-Konsole Instances und dann die Rescue-Instance aus.

3.Wählen Sie Instance-Status, Instance beenden und dann Ja, Stopp aus.

4.Trennen Sie das Root-Volume id-xxxxx (das Volume der beeinträchtigten Instance) von der Rescue-Instance.

5.Hängen Sie das Root-Volume, das Sie in Schritt 4 getrennt haben, als Root-Volume (/dev/sda1) an die beeinträchtigte Instance an und starten Sie dann die Instance.

**Hinweis:**Das Root-Gerät unterscheidet sich je nach AMI. Die Namen /dev/xvda oder /dev/sda1 sind für das Root-Gerät reserviert. Amazon Linux 1 und 2 verwenden beispielsweise /dev/xvda. Andere Distributionen wie Ubuntu 16, 18, CentOS 7 und RHEL 7.5 verwenden /dev/sda1.

Jetzt können Sie über die serielle EC2-Konsole auf das Betriebssystem der beeinträchtigten Instance zugreifen, indem Sie das Passwort verwenden, das im vorherigen Schritt für den Root-Benutzer oder einen anderen Betriebssystembenutzer definiert wurde.

Verwandte Informationen

Problembehandlung Ihrer Linux-Instance mithilfe von GRUB

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 2 Jahren