Den virtuella Azure Linux-datorn kan inte startas efter att kerneländringar har tillämpats

Artikel
07/30/2024

Gäller för: ✔️ Virtuella Linux-datorer

Kommentar

CentOS som refereras i den här artikeln är en Linux-distribution och kommer att nå End Of Life (EOL). Överväg att använda och planera i enlighet med detta. Mer information finns i CentOS End Of Life-vägledning.

Den här artikeln innehåller lösningar på ett problem där en virtuell Linux-dator (VM) inte kan starta efter att kerneländringar har tillämpats.

Förutsättningar

Kontrollera att seriekonsolen är aktiverad och funktionell på den virtuella Linux-datorn.

Så här identifierar du kernelrelaterade startproblem

Om du vill identifiera ett kernelrelaterat startproblem kontrollerar du den specifika kernel-paniksträngen. Det gör du genom att använda Azure CLI eller Azure Portal för att visa utdata från seriekonsolloggen för den virtuella datorn i startdiagnostikfönstret eller seriekonsolfönstret.

En kernel-panik ser ut som följande utdata och visas i slutet av seriekonsolloggen:

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

Felsökning online

Dricks

Om du har en säkerhetskopia av den virtuella datorn nyligen återställer du den virtuella datorn från säkerhetskopian för att åtgärda startproblemet.

Seriekonsolen är den snabbaste metoden för att lösa startproblemet. Det gör att du kan åtgärda problemet direkt utan att behöva presentera systemdisken för en virtuell återställningsdator. Se till att du uppfyller de nödvändiga förutsättningarna för distributionen. Mer information finns i Seriekonsolen för virtuella datorer för Linux.

Identifiera det specifika kernelrelaterade startproblemet.
Använd Azure-seriekonsolen för att avbryta den virtuella datorn på GRUB-menyn och välj valfri tidigare kernel för att starta den. Mer information finns i Startsystem på äldre kernelversion.
Gå till motsvarande avsnitt för att lösa det specifika kernelrelaterade startproblemet:
När det kernelrelaterade startproblemet har lösts startar du om den virtuella datorn så att den kan startas över den senaste kernelversionen.

Felsökning offline

Dricks

Om du har en säkerhetskopia av den virtuella datorn nyligen återställer du den virtuella datorn från säkerhetskopian för att åtgärda startproblemet.

Om Azure-seriekonsolen inte fungerar på den specifika virtuella datorn eller inte är ett alternativ i din prenumeration kan du felsöka startproblemet med hjälp av en virtuell dator för återställning/reparation. För att göra detta följer du stegen nedan:

Använd vm-reparationskommandon för att skapa en reparations-VM som har en kopia av den berörda virtuella datorns OS-disk ansluten. Montera kopian av OS-filsystemen på den virtuella reparationsdatorn med hjälp av chroot.

Kommentar

Du kan också skapa en virtuell räddningsdator manuellt med hjälp av Azure Portal. Mer information finns i Felsöka en virtuell Linux-dator genom att ansluta OS-disken till en återställnings-VM med hjälp av Azure Portal.
Identifiera det specifika kernelrelaterade startproblemet.
Gå till motsvarande avsnitt för att lösa det specifika kernelrelaterade startproblemet:
När det kernelrelaterade startproblemet har lösts utför du följande åtgärder:
1. Avsluta chroot.
2. Demontera kopian av filsystemen från den virtuella datorn för räddning/reparation.
3. az vm repair restore Kör kommandot för att växla den reparerade OS-disken med den virtuella datorns ursprungliga OS-disk. Mer information finns i Steg 5 i Reparera en virtuell Linux-dator med hjälp av reparationskommandona för Azure Virtual Machine.
4. Kontrollera om den virtuella datorn kan startas genom att titta på Azure-seriekonsolen eller genom att försöka ansluta till den virtuella datorn.
Om det finns viktigt kernelrelaterat innehåll, hela /boot partitionen eller annat viktigt innehåll saknas och de inte kan återställas rekommenderar vi att du återställer den virtuella datorn från en säkerhetskopia. Mer information finns i Så här återställer du data för virtuella Azure-datorer i Azure Portal.

