Kernel paniek in Azure Linux-VM's
Van toepassing op: ✔️ Virtuele Linux-machines
In dit artikel worden meerdere voorwaarden besproken die kunnen leiden tot een kernel paniek en richtlijnen voor probleemoplossing bieden.
Over het algemeen is een kernel paniek een situatie wanneer de kernel niet goed kan laden, en daarom kan het systeem niet worden opgestart. Een andere vorm van kernel-paniek treedt op wanneer de kernel een situatie tegenkomt die niet weet hoe ze zichzelf moet afhandelen en beveiligen door te stoppen.
Vereisten
Zorg ervoor dat de seriële console is ingeschakeld en functioneel is in de Virtuele Linux-machine.
Hoe kan ik een kernel-paniek identificeren?
Gebruik Azure Portal om de uitvoer van het seriële consolelogboek van de VIRTUELE machine weer te geven op de blade met diagnostische opstartgegevens, de blade seriële console of AZ CLI om de specifieke kernel-paniekreeks te identificeren.
Een kernel paniek lijkt op de onderstaande 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
Enkele van de meest voorkomende kernel paniek gebeurtenissen:
Paniekbericht | Reden |
---|---|
Oops: 0000 [#1] SMP " (logboek controleren op details) | Systeem raakte in paniek vanwege het uitstellen van een ongeldig adres. |
SysRq: een crashdump activeren | Coredump is door de gebruiker geïnitieerd met sysrq-c of door c te echoën in /proc/sysrq-trigger. |
kernel BUG bij <padnaam/bestandsnaam>:<regelnummer>! | Deze indeling is de standaard voor een mislukte BUG-controle (dit is net als een ASSERT, maar de logica wordt omgekeerd). De bestandsnaam en het regelnummer geven aan welke BUG-controle is mislukt. |
Kernel paniek - niet synchroniseren: softlockup: vastgelopen taken | De zachte vergrendelingsdetector heeft een CPU gevonden die de watchdog-taak niet heeft gepland binnen de drempelwaarde voor zachte vergrendeling. |
Kernel paniek - niet synchroniseren: Watchdog gedetecteerd harde LOCKUP op cpu 0 | De harde vergrendelingsdetector heeft een CPU gevonden die geen hrtimer-interrupts heeft ontvangen binnen de drempelwaarde voor harde vergrendeling. |
Kernel paniek - niet synchroniseren: hung_task: geblokkeerde taken | De vastgelopen taak-watchdog heeft ten minste één taak gedetecteerd die een niet-onderbreekbare status heeft voor meer dan de time-outwaarde voor geblokkeerde taken. |
Kernel paniek - niet gesynchroniseerd: onvoldoende geheugen. panic_on_oom is geselecteerd | Het systeem heeft onvoldoende geheugen en is gedwongen om processen te doden om geheugen vrij te maken (niet standaardgedrag). |
Kernel paniek - niet synchroniseren: onvoldoende geheugen en geen killable processen... | Het systeem heeft onvoldoende geheugen en wisselt en doodt processen om geheugen vrij te maken, maar heeft geen processen meer om te doden. |
Kernel paniek - niet synchroniseren: er is een NMI opgetreden, zie het geïntegreerde beheerlogboek voor meer informatie. | Watchdog heeft een NMI (niet-maskerbare interrupt) onderschept. |
Kernel paniek - niet synchroniseren: NMI IOCK-fout: Niet doorgaan | Het systeem heeft een IO-controle-NMI ontvangen van de hardware (geen geheugenpariteitsfout) en kernel.panic_on_io_nmi is ingesteld (niet de standaardinstelling). |
Kernel paniek - niet synchroniseren: NMI: Niet doorgaan | Het systeem heeft een NMI (hardware- of geheugenpariteitsfout) ontvangen en kernel.panic_on_unrecovered_nmi is ingesteld (niet de standaardinstelling). |
Kernel paniek - niet synchroniseren: nmi watchdog | Het systeem heeft een NMI ontvangen en kernel.panic_on_timeout of kernel.panic_on_oops is ingesteld (niet de standaardwaarden). |
Kernel paniek - niet synchroniseren: fatale machinecontrole | Er is een uitzonderingsgebeurtenis voor machinecontrole gegenereerd voor een fatale toestand. |
Kernel paniek - niet gesynchroniseerd: poging om init te doden! | Het init-proces is het eerste proces dat moet worden gestart en mag nooit worden afgesloten. |
Scenario 1: Kernel-paniek treedt op tijdens het opstarten
Een kernel-paniek tijdens het opstarten voorkomt dat de VM het opstartproces van het besturingssysteem voltooit. Dit gebeurt telkens wanneer de virtuele machine wordt gestart en het aanmelden niet is toegestaan.
Dit soort gebeurtenissen is vaak gerelateerd, maar niet beperkt tot:
- Een recente kernelupgrade.
- Een recente kernel downgrade.
- Wijzigingen in kernelmodules.
- Wijzigingen in de configuratie van het besturingssysteem (GRUB, sysctl en SELinux).
- Belangrijke bestanden en mappen ontbreken.
- Belangrijke systeemkernbibliotheken en -pakketten ontbreken.
- Verkeerde machtigingen voor bestanden.
- Ontbrekende partities.
Oplossing voor scenario 1
Om met dit soort kernel paniek om te gaan, kunnen de volgende benaderingen worden gebruikt:
Methode 1: De seriële Console van Azure gebruiken
Gebruik de seriële Azure-console om het opstartproces te onderbreken en selecteer een eerdere kernelversie, indien beschikbaar. Op deze manier kan de VIRTUELE machine opnieuw worden opgestart. Vervolgens kunt u een van de volgende methoden gebruiken om het specifieke probleem met de niet-opstartkernel op te lossen:
- Installeer een ontbrekende initramfs opnieuw of genereer deze opnieuw.
- Installeer de problematische kernel opnieuw.
- Controleer de geladen of ontbrekende kernelmodules.
- Controleer de partities.
Methode 2: Offline herstellen met behulp van een herstel-VM
Als de seriële Console van Azure niet beschikbaar is of er geen eerdere kernel beschikbaar is, hebt u een herstel-/herstel-VM nodig om offline te herstellen.
Gebruik de opdracht VM herstellen om een herstel-VM te maken waarop een kopie van de besturingssysteemschijf van de doel-VM is gekoppeld. Gebruik vervolgens chroot om de kopie van de besturingssysteembestandssystemen in de herstel-VM te koppelen. Probeer daarna de volgende methoden om de kernelproblemen op te lossen:
- Installeer een ontbrekende initramfs opnieuw of genereer deze opnieuw.
- Installeer de problematische kernel opnieuw.
- Controleer de geladen of ontbrekende kernelmodules.
- Controleer de partities.
- Ontbrekende bestanden herstellen.
- Herstel ontbrekende belangrijke systeemkernbibliotheken en -pakketten.
Scenario 2: Kernel paniek tijdens runtime
Dit soort kernel paniek wordt meestal geactiveerd op onvoorspelbare tijden nadat het opstartproces van het besturingssysteem is voltooid en zorgt ervoor dat de VIRTUELE machine niet meer reageert, waardoor het niet meer kan worden aangemeld. Het is vaak gerelateerd, maar niet beperkt tot:
- Een recente kernelupgrade.
- Een recente kernel downgrade.
- Wijzigingen in kernelmodules.
- Wijzigingen in de configuratie van het besturingssysteem (GRUB, sysctl en SELinux).
- Wijzigingen in toepassingsworkloads.
- Wijzigingen of fouten in de ontwikkeling van toepassingen.
- Mogelijke kernelfouten.
- Prestatieproblemen.
Oplossing voor scenario 2
Om met dit soort kernel paniek om te gaan, kunnen de volgende benaderingen worden gebruikt:
- Bekijk het resourcegebruik en de algehele systeemprestaties. De paniek van de kernel kan te maken hebben met een mogelijk tekort aan resources die kunnen leiden tot het wijzigen van de grootte van een VIRTUELE machine.
- Installeer indien mogelijk de meest recente updates die beschikbaar zijn in de bijbehorende Linux-distributieopslagplaatsen. De kernel paniek kan te maken hebben met bekende bugs in de kernel of andere software.
- Er is een mogelijkheid dat de kernel paniek te maken heeft met een recente kernelwijziging. In dat geval is het ook raadzaam om op te starten via een eerdere kernelversie, zoals uitgelegd in Oplossing voor scenario 1.
- Als de bovenstaande opties niet van toepassing zijn, kan het nodig zijn om kdump te configureren en een kerndump te genereren om te delen met ondersteuning voor verdere analyse.
Meer specifieke kernel-paniekscenario's
Veelvoorkomende kernel-paniekscenario's met specifieke instructies voor probleemoplossing/herstel:
Document | Scenario |
---|---|
Een Azure Linux-VM op een 3.10-kernel crasht na een upgrade van een hostknooppunt | In dit artikel wordt een probleem besproken dat zich voordoet wanneer een Azure Linux-VM waarop de kernel op basis van 3.10 wordt uitgevoerd, vastloopt na een upgrade van een hostknooppunt in Azure. |
Een virtuele Azure Linux-machine herstellen na opstartproblemen met betrekking tot de kernel | Dit artikel bevat oplossingen voor een probleem waarbij een virtuele Linux-machine (VM) niet opnieuw kan worden opgestart nadat kernelwijzigingen zijn toegepast. |
Contact met ons opnemen voor ondersteuning
Als u vragen hebt of hulp nodig hebt, maakt u een ondersteuningsaanvraag of stelt u ondersteuning voor de Azure-community. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.