Oplossing voor kernel panic VFS unable to mount root fs on unknown-block(0,0)

Wanneer het gevreesde bericht op het scherm verschijnt “Kernel panic – not syncing: VFS: unable to mount root fs on unknown-block(0,0)” Het is normaal om nerveus te worden. Plotseling start je Linux-systeem niet meer op, de console loopt vast met een enorme hoeveelheid tekst en het lijkt alsof je alles kwijt bent. Het goede nieuws is dat je in de meeste gevallen geen gegevens bent kwijtgeraakt en dat de situatie kan worden opgelost door rustig een paar stappen te volgen.

Dit probleem kan zich in verschillende scenario's voordoen: Bij het installeren van een nieuwe distributie (zoals Linux Mint), bij het bijwerken van Ubuntu, bij het opstarten van een CentOS-server of bij het starten van een virtuele machine met Ubuntu of een andere distributie.Hoewel de context kan verschillen, is de kernel-fout vergelijkbaar en draaien de oorzaken meestal om hetzelfde probleem: de kernel kan het root-bestandssysteem niet aankoppelen. In dit artikel zullen we in detail en in zo duidelijk mogelijke taal uitleggen wat deze fout betekent en hoe je deze in elk praktijkscenario kunt oplossen.

Wat betekent de foutmelding “kernel panic – VFS: unable to mount root fs on unknown-block(0,0)”?

