Delen via

De virtuele Azure Linux-machine kan niet worden opgestart na het toepassen van kernelwijzigingen

  • Artikel

Opmerking

CentOS waarnaar in dit artikel wordt verwezen, is een Linux-distributie en bereikt end of life (EOL). Overweeg uw gebruik en plan dienovereenkomstig. Zie Richtlijnen voor het einde van de levensduur van CentOS voor meer informatie.

Dit artikel biedt oplossingen voor een probleem waarbij een virtuele Linux-machine (VM) niet kan worden opgestart na het toepassen van kernelwijzigingen.

Voorwaarden

Zorg ervoor dat de seriële console is ingeschakeld en functioneel is op de Linux-VM.

Opstartprobleem met betrekking tot kernels identificeren

Als u een opstartprobleem met betrekking tot de kernel wilt identificeren, controleert u de specifieke kernel panic-tekenreeks. Gebruik hiervoor de Azure CLI of de Azure Portal om de uitvoer van het seriële consolelogboek van de VM weer te geven in het deelvenster diagnostische gegevens over opstarten of seriële console.

Een kernel panic ziet eruit als de volgende uitvoer en wordt weergegeven aan het einde van het seriële consolelogboek:

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

Tip

Als u een recente back-up van de VM hebt, herstelt u de VM 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 kernelgerelateerde opstartprobleem.

  2. Gebruik de seriële Console van Azure om uw VM 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 het specifieke kernelgerelateerde opstartprobleem op te lossen:

  4. Nadat het kernelgerelateerde opstartprobleem is opgelost, start u de VM opnieuw op zodat deze kan opstarten via de nieuwste kernelversie.

Offline oplossen van problemen

Tip

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

Als de seriële Azure-console niet werkt op de specifieke VM of geen optie is in uw abonnement, kunt u het opstartprobleem oplossen met behulp van een herstel-VM. Ga hiervoor als volgt te werk:

  1. Gebruik vm-herstelopdrachten om een herstel-VM te maken waaraan een kopie van de besturingssysteemschijf van de betrokken VM is gekoppeld. Koppel de kopie van de besturingssysteembestandssystemen in de herstel-VM met behulp van chroot.

    Opmerking

    U kunt ook handmatig een reddings-VM maken met behulp van de Azure Portal. Zie Problemen met een Virtuele Linux-machine oplossen door de besturingssysteemschijf te koppelen aan een herstel-VM met behulp van de Azure Portal voor meer informatie.

  2. Identificeer het specifieke kernelgerelateerde opstartprobleem.

  3. Ga naar de bijbehorende sectie om het specifieke kernelgerelateerde opstartprobleem op te lossen:

  4. Nadat het kernelgerelateerde opstartprobleem is opgelost, voert u de volgende acties uit:

    1. Sluit chroot af.
    2. Ontkoppel de kopie van de bestandssystemen van de herstel-VM.
    3. Voer de az vm repair restore opdracht uit om de herstelde besturingssysteemschijf te vervangen door de oorspronkelijke besturingssysteemschijf van de VM. Zie Stap 5 in Een Virtuele Linux-machine herstellen met behulp van de herstelopdrachten voor virtuele Azure-machines voor meer informatie.
    4. Controleer of de VM kan worden opgestart door de seriële console van Azure te bekijken of door verbinding te maken met de VM.

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

Opstartsysteem op oudere kernelversie

Seriële Console van Azure gebruiken

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

    1. Selecteer de afsluitknop boven in het seriële consolevenster.
    2. Selecteer de optie VM opnieuw opstarten (hard).

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

  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 bestand /etc/default/grub volgens instructies in Standaard kernelversie handmatig wijzigen. Dit is een permanente wijziging.

Opmerking

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.

Vm herstellen (ALAR-scripts) gebruiken

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

    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

Opmerking

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

Standaard kernelversie handmatig wijzigen

Voer de volgende stappen uit om de standaard kernelversie van een herstel-VM (in chroot) of op een actieve VM te wijzigen:

Opmerking

