Azure virtuele Linux-machine kan niet worden opgestart nadat kernelwijzigingen zijn toegepast

Van toepassing op: ✔️ Virtuele Linux-machines

Notitie

CentOS waarnaar in dit artikel wordt verwezen, is een Linux-distributie en bereikt het einde van de levensduur (EOL). Houd rekening met uw gebruik en plan dienovereenkomstig. Zie De richtlijnen voor het einde van de levensduur van CentOS voor meer informatie.

Overzicht

Dit artikel bevat oplossingen voor een probleem waarbij een virtuele Linux-machine (VM) niet kan worden opgestart nadat kernelwijzigingen zijn toegepast.

Voorwaarden

Zorg ervoor dat de seriële console is ingeschakeld en functioneel is in de Virtuele Linux-machine.

Hoe een opstartprobleem met betrekking tot de kernel identificeren

Als u een probleem met betrekking tot het opstarten van een kernel wilt identificeren, controleert u het specifieke kernel-paniekbericht. Gebruik hiervoor de Azure CLI of de Azure-portal om de uitvoer van het seriële consolelogboek van de virtuele machine weer te geven in het deelvenster Diagnostische gegevens over opstarten of het deelvenster seriële console.

Een kernel panic heeft de volgende uitvoer en wordt weergegeven aan het einde van het seriële consolelog.

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

Online probleemoplossing

Aanbeveling

Als u een recente back-up van de virtuele machine hebt, herstelt u de VIRTUELE machine vanuit de back-up om het opstartprobleem op te lossen.

De seriële console is de snelste methode om het opstartprobleem op te lossen. Hiermee kunt u het probleem rechtstreeks oplossen zonder dat u de systeemschijf hoeft te presenteren aan een herstel-VM. Zorg ervoor dat u voldoet aan de vereiste vereisten voor uw distributie. Zie seriële console voor virtuele machines voor Linux voor meer informatie.

  1. Identificeer het specifieke probleem met het opstarten van de kernel.

  2. Gebruik de Azure seriële console om uw VIRTUELE machine te onderbreken in het GRUB-menu en selecteer een eerdere kernel om deze op te starten. Zie Opstartsysteem op oudere kernelversie voor meer informatie.

  3. Ga naar de bijbehorende sectie om een kernel-gerelateerd opstartprobleem op te lossen.

  4. Nadat het probleem met het opstarten van de kernel is opgelost, start u de VIRTUELE machine opnieuw op, zodat deze kan worden opgestart via de meest recente kernelversie.

Offline probleemoplossing

Aanbeveling

Als u een recente back-up van de virtuele machine hebt, herstelt u de VIRTUELE machine vanuit de back-up om het opstartprobleem op te lossen.

Als de Azure seriële console niet werkt op de specifieke VM of geen optie in uw abonnement is, kunt u het opstartprobleem oplossen met behulp van een herstel-/herstel-VM. Hiervoor volgt u deze stappen:

  1. Gebruik vm-herstelopdrachten om een herstel-VM te maken waarop een kopie van de besturingssysteemschijf van de betreffende VM is gekoppeld. Mount de kopie van de besturingssysteem bestanden in de herstel-VM met behulp van chroot.

    Notitie

    U kunt ook handmatig een reddings-VM maken met behulp van de Azure-portal. Zie voor meer informatie Problemen oplossen met een Linux-VM door de OS-schijf aan een herstel-VM te koppelen via het Azure-portaal.

  2. Identificeer het specifieke probleem met het opstarten van de kernel.

  3. Ga naar de bijbehorende sectie om het specifieke kernel-gerelateerde opstartprobleem op te lossen.

  4. Nadat het kernelprobleem is opgelost, voert u de volgende stappen uit:

    1. Verlaat chroot.
    2. Ontkoppel de kopie van de bestandssystemen van de herstel-/reparatie-VM.
    3. Voer de az vm repair restore opdracht uit om de herstelde besturingssysteemschijf te wisselen met de oorspronkelijke besturingssysteemschijf van de virtuele machine. Zie stap 5 in Een virtuele Linux-machine opnieuw maken met behulp van de Azure virtuele-machineherstelopdrachten voor meer informatie.
    4. Controleer of de VM kan worden opgestart door de Azure seriële console te bekijken of door verbinding te maken met de virtuele machine.

  5. Als er belangrijke kernelgerelateerde inhoud, de volledige /boot partitie of andere belangrijke inhoud ontbreekt en deze niet kunnen worden hersteld, raden we u aan de virtuele machine te herstellen vanuit een back-up. Zie Het herstellen van Azure VM-gegevens in Azure portal voor meer informatie.

