Ich habe meine Azure VM Ubuntu 18.04 (LTS) auf 20.04 (LTS) aktualisiert und neu gestartet, konnte jedoch keine unbegrenzte Remoteverbindung mit SSH herstellen.
Die serielle Azure Portal-Konsole reagiert ebenfalls nicht. Die folgende Meldung wird im Screenshot der Startdiagnose von Azure VM im Azure-Portal angezeigt.
'grub_file_filters' not found
Grub scheint kaputt zu sein.
Ich habe ein Upgrade auf Ubuntu 18.04 (LTS) von Azure VM durch Remoteverbindung von Ubuntu von WSL mit SSH und gemäß dem folgenden Verfahren durchgeführt.
Überprüfen Sie die Updates und wenden Sie sie im Voraus an
$ sudo apt update
$ sudo apt upgrade
Führen Sie das Upgrade durch
$ sudo do-release-upgrade
Die Auswahlmöglichkeiten sind grundlegend y (JA), alle Upgrade-Vorschläge akzeptiert, LXD 4.0
Starten Sie neu, um das Upgrade abzuschließen
Konnte nicht neu gestartet werden ... ('grub_file_filters' nicht gefunden)
Ich möchte Grub neu installieren und reparieren, aber als ich mich fragte, was in der Azure VM-Umgebung passiert ist, habe ich die folgenden Informationen von Microsoft gefunden.
In "Empfohlene Schritte" gab es keine entsprechenden Informationen, daher folgte ich dem Link.
So stellen Sie eine virtuelle Azure Linux-Maschine nach Kernel-bezogenen Startproblemen wieder her (https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/kernel-related-boot%20issues)
Ich dachte, es geht um "Methode 2: Offline-Reparatur" von "So aktualisieren Sie die Konfigurationsdatei", also habe ich mir den Link angesehen.
Troubleshoot a Linux VM by attaching the OS disk to a recovery VM with the Azure CLI
Ich habe das Problem gelöst, indem ich eine Festplatte aus einem Snapshot der Betriebssystemfestplatte der problematischen Azure-VM erstellt und zur Reparatur auf der Azure-VM bereitgestellt habe, wie in der folgenden Übersicht über den Wiederherstellungsprozess beschrieben. Es scheint, dass wir zur ursprünglichen Azure-VM zurückkehren können.
Stop the affected VM.
Take a snapshot from the OS disk of the VM.
Create a disk from the OS disk snapshot.
Attach and mount the new OS disk to another Linux VM for troubleshooting purposes.
Connect to the troubleshooting VM. Edit files or run any tools to fix issues on the new OS disk.
Unmount and detach the new OS disk from the troubleshooting VM. Change the OS disk for the affected VM.
Über das Azure-Portal haben Sie die problematische Azure-VM gestoppt.
Es ist in Ordnung, die neueste Version von Azure CLI zu installieren und die Verwendung von Azure CLI zu beenden. ..
> az login
> az vm stop --resource-group <Name der Ressourcengruppe> --name <Name der virtuellen Maschine>
Erstellen Sie einen Snapshot der Betriebssystemfestplatte der problematischen Azure-VM.
Ich verwende die Azure-CLI. (Erstellen Sie einen Snapshot basierend auf der Festplatten-ID.)
> $osdiskid=(az vm show -g <Name der Ressourcengruppe> -n <Name der virtuellen Maschine> --query "storageProfile.osDisk.managedDisk.id" -o tsv)
> az snapshot create --resource-group <Name der Ressourcengruppe> --source "$osdiskid" --name <Schnappschussname>
Erstellen Sie eine verwaltete Festplatte, die basierend auf dem erstellten Snapshot repariert werden soll.
Ich verwende die Azure-CLI. (Erstellen Sie eine verwaltete Festplatte basierend auf dem Snapshot.)
> $resourceGroup="<Name der Ressourcengruppe>"
> $snapshot="<Schnappschussname>"
> $osDisk="<Neuer Plattenname = zur Reparatur>"
> $diskSize=30 #Geben Sie die erforderliche Größe (GB) an.
> $storageType="Standard_LRS" #Geben Sie den erforderlichen Speichertyp an
> $osType="Linux" #Geben Sie den erforderlichen Betriebssystemtyp an
> $snapshotId=(az snapshot show --name $snapshot --resource-group $resourceGroup --query id -o tsv)
> az disk create --resource-group $resourceGroup --name $osDisk --sku $storageType --size-gb $diskSize --source $snapshotId
Über das Azure-Portal haben wir eine neue Azure-VM zur Verwendung bei Reparaturen erstellt.
Referenz
Sie erstellen virtuelle Maschinen, öffentliche IP-Adressen, Netzwerksicherheitsgruppen und Netzwerkschnittstellen gleicher Größe in demselben virtuellen Netzwerk in derselben Ressourcengruppe.
Ich habe die DNS-Namensbezeichnung auf der erstellten virtuellen Maschine festgelegt und bestätigt, dass sie über SSH remote verbunden werden kann.
Über das Azure-Portal habe ich die aus dem Snapshot erstellte Festplatte zur Reparatur mit der Azure-VM verbunden.
Es ist in Ordnung, die Festplatte über die Azure-CLI zu verbinden.
> $newdiskid=(az disk show -g $resourceGroup -n $osDisk --query id -o tsv)
> az vm disk attach --disk $newdiskid --resource-group $resourceGroup --size-gb $diskSize --sku $storageType --vm-name <Name der virtuellen Maschine zur Reparatur>
Ich habe eine Remoteverbindung zur Azure-VM hergestellt, die für die Reparatur durch SSH verwendet werden soll, und die verbundene Festplatte bereitgestellt.
Überprüfen Sie die Festplattennutzung der Azure-VM zur Reparatur.
$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 2.0G 0 2.0G 0% /dev
tmpfs 394M 676K 393M 1% /run
/dev/sdc1 29G 1.4G 28G 5% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/sdc15 105M 3.6M 101M 4% /boot/efi
/dev/sdb1 7.9G 36M 7.4G 1% /mnt
tmpfs 394M 0 394M 0% /run/user/1000
Listen Sie Blockgeräte auf, um zu sehen, welche Festplatten gemountet werden sollen.
$ lsblk -o NAME,HCTL,SIZE,MOUNTPOINT | grep -i "sd"
sda 3:0:0:0 30G
├─sda1 29.9G
├─sda14 4M
└─sda15 106M
sdb 1:0:1:0 8G
└─sdb1 8G /mnt
sdc 0:0:0:0 30G
├─sdc1 29.9G /
├─sdc14 4M
└─sdc15 106M /boot/efi
Da sdb und sdc gemountet sind, scheint sda die zu reparierende Festplatte zu sein.
Erstellen Sie ein Mount-Verzeichnis und mounten Sie sda1 von sda.
$ sudo mkdir /datadrive
$ sudo mount /dev/sda1 /datadrive
Stellen Sie sicher, dass Sie die zu reparierende Festplatte gemountet haben.
$ ls /datadrive/
bin dev home initrd.img.old lib64 media opt root sbin srv tmp var vmlinuz.old
boot etc initrd.img lib lost+found mnt proc run snap sys usr vmlinuz
Binden Sie mount sys, proc, dev, um zur Chroot-Umgebung zu wechseln und mit der zu reparierenden gemounteten Festplatte zu spielen.
$ sudo mount --bind /sys /datadrive/sys
$ sudo mount --bind /proc /datadrive/proc
$ sudo mount --bind /dev /datadrive/dev
$ sudo chroot /datadrive
Installieren Sie Grub auf der zu reparierenden Festplatte.
$ sudo grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
Hängen Sie die reparierte Festplatte aus.
$ cd /
$ sudo umount /dev/sda1
Vom Azure-Portal haben Sie die reparierte Festplatte getrennt, die zur Reparatur mit der Azure-VM verbunden ist.
Es ist in Ordnung, die Festplatte mithilfe der Azure-CLI zu trennen.
> az vm disk detach -g <Name der Ressourcengruppe> --vm-name <Name der virtuellen Maschine zur Reparatur> --name <Neuer Plattenname = zur Reparatur>
Wenn Sie es nicht benötigen, stoppen Sie die Azure-VM zur Reparatur.
Über das Azure-Portal habe ich die problematische Azure-VM gestoppt und die Betriebssystemfestplatte durch eine reparierte Festplatte ersetzt.
Ich verwende "OS Disk Swap" der Festplatte der virtuellen Maschine in Azure Portal.
Es ist in Ordnung, die Festplatte mithilfe der Azure-CLI zu ändern.
> az vm stop -n <Name der virtuellen Maschine> -g <Name der Ressourcengruppe>
> $newdiskid=(az vm show -g <Name der Ressourcengruppe> -n <Neuer Plattenname = zur Reparatur> --query id -o tsv)
> az vm update -g <Name der Ressourcengruppe> -n <Name der virtuellen Maschine> --os-disk $newdiskid
> az vm start -n <Name der virtuellen Maschine> -g <Name der Ressourcengruppe>
Ich habe bestätigt, dass ich eine Remoteverbindung mit der Azure-VM herstellen kann, die ich über SSH durch die reparierte Festplatte ersetzt habe. Das Upgrade auf 20.04 (LTS) wurde ebenfalls abgeschlossen.
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-1031-azure x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Sat Nov 7 13:14:17 JST 2020
System load: 0.04 Processes: 139
Usage of /: 26.2% of 28.90GB Users logged in: 1
Memory usage: 61% IPv4 address for eth0: 10.0.0.5
Swap usage: 0%
* Introducing self-healing high availability clustering for MicroK8s!
Super simple, hardened and opinionated Kubernetes for production.
https://microk8s.io/high-availability
0 updates can be installed immediately.
0 of these updates are security updates.
Last login: Fri Nov 6 13:55:00 2020 from 133.200.8.0
Löschen Sie unnötige Elemente wie Schnappschüsse und Datenträger, bevor Sie sie ersetzen.
Wenn Sie die Azure-VM zur Reparatur behalten möchten, können Sie sie sicher stehen lassen (freigegeben).
Ich bin froh, dass ich es als Ergebnis reparieren konnte, aber ich hätte es vor dem Upgrade sichern sollen.