Als een kernel downgrade terugdraait, 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-VM's:

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

    2. Stel de nieuwe standaardkernel 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'

      Opmerking

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

    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

      Opmerking

      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. Geef de beschikbare kernels in het GRUB-configuratiebestand weer door de volgende opdracht uit te voeren:

      • Gen1-VM's:

        • SLES 12/15:

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

        • Ubuntu 18.04/20.04:

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

      • Gen2-VM's:

        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"

      Opmerking

      Zie SUSE Boot Loader GRUB2 en Ubuntu Grub2/Setup voor meer informatie over het configureren van de GRUB_DEFAULT variabele. Ter referentie: de waarde menuentry op het hoogste niveau is 0, de eerste waarde van het submenu op het hoogste niveau is 1 en elke waarde voor geneste menu-pogingen 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 GRUB-configuratiebestand opnieuw genereren voor de bijbehorende Linux-distributie en VM-generatie.

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

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

  1. "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)

  2. "error: file '/initramfs-*.img' not found"

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

Dit soort fout geeft aan dat het initramfs-bestand niet wordt gegenereerd, dat het GRUB-configuratiebestand de initrd-vermelding ontbreekt na een patchproces of een onjuiste 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 is voltooid en er geen initramfs-bestanden ontbreken.

  • BIOS-gebaseerd - Gen1-systemen

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

  • Op basis van UEFI - Gen2-systemen

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

Ontbrekende initramfs opnieuw genereren met behulp van Azure Repair VM ALAR-scripts

  1. Maak een herstel-VM door de volgende Bash-opdrachtregel uit te voeren met Azure Cloud Shell. Zie Azure Linux Auto Repair (ALAR) gebruiken om een Linux-VM te herstellen - initrd-optie voor meer informatie.

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

  2. De installatiekopieën initrd/initramfs opnieuw genereren en het GRUB-configuratiebestand opnieuw genereren als de initrd-vermelding ontbreekt. Voer hiervoor de volgende opdracht uit:

    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 $VMNAME

  3. Zodra de herstelopdracht is uitgevoerd, start u de oorspronkelijke VM opnieuw op en controleert u of deze kan worden opgestart.

Ontbrekende initramfs handmatig opnieuw genereren

Belangrijk

  • Als u de VM kunt opstarten met behulp van een eerdere kernelversie of binnen chroot van de repair/rescue-VM, moet u ontbrekende initramfs handmatig opnieuw genereren.
  • 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 in chroot worden uitgevoerd.

  1. Identificeer de specifieke kernelversie die problemen heeft met opstarten. U kunt de versie-informatie extraheren uit de bijbehorende kernel panic-fout.

    Raadpleeg de volgende schermopname als voorbeeld. De kernel panic-fout toont aan dat de kernelversie '3.10.0-1160.59.1.el7.x86_64' is:

    Schermopname die laat zien hoe u de specifieke kernelversie met de ontbrekende initramfs-installatiekopieën kunt identificeren.

  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. Het GRUB-configuratiebestand opnieuw genereren. Volg de instructies in GRUB opnieuw installeren en 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 oplossen. Als de bovenstaande stappen worden uitgevoerd vanuit de seriële Azure-console, volgt u de methode Online probleemoplossing .

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

Kernel panic - niet synchroniseren: geprobeerd init te doden

Identificeer dit probleem vanuit de seriële Azure-console. De uitvoer ziet er ongeveer 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 soort kernel panic treedt op vanwege de volgende mogelijke oorzaken:

Zie de volgende secties voor details van de oorzaak en oplossingen. Zorg ervoor dat de opdrachten worden uitgevoerd vanaf een herstel-/herstel-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 het bestandssysteem beschadigd.

  1. Valideer de inhoud van de besturingssysteemschijf nadat u de kopie van de besturingssysteemschijf hebt gekoppeld aan een herstel-VM en de bijbehorende bestandssystemen hebt gekoppeld 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 Bestanden herstellen van back-up van virtuele Azure-machines voor meer informatie. Afhankelijk van het aantal ontbrekende bestanden is het misschien beter om een volledige VM te herstellen. Zie Azure VM-gegevens herstellen in Azure Portal voor meer informatie.

Belangrijke systeemkernbibliotheken en -pakketten ontbreken

Belangrijke systeemkernbibliotheken, bestanden of pakketten worden van het systeem verwijderd of 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 de VM te herstellen vanuit een back-up.