Opstartsysteem op oudere kernelversie

Azure seriële console gebruiken

  1. Start de VIRTUELE machine opnieuw op met behulp van de Azure seriële console.

    1. Selecteer de knop Afsluiten boven aan het seriële consolevenster.
    2. Selecteer de optie VM opnieuw opstarten (hard).

  2. Zodra de seriële consoleverbinding is hervat, ziet u een aftelteller in de linkerbovenhoek van het seriële consolevenster. Druk op de ESCAPE-toets om de VM te onderbreken in het GRUB-menu.

  3. Druk op de pijl-omlaag om een eerdere kernelversie te selecteren.

    GIF-animatie die het proces van het onderbreken van het opstartproces op GRUB-menuniveau laat zien om een oudere kernel te selecteren waarop het systeem moet worden opgestart.

  4. Wijzig de GRUB_DEFAULT variabele in het /etc/default/grub-bestand zoals aangegeven in de standaard kernelversie handmatig wijzigen. Dit is een permanente wijziging.

Notitie

Als er slechts één kernelversie wordt vermeld in het menu GRUB, volgt u de offline-probleemoplossingsbenadering om dit probleem vanaf een herstel-VM op te lossen.

Gebruik de herstel-VM (ALAR-scripts)

  1. Voer de volgende bash-opdracht uit in Azure Cloud Shell om een herstel-VM te maken. Zie Use Azure Linux Auto Repair (ALAR) voor meer informatie om een Linux-VM - kerneloptie te herstellen.

    az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy

  2. Voer de volgende opdracht uit om de verbroken kernel te vervangen door de eerder geïnstalleerde versie:

    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

Notitie

Als er slechts één kernelversie in het systeem is geïnstalleerd, volgt u de offlineoplossingsbenadering om dit probleem op te lossen vanaf een herstel-VM.

Standaard kernelversie handmatig wijzigen

Als u de standaard kernelversie wilt wijzigen van een herstel-VM (binnen chroot) of op een actieve VM, voert u de volgende stappen uit:

Notitie