Startsystem på äldre kernelversion

Använda Seriekonsolen i Azure

Starta om den virtuella datorn med azure-seriekonsolen.
1. Välj avstängningsknappen överst i seriekonsolfönstret.
2. Välj alternativet Starta om virtuell dator (hårt).
När seriekonsolanslutningen återupptas visas en nedräkningsräknare i det vänstra övre hörnet i seriekonsolfönstret. Tryck på ESCAPE-tangenten för att avbryta den virtuella datorn på GRUB-menyn.
Tryck på nedåtpilen för att välja valfri tidigare kernelversion.
Ändra variabeln GRUB_DEFAULT i filen /etc/default/grub enligt instruktionerna i Ändra standard kernelversion manuellt. Det här är en beständig ändring.

Kommentar

Om det bara finns en kernelversion i GRUB-menyn följer du felsökningsmetoden Offline för att felsöka problemet från en virtuell reparationsdator.

Använda reparations-VM (ALAR-skript)

Kör följande bash-kommando i Azure Cloud Shell för att skapa en virtuell reparationsdator. Mer information finns i Använda Azure Linux Auto Repair (ALAR) för att åtgärda en virtuell Linux-dator – kernelalternativ.
```
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
```

Kör följande kommando för att ersätta den brutna kerneln med den tidigare installerade versionen:

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

Kommentar

Om det bara finns en kernelversion installerad i systemet följer du felsökningsmetoden Offline för att felsöka problemet från en virtuell reparationsdator.

Ändra standardversionen av kerneln manuellt

Följ dessa steg om du vill ändra standardversionen av kerneln från en virtuell reparationsdator (inuti chroot) eller på en virtuell dator som körs:

Kommentar

Om en kernelnedgraderingsåterställning är klar väljer du den senaste kernelversionen i stället för den äldre.

RHEL 7, Oracle Linux 7 och CentOS 7
1. Verifiera listan över tillgängliga kernels i GRUB-konfigurationsfilen genom att köra något av följande kommandon:
  - Virtuella Gen1-datorer:
```
cat /boot/grub2/grub.cfg | grep menuentry
```
  - Virtuella Gen2-datorer:
```
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
```
2. Ange den nya standardkärnan och ange motsvarande kernelrubrik genom att köra följande kommando:
```
# grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64'
```
  Kommentar
  
  Ersätt Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 med motsvarande menyrubrik.
3. Kontrollera att den nya standardkärnan är önskad genom att köra följande kommando:
```
grub2-editenv list
```
4. Kontrollera att värdet för variabeln GRUB_DEFAULT i filen /etc/default/grub är inställt på saved. Om du vill ändra den kontrollerar du att du återskapar GRUB-konfigurationsfilen för att tillämpa ändringarna.
RHEL 8/9 och CentOS 8
1. Visa en lista över tillgängliga kernels genom att köra följande kommando:
```
ls -l /boot/vmlinuz-*
```
2. Ange den nya standardkärnan genom att köra följande kommando:
```
grubby --set-default /boot/vmlinuz-4.18.0-372.19.1.el8_6.x86_64
```
  Kommentar
  
  Ersätt 4.18.0-372.19.1.el8_6.x86_64 med motsvarande kernelversion.
3. Kontrollera att den nya standardkärnan är önskad genom att köra följande kommando:
```
grubby --default-kernel
```
SLES 12/15, Ubuntu 18.04/20.04
1. Visa en lista över tillgängliga kernels i GRUB-konfigurationsfilen genom att köra följande kommando:
  - Virtuella Gen1-datorer:
    - SLES 12/15:
```
cat /boot/grub2/grub.cfg | grep menuentry
```
    - Ubuntu 18.04/20.04:
```
cat /boot/grub/grub.cfg | grep menuentry
```
  - Virtuella Gen2-datorer:
```
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
```
2. Ange den nya standardkärnan genom att ändra värdet för variabeln GRUB_DEFAULT i filen /etc/default/grub . För den senaste kernelversionen som installerats i systemet är standardvärdet 0. Nästa tillgängliga kernel är inställd på "1>2".
```
vi /etc/default/grub
GRUB_DEFAULT="1>2"
```
  Kommentar
  
  Mer information om hur du konfigurerar variabeln finns i GRUB_DEFAULT SUSE Boot Loader GRUB2 och Ubuntu Grub2/Setup. Som referens: menyobjektvärdet på den översta nivån är 0, det första undermenyvärdet på den översta nivån är 1 och varje kapslat menyförsöksvärde börjar med 0. Till exempel är "1>2" det tredje menyförsöket från den första undermenyn.
3. Återskapa GRUB-konfigurationsfilen för att tillämpa ändringarna. Följ anvisningarna i Installera om GRUB och återskapa GRUB-konfigurationsfilen för motsvarande Linux-distribution och VM-generering.

Kernel panic – synkroniseras inte: VFS: Det går inte att montera root fs på unknown-block(0,0)

Det här felet uppstår på grund av en nyligen genomförd systemuppdatering (kernel). Det är vanligast i RHEL-baserade distributioner. Du kan identifiera det här problemet från Azure-seriekonsolen. Du ser något av följande felmeddelanden:

"Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"