Wanneer de kernel opstart, is een van zijn eerste taken: Zoek en koppel de partitie die het rootbestandssysteem “/” zal bevatten.Om dit te doen, moet je weten op welk apparaat het zich bevindt (bijvoorbeeld /dev/sda2), welk type bestandssysteem het gebruikt (ext4, xfs, enz.) en beschikken over de benodigde modules om toegang te krijgen tot dat apparaat (schijfcontrollers, controllerstuurprogramma's, enz.).

Het bericht “VFS: kan root-bestandssysteem niet mounten op onbekend blok (0,0)” Dit geeft aan dat het virtuele bestandssysteem (VFS) van de kernel de rootdirectory niet kon mounten. De foutmelding "unknown-block(0,0)" laat zien dat het zelfs het blokapparaat waarvan het zou moeten opstarten niet correct kon identificeren. Met andere woorden, voor de kernel is de schijf met uw "/" op dat moment praktisch onzichtbaar of ontoegankelijk.

Deze storing kan verschillende oorzaken hebben: Ontbrekende of beschadigde initramfs-image, wijzigingen in UUID of schijftoewijzing, stuurprogramma's die niet laden, bootloader (GRUB) fouten of zelfs problemen met de configuratie van partities en partitietabellen.

Een belangrijk punt dat veel mensen doorgaans geruststelt, is dat Een kernelpanic betekent op zich niet dat er gegevens verloren gaan.De opstartfase is mislukt, maar de partities blijven in de overgrote meerderheid van de gevallen intact en wachten erop dat we een herstelomgeving of een functionerende kernel opstarten om er toegang toe te krijgen.

Veel foutmeldingen tonen ook aanvullende berichten, zoals: “SGX uitgeschakeld” of waarschuwingen van andere modules, die misleidend kunnen zijn. Deze regels zijn meestal niet de hoofdoorzaak van het probleem, maar slechts informatieve berichten over processor- of systeemkenmerken. De sleutel zit altijd in de zin die betrekking heeft op VFS en de root mount.

Typische voorbeelden: installatie van Linux Mint, upgrade van Ubuntu, CentOS en virtuele machines

Deze kernel panic-fout treedt meestal op in zeer specifieke situaties. Door deze scenario's te kennen, kun je beter begrijpen wat er mis is gegaan en welke stappen je moet ondernemen. Een van de meest voorkomende gevallen is... Een nieuw geïnstalleerd systeem, zoals Linux Mint 21.2 Cinnamon, voor de eerste keer opstarten nadat de partities handmatig zijn aangemaakt..

Een praktijkvoorbeeld: een gebruiker op een Windows-laptop besluit Linux Mint te installeren met behulp van BalenaEtcher om de ISO naar een USB-stick van 16 GB te branden.Controleer in Windows of de computer UEFI-firmware gebruikt, ga naar de BIOS, selecteer de opstartbare USB-schijf en start de Mint Live-sessie. Tot zover lijkt alles normaal. Het probleem ontstaat wanneer tijdens de installatie een handmatige partitie wordt aangemaakt met Er wordt een nieuwe partitietabel aangemaakt op /dev/sda (1 TB), een EFI-partitie van 512 MB op /dev/sda1, 2 GB swap, een root-partitie (/) van ongeveer 10 GB in ext4, en /home gebruikt de rest van de schijf..

In dat specifieke scenario wordt het ook geselecteerd /dev/sda1 (de EFI-partitie) als het apparaat voor het installeren van de bootloader.De installatie is voltooid, opties zoals de installatie van de codec worden geselecteerd en de gebruiker wordt aangemaakt. Vervolgens wordt, in plaats van opnieuw op te starten, besloten om een ​​programma in de live-sessie uit te voeren. “apt update” en “apt upgrade” Het systeem is al bijgewerkt en wordt vervolgens afgesloten. Bij het opnieuw opstarten verschijnt, in plaats van correct op te starten, de beruchte kernel panic, waardoor de gebruiker vast komt te zitten tussen het BIOS en de opstartopties van Mint.

Een ander typisch scenario doet zich voor. na het upgraden van Ubuntu naar een hogere versieIn theorie zou het een transparant proces moeten zijn: de nieuwe kernel wordt gedownload, de benodigde bestanden worden gegenereerd en GRUB wordt bijgewerkt. Soms gaat de generatiestap van de kernel echter mis. De initramfs van de nieuw geïnstalleerde kernel faalt of wordt niet correct uitgevoerd.Het systeem lijkt zonder problemen te updaten, maar na het herstarten verschijnt de foutmelding "Kernel Panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" en is er geen manier om op te starten met de nieuwe kernel.

Ook in serveromgevingen komen dergelijke gevallen vaak voor, bijvoorbeeld in CentOS 6.x na het toepassen van updatesOp sommige servers kan de nieuwe kernel na een `yum update` of een vergelijkbaar commando beschadigd raken of onjuist worden geïnstalleerd. Bij het opstarten treedt er dan een kernel panic op en crasht het systeem. In dergelijke omgevingen is het vanzelfsprekend van belang om de service zo snel mogelijk te herstellen, daarom zijn er specifieke procedures voorhanden. herstelmodus en herinstallatie van het kernelpakket.

Ten slotte mogen we de virtuele machines (VM) met Ubuntu of andere distributiesSoms, bij het opstarten van de virtuele machine, geeft het systeem de melding "end kernel panic: not syncing: VFS: unable to mount root fs on unknown-block(0,0)" weer en loopt het volledig vast. In deze gevallen is het meestal mogelijk om op te starten met een oudere kernel door "Geavanceerde opties voor Ubuntu" te openen in het GRUB-menu van de virtuele machine, terwijl de nieuwere kernel altijd dezelfde foutmelding geeft.

Belangrijkste technische oorzaken van het mislukken van het mounten van het rootbestandssysteem

Aan de basis van al deze gevallen liggen een aantal terugkerende technische redenen. Een van de meest voorkomende oorzaken, vooral na Ubuntu-updates of nieuwe kernels, is De afwezigheid of beschadiging van het initramfs dat overeenkomt met de geladen kernelversie.De initramfs is een image die een minimaal bestandssysteem bevat met de modules en tools die nodig zijn om de daadwerkelijke root te mounten.

Als het initramfs ontbreekt, beschadigd is of niet de juiste modules bevat om toegang te krijgen tot de schijf waarop de rootpartitie zich bevindt, De kernel zal "/" nooit mounten.Daarom wordt in veel handleidingen over deze fout de nadruk gelegd op het "opnieuw genereren van de initramfs" en ervoor zorgen dat GRUB die image correct oppikt voor de betreffende opstartvermelding.

Een andere veelvoorkomende oorzaak heeft te maken met GRUB-bootloaderproblemenOnjuist geconfigureerde paden, gewijzigde UUID's, vermeldingen die verwijzen naar een onjuiste schijf of partitie, of installaties waarbij de EFI-partitie onjuist is aangekoppeld. In het voorbeeld van Linux Mint met handmatige partitionering is een veelvoorkomende fout: GRUB installeren op de verkeerde EFI-partitie, of de UEFI/Legacy-instellingen niet respecteren.Dit zorgt ervoor dat de firmware of GRUB niet de juiste kernel opstart, of dit doet zonder de juiste parameters.

Op CentOS-servers en vergelijkbare omgevingen kunnen, naast initramfs, ook andere factoren een rol spelen. beschadigde kernelpakketten of inconsistenties in de RPM-databaseAls de pakketdatabase beschadigd is, kan de pakketbeheerder de kernel onvolledig achterlaten of essentiële bestanden missen, wat bij de volgende herstart tot een kernelpanic kan leiden.

Bij virtuele machines doen zich, naast de reeds genoemde problemen, ook configuratieproblemen voor. virtuele schijven, controllers (IDE, SATA, SCSI, VirtIO) en wijzigingen in virtuele hardwareAls we het type schijfcontroller van de VM wijzigen en de kernel niet de juiste module in zijn initramfs heeft, kan precies hetzelfde gebeuren tijdens het opstarten: Hij ziet de schijf niet. en het eindigt met een onbekend blok (0,0).

In alle gevallen is er één constante: De kernel slaagt er niet in een geldig blokapparaat met een bruikbaar rootbestandssysteem te detecteren.De sleutel tot het herstel ligt in het herstellen van de verbinding tussen de kernel en de root-partitie: het repareren van initramfs, het opnieuw installeren van de kernel, het corrigeren van de GRUB-configuratie of het aanpassen van de zichtbare partities en apparaten.

Oplossing in Ubuntu: genereer de initramfs opnieuw en update GRUB.

Wanneer het probleem zich voordoet na Upgrade Ubuntu naar een nieuwere versie of installeer een modernere kernel.Een van de meest effectieve oplossingen is het opnieuw genereren van de initramfs-image van de betreffende kernel en het bijwerken van de bootloader. Dit proces is gebaseerd op het feit dat er meestal een eerdere, werkende kernel aanwezig is waarmee het systeem kan opstarten.

Het eerste dat u moet doen, is toegang tot het GRUB-menuOm dit te doen, start u uw computer opnieuw op en drukt u direct na het opstarten van de BIOS/UEFI herhaaldelijk op de Shift-toets (op veel BIOS-systemen) of de Esc-toets (op sommige UEFI-systemen) totdat het GRUB-scherm verschijnt. Daar ziet u een hoofdoptie zoals "Ubuntu" en een andere genaamd "Geavanceerde opties voor Ubuntu".

Binnen "Geavanceerde opties voor Ubuntu" vindt u een lijst met alle geïnstalleerde kernelversiesHet idee is om een ​​oudere versie te selecteren waarvan bekend is dat deze vóór de update wel werkte. Meestal is de nieuwste versie degene die een kernel panic veroorzaakt, dus het is het beste om de versie te kiezen die er direct aan voorafgaat (bijvoorbeeld, als 5.15.x niet werkt, probeer dan 5.13.x). Selecteer die versie en druk op Enter om ermee op te starten.

Zodra het systeem succesvol is opgestart met de oude kernel, moet u een terminal openen. Ga vervolgens verder met... Genereer de initramfs van de kernel die vastliep opnieuw.Een typisch commando in Ubuntu zou er ongeveer zo uitzien:

sudo update-initramfs -c -k

Vervangen voor de exacte tekenreeks van de problematische versie, bijvoorbeeld 4.15.0-36-generic of degene die in het foutbericht of in de uitvoer van verschijnt uname -r Indien nodig, kan dit commando de initramfs-image voor die specifieke kernelversie aanmaken (of opnieuw aanmaken), inclusief de modules en hulpprogramma's die nodig zijn om de root te mounten.

Na het regenereren van de initramfs is het essentieel GRUB bijwerken Om ervoor te zorgen dat de nieuwe image correct wordt gedetecteerd en de opstartparameters worden aangepast. Voer hiervoor het volgende commando uit:

sudo update-grub

Deze opdracht scant het systeem, vindt de verschillende kernelversies, herbouwt het GRUB-menu en koppelt elke kernel correct aan de bijbehorende initramfs. Zodra het proces is voltooid, start u uw computer normaal opnieuw op, zonder iets in GRUB te wijzigen, om te controleren of het systeem nu opstart met de nieuwe kernel zonder een kernel panic.

CentOS-serverherstel in de herstelmodus

In de wereld van servers, vooral met CentOS 6.x (en vergelijkbare versies van RHEL)Een kernelpanic na een update kan behoorlijk schrikken, maar er is een vrij eenvoudige oplossing met behulp van de herstelmodus. Het idee is om op te starten vanaf een extern medium, het geïnstalleerde systeem te mounten, er een chroot-omgeving van te maken en indien nodig de kernel en pakketdatabase te repareren.

De eerste stap is om De server opstarten vanaf een hersteldiskDit kan een cd/dvd of een ISO-bestand zijn dat is gekoppeld via de beheerconsole van de server (iLO, iDRAC, externe KVM, enz.). Wanneer u vanaf dit medium opstart, kiest u in plaats van een normale installatie de optie "Geïnstalleerd systeem herstellen" of iets dergelijks. Als deze optie niet direct verschijnt, kunt u de herstelmodus openen door het volgende in te typen bij de opstartprompt:

opstarten: linux rescue

Vervolgens zal de assistent u vragen om te kiezen. taal en toetsenbordindelingHet biedt ook de mogelijkheid om het netwerk te activeren, bijvoorbeeld via DHCP. Het activeren van het netwerk kan handig zijn als u tijdens het reparatieproces pakketten moet downloaden of toegang moet krijgen tot externe repositories.

Zodra de herstelomgeving het geïnstalleerde systeem heeft gedetecteerd, zal deze de rootpartitie koppelen aan /mnt/sysimageWanneer je in deze omgeving een shell start, is de volgende stap om in te loggen op het systeem alsof we het daadwerkelijk hebben opgestart, met behulp van het volgende commando:

chroot /mnt/sysimage

Vanaf dit punt hebben alle uitgevoerde commando's invloed op het daadwerkelijke serversysteem, niet op de herstelomgeving. Dit is waar reparatie met yum van pas komt. Een veelvoorkomend probleem is dat De RPM-database is beschadigd.Dit voorkomt dat de kernelpakketten correct worden beheerd. Om dit te controleren, kunt u eerst het volgende proberen:

yum clean

Als deze opdracht fouten retourneert met betrekking tot het openen van de databases, moet u deze handmatig verwijderen. Ga hiervoor naar de map waarin ze zijn opgeslagen:

cd /var/lib/rpm

En de tijdelijke databasebestanden worden verwijderd:

rm -f __db.00*

Na deze verwijdering wordt een nieuwe poging gedaan om yum op te schonen, dit keer grondiger:

yum maak alles schoon

Als het nu werkt, betekent dit dat de RPM-database succesvol opnieuw is opgebouwd. De volgende belangrijke stap is installeer het kernelpakket opnieuwDit is meestal de oorzaak van een kernel panic wanneer bestanden beschadigd of ontbreken. Om dit te doen, voer je het volgende commando uit:

yum herinstalleer kernel

Met dit commando worden alle huidige kernelbestanden gedownload en geïnstalleerd, inclusief het kernelbinair bestand zelf, de initramfs en alle bijbehorende afhankelijkheden. Zodra de herinstallatie is voltooid, verlaat u de chroot-omgeving, stopt u de herstelomgeving en herstart u de server normaal. Als alles goed is gegaan, De server moet zonder kernelpaniek en zonder gegevensverlies opstarten..

Opstartproblemen in virtuele machines met Ubuntu

In het geval van virtuele machines is het bericht van “einde kernel panic: niet sync: VFS: kan root fs niet mounten op onbekend-blok(0,0)” Deze fout treedt meestal op bij het opstarten van de virtuele machine, waardoor het systeem volledig vastloopt. Deze situatie kan erg frustrerend zijn, omdat de enige manier om toegang tot het systeem te krijgen is via een oudere kernelversie, die geselecteerd moet worden in het menu "Geavanceerde opties voor Ubuntu" in GRUB.

Als de virtuele machine het opstarten met een oudere kernel toestaat, is de strategie vrijwel gelijk aan die beschreven voor Ubuntu op een fysieke installatie: Start op met de werkende kernel, genereer de initramfs van de problematische kernel opnieuw en update GRUB.Dit is meestal voldoende om de nieuwe kernel weer in staat te stellen de rootdirectory te mounten en het systeem weer normaal op te starten.

Als het om een ​​virtuele machine gaat, moet je ook het volgende controleren: Hypervisorconfiguratie (VirtualBox, VMware, KVM, Hyper-V, enz.)Wijzigingen in het type schijfcontroller (bijvoorbeeld overschakelen van SATA naar VirtIO) of schijftoewijzing kunnen ertoe leiden dat de kernel het juiste apparaat niet kan vinden als het initramfs niet de benodigde modules voor die specifieke schijfcontroller bevat.

Op sommige forums wordt vermeld dat het probleem zich voordoet "zelfs als virtualisatie al is ingeschakeld" in de BIOS van de host, wat verwarrend kan zijn. De waarheid is dat, op een paar uitzonderingen na, De opties voor processorvirtualisatie (VT-x, AMD-V) houden geen direct verband met de VFS-fout in de kernel.Het inschakelen ervan garandeert alleen dat de VM betere prestaties levert, maar kernelpanieken houden meestal meer verband met de interne configuratie van de VM (schijven, controllers) of met de kernel/initramfs binnen de gastdistributie.

Als het probleem aanhoudt na het opnieuw genereren van initramfs en het bijwerken van GRUB, kunt u het volgende proberen: Start de virtuele machine op vanaf een ISO-bestand in de live-modus.Koppel de virtuele schijf van de betreffende machine en controleer handmatig de GRUB-configuratiebestanden, de inhoud van /boot en de aanwezigheid van de initramfs-bestanden die overeenkomen met elke geïnstalleerde kernelversie.

Fouten bij het installeren van Linux Mint met handmatige partitionering en UEFI.

Terugkerend naar het geval van het installeren van Linux Mint 21.2 Cinnamon met BIOS in UEFI-modus en handmatige partitioneringVeel gebruikers maken kleine configuratiefouten die leiden tot een kernel panic bij het mounten van de root-directory. Het gebruikelijke proces omvat het aanmaken van een nieuwe partitietabel op /dev/sda (waarbij alle eerdere inhoud wordt verwijderd), het definiëren van een EFI-partitie, swap, root en /home, en vervolgens het selecteren van de EFI-partitie als locatie voor de bootloader-installatie.

Hoewel dit in principe correct klinkt, zijn er verschillende gevoelige punten. Bijvoorbeeld de De EFI-partitie moet van het type "EFI System Partition" (ESP) zijn, geformatteerd als FAT32 en gekoppeld aan /boot/efiAls de partitie tijdens de installatie simpelweg als een gewone partitie wordt aangemaakt, zonder deze correct als EFI te markeren, kan GRUB mogelijk niet correct installeren en kan de UEFI-firmware deze mogelijk niet herkennen als een geldige opstartpartitie.

Een ander cruciaal detail is ervoor te zorgen dat Het apparaat dat voor de bootloader is geselecteerd, is ofwel de volledige schijf (bijv. /dev/sda) of de juiste EFI-partitie.Afhankelijk van de specifieke distributie en het installatieprogramma kan het handmatig selecteren van /dev/sda1 als bestemming, terwijl de distributie verwacht dat GRUB op /dev/sda wordt geïnstalleerd, ertoe leiden dat het systeem de juiste opstartstructuur niet kan genereren, met een mislukt opstartproces na een herstart tot gevolg.

het feit Voer vóór de eerste herstart een "apt update" en een "apt upgrade" uit vanuit de live-sessie. Dit is ook niet de beste aanpak, omdat je de live-omgeving bijwerkt en niet per se het systeem dat al op de schijf is geïnstalleerd. Dit kan verwarring veroorzaken en onder bepaalde omstandigheden zelfs gevolgen hebben voor pakketten die van invloed kunnen zijn op het installatieprogramma of de opstartbestanden.

Als de computer na de installatie vastloopt in een opstartlus tussen de BIOS- en Mint-opstartopties, en elke keer dat je probeert op te starten een kernel panic optreedt, is een mogelijke oplossing: Start een live-sessie opnieuw vanaf de USB-schijf, koppel het reeds geïnstalleerde systeem en controleer de EFI-partitie, de inhoud van /boot/efi, de fstab-configuratie en de GRUB-vermeldingen.In sommige gevallen is het sneller en schoner om de installatie te herhalen, zodat de GPT-partitietabel en de EFI-partitie vanaf het begin correct geconfigureerd zijn.

Je kunt ook de BIOS/UEFI controleren op opties die van invloed kunnen zijn op het opstarten, zoals: MOK en Secure BootUEFI versus Legacy/CSM-modus of opstartvolgordeHoewel het kernelbericht "SGX uitgeschakeld" vermeldt, is die regel meestal niet relevant voor het specifieke VFS-probleem; wat belangrijk is, is dat de firmware de juiste GRUB vindt en start, en dat deze verwijst naar de juiste kernel en initramfs.

Wanneer moet je een extern apparaat of een live systeem gebruiken om gegevens te herstellen?

In al deze scenario's is een veelvoorkomende zorg: indien een extern apparaat nodig is om toegang te krijgen tot de schijf en bestanden te herstellenHet antwoord hangt af van de urgentie en of het systeem nog een werkende kernel heeft om mee op te starten, hetzij via "Geavanceerde opties" of via een oude GRUB-vermelding.

Als de computer nog kan opstarten met een oudere kernelversie (zoals in het geval van een virtuele machine met Ubuntu of sommige desktopinstallaties), is de handigste optie: Maak gebruik van die werkende kernel om volledige back-ups te maken. Voordat je iets serieuzers gaat doen, kun je een externe USB-schijf aansluiten en /home of een andere belangrijke map kopiëren, of zelfs kloonprogramma's gebruiken als je een complete systeemimage wilt opslaan.

Als er geen opstartkernel is en het systeem steeds in een kernelpaniek terechtkomt, dan is het de moeite waard. Opstarten vanaf een extern medium: USB-stick met een live-distributie, rescue ISO, cd/dvd, enz.Vanuit deze live-omgeving kunt u de interne harde schijf koppelen, toegang krijgen tot de partities (meestal ext4 of andere) en de gewenste gegevens extraheren, naar een externe schijf, via het netwerk of op een andere manier naar keuze.

Ditzelfde live medium dient ook om De installatie ter plaatse repareren.Dit houdt in dat je commando's moet uitvoeren zoals chroot, de kernel opnieuw moet installeren, initramfs opnieuw moet genereren of GRUB moet repareren. Sterker nog, veel handleidingen raden deze aanpak aan, vooral wanneer het systeem ernstig beschadigd is of wanneer de geïnstalleerde omgeving met een eerdere kernel niet toegankelijk is.

Het is belangrijk om dat te benadrukken De kernelpaniek zelf vernietigt geen gegevens en verwijdert geen partities.Het is een beveiligingsmechanisme van de kernel dat het systeem afsluit wanneer het ernstige fouten tegenkomt die de integriteit ervan in gevaar brengen. De prioriteit moet liggen bij het voorkomen van geforceerde afsluitingen of ongebruikelijke schijfmanipulaties, en als er belangrijke gegevens zijn, moet eerst de nadruk liggen op het beveiligen van back-ups voordat er reparaties worden uitgevoerd.

Met al deze kennis is dit soort fouten geen "einde van de wereld" meer, maar een technische tegenslag die bijna altijd kan worden opgelost: Het opstarten vanaf een oude kernel of herstelomgeving, het opnieuw genereren van de initramfs, het opnieuw installeren van de kernel of het corrigeren van de GRUB-configuratie en partities.Hierdoor kan het systeem zijn basisstructuur herstellen en normaal opstarten zonder gegevens te verliezen.

Gerelateerd artikel:

"Onbekend bestandssysteem"-fout in GRUB: oorzaken, praktijkvoorbeelden en hoe je deze stap voor stap kunt oplossen.

Isaac

Gepassioneerd schrijver over de wereld van bytes en technologie in het algemeen. Ik deel mijn kennis graag door te schrijven, en dat is wat ik in deze blog ga doen: je de meest interessante dingen laten zien over gadgets, software, hardware, technologische trends en meer. Mijn doel is om u te helpen op een eenvoudige en onderhoudende manier door de digitale wereld te navigeren.