Der virtuelle Azure Linux-Computer kann nach dem Anwenden von Kerneländerungen nicht gestartet werden
Hinweis
CentOS, auf das in diesem Artikel verwiesen wird, ist eine Linux-Distribution und erreicht das Ende der Lebensdauer (End Of Life, EOL). Berücksichtigen Sie Ihre Verwendung, und planen Sie sie entsprechend. Weitere Informationen finden Sie unter Leitfaden zum Ende der Lebensdauer von CentOS.
Dieser Artikel bietet Lösungen für ein Problem, bei dem ein virtueller Linux-Computer (VM) nach dem Anwenden von Kerneländerungen nicht gestartet werden kann.
Voraussetzungen
Stellen Sie sicher, dass die serielle Konsole auf der Linux-VM aktiviert und funktionsfähig ist.
Identifizieren eines Kernel-bezogenen Startproblems
Um ein Kernel-bezogenes Startproblem zu identifizieren, überprüfen Sie die spezifische Kernel panic-Zeichenfolge. Verwenden Sie hierzu die Azure CLI oder die Azure-Portal, um die Ausgabe des seriellen Konsolenprotokolls der VM im Startbereich Diagnose oder seriellen Konsolenbereich anzuzeigen.
Ein Kernel panic sieht wie die folgende Ausgabe aus und wird am Ende des seriellen Konsolenprotokolls angezeigt:
Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[ 300.206297] Kernel panic - xxxxxxxx
[ 300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G ------------ T 3.xxx.x86_64 #1
Onlineproblembehandlung
Tipp
Wenn Sie über eine aktuelle Sicherung des virtuellen Computers verfügen, stellen Sie die VM aus der Sicherung wieder her , um das Startproblem zu beheben.
Die serielle Konsole ist die schnellste Methode, um das Startproblem zu beheben. Damit können Sie das Problem direkt beheben, ohne den Systemdatenträger einer Wiederherstellungs-VM präsentieren zu müssen. Stellen Sie sicher, dass Sie die erforderlichen Voraussetzungen für Ihre Verteilung erfüllen. Weitere Informationen finden Sie unter Serielle Konsole für virtuelle Computer für Linux.
Identifizieren Sie das spezifische Kernel-bezogene Startproblem.
Verwenden Sie die serielle Azure-Konsole , um Ihre VM im GRUB-Menü zu unterbrechen, und wählen Sie einen beliebigen vorherigen Kernel aus, um ihn zu starten. Weitere Informationen finden Sie unter Boot system on older kernel version .For more information, see Boot system on older kernel version.For more information, see Boot system on older kernel version.
Wechseln Sie zum entsprechenden Abschnitt, um das spezifische Kernel-bezogene Startproblem zu beheben:
Nachdem das Kernel-bezogene Startproblem behoben wurde, starten Sie die VM neu, damit sie über die neueste Kernelversion gestartet werden kann.
Offlineproblembehandlung
Tipp
Wenn Sie über eine aktuelle Sicherung des virtuellen Computers verfügen, stellen Sie die VM aus der Sicherung wieder her , um das Startproblem zu beheben.
Wenn die serielle Azure-Konsole auf dem jeweiligen virtuellen Computer nicht funktioniert oder in Ihrem Abonnement keine Option ist, beheben Sie das Startproblem mithilfe einer Rettungs-/Reparatur-VM. Gehen Sie dazu wie folgt vor:
Verwenden Sie VM-Reparaturbefehle, um eine Reparatur-VM zu erstellen, an die eine Kopie des Betriebssystemdatenträgers der betroffenen VM angehängt ist. Mounten Sie die Kopie der OS-Dateisysteme in der Reparatur-VM mithilfe von chroot.
Hinweis
Alternativ können Sie mithilfe des Azure-Portals manuell eine Rettungs-VM erstellen. Weitere Informationen finden Sie unter Beheben von Problemen mit einer Linux-VM durch Hinzufügen des Betriebssystemdatenträgers zu einer Wiederherstellungs-VM im Azure-Portal.
Identifizieren Sie das spezifische Kernel-bezogene Startproblem.
Wechseln Sie zum entsprechenden Abschnitt, um das spezifische Kernel-bezogene Startproblem zu beheben:
Nachdem das Kernel-bezogene Startproblem behoben wurde, führen Sie die folgenden Aktionen aus:
- Beenden Sie chroot.
- Entfernen Sie die Kopie der Dateisysteme von der Rettungs-/Reparatur-VM.
- Führen Sie den Befehl
az vm repair restoreaus, um den reparierten Betriebssystemdatenträger durch den ursprünglichen Betriebssystemdatenträger der VM auszutauschen. Weitere Informationen finden Sie unter Schritt 5 in Reparieren eines virtuellen Linux-Computers mit dem Reparaturbefehlen virtueller Azure-Computer. - Überprüfen Sie, ob die VM gestartet werden kann, indem Sie einen Blick auf die serielle Azure-Konsole werfen oder versuchen, eine Verbindung zur VM herzustellen.
Wenn wichtige Kernelinhalte vorhanden sind, die gesamte
/bootPartition oder andere wichtige Inhalte fehlen und sie nicht wiederhergestellt werden können, wird empfohlen, die VM aus einer Sicherung wiederherzustellen. Weitere Informationen finden Sie unter Wiederherstellen von Azure-VM-Daten im Azure-Portal.
Startsystem auf einer älteren Kernelversion
Verwenden der seriellen Azure-Konsole
Starten Sie den virtuellen Computer mithilfe der seriellen Azure-Konsole neu.
- Wählen Sie oben im Fenster der seriellen Konsole die Schaltfläche zum Herunterfahren aus.
- Wählen Sie die Option VM neu starten (hart) aus.
Sobald die serielle Konsolenverbindung fortgesetzt wird, wird in der linken oberen Ecke des Fensters der seriellen Konsole ein Countdownzähler angezeigt. Drücken Sie die ESCAPE-TASTE , um Ihren virtuellen Computer im GRUB-Menü zu unterbrechen.
Drücken Sie die NACH-UNTEN-TASTE, um eine frühere Kernelversion auszuwählen.
Ändern Sie die
GRUB_DEFAULTVariable in der Datei "/etc/default/grub ", wie unter Ändern der Standardkernelsversion manuell angegeben. Dies ist eine permanente Änderung.
Hinweis
Wenn nur eine Kernelversion im GRUB-Menü aufgeführt ist, befolgen Sie den Offline-Problembehandlungsansatz , um dieses Problem von einer Reparatur-VM aus zu beheben.
Verwenden einer Reparatur-VM (ALAR-Skripts)
Führen Sie den folgenden Bash-Befehl in Azure Cloud Shell aus, um eine Reparatur-VM zu erstellen. Weitere Informationen finden Sie unter Verwenden der automatischen Reparatur von Azure Linux (ALAR) zum Beheben einer Linux-VM – Kerneloption.
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopyFühren Sie den folgenden Befehl aus, um den fehlerhaften Kernel durch die zuvor installierte Version zu ersetzen:
az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters kernel --run-on-repair az vm repair restore --verbose -g $RGNAME -n $VMNAME
Hinweis
Wenn nur eine Kernelversion im System installiert ist, befolgen Sie den Offline-Problembehandlungsansatz , um dieses Problem von einer Reparatur-VM aus zu beheben.
Manuelles Ändern der Standardkernelsversion
Führen Sie die folgenden Schritte aus, um die Standardkernelsversion von einer Reparatur-VM (in chroot) oder auf einem ausgeführten virtuellen Computer zu ändern:
Hinweis
Wenn ein Kerneldownback ausgeführt wird, wählen Sie die neueste Kernelversion anstelle der älteren Version aus.
RHEL 7, Oracle Linux 7 und CentOS 7
Überprüfen Sie die Liste der verfügbaren Kernels in der GRUB-Konfigurationsdatei, indem Sie einen der folgenden Befehle ausführen:
Gen1-VMs:
cat /boot/grub2/grub.cfg | grep menuentryGen2-VMs:
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
Legen Sie den neuen Standardkernels fest, und geben Sie den entsprechenden Kerneltitel an, indem Sie den folgenden Befehl ausführen:
# grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64'Hinweis
Ersetzen Sie durch
Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64den entsprechenden Menüeintragstitel.Überprüfen Sie, ob der neue Standardkernels der gewünschte Ist, indem Sie den folgenden Befehl ausführen:
grub2-editenv listStellen Sie sicher, dass der Wert der
GRUB_DEFAULTVariablen in der Datei /etc/default/grub aufsavedfestgelegt ist. Um sie zu ändern, stellen Sie sicher, dass Sie die GRUB-Konfigurationsdatei neu generieren , um die Änderungen anzuwenden.
RHEL 8/9 und CentOS 8
Listen Sie die verfügbaren Kernel auf, indem Sie den folgenden Befehl ausführen:
ls -l /boot/vmlinuz-*Legen Sie den neuen Standardkernels fest, indem Sie den folgenden Befehl ausführen:
grubby --set-default /boot/vmlinuz-4.18.0-372.19.1.el8_6.x86_64Hinweis
Ersetzen Sie durch
4.18.0-372.19.1.el8_6.x86_64die entsprechende Kernelversion.Überprüfen Sie, ob der neue Standardkernels der gewünschte Ist, indem Sie den folgenden Befehl ausführen:
grubby --default-kernel
SLES 12/15, Ubuntu 18.04/20.04
Listen Sie die verfügbaren Kernel in der GRUB-Konfigurationsdatei auf, indem Sie den folgenden Befehl ausführen:
Gen1-VMs:
SLES 12/15:
cat /boot/grub2/grub.cfg | grep menuentryUbuntu 18.04/20.04:
cat /boot/grub/grub.cfg | grep menuentry
Gen2-VMs:
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
Legen Sie den neuen Standardkernels fest, indem Sie den Wert der
GRUB_DEFAULTVariablen in der Datei /etc/default/grub ändern. Für die neueste im System installierte Kernelversion ist der Standardwert 0. Der nächste verfügbare Kernel ist auf "1>2" festgelegt.vi /etc/default/grub GRUB_DEFAULT="1>2"Hinweis
Weitere Informationen zum Konfigurieren der
GRUB_DEFAULTVariablen finden Sie unter SUSE Boot Loader GRUB2 und Ubuntu Grub2/Setup. Als Referenz: Der Oberste Ebene menuentry-Wert ist 0, der erste Untermenüwert der obersten Ebene ist 1, und jeder geschachtelte menuentry-Wert beginnt mit 0. Beispielsweise ist "1>2" der dritte Menüeintrag aus dem ersten Untermenü.Generieren Sie die GRUB-Konfigurationsdatei erneut, um die Änderungen anzuwenden. Befolgen Sie die Anweisungen unter Erneutes Installieren von GRUB und erneutes Generieren der GRUB-Konfigurationsdatei für die entsprechende Linux-Distribution und VM-Generierung.
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) (Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Dieser Fehler tritt aufgrund eines aktuellen Systemupdates (Kernel) auf. Dies wird am häufigsten in RHEL-basierten Distributionen verwendet. Sie können dieses Problem über die serielle Azure-Konsole identifizieren. Es wird eine der folgenden Fehlermeldungen angezeigt:
"Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" (Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"
[ 301.026129] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 301.027122] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G ------------ T 3.10.0-1160.36.2.el7.x86_64 #1 [ 301.027122] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 12/07/2018 [ 301.027122] Call Trace: [ 301.027122] [<ffffffff82383559>] dump_stack+0x19/0x1b [ 301.027122] [<ffffffff8237d261>] panic+0xe8/0x21f [ 301.027122] [<ffffffff8298b794>] mount_block_root+0x291/0x2a0 [ 301.027122] [<ffffffff8298b7f6>] mount_root+0x53/0x56 [ 301.027122] [<ffffffff8298b935>] prepare_namespace+0x13c/0x174 [ 301.027122] [<ffffffff8298b412>] kernel_init_freeable+0x222/0x249 [ 301.027122] [<ffffffff8298ab28>] ? initcall_blcklist+0xb0/0xb0 [ 301.027122] [<ffffffff82372350>] ? rest_init+0x80/0x80 [ 301.027122] [<ffffffff8237235e>] kernel_init+0xe/0x100 [ 301.027122] [<ffffffff82395df7>] ret_from_fork_nospec_begin+0x21/0x21 [ 301.027122] [<ffffffff82372350>] ? rest_init+0x80/0x80 [ 301.027122] Kernel Offset: 0xc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)"error: file '/initramfs-*.img' not found" (Fehler: Datei '/initramfs-*.img' nicht gefunden)
Fehler: Datei '/initramfs-3.10.0-1160.36.2.el7.x86_64.img' nicht gefunden.
Diese Art von Fehler weist darauf hin, dass die Initramfs-Datei nicht generiert wird, dass in der GRUB-Konfigurationsdatei der Initialeintrag nach einem Patchvorgang fehlt oder dass eine manuelle GRUB-Fehlkonfiguration vorliegt.
Vor dem Neustart eines Servers wird empfohlen, die GRUB-Konfiguration und /boot den Inhalt zu überprüfen, wenn ein Kernelupdate vorhanden ist, indem Sie einen der folgenden Befehle ausführen. Es ist wichtig sicherzustellen, dass das Update abgeschlossen ist und keine Initramfs-Dateien fehlen.
BIOS-basiert – Gen1-Systeme
# ls -l /boot # cat /boot/grub2/grub.cfgUEFI-basiert – Gen2-Systeme
# ls -l /boot # cat /boot/efi/EFI/*/grub.cfg
Erneutes Generieren fehlender Initramfs mithilfe von Azure Repair-VM-ALAR-Skripts
Erstellen Sie eine Reparatur-VM, indem Sie die folgende Bash-Befehlszeile mit Azure Cloud Shell ausführen. Weitere Informationen finden Sie unter Verwenden der automatischen Reparatur von Azure Linux (ALAR) zum Beheben einer Linux-VM – Initialisierungsoption.
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopyGenerieren Sie das Image initrd/initramfs erneut, und generieren Sie die GRUB-Konfigurationsdatei erneut, wenn der Initialeintrag fehlt. Führen Sie dazu den folgenden Befehl aus:
az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters initrd --run-on-repair az vm repair restore --verbose -g $RGNAME -n $VMNAMENachdem der Wiederherstellungsbefehl ausgeführt wurde, starten Sie den ursprünglichen virtuellen Computer neu, und überprüfen Sie, ob sie gestartet werden kann.
Manuelles Erneutes Generieren fehlender Initramfs
Wichtig
- Wenn Sie den virtuellen Computer mithilfe einer vorherigen Kernelversion oder innerhalb von chroot von der Reparatur-/Rettungs-VM starten können, generieren Sie fehlende Initramfs manuell neu.
- Um fehlende Initramfs manuell von einer Reparatur-VM neu zu generieren, stellen Sie sicher, dass Schritt 1 unter Offline-Problembehandlung bereits ausgeführt wurde und diese Befehle in chroot ausgeführt werden.
Identifizieren Sie die spezifische Kernelversion, die Probleme beim Starten aufweist. Sie können die Versionsinformationen aus dem entsprechenden Kernel panic-Fehler extrahieren.
Sehen Sie sich den folgenden Screenshot als Beispiel an. Der Kernel panic-Fehler zeigt, dass die Kernelversion "3.10.0-1160.59.1.el7.x86_64" lautet:
Generieren Sie die fehlende Initramfs-Datei erneut, indem Sie einen der folgenden Befehle ausführen:
RHEL/CentOS/Oracle Linux 7/8
sudo depmod -a 3.10.0-1160.59.1.el7.x86_64 sudo dracut -f /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img 3.10.0-1160.59.1.el7.x86_64Wichtig
Ersetzen Sie durch
3.10.0-1160.59.1.el7.x86_64die entsprechende Kernelversion.SLES 12/15
sudo depmod -a 5.3.18-150300.38.53-azure sudo dracut -f /boot/initrd-5.3.18-150300.38.53-azure 5.3.18-150300.38.53-azureWichtig
Ersetzen Sie durch
5.3.18-150300.38.53-azuredie entsprechende Kernelversion.Ubuntu 18.04
sudo depmod -a 5.4.0-1077-azure sudo mkinitramfs -k -o /boot/initrd.img-5.4.0-1077-azureWichtig
Ersetzen Sie durch
5.4.0-1077-azuredie entsprechende Kernelversion.
Generieren Sie die GRUB-Konfigurationsdatei erneut. Befolgen Sie die Anweisungen unter Erneutes Installieren von GRUB und erneutes Generieren der GRUB-Konfigurationsdatei für die entsprechende Linux-Distribution und VM-Generierung.
Wenn die oben genannten Schritte von einer Reparatur-VM ausgeführt werden, führen Sie Schritt 3 unter Offlineproblembehandlung aus. Wenn die oben genannten Schritte über die serielle Azure-Konsole ausgeführt werden, führen Sie die Online-Problembehandlungsmethode aus .
Starten Sie Ihren virtuellen Computer über die neueste Kernelversion neu.
Kernel panic - not syncing: Attempted to killed init
Identifizieren Sie dieses Problem über die serielle Azure-Konsole. Es wird eine Ausgabe wie die folgende angezeigt:
dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 2.6.32-754.17.1.el6.x86_64 #1
Call Trace:
[<ffffffff81558bfa>] ? panic+0xa7/0x18b
[<ffffffff81130370>] ? perf_event_exit_task+0xc0/0x340
[<ffffffff81086433>] ? do_exit+0x853/0x860
[<ffffffff811a33b5>] ? fput+0x25/0x30
[<ffffffff81564272>] ? system_call_after_swapgs+0xa2/0x152
[<ffffffff81086498>] ? do_group_exit+0x58/0xd0
[<ffffffff81086527>] ? sys_exit_group+0x17/0x20
[<ffffffff81564357>] ? system_call_fastpath+0x35/0x3a
[<ffffffff8156427e>] ? system_call_after_swapgs+0xae/0x152
Diese Art von Kernel panic tritt aufgrund der folgenden möglichen Ursachen auf:
In den folgenden Abschnitten finden Sie Ursachendetails und Lösungen. Stellen Sie sicher, dass die Befehle von einer Reparatur-/Rettungs-VM in einer chroot-Umgebung ausgeführt werden, wie unter Problembehandlung für offline beschrieben.
Fehlende wichtige Dateien und Verzeichnisse
Wichtige Linux-Dateien und -Verzeichnisse fehlen aufgrund eines menschlichen Fehlers. Beispielsweise werden Dateien versehentlich gelöscht oder das Dateisystem beschädigt.
Überprüfen Sie den Inhalt des Betriebssystemdatenträgers, nachdem Sie die Kopie des Betriebssystemdatenträgers an eine Reparatur-VM angefügt und die entsprechenden Dateisysteme mithilfe von chroot eingebunden haben. Sie können die Ausgaben mit denen eines funktionierenden virtuellen Computers mit derselben Betriebssystemversion vergleichen.
ls -l / ls -l /usr/lib ls -l /usr/lib64 ls -lR / | moreStellen Sie die fehlenden Dateien aus einer Sicherung wieder her. Weitere Informationen finden Sie unter Wiederherstellen von Dateien aus der Sicherung virtueller Azure-Computer. Abhängig von der Anzahl der fehlenden Dateien ist es möglicherweise besser, eine vollständige VM-Wiederherstellung durchzuführen. Weitere Informationen finden Sie unter Wiederherstellen von Azure-VM-Daten im Azure-Portal.
Fehlende wichtige Systemkernbibliotheken und -pakete
Wichtige Systemkernbibliotheken, Dateien oder Pakete werden aus dem System gelöscht oder beschädigt. Installieren Sie die betroffenen Bibliotheken, Dateien oder Pakete neu, um dieses Problem zu beheben. Diese Lösung funktioniert auf RPM-basierten Distributionen wie Red Hat/CentOS/SUSE-VMs. Für andere Linux-Distributionen wird empfohlen, die VM aus der Sicherung wiederherzustellen.
Führen Sie die folgenden Schritte aus, um die Neuinstallation durchzuführen:
Erstellen Sie eine Rettungs-VM, indem Sie ein unformatiertes Image mit der gleichen Betriebssystemversion und -generation wie die betroffene VM verwenden.
Greifen Sie auf die chroot-Umgebung auf der Rettungs-VM zu, um das Problem zu beheben.
sudo chroot /rescueDie Befehlsausgabe zeigt an, welche Bibliothek fehlt oder beschädigt ist, wie unten gezeigt:
/bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directoryÜberprüfen Sie alle Systempakete und die entsprechenden status auf der Rettungs-VM. Vergleichen Sie die Ausgabe mit einer fehlerfreien VM, auf der die gleiche Betriebssystemversion ausgeführt wird.
sudo rpm --verify --all --root=/rescueHier sehen Sie ein Beispiel für die Befehlsausgabe:
error: Failed to dlopen /usr/lib64/rpm-plugins/systemd_inhibit.so /lib64/librt.so.1: undefined symbol: __pthread_attr_copy, version GLIBC_PRIVATE S.5....T. c /etc/dnf/dnf.conf S.5....T. c /etc/ssh/sshd_config .M....... /boot/efi/EFI/BOOT/BOOTX64.EFI .M....... /boot/efi/EFI/BOOT/fbx64.efi .M....... /boot/efi/EFI/redhat/BOOTX64.CSV .M....... /boot/efi/EFI/redhat/mmx64.efi .M....... /boot/efi/EFI/redhat/shimx64-redhat.efi .M....... /boot/efi/EFI/redhat/shimx64.efi missing /run/motd.d .M....... g /var/spool/anacron/cron.daily .M....... g /var/spool/anacron/cron.monthly .M....... g /var/spool/anacron/cron.weekly missing /lib64/libc-2.28.so <------- .M....... /boot/efi/EFI/redhat S.5....T. c /etc/security/pwquality.confDie Ausgabezeile
missing /lib64/libc-2.28.sobezieht sich auf den vorherigen Fehler in Schritt 2 und gibt an, dass libc-2.28.so Paket fehlt. Das libc-2.28.so-Paket kann jedoch geändert werden. In diesem Fall wird die Ausgabe anstelle vonmissingangezeigt.M...... Auf das libc-2.28.so-Paket wird in den folgenden Schritten als Beispiel verwiesen.Überprüfen Sie auf der Rettungs-VM, welches Paket die Bibliothek /lib64/libc-2.28.so enthält.
sudo rpm -qf /lib64/libc-2.28.soglibc-2.28-127.0.1.el8.x86_64Hinweis
Die Ausgabe zeigt das Paket an, das neu installiert werden muss, einschließlich des Paketnamens und der Version. Die Paketversion kann sich von der auf dem betroffenen virtuellen Computer installierten Version unterscheiden.
Überprüfen Sie auf der betroffenen VM, welche Version des glibc-Pakets installiert ist.
sudo rpm -qa --all --root=/rescue | grep -i glibcglibc-common-2.28-211.0.1.el8.x86_64 glibc-gconv-extra-2.28-211.0.1.el8.x86_64 glibc-2.28-211.0.1.el8.x86_64 <---- glibc-langpack-en-2.28-211.0.1.el8.x86_64Laden Sie das Paket glibc-2.28-211.0.1.el8.x86_64 herunter. Sie können es von der offiziellen Website des Betriebssystemanbieters oder von der Rettungs-VM herunterladen, indem Sie ein Paketverwaltungstool wie
yumdownloaderoderzypper install --download-only <packagename>je nach Betriebssystem verwenden, das Sie ausführen.Hier sehen Sie ein Beispiel für die Verwendung des
yumdownloaderTools:cd /tmp sudo yumdownloader glibc-2.28-211.0.1.el8.x86_64Last metadata expiration check: 0:03:24 ago on Thu 25 May 2023 02:36:25 PM UTC. glibc-2.28-211.0.1.el8.x86_64.rpm 8.7 MB/s | 2.2 MB 00:00Installieren Sie das betroffene Paket auf der Rettungs-VM neu.
sudo rpm -ivh --root=/rescue /tmp/glibc-*.rpm --replacepkgs --replacefileswarning: /tmp/glibc-2.28-211.0.1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID ad986da3: NOKEY Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:glibc-2.28-211.0.1.el8 ################################# [100%]Greifen Sie auf die chroot-Umgebung auf der Rettungs-VM zu, um die Neuinstallation zu überprüfen.
sudo chroot /rescueDeaktivieren Sie die Rettungs-VM, und tauschen Sie den Betriebssystemdatenträger auf den betroffenen virtuellen Computer aus.
Falsche Dateiberechtigungen
Falsche systemweite Dateiberechtigungen werden aufgrund eines menschlichen Fehlers geändert (z. B. wenn jemand auf / oder anderen wichtigen Betriebssystemdateisystemen ausgeführt wirdchmod 777). Um dieses Problem zu beheben, stellen Sie die Dateiberechtigungen wieder her. Diese Lösung funktioniert auf RPM-basierten Distributionen wie Red Hat/CentOS/SUSE-VMs. Für andere Linux-Distributionen wird empfohlen, die VM aus der Sicherung wiederherzustellen.
Führen Sie zum Wiederherstellen der Dateiberechtigungen den folgenden Befehl aus, nachdem Sie die Kopie des Betriebssystemdatenträgers an eine Reparatur-VM angefügt und die entsprechenden Dateisysteme mithilfe von chroot eingebunden haben:
rpm -a --setperms
rpm --setugids --all
chmod u+s /bin/sudo
chmod 660 /etc/sudoers.d/*
chmod 644 /etc/ssh/*.pub
chmod 640 /etc/ssh/*.key
Hinweis
Führen Sie diesen Befehl nicht auf ausgeführten Produktionssystemen aus.
Wenn das Problem nach der manuellen Wiederherstellung der entsprechenden Dateiberechtigungen weiterhin besteht, führen Sie eine Wiederherstellung aus der Sicherung aus.
Fehlende Partitionen
In Fällen, in denen /var/home/opt/usr/tmpDie Dateisysteme , und / auf verschiedene Partitionen verteilt sind, kann der Zugriff auf die Daten aufgrund von Problemen auf Partitionsebene nicht möglich sein, die durch Fehler bei Partitionsänderungsvorgängen oder anderen verursacht werden können.
Wenn Sie in diesem Szenario das ursprüngliche Partitionstabellenlayout mit den genauen Start- und Endsektoren für jede der ursprünglichen Partitionen dokumentieren und keine weiteren Änderungen am System vorgenommen werden, z. B. die Erstellung neuer Dateisysteme, erstellen Sie die Partitionen neu, indem Sie dasselbe ursprüngliche Layout mit Tools wie fdisk (für MBR-Partitionstabellen) oder gdisk (für GPT-Partitionstabellen) verwenden, um Zugriff auf das fehlende Dateisystem zu erhalten.
Wenn dieser Ansatz nicht funktioniert, führen Sie eine Wiederherstellung aus einer Sicherung durch.
SELinux-Probleme
Falsche SELinux-Berechtigungen können das System daran hindern, auf wichtige Dateien zuzugreifen. Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:
Um zu überprüfen, ob das System Aufgrund falscher SELinux-Berechtigungen Probleme hat, starten Sie das System mit deaktiviertem SELinux, indem Sie der GRUB linux16-Zeile die Kerneloption selinux=0 hinzufügen.
Wenn das System gestartet werden kann, führen Sie den folgenden Befehl aus, um zum Startzeitpunkt eine SELinux-Neubezeichnung auszulösen und das System neu zu starten:
touch /.autorelabelWenn der virtuelle Computer immer noch nicht gestartet werden kann, führen Sie eine vollständige VM-Wiederherstellung aus der Sicherung durch. Weitere Informationen finden Sie unter Wiederherstellen von Azure-VM-Daten im Azure-Portal.
Andere Kernel-bezogene Startprobleme
In diesem Artikel werden die am häufigsten in Azure identifizierten Linux-Kernel-Panics behandelt. Weitere Informationen zu gängigen Kernel panic-Szenarien finden Sie unter Kernel panic in Azure Linux VMs – Allgemeine Kernel panic-Ereignisse.
Es gibt einige andere wichtige mögliche Kernel-Panics, die keine Start- oder SSH-Szenarien (Secure Shell) verursachen können.
Stellen Sie sicher, dass Sie alle Befehle von einer Reparatur-VM in einer chroot-Umgebung ausführen, wie unter Offlineproblembehandlung beschrieben. Wenn das System bereits über eine frühere Kernelversion gestartet wurde, können diese Befehle auch von der ursprünglichen VM ausgeführt werden, indem Stammberechtigungen oder sudoverwendet werden, wie unter Onlineproblembehandlung beschrieben.
Aktuelles Kernelupgrade
Wenn die Kernel panics nach einem letzten Kernelupgrade beginnen, starten Sie die VM über die vorherige Kernelversion. Weitere Informationen finden Sie unter Boot system on older kernel version .For more information, see Boot system on older kernel version.For more information, see Boot system on older kernel version.
Sie können auch überprüfen, ob bereits eine neuere Kernelversion vom Linux-Distributionsanbieter veröffentlicht wurde, und diese installieren. Weitere Informationen zum Installieren der neuesten Kernelversion finden Sie unter Kernelupdateprozess.
Aktuelles Kernel-Downgrade
Wenn die Kernel panics nach einem letzten Kerneldownupgrade beginnen, kehren Sie zum zuletzt installierten Kernel zurück. Sie können auch überprüfen, ob bereits eine neuere Kernelversion vom Linux-Distributionsanbieter veröffentlicht wurde, und diese installieren. Weitere Informationen zum Installieren der neuesten Kernelversion finden Sie unter Kernelupdateprozess.
Um das System über die neueste Kernelversion zu starten, befolgen Sie die Anweisungen unter Manuelles Ändern der Standardkernelsversion, aber wählen Sie den ersten Kernel aus, der im GRUB-Menü aufgeführt ist. Bei einer manuellen Änderung können Sie den GRUB_DEFAULT Wert auf 0 festlegen und die entsprechende GRUB-Konfigurationsdatei erneut generieren.
Kernelmoduländerungen
Möglicherweise treten kernel panic auf, die sich auf ein neues Kernelmodul oder ein fehlendes Kernelmodul bezieht. Um Details zu dem spezifischen Kernelmodul zu erhalten, das Probleme verursacht (falls vorhanden), überprüfen Sie die entsprechende Kernel panic-Ablaufverfolgung.
Führen Sie einen der folgenden Befehle aus, um die geladenen und deaktivierten Kernelmodule in den Dateien /etc/modprobe.d/*.conf zu überprüfen:
RHEL/CentOS/Oracle Linux 7/8
lsinitrd /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img lsmod cat /etc/modprobe.d/*.confWichtig
Ersetzen Sie durch
3.10.0-1160.59.1.el7.x86_64die entsprechende Kernelversion.SLES 12/15
lsinitrd /boot/initrd-5.3.18-150300.38.53-azure lsmod cat /etc/modprobe.d/*.confWichtig
Ersetzen Sie durch
5.3.18-150300.38.53-azuredie entsprechende Kernelversion.Ubuntu 18.04
lsinitramfs /boot/initrd.img-5.4.0-1077-azure lsmod cat /etc/modprobe.d/*.confWichtig
Ersetzen Sie durch
5.4.0-1077-azuredie entsprechende Kernelversion.
Um ein bestimmtes Kernelmodul zu entfernen, führen Sie den folgenden Befehl aus, und generieren Sie die Initramfs bei Bedarf erneut.
rmmod <kernel_module_name>
Wenn ein Systemdienst das bestimmte Kernelmodul verwendet, deaktivieren Sie es, indem Sie den systemctl disable <serviceName> Befehl oder systemctl stop <serviceName> ausführen.
Aktuelle Konfigurationsänderungen des Betriebssystems
Identifizieren Sie alle kürzlich vorgenommenen Kernelkonfigurationsänderungen, die Probleme verursachen können. Passen Sie diese Einstellungen an, oder führen Sie ein Rollback der Konfigurationsänderungen durch, um die Probleme zu beheben.
Führen Sie den folgenden Befehl aus, um persistente Kernelparameter zu suchen, die in einer der folgenden Dateien konfiguriert sind:
cat /etc/systctl.conf
cat /etc/sysctl.d/*
Führen Sie den folgenden Befehl aus, um die aktuellen Kernelparameter und ihre aktuellen Werte zu analysieren:
sysctl -a
Hinweis
Führen Sie diesen Befehl auf einem ausgeführten System und nicht in einer chroot-Umgebung aus.
Mögliche fehlende Dateien
Weitere Informationen zu dieser Art von Problem finden Sie unter Fehlende wichtige Dateien und Verzeichnisse.
Falsche Berechtigungen für Dateien
Weitere Informationen zu dieser Art von Problem finden Sie unter Falsche Dateiberechtigungen.
Fehlende Partitionen
Weitere Informationen zu dieser Art von Problem finden Sie unter Fehlende Partitionen.
Kernelfehler
Identifizieren Sie dieses Problem über die serielle Azure-Konsole. Diese Art von Problem sieht wie die folgende Ausgabe aus:
[5275698.017004] kernel BUG at XXX/YYY.c:72!
[5275698.017004] invalid opcode: 0000 [#1] SMP
Diese Art von Kernel panic ist mit Kernelfehlern oder Kernelfehlern von Drittanbietern verbunden.
Um Kernelfehler zu beheben, durchsuchen Sie die Wissensdatenbank des Anbieters mithilfe der Kernel-BUG-Zeichenfolge, und suchen Sie nach bekannten Problemen in der entsprechenden Kernelversion, die Auf Ihrem System ausgeführt wird. Hier sind einige wichtige Anbieterressourcen:
-
Dieses Tool wurde entwickelt, um Sie bei der Diagnose eines Kernelabsturzes zu unterstützen. Wenn Sie einen Text, vmcore-dmesg.txtoder eine Datei eingeben, die eine oder mehrere Kernel-Oops-Nachrichten enthält, führt sie Sie durch die Diagnose des Kernelabsturzproblems.
-
Um Zugriff auf die Red Hat-Ressourcen zu erhalten, verknüpfen Sie Ihre Microsoft Azure- und Red Hat-Konten. Weitere Informationen finden Sie unter So können Microsoft Azure-Kunden auf das Red Hat-Kundenportal zugreifen.
Es wird empfohlen, alle Ihre Systeme auf dem neuesten Stand zu halten, um mögliche Fehler auszuschließen, die bereits in den neuesten Kernelversionen behoben wurden. Weitere Informationen finden Sie unter Kernelupdateprozess.
Wenn eine weitere Analyse vom Anbieter erforderlich ist, konfigurieren und aktivieren Sie kdump, um ein Kerndump zu generieren:
- Kdump-Konfiguration auf Red Hat-basierten VMs.
- Konfiguration des Kernelabsturzabbilds auf Ubuntu-VMs.
- Konfiguration des Kernelkernabbilds auf SLES-VMs
Kernelupdateprozess
Führen Sie einen der folgenden Befehle aus, um die neueste verfügbare Kernelversion zu installieren:
RHEL/CentOS/Oracle Linux
yum update kernelSLES 12/15
zypper refresh zypper update kernel*Ubuntu 18.04/20.04
apt update apt install linux-azure
Führen Sie einen der folgenden Befehle aus, um eine bestimmte Kernelversion neu zu installieren. Stellen Sie sicher, dass Sie nicht über dieselbe Kernelversion gestartet werden, die Sie neu installieren möchten. Weitere Informationen finden Sie unter Boot system on older kernel version .For more information, see Boot system on older kernel version.For more information, see Boot system on older kernel version.
RHEL/CentOS/Oracle Linux
yum reinstall kernel-3.10.0-1160.59.1.el7.x86_64Wichtig
Ersetzen Sie durch
3.10.0-1160.59.1.el7.x86_64die entsprechende Kernelversion.SLES 12/15
zypper refresh zypper install -f kernel-azure-5.3.18-150300.38.75.1.x86_64Wichtig
Ersetzen Sie durch
kernel-azure-5.3.18-150300.38.75.1.x86_64die entsprechende Kernelversion.Ubuntu 18.04/20.04
apt update apt install --reinstall linux-azure=5.4.0.1091.68Wichtig
Ersetzen Sie durch
5.4.0.1091.68die entsprechende Kernelversion.
Führen Sie einen der folgenden Befehle aus, um das System zu aktualisieren und die neuesten verfügbaren Änderungen anzuwenden:
RHEL/CentOS/Oracle Linux
yum updateSLES 12/15
zypper refresh zypper updateUbuntu 18.04/20.04
apt update apt upgrade
Kernel panics können mit einem der folgenden Elemente zusammenhängen. Weitere Informationen finden Sie unter Kernel Panics zur Laufzeit.
- Änderungen an der Anwendungsworkload.
- Anwendungsentwicklung oder Anwendungsfehler.
- Leistungsbezogene Probleme usw.
Nächste Schritte
Wenn der spezifische Startfehler kein Kernel-bezogenes Startproblem ist, finden Sie weitere Optionen zur Problembehandlung unter Azure Linux Virtual Machines Bootfehler.
Kontaktieren Sie uns für Hilfe
Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für