Als het terugdraaien van een kernel downgrade is voltooid, selecteert u de meest recente kernelversie in plaats van de oudere versie.

  • RHEL 7, Oracle Linux 7 en CentOS 7

    1. Valideer de lijst met beschikbare kernels in het GRUB-configuratiebestand door een van de volgende opdrachten uit te voeren:

      • Gen1-VM's:

        cat /boot/grub2/grub.cfg | grep menuentry

      • Gen2-VMs:

        cat /boot/efi/EFI/*/grub.cfg | grep menuentry

    2. Stel de nieuwe standaard kernel in en geef de bijbehorende kerneltitel op door de volgende opdracht uit te voeren:

      # grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64'

      Notitie

      Vervang Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 door de bijbehorende titel van de menuvermelding.

    3. Controleer of de nieuwe standaardkernel de gewenste is door de volgende opdracht uit te voeren:

      grub2-editenv list

    4. Zorg ervoor dat de waarde van de GRUB_DEFAULT variabele in het bestand /etc/default/grub is ingesteld op saved. Als u dit wilt wijzigen, moet u het GRUB-configuratiebestand opnieuw genereren om de wijzigingen toe te passen.

  • RHEL 8/9 en CentOS 8

    1. Geef de beschikbare kernels weer door de volgende opdracht uit te voeren:

      ls -l /boot/vmlinuz-*

    2. Stel de nieuwe standaardkernel in door de volgende opdracht uit te voeren:

      grubby --set-default /boot/vmlinuz-4.18.0-372.19.1.el8_6.x86_64

      Notitie

      Vervang door 4.18.0-372.19.1.el8_6.x86_64 de bijbehorende kernelversie.

    3. Controleer of de nieuwe standaardkernel de gewenste is door de volgende opdracht uit te voeren:

      grubby --default-kernel

  • SLES 12/15, Ubuntu 18.04/20.04

    1. Vermeld de beschikbare kernels in het GRUB-configuratiebestand door de volgende opdracht uit te voeren:

      • Gen1-VMs:

        • SLES 12/15:

          cat /boot/grub2/grub.cfg | grep menuentry

        • Ubuntu 18.04/20.04:

          cat /boot/grub/grub.cfg | grep menuentry

      • Gen2-VMs:

        cat /boot/efi/EFI/*/grub.cfg | grep menuentry

    2. Stel de nieuwe standaardkernel in door de waarde van de GRUB_DEFAULT variabele in het bestand /etc/default/grub te wijzigen. Voor de meest recente kernelversie die in het systeem is geïnstalleerd, is de standaardwaarde 0. De volgende beschikbare kernel is ingesteld op '1>2'.

      vi /etc/default/grub
GRUB_DEFAULT="1>2"

      Notitie

      Zie SUSE Boot Loader GRUB2 en Ubuntu Grub2/Setup voor meer informatie over het configureren van de GRUB_DEFAULT variabele. Als referentie: de waarde voor menu-items op het bovenliggende menu is 0, de eerste bovenliggende submenuwaarde is 1, en elke geneste menu-itemwaarde begint met 0. '1>2' is bijvoorbeeld het derde menu uit het eerste submenu.

    3. Genereer het GRUB-configuratiebestand opnieuw om de wijzigingen toe te passen. Volg de instructies in Grub opnieuw installeren en het GRUB-configuratiebestand opnieuw genereren voor de bijbehorende Linux-distributie en vm-generatie.

Kernel paniek - niet synchroniseren: VFS: kan root fs niet koppelen op unknown-block(0,0)

Deze fout treedt op vanwege een recente systeemupdate (kernel). Het wordt meestal gezien in RHEL-distributies. U kunt dit probleem identificeren vanuit de Azure seriële console. U ziet een van de volgende foutberichten:

  1. Kernel panic - not syncing: VFS: Kan root fs niet koppelen op onbekend-blok(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)

  2. "error: file '/initramfs-*.img' niet gevonden"

    fout: bestand '/initramfs-3.10.0-1160.36.2.el7.x86_64.img' niet gevonden.

Dit type fout geeft aan dat het initramfs-bestand niet wordt gegenereerd, dat het GRUB-configuratiebestand de initrd vermelding ontbreekt na een patchproces of een handmatige configuratie van GRUB.

Voordat u een server opnieuw opstart, raden we u aan de GRUB-configuratie en /boot -inhoud te valideren als er een kernelupdate is door een van de volgende opdrachten uit te voeren. Het is belangrijk om ervoor te zorgen dat de update wordt uitgevoerd en dat er geen initramfs-bestanden ontbreken.

  • Op BIOS gebaseerde Gen1-systemen

    # ls -l /boot
# cat /boot/grub2/grub.cfg

  • UEFI-gebaseerde - Gen2-systemen

    # ls -l /boot
# cat /boot/efi/EFI/*/grub.cfg

Ontbrekende initramfs opnieuw genereren met Azure Repair VM ALAR-scripts

Uitvoeren in Linux

Azure ALAR-scripts (Linux Auto Repair) maken deel uit van de VM-herstelextensie die wordt beschreven in Use Azure Linux Auto Repair (ALAR) voor het herstellen van een Linux-VM. ALAR behandelt de automatisering van meerdere herstelscenario's, waaronder dit ontbrekende probleem met initramfs.

