Virtuele Azure 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.
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.
Opstartprobleem met betrekking tot kernel identificeren
Als u een probleem met betrekking tot het opstarten van een kernel wilt identificeren, controleert u de specifieke kernel-paniekreeks. Hiervoor gebruikt u de Azure CLI of 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 paniek 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 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.
Identificeer het specifieke probleem met het opstarten van de kernel.
Gebruik de seriële Azure-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.
Ga naar de bijbehorende sectie om het specifieke probleem met de kernel op te lossen:
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.
Problemen met offline oplossen
Tip
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 seriële Azure-console niet werkt in 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:
Gebruik vm-herstelopdrachten om een herstel-VM te maken waarop een kopie van de besturingssysteemschijf van de betreffende VM is gekoppeld. Koppel de kopie van de besturingssysteembestandssystemen in de herstel-VM met behulp van chroot.
Notitie
U kunt ook handmatig een reddings-VM maken met behulp van Azure Portal. Zie Problemen met een Virtuele Linux-machine oplossen door de besturingssysteemschijf te koppelen aan een herstel-VM met behulp van Azure Portal.
Identificeer het specifieke probleem met het opstarten van de kernel.
Ga naar de bijbehorende sectie om het specifieke probleem met de kernel op te lossen:
Nadat het probleem met betrekking tot de kernel is opgelost, voert u de volgende acties uit:
- Sluit chroot.
- Ontkoppel de kopie van de bestandssystemen van de herstel-/herstel-VM.
- 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 Het herstellen van een Virtuele Linux-machine met behulp van de herstelopdrachten voor virtuele Azure-machines voor meer informatie. - Controleer of de VIRTUELE machine kan worden opgestart door de seriële Azure-console te bekijken of door verbinding te maken met de virtuele machine.
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 Azure VM-gegevens herstellen in Azure Portal voor meer informatie.
Opstartsysteem op oudere kernelversie
Seriële Azure-console gebruiken
Start de VIRTUELE machine opnieuw op met behulp van de seriële Azure-console.
- Selecteer de knop Afsluiten boven aan het seriële consolevenster.
- Selecteer de optie VM opnieuw opstarten (hard).
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.
Druk op de pijl-omlaag om een eerdere kernelversie te selecteren.
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.
Herstel-VM (ALAR-scripts) gebruiken
Voer de volgende bash-opdracht uit in Azure Cloud Shell om een herstel-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
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
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
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 door
Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64
de bijbehorende titel van de menuvermelding.Controleer of de nieuwe standaardkernel de gewenste is door de volgende opdracht uit te voeren:
grub2-editenv list
Zorg ervoor dat de waarde van de
GRUB_DEFAULT
variabele in het bestand /etc/default/grub is ingesteld opsaved
. Als u dit wilt wijzigen, moet u het GRUB-configuratiebestand opnieuw genereren om de wijzigingen toe te passen.
RHEL 8/9 en CentOS 8
Geef de beschikbare kernels weer door de volgende opdracht uit te voeren:
ls -l /boot/vmlinuz-*
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.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
Vermeld de beschikbare kernels in het GRUB-configuratiebestand 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
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. Ter referentie: de waarde voor menu's op het hoogste niveau is 0, de eerste submenuwaarde op het hoogste niveau is 1 en elke geneste menu-waarde begint met 0. '1>2' is bijvoorbeeld het derde menu uit het eerste submenu.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 via de seriële Console van Azure. U ziet een van de volgende foutberichten:
"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' 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 BASIS VAN BIOS - 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 behulp van ALAR-scripts voor Azure Repair VM
Maak een herstel-VM door de volgende Bash-opdrachtregel uit te voeren met Azure Cloud Shell. Zie Azure Linux Auto Repair (ALAR) gebruiken voor het herstellen van een Linux-VM - 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
Genereer de initrd/initramfs-installatiekopieën opnieuw en genereer het GRUB-configuratiebestand 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
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 VIRTUELE machine kunt opstarten met behulp van een eerdere kernelversie of in chroot vanaf de herstel-/reddings-VM, genereert u handmatig 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.
Identificeer de specifieke kernelversie met problemen met opstarten. U kunt de versie-informatie extraheren uit de bijbehorende kernel paniekfout.
Raadpleeg de volgende schermopname als voorbeeld. De kernel-paniekfout geeft aan dat de kernelversie 3.10.0-1160.59.1.el7.x86_64 is:
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.
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
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 seriële Azure-console, volgt u de online probleemoplossingsmethode .
Start de VM opnieuw op via de meest recente kernelversie.
Kernel paniek - niet synchroniseren: geprobeerd init te doden
Identificeer dit probleem vanuit de seriële Azure-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 soort kernel paniek treedt op vanwege de volgende mogelijke oorzaken:
Belangrijke bestanden en mappen ontbreken.
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.
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
Herstel de ontbrekende bestanden uit een back-up. Zie Bestanden herstellen vanuit back-up van virtuele Azure-machines voor meer informatie. Afhankelijk van het aantal ontbrekende bestanden is het wellicht beter om een volledige VM-herstel uit te voeren. Zie Azure VM-gegevens herstellen 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:
Maak een reddings-VM met behulp van een onbewerkte installatiekopieën met dezelfde versie en generatie van het besturingssysteem als de betreffende VM.
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
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 vanmissing
. In de volgende stappen wordt verwezen naar het libc-2.28.so-pakket .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.
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
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
ofzypper 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
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%]
Open de chroot-omgeving in de reddings-VM om de herinstallatie te valideren.
sudo chroot /rescue
Schakel de reddings-VM uit en verwissel de besturingssysteemschijf naar de betreffende VM.
Verkeerde bestandsmachtigingen
Verkeerde systeembrede bestandsmachtigingen worden gewijzigd vanwege een menselijke fout (bijvoorbeeld iemand wordt uitgevoerd chmod 777
op / of andere belangrijke besturingssysteembestandssystemen). 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 het uitvoeren van 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:
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.
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
Als de VIRTUELE machine 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 kernel
In dit artikel worden de meest voorkomende paniek in linux-kernels 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 enkele andere belangrijke mogelijke kernel paniek die kan leiden tot geen opstart- of geen SSH-scenario's (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 kernel in paniek raakt 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 de bijbehorende kernel-paniektracering.
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 seriële Azure-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:
-
Dit hulpprogramma is ontworpen om u te helpen een kernel-crash te diagnosticeren. Wanneer u een tekst, vmcore-dmesg.txt of een bestand invoert, inclusief een of meer kernel-oops-berichten, wordt u begeleid bij het vaststellen van het probleem met het vastlopen van de kernel.
-
Als u toegang wilt krijgen tot de Red Hat-resources, koppelt u uw Microsoft Azure- en Red Hat-account. Zie Hoe Microsoft Azure-klanten toegang hebben tot de Red Hat-klantportal voor meer informatie.
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:
- Configuratie van kdump in Red Hat-VM's.
- Configuratie van kernel-crashdump in Ubuntu-VM's.
- Configuratie van kernel-kerndump in SLES-VM's.
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
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 items. Zie Kernel-paniek tijdens runtime voor meer informatie.
- Wijzigingen in toepassingsworkloads.
- Toepassingsontwikkeling of toepassingsfouten.
- Prestatieproblemen, enzovoort.
Volgende stappen
Als de specifieke opstartfout geen probleem is met betrekking tot het opstarten van een kernel, raadpleegt u Opstartfouten in Virtuele Azure Linux-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 Azure-feedbackcommunity.