[  301.026129] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[  301.027122] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.10.0-1160.36.2.el7.x86_64 #1
[  301.027122] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008  12/07/2018
[  301.027122] Call Trace:
[  301.027122]  [<ffffffff82383559>] dump_stack+0x19/0x1b
[  301.027122]  [<ffffffff8237d261>] panic+0xe8/0x21f
[  301.027122]  [<ffffffff8298b794>] mount_block_root+0x291/0x2a0
[  301.027122]  [<ffffffff8298b7f6>] mount_root+0x53/0x56
[  301.027122]  [<ffffffff8298b935>] prepare_namespace+0x13c/0x174
[  301.027122]  [<ffffffff8298b412>] kernel_init_freeable+0x222/0x249
[  301.027122]  [<ffffffff8298ab28>] ? initcall_blcklist+0xb0/0xb0
[  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
[  301.027122]  [<ffffffff8237235e>] kernel_init+0xe/0x100
[  301.027122]  [<ffffffff82395df7>] ret_from_fork_nospec_begin+0x21/0x21
[  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
[  301.027122] Kernel Offset: 0xc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

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

error: filen '/initramfs-3.10.0-1160.36.2.el7.x86_64.img' hittades inte.

Den här typen av fel indikerar att initramfs-filen inte genereras, GRUB-konfigurationsfilen har den initrd posten saknas efter en korrigeringsprocess eller en MANUELL GRUB-felkonfiguration.

Innan du startar om en server rekommenderar vi att du verifierar GRUB-konfigurationen och /boot innehållet om det finns en kerneluppdatering genom att köra något av följande kommandon. Det är viktigt att se till att uppdateringen är klar och att det inte saknas initramfs-filer.

BIOS-baserade – Gen1-system

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

UEFI-baserade – Gen2-system

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

Återskapa saknade initramfs med hjälp av Azure Repair VM ALAR-skript

Skapa en virtuell reparationsdator genom att köra följande Bash-kommandorad med Azure Cloud Shell. Mer information finns i Använda Azure Linux Auto Repair (ALAR) för att åtgärda en virtuell Linux-dator – initrd option.
```
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
```

Återskapa initrd/initramfs-avbildningen och återskapa GRUB-konfigurationsfilen om den initrd posten saknas. Gör detta genom att köra följande kommando:

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

När återställningskommandot har körts startar du om den ursprungliga virtuella datorn och kontrollerar att den kan startas upp.

Återskapa saknade initramfs manuellt

Viktigt!

Om du kan starta den virtuella datorn med hjälp av en tidigare kernelversion eller inuti chroot från den virtuella reparations-/räddningsdatorn återskapar du saknade initramfs manuellt.
Om du vill återskapa saknade initramfs manuellt från en virtuell reparationsdator kontrollerar du att steg 1 i offlinefelsökning redan har följts och att dessa kommandon körs i chroot.

Identifiera den specifika kernelversion som har problem med start. Du kan extrahera versionsinformationen från motsvarande kernel-panikfel.

Se följande skärmbild som ett exempel. Kernel-panikfelet visar att kernelversionen är "3.10.0-1160.59.1.el7.x86_64":

Återskapa den saknade initramfs-filen genom att köra något av följande kommandon:

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

Viktigt!

Ersätt 3.10.0-1160.59.1.el7.x86_64 med motsvarande kernelversion.

SLES 12/15

sudo depmod -a 5.3.18-150300.38.53-azure
sudo dracut -f /boot/initrd-5.3.18-150300.38.53-azure 5.3.18-150300.38.53-azure

Viktigt!

Ersätt 5.3.18-150300.38.53-azure med motsvarande kernelversion.

Ubuntu 18.04

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

Viktigt!

Ersätt 5.4.0-1077-azure med motsvarande kernelversion.

Återskapa GRUB-konfigurationsfilen. Följ anvisningarna i Installera om GRUB och återskapa GRUB-konfigurationsfilen för motsvarande Linux-distribution och VM-generering
Om stegen ovan utförs från en virtuell reparationsdator följer du steg 3 i Felsökning offline. Om stegen ovan utförs från Azure-seriekonsolen följer du felsökningsmetoden Online.
Starta om den virtuella datorn via den senaste kernelversionen.

Kernel panic – inte synkronisering: Försökte döda init

Identifiera det här problemet från Azure-seriekonsolen. Du ser utdata som följande:

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

Den här typen av kernel-panik uppstår på grund av följande möjliga orsaker:

Viktiga filer och kataloger saknas.
Viktiga systemkärnbibliotek och paket saknas
Fel filbehörigheter
Partitioner saknas
SELinux-problem

Mer information och lösningar finns i följande avsnitt. Kontrollera att kommandona körs från en reparations-/räddnings-VM i en chroot-miljö enligt anvisningarna i Felsökning offline.

Viktiga filer och kataloger saknas

Viktiga Linux-filer och kataloger saknas på grund av ett mänskligt fel. Till exempel tas filer bort av misstag eller filsystemet skadas.

Verifiera os-diskinnehållet efter att du har bifogat kopian av OS-disken till en virtuell reparationsdator och monterat motsvarande filsystem med chroot. Du kan jämföra utdata med de från en fungerande virtuell dator som kör samma os-version.
```
ls -l /
ls -l /usr/lib
ls -l /usr/lib64
ls -lR / | more
```
Återställ de filer som saknas från en säkerhetskopia. Mer information finns i Återställa filer från säkerhetskopiering av virtuella Azure-datorer. Beroende på antalet filer som saknas kan det vara bättre att göra en fullständig återställning av virtuella datorer. Mer information finns i Så här återställer du data för virtuella Azure-datorer i Azure Portal.

Viktiga systemkärnbibliotek och paket saknas

Viktiga systemkärnbibliotek, filer eller paket tas bort från systemet eller skadas. Lös problemet genom att installera om de berörda biblioteken, filerna eller paketen. Den här lösningen fungerar på RPM-baserade distributioner som red hat/centOS/virtuella SUSE-datorer. För andra Linux-distributioner rekommenderar vi att du återställer den virtuella datorn från en säkerhetskopia.

Följ dessa steg för att utföra ominstallationen:

Skapa en virtuell räddningsdator med hjälp av en råavbildning med samma operativsystemversion och generering som den berörda virtuella datorn.
Få åtkomst till chroot-miljön på den virtuella räddningsdatorn för att felsöka problemet.
```
sudo chroot /rescue
```
Kommandoutdata anger vilket bibliotek som saknas eller är skadat enligt nedan:
```
/bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
```

Kontrollera alla systempaket och deras motsvarande status i den virtuella räddningsdatorn. Jämför utdata med en felfri virtuell dator som kör samma operativsystemversion.

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

Här är ett exempel på kommandoutdata:

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

Utdataraden missing /lib64/libc-2.28.so är relaterad till det tidigare felet i steg 2 och anger att libc-2.28.so-paketet saknas. Det libc-2.28.so paketet kan dock ändras. I det här fallet visas .M..... utdata i stället för missing. Libc-2.28.so-paketet refereras som ett exempel i följande steg.

I den virtuella räddningsdatorn kontrollerar du vilket paket som innehåller biblioteket /lib64/libc-2.28.so.
```
sudo rpm -qf /lib64/libc-2.28.so
```
```
glibc-2.28-127.0.1.el8.x86_64
```
Kommentar

Utdata visar paketet som måste installeras om, inklusive paketnamnet och versionen. Paketversionen kan skilja sig från den som är installerad på den berörda virtuella datorn.

I den berörda virtuella datorn kontrollerar du vilken version av glibc-paketet som är installerad.

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

Ladda ned paketet glibc-2.28-211.0.1.el8.x86_64. Du kan ladda ned den från os-leverantörens officiella webbplats eller från den virtuella räddningsdatorn med hjälp av ett pakethanteringsverktyg som yumdownloader eller zypper install --download-only <packagename> beroende på vilket operativsystem du kör.

Här är ett exempel på yumdownloader hur du använder verktyget:
```
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    
```

Installera om det berörda paketet på den virtuella räddningsdatorn.

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%]

Få åtkomst till chroot-miljön på den virtuella räddningsdatorn för att verifiera ominstallationen.
```
sudo chroot /rescue
```
Inaktivera den virtuella räddningsdatorn och växla OS-disken till den berörda virtuella datorn.

Fel filbehörigheter

Fel systemomfattande filbehörigheter ändras på grund av ett mänskligt fel (till exempel körs någon chmod 777 på / eller andra viktiga OPERATIVSYSTEM-filsystem). Lös problemet genom att återställa filbehörigheterna. Den här lösningen fungerar på RPM-baserade distributioner som red hat/centOS/virtuella SUSE-datorer. För andra Linux-distributioner rekommenderar vi att du återställer den virtuella datorn från en säkerhetskopia.

Om du vill återställa filbehörigheterna kör du följande kommando efter att du har bifogat kopian av OS-disken till en virtuell reparationsdator och monterat motsvarande filsystem med 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

Kommentar

Kör inte det här kommandot på produktionssystem som körs.

Om problemet kvarstår när motsvarande filbehörigheter har återställts manuellt utför du en återställning från säkerhetskopian.

Partitioner saknas

I de fall där /usr, /opt, /home/var, , /tmpoch / filsystem är spridda över olika partitioner kan data vara otillgängliga på grund av problem på partitionsnivå, vilket kan orsakas av misstag vid partitionsändringsåtgärder eller andra.

I det här scenariot, om du dokumenterar den ursprungliga partitionstabelllayouten, med de exakta start- och slutsektorerna för var och en av de ursprungliga partitionerna, och inga ytterligare ändringar görs i systemet, till exempel när nya filsystem skapas, återskapar du partitionerna med samma ursprungliga layout med verktyg som fdisk (för MBR-partitionstabeller) eller gdisk (för GPT-partitionstabeller) för att få åtkomst till det saknade filsystemet.

Om den här metoden inte fungerar utför du en återställning från säkerhetskopian.

SELinux-problem

Felaktiga SELinux-behörigheter kan hindra systemet från att komma åt viktiga filer. Följ dessa anvisningar för att lösa problemet:

Om du vill kontrollera om systemet har problem på grund av felaktiga SELinux-behörigheter startar du systemet med SELinux inaktiverat genom att lägga till alternativet selinux=0 kernel på GRUB linux16-raden.
Om systemet kan startas kör du följande kommando för att utlösa en SELinux-relabel vid starttiden och starta om systemet:
```
touch /.autorelabel
```
Om den virtuella datorn fortfarande inte kan starta gör du en fullständig återställning av den virtuella datorn från säkerhetskopian. Mer information finns i Så här återställer du data för virtuella Azure-datorer i Azure Portal.

Andra kernelrelaterade startproblem

Den här artikeln beskriver de vanligaste problem med Linux-kernel som identifierats i Azure. Mer information om vanliga kernel-panikscenarier finns i Kernel-panik i virtuella Azure Linux-datorer – Vanliga kernel-panikhändelser.

Det finns några andra viktiga möjliga kernel-panik som kanske inte orsakar några start- eller SSH-scenarier (Secure Shell).

Kontrollera att du kör alla kommandon från en virtuell reparationsdator i en chroot-miljö enligt anvisningarna i Felsökning offline. Om systemet redan har startats över en tidigare kernelversion kan dessa kommandon också köras från den ursprungliga virtuella datorn med hjälp av rotbehörigheter eller sudo, enligt anvisningarna i Online-felsökning.

Nyligen genomförd kerneluppgradering

Om kerneln får panik startar efter en nyligen genomförd kerneluppgradering startar du den virtuella datorn över den tidigare kernelversionen. Mer information finns i Startsystem på äldre kernelversion.

Du kan också kontrollera om det redan finns en nyare kernelversion som släppts av Linux-distributionsleverantören och installera den. Mer information om hur du installerar den senaste kernelversionen finns i Processen för kerneluppdatering.

Nyligen nedgradering av kernel

Om kerneln får panik startar efter en nyligen nedgradering av kerneln går du tillbaka till den senaste installerade kerneln. Du kan också kontrollera om det redan finns en nyare kernelversion som släppts av Linux-distributionsleverantören och installera den. Mer information om hur du installerar den senaste kernelversionen finns i Processen för kerneluppdatering.

Om du vill starta systemet över den senaste kernelversionen följer du anvisningarna i Ändra standardversionen av kerneln manuellt, men väljer den första kerneln som visas på GRUB-menyn. I en manuell ändring kan du ange GRUB_DEFAULT värdet till 0 och återskapa motsvarande GRUB-konfigurationsfil.

Ändringar i kernelmodulen

Du kan uppleva en kernel-panik som är relaterad till en ny kernelmodul eller en kernelmodul som saknas. Om du vill få information om den specifika kernelmodulen som orsakar problem (om någon) kontrollerar du motsvarande kernel-panikspårning.

Kör något av följande kommandon för att verifiera inlästa kernelmoduler och inaktiverade moduler i /etc/modprobe.d/*.conf-filer :

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
```
Viktigt!

Ersätt 3.10.0-1160.59.1.el7.x86_64 med motsvarande kernelversion.

SLES 12/15

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

Viktigt!

Ersätt 5.3.18-150300.38.53-azure med motsvarande kernelversion.

Ubuntu 18.04

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

Viktigt!

Ersätt 5.4.0-1077-azure med motsvarande kernelversion.

Om du vill ta bort en specifik kernelmodul kör du följande kommando och återskapar initramferna om det behövs.

rmmod <kernel_module_name>

Om en systemtjänst använder den specifika kernelmodulen inaktiverar du den genom att systemctl disable <serviceName> köra kommandot eller systemctl stop <serviceName> .

Senaste konfigurationsändringar för operativsystem

Identifiera eventuella nyligen gjorda ändringar i kernelkonfigurationen som kan orsaka problem. Lös problemen genom att justera inställningarna eller återställa konfigurationsändringarna.

Kör följande kommando för att hitta beständiga kernelparametrar som konfigurerats i någon av följande filer:

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

Kör följande kommando för att analysera de aktuella kernelparametrarna och deras aktuella värden:

sysctl -a

Kommentar

Kör det här kommandot på ett system som körs och inte från en chroot-miljö.

Möjliga filer som saknas

Mer information om den här typen av problem finns i Saknade viktiga filer och kataloger.

Fel behörigheter för filer

Mer information om den här typen av problem finns i Fel filbehörigheter.

Partitioner saknas

Mer information om den här typen av problem finns i Saknade partitioner.

Kernelbuggar

Identifiera det här problemet från Azure-seriekonsolen. Den här typen av problem ser ut som följande utdata:

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

Den här typen av kernel-panik är associerad med kernelbuggar eller kernelbuggar från tredje part.

Om du vill åtgärda kernelbuggar söker du i kunskapsbasen för leverantören med hjälp av kernel-BUG-strängen och letar efter kända problem i motsvarande kernelversion som systemet kör. Här är några viktiga leverantörsresurser:

Red Hat Kernel Oops Analyzer

Det här verktyget är utformat för att hjälpa dig att diagnostisera en kernelkrasch. När du matar in en text, vmcore-dmesg.txt eller en fil som innehåller ett eller flera kernel-oops-meddelanden, vägleder den dig genom att diagnostisera kernelkraschproblemet.
Kunskapsbas för Red Hat

Om du vill få åtkomst till Red Hat-resurserna länkar du dina Microsoft Azure- och Red Hat-konton. Mer information finns i Hur Microsoft Azure-kunder kan komma åt Red Hat-kundportalen.
Kunskapsbas för SUSE
Kunskapsbas för Ubuntu

Vi rekommenderar att du håller alla dina system uppdaterade för att utesluta eventuella buggar som redan har åtgärdats i de senaste kernelversionerna. Mer information finns i Processen för kerneluppdatering.

Om ytterligare analys krävs från leverantören, konfigurerar och aktiverar du kdump för att generera en kärndump:

Process för kerneluppdatering

Om du vill installera den senaste tillgängliga kernelversionen kör du något av följande kommandon:

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
```

Om du vill installera om en specifik kernelversion kör du något av följande kommandon. Kontrollera att du inte startas över samma kernelversion som du försöker installera om. Mer information finns i Startsystem på äldre kernelversion.

RHEL/CentOS/Oracle Linux
```
yum reinstall kernel-3.10.0-1160.59.1.el7.x86_64
```
Viktigt!

Ersätt 3.10.0-1160.59.1.el7.x86_64 med motsvarande kernelversion.
SLES 12/15
```
zypper refresh
zypper install -f kernel-azure-5.3.18-150300.38.75.1.x86_64
```
Viktigt!

Ersätt kernel-azure-5.3.18-150300.38.75.1.x86_64 med motsvarande kernelversion.
- Ubuntu 18.04/20.04
```
apt update
apt install --reinstall linux-azure=5.4.0.1091.68
```
  Viktigt!
  
  Ersätt 5.4.0.1091.68 med motsvarande kernelversion.

Om du vill uppdatera systemet och tillämpa de senaste tillgängliga ändringarna kör du något av följande kommandon:

RHEL/CentOS/Oracle Linux
```
yum update
```
SLES 12/15
```
zypper refresh
zypper update
```
Ubuntu 18.04/20.04
```
apt update
apt upgrade
```

Kernel-panik kan vara relaterat till något av följande objekt. Mer information finns i Kernel panics at run time (Kernel panics at run time).

Programarbetsbelastningen ändras.
Programutveckling eller programbuggar.
Prestandarelaterade problem och så vidare.

Nästa steg

Om det specifika startfelet inte är ett kernelrelaterat startproblem kan du läsa Felsöka startfel för virtuella Azure Linux-datorer för ytterligare felsökningsalternativ.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.

Dela via

Den virtuella Azure Linux-datorn kan inte startas efter att kerneländringar har tillämpats

Förutsättningar

Så här identifierar du kernelrelaterade startproblem

Felsökning online

Felsökning offline

Startsystem på äldre kernelversion

Använda Seriekonsolen i Azure

Använda reparations-VM (ALAR-skript)

Ändra standardversionen av kerneln manuellt

Kernel panic – synkroniseras inte: VFS: Det går inte att montera root fs på unknown-block(0,0)

Återskapa saknade initramfs med hjälp av Azure Repair VM ALAR-skript

Återskapa saknade initramfs manuellt

Kernel panic – inte synkronisering: Försökte döda init

Viktiga filer och kataloger saknas

Viktiga systemkärnbibliotek och paket saknas

Fel filbehörigheter

Partitioner saknas

SELinux-problem

Andra kernelrelaterade startproblem

Nyligen genomförd kerneluppgradering

Nyligen nedgradering av kernel

Ändringar i kernelmodulen

Senaste konfigurationsändringar för operativsystem

Möjliga filer som saknas

Fel behörigheter för filer

Partitioner saknas

Kernelbuggar

Process för kerneluppdatering

Nästa steg

Kontakta oss för att få hjälp

Feedback

Ytterligare resurser