De ALAR-scripts gebruiken de reparatie-extensie repair-button om de ontbrekende initramfs-problemen op te lossen door op te --button-command initrdgeven. Met deze parameter wordt het geautomatiseerde en onbeheerde herstel geactiveerd. Implementeer de volgende opdrachten om het regenereren van het ontbrekende initramfs-bestand te automatiseren en het bijbehorende configuratiebestand opnieuw te genereren:

    az extension add -n vm-repair
    az extension update -n vm-repair
    az vm repair repair-button --button-command 'initrd' --verbose --resource-group $RGNAME --name $VMNAME

Belangrijk

Vervang de naam $RGNAME van de resourcegroep en de NAAM van $VMNAME de VM dienovereenkomstig.

  • Het herstel-VM-script, in combinatie met het ALAR-script en de repair-button knop, wordt uitgevoerd in de onbeheerde modus. Er wordt tijdelijk een resourcegroep, een herstel-VM en een kopie van de besturingssysteemschijf van de betrokken VM gemaakt.
  • Vervolgens worden de ontbrekende initramfs opnieuw gegenereerd, wordt het bijbehorende GRUB-configuratiebestand opnieuw gegenereerd en wordt de besturingssysteemschijf van de verbroken VIRTUELE machine verwisseld met de gekopieerde vaste schijf.
  • Ten slotte wordt met het repair-button script automatisch de resourcegroep verwijderd die de tijdelijke herstel-VM bevat.

Ontbrekende initramfs handmatig opnieuw genereren

Belangrijk

  • Als u de VM kunt opstarten met behulp van een eerdere kernelversie of in een chroot-omgeving vanaf de herstel-/reddings-VM, genereer dan handmatig de ontbrekende initramfs opnieuw.
  • Als u ontbrekende initramfs handmatig opnieuw wilt genereren vanaf een herstel-VM, moet u ervoor zorgen dat stap 1 in Offline probleemoplossing al is gevolgd en dat deze opdrachten worden uitgevoerd in chroot.

  1. Identificeer de specifieke kernelversie met problemen met opstarten. U kunt de versie-informatie extraheren uit de bijbehorende kernelpanic-fout.

    Raadpleeg de volgende schermopname als voorbeeld. De kernel-paniekfout geeft aan dat de kernelversie 3.10.0-1160.59.1.el7.x86_64 is:

    Schermopname van het identificeren van de specifieke kernelversie met de ontbrekende initramfs-installatiekopieën.

  2. Genereer het ontbrekende initramfs-bestand opnieuw door een van de volgende opdrachten uit te voeren:

    • 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_64

      Belangrijk

      Vervang door 3.10.0-1160.59.1.el7.x86_64 de bijbehorende kernelversie.

    • 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-azure

      Belangrijk

      Vervang door 5.3.18-150300.38.53-azure de bijbehorende kernelversie.

    • Ubuntu 18.04

      sudo depmod -a 5.4.0-1077-azure
sudo mkinitramfs -k -o /boot/initrd.img-5.4.0-1077-azure

      Belangrijk

      Vervang door 5.4.0-1077-azure de bijbehorende kernelversie.

  3. Genereer het GRUB-configuratiebestand opnieuw. Volg de instructies in Grub opnieuw installeren en het GRUB-configuratiebestand opnieuw genereren voor de bijbehorende Linux-distributie en vm-generatie

  4. Als de bovenstaande stappen worden uitgevoerd vanaf een herstel-VM, volgt u stap 3 in offline probleemoplossing. Als de bovenstaande stappen worden uitgevoerd vanuit de Azure seriële console, volgt u de methode Online probleemoplossing.

  5. Start de VM opnieuw op via de meest recente kernelversie.

Kernel paniek - niet synchroniseren: geprobeerd init te doden

Identificeer dit probleem vanuit de Azure seriële console. De uitvoer ziet er als volgt uit:

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