Voer de volgende stappen uit om het opnieuw installeren uit te voeren:

  1. Maak een herstel-VM met behulp van een onbewerkte installatiekopieën met dezelfde versie en generatie van het besturingssysteem als de betreffende VM.

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

    sudo chroot /rescue

    De uitvoer van de opdracht geeft aan 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 hun bijbehorende status in de herstel-VM. Vergelijk de uitvoer met een goede VM waarop dezelfde versie van het besturingssysteem wordt uitgevoerd.

    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. In de volgende stappen wordt naar het libc-2.28.so-pakket verwezen als voorbeeld.

  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

    Opmerking

    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 is geïnstalleerd op de betreffende VM.

  5. Controleer in 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 deze downloaden van 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 het opnieuw installeren te valideren.

    sudo chroot /rescue

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

Verkeerde bestandsmachtigingen

Onjuiste systeembrede bestandsmachtigingen worden gewijzigd vanwege een menselijke fout (bijvoorbeeld iemand die op / of andere belangrijke bestandssystemen van het besturingssysteem wordt uitgevoerdchmod 777). 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 de VM 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 hebt gekoppeld 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

Opmerking

Voer deze opdracht niet uit op actieve productiesystemen.

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

Ontbrekende partities

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

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

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

SELinux-problemen

Verkeerde SELinux-machtigingen kunnen voorkomen dat het systeem toegang heeft tot belangrijke bestanden. Voer de volgende stappen uit om dit probleem op te lossen:

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

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

    touch /.autorelabel

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

Andere opstartproblemen met betrekking tot kernels

In dit artikel worden de meest voorkomende Linux-kernelpanieken beschreven die in Azure zijn geïdentificeerd. Zie Kernel panic in Azure Linux-VM's - Veelvoorkomende kernelpanniekgebeurtenissen voor meer informatie over veelvoorkomende kernel panic-scenario's.

Er zijn enkele andere belangrijke mogelijke kernelpanieken die geen opstart- of SSH-scenario's (Secure Shell) kunnen veroorzaken.

Zorg ervoor dat u opdrachten uitvoert vanaf een herstel-VM in een chroot-omgeving, zoals 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 basisbevoegdheden 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 uitgebracht door de Linux-distributieleverancier en deze installeren. Zie Kernelupdateproces voor meer informatie over het installeren van de meest recente kernelversie.

Recente kernel downgrade

Als de kernel in paniek raakt na een recente kerneldowngrade, keert u terug naar de laatst geïnstalleerde kernel. U kunt ook controleren of er al een nieuwere kernelversie is uitgebracht door de Linux-distributieleverancier en deze installeren. Zie Kernelupdateproces 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 standaardversie van de kernel 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 kernelmodule

Mogelijk ondervindt u een kernelpanniek die is gerelateerd aan een nieuwe kernelmodule of een ontbrekende kernelmodule. Voor meer informatie over de specifieke kernelmodule die problemen veroorzaakt (indien aanwezig), controleert u de bijbehorende kernel panic trace.

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 zo nodig opnieuw.

rmmod <kernel_module_name>

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

Recente configuratiewijzigingen van het besturingssysteem

Identificeer recente wijzigingen in de kernelconfiguratie 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

Opmerking

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

Mogelijk ontbrekende bestanden

Zie Belangrijke bestanden en mappen ontbreken voor meer informatie over dit soort problemen.

Verkeerde machtigingen voor bestanden

Zie Onjuiste 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 seriële Azure-console. Dit soort 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 kernelpanniek 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 bugtekenreeks van de kernel en zoekt u naar bekende problemen in de bijbehorende kernelversie van uw systeem. Hier volgen enkele belangrijke leveranciersresources:

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 kernelversies. Zie Kernelupdateproces voor meer informatie.

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

Kernelupdateproces

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

Als u een specifieke kernelversie opnieuw wilt installeren, voert u een van de volgende opdrachten uit. Zorg ervoor dat u niet bent opgestart met 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 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 panics kunnen gerelateerd zijn aan een van de volgende items. Zie Kernel panics at runtime (Kernel panics at runtime) voor meer informatie.

  • Wijzigingen in de toepassingsworkload.
  • Toepassingsontwikkeling of toepassingsfouten.
  • Prestatieproblemen, enzovoort.

Volgende stappen

Als de specifieke opstartfout geen opstartprobleem met betrekking tot de kernel is, raadpleegt u Opstartfouten in Azure Linux Virtual Machines oplossen voor verdere probleemoplossingsopties.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Feedback-community van Azure.