Dela via

Kernel-panik på virtuella Azure Linux-datorer

  • Artikel

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

Den här artikeln beskriver flera villkor som kan leda till en kernel-panik och ger felsökningsvägledning.

I allmänhet är en kernel-panik en situation när kerneln inte kan läsas in korrekt och därför systemet inte kan starta. En annan form av kernel-panik uppstår när kerneln stöter på en situation som den inte vet hur man hanterar och skyddar sig själv genom att stoppa.

Förutsättningar

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

Hur identifierar jag en kernel-panik?

Använd Azure Portal för att visa utdata från seriekonsolloggen för den virtuella datorn på startdiagnostikbladet, seriekonsolbladet eller AZ CLI för att identifiera den specifika kernel-paniksträngen.

En kernel-panik ser ut ungefär som utdata nedan 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

Några av de vanligaste kernel-panikhändelserna:

Panikmeddelande Anledning
Hoppsan: 0000 [#1] SMP " (kontrollera loggen för mer information) Systemet fick panik på grund av att en felaktig adress avrefererades.
SysRq: Utlösa en kraschdumpa Core dump initierades av användaren med sysrq-c eller genom att upprepa c till /proc/sysrq-trigger.
kernel BUG på <pathname/filename>:<line number>! Det här formatet är standard för en misslyckad BUGG-kontroll (som är precis som en ASSERT, men logiken är inverterad). Filnamnet och radnumret anger vilken BUGG-kontroll som misslyckades.
Kernel panic – inte synkronisering: softlockup: låsta uppgifter Den mjuka låsdetektorn har hittat en PROCESSOR som inte har schemalagt övervakningsaktiviteten inom tröskelvärdet för mjuk låsning.
Kernel panic – inte synkronisering: Watchdog identifierade hård LOCKUP på cpu 0 Detektorn för hård låsning har hittat en processor som inte har fått några hrtimer-avbrott inom tröskelvärdet för hård låsning.
Kernel-panik – synkroniseras inte: hung_task: blockerade uppgifter Den låsta aktivitetsvakten har identifierat minst en aktivitet som har varit i ett avbrottsfritt tillstånd för mer än det blockerade timeout-värdet för aktiviteten.
Kernel panic – inte synkronisering: slut på minne. panic_on_oom är markerat Systemet har slut på minne och byte och har tvingats att börja döda processer för att frigöra minne (inte standardbeteende).
Kernel panic – inte synkronisering: Slut på minne och inga dödande processer... Systemet har slut på minne och byte och har dödat processer för att frigöra minne men har slut på processer för att döda.
Kernel panic – inte synkronisering: Ett NMI har inträffat. Mer information finns i den integrerade hanteringsloggen. Watchdog har fångat upp ett NMI (icke-maskerbart avbrott).
Kernel-panik – synkroniseras inte: NMI IOCK-fel: Fortsätter inte Systemet fick en I/O-kontroll av NMI från maskinvaran (inte ett minnesparitetsfel) och kernel.panic_on_io_nmi angavs (inte standard).
Kernel-panik – synkroniseras inte: NMI: Fortsätter inte Systemet tog emot ett NMI (antingen maskinvaru- eller minnesparitetsfel) och kernel.panic_on_unrecovered_nmi angavs (inte standardvärdet).
Kernel panic – synkroniserar inte: nmi watchdog Systemet tog emot ett NMI och antingen kernel.panic_on_timeout eller kernel.panic_on_oops angetts (inte standardvärdena).
Kernel-panik – synkroniseras inte: Kontroll av allvarlig dator En datorkontrollsfelhändelse har skapats för ett allvarligt tillstånd.
Kernel panic – inte synkronisering: Försökte döda init! Init-processen är den första processen som startas och bör aldrig avslutas.
Kernel panic – synkroniseras inte: VFS: Det går inte att montera root fs på unknown-block(0,0) Det förutsätts att kerneln använder en initramfs för att montera rotfarna. Det här felet uppstår när kerneln inte har några initramfs.

Scenario 1: Kernel-panik inträffar vid starttiden

En kernel-panik vid start hindrar den virtuella datorn från att slutföra operativsystemets startprocess. Det händer varje gång den virtuella datorn startas och tillåter inte inloggning.

Den här typen av händelse är ofta relaterad men inte begränsad till:

Lösning för scenario 1

För att hantera den här typen av kernelpanik kan följande metoder användas:

Metod 1: Använda Azure-seriekonsolen

Använd Azure-seriekonsolen för att avbryta startprocessen och välja en tidigare kernelversion, om den är tillgänglig. På så sätt kan den virtuella datorn startas upp igen och sedan kan du använda någon av följande metoder för att åtgärda det specifika problemet med kerneln som inte startar:

Metod 2: Offlinereparation med hjälp av en virtuell räddningsdator

Om Azure-seriekonsolen inte är tillgänglig eller om ingen tidigare kernel är tillgänglig behöver du en virtuell dator för återställning/reparation för att utföra en offlinereparation.

Använd kommandot Reparera virtuell dator för att skapa en reparations-VM som har en kopia av den virtuella måldatorns OS-disk ansluten. Använd sedan chroot montera kopian av OS-filsystemen på den virtuella reparationsdatorn. Därefter kan du prova följande metoder för att åtgärda kernelproblemen:

Scenario 2: Kernel-panik vid körning

Den här typen av kernel-panik utlöses ofta vid oförutsägbara tidpunkter när operativsystemets startprocess har slutförts och gör att den virtuella datorn slutar svara, vilket hindrar den från att logga in. Det är ofta relaterat men inte begränsat till:

Lösning för scenario 2

För att hantera den här typen av kernelpanik kan följande metoder användas:

  • Granska resursanvändning och övergripande systemprestanda. Kernel-paniken kan bero på en eventuell brist på resurser som kan leda till att en virtuell dator ändrar storlek.
  • Installera om möjligt de senaste uppdateringarna som är tillgängliga i motsvarande Linux-distributionsdatabaser. Kernel-paniken kan vara relaterad till kända buggar i antingen kerneln eller annan programvara.
  • Det finns en möjlighet att kernel-paniken är relaterad till en nyligen genomförd kerneländring, i vilket fall det också är lämpligt att starta över en tidigare kernelversion, enligt beskrivningen i Lösning för scenario 1.
  • Om alternativen ovan inte är tillämpliga kan det vara nödvändigt att konfigurera kdump och generera en kärndump att dela med stöd för ytterligare analys.

Mer specifika kernel-panikscenarier

Vanliga kernel-panikscenarier med specifika anvisningar för felsökning/återställning:

Dokument Scenario
Det uppstår ”kernel panic” på en virtuell Linux-dator i Azure på kernelversion 3.10 efter en uppgradering av värdnoden I den här artikeln beskrivs ett problem som uppstår när en virtuell Azure Linux-dator som kör den 3,10-baserade kerneln kraschar efter en uppgradering av värdnoden i Azure.
Återställa en virtuell Linux-dator i Azure från kernelrelaterade startproblem Den här artikeln innehåller lösningar på ett problem där en virtuell Linux-dator (VM) inte kan startas om efter att kerneländringar har tillämpats.

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.