Dit type kernel panic treedt op vanwege de volgende mogelijke oorzaken:

Zie de volgende secties voor oorzaakdetails en oplossingen. Zorg ervoor dat de opdrachten worden uitgevoerd vanaf een herstel-/reddings-VM in een chroot-omgeving, zoals wordt aangegeven in offline probleemoplossing.

Belangrijke bestanden en mappen ontbreken

Belangrijke Linux-bestanden en -mappen ontbreken vanwege een menselijke fout. Bestanden worden bijvoorbeeld per ongeluk verwijderd of beschadiging van het bestandssysteem.

  1. Valideer de inhoud van de besturingssysteemschijf nadat u de kopie van de besturingssysteemschijf hebt gekoppeld aan een herstel-VM en koppel de bijbehorende bestandssystemen met behulp van chroot. U kunt de uitvoer vergelijken met de uitvoer van een werkende VM waarop dezelfde versie van het besturingssysteem wordt uitgevoerd.

    ls -l /
ls -l /usr/lib
ls -l /usr/lib64
ls -lR / | more

  2. Herstel de ontbrekende bestanden uit een back-up. Zie voor meer informatie Bestanden herstellen van Azure back-up van virtuele machines. Afhankelijk van het aantal ontbrekende bestanden is het wellicht beter om een volledige VM-herstel uit te voeren. Zie Het herstellen van Azure VM-gegevens in Azure portal voor meer informatie.

Belangrijke systeemkernbibliotheken en -pakketten ontbreken

Belangrijke systeemkernbibliotheken, bestanden of pakketten worden verwijderd uit het systeem of zijn beschadigd. U kunt dit probleem oplossen door de betrokken bibliotheken, bestanden of pakketten opnieuw te installeren. Deze oplossing werkt op RPM gebaseerde distributies zoals Red Hat/CentOS/SUSE-VM's. Voor andere Linux-distributies raden we u aan om de VIRTUELE machine te herstellen vanuit een back-up.

Voer de volgende stappen uit om de herinstallatie uit te voeren:

  1. Maak een reddings-VM met behulp van een raw image met dezelfde besturingssysteemversie en generatie als de betreffende VM.

  2. Open de chroot-omgeving in de herstel-VM om het probleem op te lossen.

    sudo chroot /rescue

    In de uitvoer van de opdracht wordt aangegeven welke bibliotheek ontbreekt of beschadigd is, zoals hieronder wordt weergegeven:

    /bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

  3. Controleer alle systeempakketten en de bijbehorende status in de herstel-VM. Vergelijk de uitvoer met een vm met dezelfde versie van het besturingssysteem die in orde is.

    sudo rpm --verify --all --root=/rescue

    Hier volgt een voorbeeld van de uitvoer van de opdracht:

    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.conf

    De uitvoerregel missing /lib64/libc-2.28.so is gerelateerd aan de vorige fout in stap 2 en geeft aan dat het libc-2.28.so pakket ontbreekt. Het libc-2.28.so-pakket kan echter worden gewijzigd. In dit geval wordt de uitvoer weergegeven .M..... in plaats van missing. Bij de volgende stappen wordt het libc-2.28.so-pakket als voorbeeld genoemd.

  4. Controleer in de reddings-VM welk pakket de bibliotheek /lib64/libc-2.28.so bevat.

    sudo rpm -qf /lib64/libc-2.28.so

    glibc-2.28-127.0.1.el8.x86_64

    Notitie

    In de uitvoer wordt het pakket weergegeven dat opnieuw moet worden geïnstalleerd, inclusief de pakketnaam en versie. De pakketversie kan afwijken van de versie die op de betreffende VM is geïnstalleerd.

  5. Controleer op de betreffende VM welke versie van het glibc-pakket is geïnstalleerd.

    sudo rpm -qa --all --root=/rescue | grep -i glibc

    glibc-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_64

  6. Download het pakket glibc-2.28-211.0.1.el8.x86_64. U kunt het downloaden vanaf de officiële website van de leverancier van het besturingssysteem of van de reddings-VM met behulp van een hulpprogramma voor pakketbeheer, zoals yumdownloader of zypper install --download-only <packagename> afhankelijk van het besturingssysteem dat u uitvoert.

    Hier volgt een voorbeeld van het gebruik van het yumdownloader hulpprogramma:

    cd /tmp
