In diesem Fall ging es um eine Debian-VM in Microsoft Azure, auf der eine produktive Anwendung lief. Die VM war über Nacht ausgefallen und am nächsten Morgen weder per SSH noch über die Weboberfläche der Anwendung erreichbar.

Im Azure Portal wurde die VM weiterhin als „Wird ausgeführt“ angezeigt. Auch ein Stoppen und erneutes Starten brachte keine Änderung.

Am Ende lag das Problem nicht an Azure selbst, sondern am GRUB-Bootloader der VM.

Fehlerbild

Das Fehlerbild war zunächst relativ unspezifisch:

• VM wird in Azure als gestartet angezeigt
• SSH funktioniert nicht
• Weboberfläche der Anwendung ist nicht erreichbar
• Neustart der VM bringt keine Änderung
• CPU-Auslastung nach dem Ausfall nur noch sehr gering

In den Azure-Metriken war außerdem zu erkennen, dass die Verfügbarkeit der VM während der Nacht auf 0 gefallen war.

Da sowohl SSH als auch die eigentliche Anwendung nicht mehr erreichbar waren, lag die Vermutung nahe, dass nicht nur ein einzelner Dienst ausgefallen war.

Resource Health prüfen

Ein erster sinnvoller Blick geht in Azure auf:

VM → Resource Health / Ressourcenintegrität

Dort war zum Zeitpunkt des Ausfalls ein Neustart zu sehen, der aus der VM selbst heraus ausgelöst worden war.

Sinngemäß:

Reboot initiated from inside the machine

Damit war zumindest klar, dass kein offensichtlicher Azure-Hostfehler den Neustart ausgelöst hatte.

Als mögliche Ursache kamen damit eher Dinge wie automatische Updates, Kernel-Updates oder ein geplanter Neustart aus dem Betriebssystem selbst infrage.

Startdiagnose prüfen

Der nächste wichtige Punkt war die Azure-Startdiagnose:

VM → Boot Diagnostics / Startdiagnose

Dort zeigte der Konsolen-Screenshot:

GNU GRUB version 2.x

grub>

Damit war die Richtung ziemlich eindeutig.

Debian wurde gar nicht mehr vollständig gestartet. Die VM hing bereits im GRUB-Bootloader.

Damit konnte man Netzwerk, SSH, Firewall-Regeln oder die eigentliche Anwendung zunächst weitgehend aus der Fehlersuche herausnehmen.

Serielle Konsole

Zusätzlich wurde die serielle Konsole getestet.

Die Verbindung zur VM konnte zwar hergestellt werden, es erschien aber keine Login-Konsole und auch keine weitere Ausgabe.

Das passte zum bisherigen Fehlerbild, da das Betriebssystem zu diesem Zeitpunkt gar nicht bis zu einem normalen Systemstart kam.

Vor der Reparatur: Snapshot erstellen

Bevor Änderungen an der VM vorgenommen wurden, wurde zunächst ein Snapshot der OS-Disk erstellt.

Der Weg ist beispielsweise:

VM → Datenträger → Betriebssystemdatenträger → Snapshot erstellen

Gerade bei Bootproblemen ist das sinnvoll, damit vor Reparaturversuchen ein unveränderter Stand der Disk erhalten bleibt.

Zusätzlich wurde der Snapshot als VHD exportiert und lokal heruntergeladen.

Fehler lokal mit Hyper-V nachstellen

Die heruntergeladene VHD wurde anschließend testweise in Hyper-V eingebunden.

Da es sich bei der Azure-VM um eine Generation-1-VM handelte, wurde auch lokal eine Hyper-V-VM der Generation 1 erstellt.

Nach dem Start zeigte sich lokal exakt das gleiche Bild:

grub>

Damit war bestätigt, dass das Problem tatsächlich auf der Systemdisk lag und nicht durch Azure selbst verursacht wurde.

GRUB prüfen

Am GRUB-Prompt wurde zunächst geprüft, welche Datenträger erkannt wurden:

ls

Beispielausgabe:

(hd0) (hd0,msdos1)

Damit war klar, dass die VM klassisch per BIOS/MBR startet und eine Linux-Systempartition vorhanden war.

Beim Versuch, auf die Partition zuzugreifen:

ls (hd0,msdos1)/

startete die VM direkt neu.

Das deutete darauf hin, dass GRUB selbst beim Zugriff auf die Partition bzw. auf die dort vorhandenen Bootinformationen Probleme hatte.

Dateisystem prüfen

Die VHD wurde anschließend über ein Debian-Rescue-System gestartet.

Die vorhandene Linux-Partition wurde zunächst nur geprüft:

fsck.ext4 -n /dev/sda1

Das Dateisystem wurde dabei als sauber gemeldet.

Damit war zumindest kein offensichtlicher ext4-Dateisystemfehler vorhanden.