sudo yumdownloader glibc-2.28-211.0.1.el8.x86_64

    Last 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:00

  7. Installeer het betrokken pakket opnieuw in de reddings-VM.

    sudo rpm -ivh --root=/rescue /tmp/glibc-*.rpm --replacepkgs --replacefiles

    warning: /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%]

  8. Open de chroot-omgeving in de reddings-VM om de herinstallatie te valideren.

    sudo chroot /rescue

  9. Schakel de reddings-VM uit en verwissel de besturingssysteemschijf naar de betreffende VM.

Verkeerde bestandsmachtigingen

Verkeerde systeembrede bestandsmachtigingen worden gewijzigd door een menselijke fout (bijvoorbeeld wanneer iemand chmod 777 op / of andere belangrijke besturingssysteembestanden uitvoert). U kunt dit probleem oplossen door de bestandsmachtigingen te herstellen. Deze oplossing werkt op RPM gebaseerde distributies zoals Red Hat/CentOS/SUSE-VM's. Voor andere Linux-distributies raden we u aan om de VIRTUELE machine te herstellen vanuit een back-up.

Als u de bestandsmachtigingen wilt herstellen, voert u de volgende opdracht uit nadat u de kopie van de besturingssysteemschijf hebt gekoppeld aan een herstel-VM en de bijbehorende bestandssystemen koppelt met behulp van chroot:

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

Notitie

Voer deze opdracht niet uit op draaiende productiesystemen.

Als het probleem nog steeds bestaat nadat u de bijbehorende bestandsmachtigingen handmatig hebt hersteld, voert u een herstelbewerking uit vanaf een back-up.

Ontbrekende partities

In gevallen waarin /usr, /opt, /var, , /home, en /tmp/bestandssystemen worden verspreid over verschillende partities, kunnen de gegevens niet toegankelijk zijn vanwege problemen op het niveau van partities, die kunnen worden veroorzaakt door fouten tijdens het wijzigen van de partitiebewerkingen of andere.

Als u in dit scenario de oorspronkelijke partitietabelindeling documenteert, met de exacte begin- en eindsectoren voor elk van de oorspronkelijke partities, en er geen verdere wijzigingen worden aangebracht op het systeem, zoals het maken van nieuwe bestandssystemen, maakt u de partities opnieuw met dezelfde oorspronkelijke indeling met hulpprogramma's zoals fdisk (voor MBR-partitietabellen) of gdisk (voor GPT-partitietabellen) om toegang te krijgen tot het ontbrekende bestandssysteem.

Als deze methode niet werkt, voert u een herstelbewerking uit vanuit een back-up.

Problemen met SELinux

Verkeerde SELinux-machtigingen kunnen verhinderen dat het systeem toegang heeft tot belangrijke bestanden. Volg deze stappen om dit probleem op te lossen:

  1. Als u wilt controleren of het systeem problemen heeft vanwege verkeerde SELinux-machtigingen, start u het systeem met SELinux uitgeschakeld door de selinux=0-kerneloptie toe te voegen aan de GRUB linux16-regel.

  2. Als het systeem kan opstarten, voert u de volgende opdracht uit om tijdens het opstarten een SELinux-relabel te activeren en het systeem opnieuw op te starten:

    touch /.autorelabel

  3. Als de VIRTUELE machine nog steeds niet kan worden opgestart, voert u een volledige VM-herstel uit vanuit een back-up. Zie Het herstellen van Azure VM-gegevens in Azure portal voor meer informatie.

Andere opstartproblemen met betrekking tot kernel

In dit artikel worden de meest voorkomende panieken in de Linux-kernel beschreven die in Azure zijn geïdentificeerd. Zie Kernel-paniek in Azure Linux-VM's - Veelvoorkomende kernel paniekgebeurtenissen voor meer informatie over veelvoorkomende kernel paniekscenario's.

Er zijn andere belangrijke mogelijke kernel panics die kunnen leiden tot niet opstarten of niet kunnen inloggen via SSH (Secure Shell).

Zorg ervoor dat u opdrachten uitvoert vanaf een herstel-VM in een chroot-omgeving, zoals wordt aangegeven in offline probleemoplossing. Als het systeem al is opgestart via een eerdere kernelversie, kunnen deze opdrachten ook worden uitgevoerd vanaf de oorspronkelijke VM met behulp van hoofdbevoegdheden of sudo, zoals wordt aangegeven in online probleemoplossing.

Recente kernelupgrade

Als de kernel in paniek raakt na een recente kernelupgrade, start u de VM op via de vorige kernelversie. Zie Opstartsysteem op oudere kernelversie voor meer informatie.

U kunt ook controleren of er al een nieuwere kernelversie is die is uitgebracht door de leverancier van de Linux-distributie en deze installeert. Zie het kernel-updateproces voor meer informatie over het installeren van de meest recente kernelversie.

Recente kernel downgrade

Als de kernelpanics beginnen na een recente kernel-downgrade, keert u terug naar de meest recente geïnstalleerde kernel. U kunt ook controleren of er al een nieuwere kernelversie is die is uitgebracht door de leverancier van de Linux-distributie en deze installeert. Zie het kernel-updateproces voor meer informatie over het installeren van de meest recente kernelversie.

Als u het systeem wilt opstarten via de meest recente kernelversie, volgt u de instructies in De standaard kernelversie handmatig wijzigen, maar selecteert u de eerste kernel die wordt vermeld in het grub-menu. In een handmatige wijziging kunt u de GRUB_DEFAULT waarde instellen op 0 en het bijbehorende GRUB-configuratiebestand opnieuw genereren.

Wijzigingen in kernelmodules

Mogelijk ondervindt u een kernel paniek die is gerelateerd aan een nieuwe kernelmodule of een ontbrekende kernelmodule. Als u meer informatie wilt over de specifieke kernelmodule die problemen veroorzaakt (indien van toepassing), controleert u het bijbehorende kernel panic-logboek.