Auffälligkeiten im Boot-Verzeichnis

Im Verzeichnis /boot waren mehrere Kernel vorhanden.

Beispielsweise:

vmlinuz-6.x.x-xx-amd64
vmlinuz-6.x.x-yy-amd64

Auffällig war dabei, dass der neueste Kernel, die zugehörige initrd und:

/boot/grub/grub.cfg

alle ungefähr zu dem Zeitpunkt geändert worden waren, zu dem laut Azure Resource Health auch der Neustart der VM erfolgt war.

Der vermutete Ablauf war damit:

Automatisches Update
        ↓
Kernel-/GRUB-Anpassung
        ↓
Automatischer Neustart
        ↓
GRUB startet nicht mehr korrekt
        ↓
VM bleibt bei grub> hängen

GRUB lokal reparieren

Da lokal nur mit einer Kopie der Azure-Disk gearbeitet wurde, konnte die Reparatur dort zunächst gefahrlos getestet werden.

GRUB wurde neu installiert:

grub-install --target=i386-pc --recheck /dev/sda

Anschließend wurde die GRUB-Konfiguration neu erzeugt:

update-grub

Danach:

sync
poweroff

Nach Entfernen des Rescue-Mediums startete die lokale VM wieder vollständig.

Damit war klar, dass die Reparatur grundsätzlich funktioniert.

Reparatur direkt in Azure

Nachdem die lokale Reparatur erfolgreich getestet worden war, wurde die Azure-eigene VM-Reparatur verwendet.

Azure Cloud Shell öffnen

Im Azure Portal lässt sich die Cloud Shell direkt über das Terminal-Symbol öffnen.

Als Umgebung wurde Bash verwendet.

Zunächst wurde die vorhandene VM geprüft:

az vm list -o table

Beispiel:

Name                 ResourceGroup      Location
-------------------  -----------------  ----------
vm-linux-prod-01     RG-LINUX-PROD      westeurope

VM-Repair-Erweiterung installieren

Falls noch nicht vorhanden:

az extension add -n vm-repair

Optional kann die Erweiterung anschließend aktualisiert werden:

az extension update -n vm-repair

GRUB automatisch reparieren

Für eine Generation-1-/BIOS-Linux-VM kann die Azure-Reparatur mit grubfix ausgeführt werden.

Beispiel:

az vm repair repair-button \
  --button-command grubfix \
  --verbose \
  --resource-group RG-LINUX-PROD \
  --name vm-linux-prod-01

Azure erstellt dabei automatisch eine temporäre Reparaturumgebung.

Vereinfacht passiert dabei Folgendes:

• Kopie der OS-Disk wird erstellt
• temporäre Repair-VM wird angelegt
• Disk wird dort als Datendisk eingebunden
• GRUB wird repariert
• Repair-VM wird anschließend wieder entfernt
• reparierte Disk wird an die ursprüngliche VM zurückgegeben

Bei erfolgreichem Abschluss erscheint sinngemäß:

The repairs were complete using the script.
The repair disk was restored to the source VM.

status: SUCCESS

Ergebnis

Nach Abschluss der Azure-Reparatur startete die VM wieder vollständig.

Danach funktionierten auch wieder:

• SSH
• Weboberfläche
• Anwendung
• Azure VM Agent

Das eigentliche Linux-Dateisystem war nicht beschädigt. Das Problem lag im GRUB-Bootloader bzw. in dessen Zustand nach dem vorherigen Update.

Nachträgliche Prüfung der Ursache

Nach erfolgreichem Start lohnt sich noch ein Blick in die Paket- und Update-Logs.

Beispielsweise:

grep -iE 'linux-image|grub|initramfs' /var/log/dpkg.log | tail -100

und:

cat /var/log/apt/history.log

Falls die Logs bereits rotiert wurden:

zgrep -iE 'linux-image|grub|initramfs' /var/log/dpkg.log.*

Damit lässt sich meist relativ gut nachvollziehen, welche Pakete unmittelbar vor dem fehlerhaften Neustart aktualisiert wurden.

Fazit

Wenn eine Linux-VM in Azure weiterhin als „Running“ angezeigt wird, aber weder SSH noch Anwendungen erreichbar sind, muss das Problem nicht zwingend im Netzwerk oder bei Azure selbst liegen.

Die Boot Diagnostics sind in solchen Fällen eine der ersten Stellen, die geprüft werden sollten.

Wenn dort nur noch:

grub>

zu sehen ist, liegt das Problem bereits vor dem eigentlichen Linux-Start.

In diesem Fall konnte die VM ohne Neuinstallation und ohne Restore aus einem älteren Backup wieder vollständig in Betrieb genommen werden.

Disclaimer

Dieser Artikel wurde mit Unterstützung von dieser KI gemacht, von der gerade alle reden und die den RAM so teuer macht…