Voer een van de volgende opdrachten uit om de geladen kernelmodules en de uitgeschakelde modules in /etc/modprobe.d/*.conf-bestanden te valideren:

  • RHEL/CentOS/Oracle Linux 7/8

    lsinitrd /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img
lsmod
cat /etc/modprobe.d/*.conf

    Belangrijk

    Vervang door 3.10.0-1160.59.1.el7.x86_64 de bijbehorende kernelversie.

  • SLES 12/15

    lsinitrd /boot/initrd-5.3.18-150300.38.53-azure
lsmod
cat /etc/modprobe.d/*.conf

    Belangrijk

    Vervang door 5.3.18-150300.38.53-azure de bijbehorende kernelversie.

  • Ubuntu 18.04

    lsinitramfs /boot/initrd.img-5.4.0-1077-azure
lsmod
cat /etc/modprobe.d/*.conf

    Belangrijk

    Vervang door 5.4.0-1077-azure de bijbehorende kernelversie.

Als u een specifieke kernelmodule wilt verwijderen, voert u de volgende opdracht uit en genereert u de initramfs indien nodig opnieuw.

rmmod <kernel_module_name>

Als een systeemservice gebruikmaakt van de specifieke kernelmodule, schakelt u deze uit door de systemctl disable <serviceName> of systemctl stop <serviceName> opdracht uit te voeren.

Recente configuratiewijzigingen van besturingssysteem

Identificeer recente kernelconfiguratiewijzigingen die problemen kunnen veroorzaken. U kunt de problemen oplossen door deze instellingen aan te passen of de configuratiewijzigingen terug te draaien.

Voer de volgende opdracht uit om permanente kernelparameters te vinden die zijn geconfigureerd in een van de volgende bestanden:

cat /etc/systctl.conf
cat /etc/sysctl.d/*

Voer de volgende opdracht uit om de huidige kernelparameters en hun huidige waarden te analyseren:

sysctl -a

Notitie

Voer deze opdracht uit op een actief systeem en niet vanuit een chroot-omgeving.

Mogelijke ontbrekende bestanden

Zie Ontbrekende belangrijke bestanden en mappen voor meer informatie over dit soort problemen.

Verkeerde machtigingen voor bestanden

Zie Verkeerde bestandsmachtigingen voor meer informatie over dit soort problemen.

Ontbrekende partities

Zie Ontbrekende partities voor meer informatie over dit soort problemen.

Kernelfouten

Identificeer dit probleem vanuit de Azure seriële console. Dit type probleem ziet eruit als de volgende uitvoer:

[5275698.017004] kernel BUG at XXX/YYY.c:72!
[5275698.017004] invalid opcode: 0000 [#1] SMP

Dit soort kernel paniek is gekoppeld aan kernelfouten of kernelfouten van derden.

Als u kernelfouten wilt oplossen, zoekt u in de Knowledge Base van de leverancier met behulp van de kernel BUG-tekenreeks en zoekt u naar bekende problemen in de bijbehorende kernelversie die uw systeem uitvoert. Hier volgen enkele belangrijke leveranciersbronnen:

We raden u aan al uw systemen up-to-date te houden om mogelijke fouten uit te sluiten die al zijn opgelost in de meest recente kernel-versies. Zie Kernel-updateproces voor meer informatie.

Als verdere analyse van de leverancier vereist is, configureert en schakelt u kdump in om een kern-dump te genereren:

Kernel-update-proces

Voer een van de volgende opdrachten uit om de meest recente beschikbare kernelversie te installeren:

  • RHEL/CentOS/Oracle Linux

    yum update kernel

  • SLES 12/15

    zypper refresh
zypper update kernel*

  • Ubuntu 18.04/20.04

    apt update
apt install linux-azure

Voer een van de volgende opdrachten uit om een specifieke kernelversie opnieuw te installeren. Zorg ervoor dat u niet opstart via dezelfde kernelversie die u opnieuw probeert te installeren. Zie Opstartsysteem op oudere kernelversie voor meer informatie.

  • RHEL/CentOS/Oracle Linux

    yum reinstall kernel-3.10.0-1160.59.1.el7.x86_64

    Belangrijk

    Vervang door 3.10.0-1160.59.1.el7.x86_64 de bijbehorende kernelversie.

  • SLES 12/15

    zypper refresh
zypper install -f kernel-azure-5.3.18-150300.38.75.1.x86_64

    Belangrijk

    Vervang door kernel-azure-5.3.18-150300.38.75.1.x86_64 de bijbehorende kernelversie.

    • Ubuntu 18.04/20.04

      apt update
apt install --reinstall linux-azure=5.4.0.1091.68

      Belangrijk

      Vervang door 5.4.0.1091.68 de bijbehorende kernelversie.

Voer een van de volgende opdrachten uit om het systeem bij te werken en de meest recente beschikbare wijzigingen toe te passen:

  • RHEL/CentOS/Oracle Linux

    yum update

  • SLES 12/15

    zypper refresh
zypper update

  • Ubuntu 18.04/20.04

    apt update
apt upgrade

Kernel-paniek kan betrekking hebben op een van de volgende onderdelen. Zie Kernel-paniek tijdens runtime voor meer informatie.

  • Wijzigingen in toepassingsworkloads.
  • Toepassingsontwikkeling of toepassingsfouten.
  • Prestatieproblemen, enzovoort.

Volgende stappen

Zie Troubleshoot Azure Linux Virtual Machines opstartfouten voor verdere probleemoplossingsopties als de specifieke opstartfout geen kernelprobleem is.

  • Last updated on