Lahendus kerneli paanikale, kus VFS ei suutnud juurfailisüsteemi unknown-block(0,0)-le ühendada

Kui ekraanile ilmub kardetud teade „Kerneli paanika – ei sünkroonita: VFS: root failisüsteemi ei saa ühendada tundmatule plokile (0,0)” Närviliseks muutumine on normaalne. Järsku ei käivitu teie Linuxi süsteem, konsool hangub tekstiseinaga ja tundub, nagu oleksite kõik kaotanud. Hea uudis on see, et enamasti pole te andmeid kaotanud ja olukorra saab lahendada, kui järgite rahulikult mõnda sammu.

See probleem võib ilmneda erinevates olukordades: uue distributsiooni (nt Linux Mint) installimisel, Ubuntu värskendamisel, CentOS serveri käivitamisel või virtuaalmasina käivitamisel Ubuntu või mõne muu distributsioonigaKuigi kontekstid võivad erineda, on kerneli viga sarnane ja põhjused keerlevad tavaliselt sama probleemi ümber: kernel ei saa juurfailisüsteemi ühendada. Selles artiklis selgitame üksikasjalikult ja võimalikult selges keeles, mida see viga tähendab ja kuidas seda igas reaalses stsenaariumis parandada.

Mida tähendab viga „kernel panic – VFS: unable to mount root fs on unknown-block(0,0)”?

Kui kernel käivitub, on üks selle esimesi ülesandeid Leidke ja paigaldage partitsioon, mis sisaldab juurfailisüsteemi "/"Selleks pead teadma, millisel seadmel see asub (näiteks /dev/sda2), millist tüüpi failisüsteemi see kasutab (ext4, xfs jne) ning omama sellele seadmele ligipääsemiseks vajalikke mooduleid (kettakontrollerid, kontrolleri draiverid jne).

Sõnum „VFS: root fs-i ei õnnestunud tundmatule plokile (0,0) paigaldada” See näitab, et kerneli virtuaalne failisüsteem (VFS) ei suutnud juurkataloogi ühendada. Väärtus "unknown-block(0,0)" näitab, et see ei suutnud isegi õigesti tuvastada plokkseadet, kust see peaks käivituma. Teisisõnu, kerneli jaoks on teie "/"-d sisaldav ketas sel hetkel praktiliselt nähtamatu või ligipääsmatu.

See ebaõnnestumine võib olla tingitud mitmest põhjusest: Puuduv või rikutud initramfs-kujutis, UUID-i või ketta kaardistuse muudatused, draiverid, mis ei laadi. alglaaduri (GRUB) vead või isegi partitsioonide ja partitsioonitabelite konfiguratsiooniprobleemid.

Üks oluline punkt, mis tavaliselt paljusid inimesi rahustab, on see, et Kerneli paanika iseenesest ei tähenda andmete kaduKäivitusfaas ebaõnnestus, kuid partitsioonid jäävad enamikul juhtudel terveks, oodates, et me käivitaksime päästekeskkonna või funktsionaalse kerneli, et neile ligi pääseda.

Paljudel veateadel kuvatakse ka teiseseid teateid, näiteks „SGX keelatud” või teiste moodulite hoiatused, mis võivad olla eksitavad. Need read ei ole tavaliselt probleemi algpõhjus, vaid lihtsalt informatiivsed sõnumid protsessori või süsteemi omaduste kohta. Võti peitub alati VFS-i ja juurühendusega seotud fraasis.

Tüüpilised juhtumid: Linux Minti installimine, Ubuntu uuendamine, CentOS ja virtuaalmasinad

See kerneli paanikaviga esineb tavaliselt väga spetsiifilistes olukordades. Nende stsenaariumide tundmine aitab mõista, mis võis valesti minna ja milliseid samme astuda. Üks sagedasemaid juhtumeid on Proovin esimest korda pärast partitsioonide käsitsi loomist käivitada äsja installitud süsteemi, näiteks Linux Mint 21.2 Cinnamoni.

Reaalne näide: Windowsi sülearvuti kasutaja otsustab installida Linux Minti, kasutades BalenaEtcher ISO kirjutamiseks 16 GB USB-mälupulgaleKontrollige Windowsis, kas arvuti kasutab UEFI püsivara, minge BIOS-i, valige käivitatav USB-draiv ja avage Mint Live'i seanss. Siiani tundub kõik normaalne. Probleem tekib siis, kui installimise ajal luuakse käsitsi partitsioon koos uue partitsioonitabeli loomine /dev/sda kausta (1 TB), 512 MB EFI partitsioon /dev/sda1 kausta, 2 GB swap-kettaruumi, umbes 10 GB suurune root (/) partitsioon ext4 kaustas ja /home, kasutades ülejäänud ketast.

Selles konkreetses stsenaariumis valitakse see ka /dev/sda1 (EFI partitsioon) kui seade alglaaduri installimiseksInstallimine lõpeb, valitakse suvandid, näiteks koodeki installimine, ja luuakse kasutaja. Seejärel otsustatakse taaskäivitamise asemel käivitada programm reaalajas seansis. „apt update” ja „apt upgrade” väljumiseks juba uuendatud süsteemiga. Taaskäivitamisel ilmub korrektse käivituse asemel kurikuulus kerneli paanika ning kasutaja jääb lõksu BIOS-i ja Minti käivitusvalikute vahel.

Teine tüüpiline stsenaarium leiab aset pärast Ubuntu uuemale versioonile uuendamistTeoreetiliselt peaks see olema läbipaistev protsess: uus kernel laaditakse alla, genereeritakse vajalikud failid ja GRUB-i värskendatakse. Mõnikord aga genereerimise etapp Äsja installitud kerneli initramfs protsess ebaõnnestub või ei käivitu õigesti.Süsteem näib uuenevat probleemideta, kuid taaskäivitamisel ilmub tõrge „Kernel Panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)” ja uude kerneli pole võimalik käivitada.

Serverikeskkondades on ka väga levinud juhtumeid, näiteks CentOS 6.x pärast värskenduste rakendamistMõnes serveris võib pärast käsku „yum update” või sarnast uus kernel rikkuda või valesti installida. Käivitamiskatsel kogeb süsteem kerneli paanikat ja jookseb kokku. Sellistes keskkondades on prioriteediks ilmselgelt teenuse võimalikult kiire taastamine, seega on olemas konkreetsed protseduurid. päästerežiim ja kerneli paketi uuesti installimine.

Lõpuks ei tohi me unustada, virtuaalsed masinad (VM) Ubuntu või muude distributsioonidegaMõnikord kuvab süsteem virtuaalmasina käivitamisel teate „end kernel panic: not syncing: VFS: unable to mount root fs on unknown-block(0,0)” ja hangub täielikult. Sellistel juhtudel on tavaliselt võimalik käivitada ainult vanema kerneliga, avades virtuaalmasina GRUB-menüüst „Advanced options for Ubuntu”, samas kui uuem kernel annab alati sama vea.

Juurfailisüsteemi ühendusprobleemi peamised tehnilised põhjused

Kõigi nende juhtumite taga on mitu korduvat tehnilist põhjust. Üks levinumaid, eriti pärast Ubuntu värskendusi või uusi kerneleid, on laaditava kerneli versioonile vastavate initramfide puudumine või riknemineInitramfs on kujutis, mis sisaldab minimaalset failisüsteemi koos moodulite ja tööriistadega, mis on vajalikud tegeliku juurkataloogi ühendamiseks.

Kui initramfs puudub, on rikutud või ei sisalda sobivaid mooduleid juurpartitsiooniga kettale juurdepääsuks, kernel ei paigalda kunagi "/" sümbolitSeepärast rõhutavad paljud selle vea kohta käivad õpetused "initramfsi taasloomist" ja selle tagamist, et GRUB valib selle pildi õigesti vastava alglaadimiskirje jaoks.

Teine levinud põhjus on seotud GRUB alglaaduri probleemidValesti konfigureeritud teed, muudetud UUID-d, valele kettale või partitsioonile viitavad kirjed või installid, kus EFI partitsioon on valesti paigaldatud. Linux Minti käsitsi partitsioonimise näites on väga levinud viga järgmine: GRUBi installimine valele EFI partitsioonile või UEFI/Legacy sätete mittejärgimineSee põhjustab selle, et püsivara või GRUB ei käivita õiget kerneli või teeb seda ilma sobivate parameetriteta.

CentOS serverites ja sarnastes keskkondades võivad lisaks initramfsile mõjutada ka muud tegurid. rikutud kerneli paketid või vastuolud RPM-andmebaasisKui paketiandmebaas on rikutud, võib paketihaldur jätta kerneli mittetäielikuks või oluliste failidega puuduvaks, mis võib järgmisel taaskäivitamisel kerneli paanikasse viia.

Virtuaalmasinate puhul on lisaks juba mainitud probleemidele ka järgmiste probleemide konfiguratsioon: virtuaalsed kettad, kontrollerid (IDE, SATA, SCSI, VirtIO) ja virtuaalse riistvara muudatusedKui muudame virtuaalmasina kettakontrolleri tüüpi ja kerneli initramfs-is pole sobivat moodulit, võib alglaadimise ajal juhtuda täpselt sama asi: Ta ei näe plaati ja tulemuseks on unknown-block(0,0).

Kõigil juhtudel on üks konstant: Kernel ei suuda tuvastada kehtivat plokkseadet, millel oleks kasutatav juurfailisüsteem.Parandamise võti peitub kerneli ja root'i vahelise tee taastamises: initramfsi parandamine, kerneli uuesti installimine, GRUBi konfiguratsiooni korrigeerimine või nähtavate partitsioonide ja seadmete kohandamine.

Lahendus Ubuntus: initramfsi taastamine ja GRUBi värskendamine

Kui probleem ilmneb pärast uuenda Ubuntu uuemale versioonile või installi moodsam kernelÜks tõhusamaid lahendusi on kahjustatud kerneli initramfs-kujutise taastamine ja alglaaduri värskendamine. See protsess tugineb asjaolule, et tavaliselt on olemas eelmine toimiv kernel, mis võimaldab süsteemil käivituda.

Esimene asi, mida teha, on avage GRUB menüüSelleks taaskäivitage arvuti ja kohe pärast BIOS/UEFI käivitumist vajutage korduvalt Shift-klahvi (paljudes BIOS-süsteemides) või Esc-klahvi (mõnedes UEFI-süsteemides), kuni ilmub GRUB-ekraan. Seal näete peamist kirjet, näiteks „Ubuntu“, ja teist nimega „Ubuntu lisavalikud“.

„Ubuntu lisavalikute” all on loend järgmistest funktsioonidest: kõik installitud kerneli versioonidIdee on valida vanem versioon, mis teadaolevalt enne värskendust töötas. Tavaliselt põhjustab kerneli paanika uusim kirje, seega on kõige parem valida sellele vahetult eelnev (näiteks kui 5.15.x ebaõnnestub, proovige 5.13.x). Valige see kirje ja vajutage selle käivitamiseks Enter.

Kui süsteem on vana kerneliga edukalt käivitunud, peate avama terminali. Sealt jätkake taastada ebaõnnestunud kerneli initramfidTüüpiline käsk Ubuntus oleks midagi sellist:

sudo update-initramfs -c -k

Asendades näiteks probleemse versiooni täpse stringi jaoks 4.15.0-36-generic või see, mis kuvatakse veateates või väljundis uname -r Kui see on vaja kontrollida. See käsk loob (või taastab) initramfs-i kujutise selle konkreetse kerneli versiooni jaoks, sealhulgas moodulid ja utiliidid, mis on vajalikud juurkataloogi ühendamiseks.

Pärast initramfide taastamist on oluline värskenda GRUB-i et see tuvastaks uue pildi õigesti ja kohandaks alglaadimisparameetreid. Selleks käivitage:

sudo update-grub

See käsk skannib süsteemi, leiab erinevad kerneli versioonid, loob GRUBi menüü uuesti ja seob iga kerneli korrektselt vastava initramfs-iga. Kui protsess on lõpule viidud, taaskäivitage arvuti tavapäraselt, ilma GRUBis midagi muutmata, et kontrollida, kas süsteem käivitub nüüd uue kerneliga ilma kerneli paanikata.

CentOS serveri taastamine päästerežiimis

Serverite maailmas, eriti koos CentOS 6.x (ja sarnased RHEL-i versioonid)Pärast uuendamist tekkiv kerneli paanika võib olla üsna murettekitav, kuid sellele on üsna lihtne lahendus, kasutades päästerežiimi. Üldine idee on käivitada süsteem väliselt andmekandjalt, paigaldada installitud süsteem, teha sinna chroot ning vajadusel parandada kerneli ja paketiandmebaas.

Esimene samm on käivita server päästekettaltSee võib olla CD/DVD või serveri halduskonsoolist (iLO, iDRAC, kaug-KVM jne) ühendatud ISO. Sellelt andmekandjalt käivitamisel valige tavalise installi asemel suvand „Paigaldatud süsteemi päästmine” või midagi sarnast. Kui see suvand otse ei ilmu, saate päästerežiimi siseneda, tippides käivitusaknasse järgmise käsu:

alglaadimine: Linuxi päästmine

Sealt palub assistent teil valida keel ja klaviatuuripaigutusSamuti pakub see võimalust võrk aktiveerida, näiteks DHCP kaudu. Võrgu aktiveerimine võib olla kasulik, kui teil on vaja parandusprotsessi ajal pakette alla laadida või välistele hoidlatele juurde pääseda.

Kui päästekeskkond on installitud süsteemi tuvastanud, ühendab see juurpartitsiooni /mnt/sysimageSelles keskkonnas shelli käivitamisel tuleb järgmine samm süsteemi sisse logida nii, nagu oleksime selle tegelikult käivitanud, kasutades käsku:

chroot /mnt/sysimage

Sellest hetkest alates mõjutavad kõik käivitatud käsud serverisüsteemi, mitte päästekeskkonda. Siin tulebki mängu parandamine yumiga. Tüüpiline probleem on see, et RPM-andmebaas on rikutudSee takistab kerneli pakettide korralikku haldamist. Selle kontrollimiseks võite esmalt proovida järgmist:

maitsev puhas

Kui see käsk tagastab andmebaaside avamisega seotud vigu, peate need käsitsi kustutama. Selleks avage kataloog, kuhu need on salvestatud:

cd /var/lib/rpm

Ja ajutised andmebaasifailid kustutatakse:

rm -f __db.00*

Pärast seda kustutamist tehakse uus katse yumi puhastada, seekord põhjalikumalt:

puhastage kõik

Kui see nüüd töötab, tähendab see, et RPM-andmebaas on edukalt ümber ehitatud. Järgmine oluline samm on installige kerneli pakett uuestimis on tavaliselt kerneli paanika põhjus, kui failid on rikutud või puuduvad. Selleks käivitage:

yum installi kernel uuesti

See käsk sunnib alla laadima ja installima kõik praegused kerneli failid, sealhulgas kerneli binaarfaili, initramfs-i ja kõik seotud sõltuvused. Kui uuesti installimine on lõppenud, väljuge chroot-režiimist, peatage päästekeskkond ja taaskäivitage server tavapäraselt. Kui kõik läks hästi, Server peaks käivituma ilma kerneli paanika ja andmete kadumiseta.

Ubuntuga virtuaalsete masinate käivitusprobleemid

Virtuaalmasinate puhul on sõnum „lõppkerneli paanika: sünkroonimine pole võimalik: VFS: root fs-i ei õnnestunud tundmatule plokile (0,0) paigaldada” See viga ilmneb tavaliselt virtuaalmasina käivitamisel, jättes süsteemi täielikult hangunuks. See olukord võib olla väga frustreeriv, sest süsteemile pääseb ligi ainult vanema kerneli versiooni kaudu, mis on valitud GRUB-i menüüst "Ubuntu lisavalikud".

Kui virtuaalmasin lubab käivitamist vanema kerneliga, on strateegia väga sarnane Ubuntu puhul paljasmetallis kirjeldatule: Käivitage töötav kernel, genereerige uuesti probleemse kerneli initramfid ja värskendage GRUB-i.Tavaliselt piisab sellest, et uus kernel saaks taastada juurkataloogi ühendamise võime ja süsteem saaks uuesti normaalselt käivituda.

Virtuaalmasina puhul tuleb kontrollida ka järgmist: hüperviisori konfiguratsioon (VirtualBox, VMware, KVM, Hyper-V jne)Kettakontrolleri tüübi (nt SATA-lt VirtIO-le üleminek) või ketta paigutuse muutused võivad põhjustada kerneli ebaõnnestumise õige seadme leidmisel, kui selle initramfs ei sisalda selle konkreetse kettakontrolleri jaoks vajalikke mooduleid.

Mõned foorumid mainivad, et probleem ilmneb "isegi kui virtualiseerimine on host-BIOS-is juba lubatud", mis võib segadust tekitada. Tõde on see, et väga väheste eranditega... Protsessori virtualiseerimisvalikud (VT-x, AMD-V) ei ole otseselt seotud kerneli VFS-i veaga.Nende lubamine tagab ainult virtuaalmasina parema jõudluse, kuid kerneli paanika on tavaliselt rohkem seotud virtuaalmasina sisemise konfiguratsiooniga (kettad, kontrollerid) või külalisdistributsiooni kerneli/initramfs-iga.

Kui probleem püsib pärast initramfsi taasloomist ja GRUBi värskendamist, võite pöörduda järgmise poole: käivitage virtuaalmasin ISO-lt reaalajas režiimisPaigaldage mõjutatud masina virtuaalketas ja kontrollige käsitsi GRUB-i konfiguratsioonifaile, /boot sisu ja igale installitud kerneli versioonile vastavate initramfs-failide olemasolu.

Vead Linux Minti installimisel käsitsi partitsioonimise ja UEFI abil

Tulles tagasi Linux Mint 21.2 Cinnamoni installimise juurde BIOS UEFI-režiimis ja käsitsi partitsiooniminePaljud kasutajad satuvad väiksematesse konfiguratsioonivigadesse, mis põhjustavad juurkataloogi paigaldamisel kerneli paanika. Tüüpiline protsess hõlmab uue partitsioonitabeli loomist /dev/sda kausta (kogu eelmise sisu kustutamine), EFI partitsiooni, swap-kausta, root-kausta ja /home'i määramist ning seejärel EFI partitsiooni valimist alglaaduri installisihtkohaks.

Kuigi see kõlab põhimõtteliselt õigesti, on mitu tundlikku punkti. Näiteks EFI partitsioon peab olema tüüpi „EFI System Partition” (ESP), vormindatud FAT32-vormingus ja paigaldatud aadressile /boot/efiKui see luuakse installijas lihtsalt tavalise partitsioonina, ilma seda korralikult EFI-na märkimata, ei pruugi GRUB õigesti installida ja UEFI püsivara ei pruugi seda kehtiva alglaadimispartitsioonina ära tunda.

Teine oluline detail on veenduda, et Alglaaduri jaoks valitud seade on kas terve ketas (nt /dev/sda) või õige EFI partitsioon.Sõltuvalt konkreetsest distributsioonist ja installijast võib /dev/sda1 käsitsi sihtkohaks valimine olukorras, kus distributsioon peaks GRUB-i /dev/sda-le installima, põhjustada süsteemi ebaõnnestunud õige alglaadimisstruktuuri loomisel, mille tulemuseks on taaskäivitamisel vigane alglaadimisprotsess.

Asjaolu Enne esimest taaskäivitust tehke reaalajas seansist „apt update” ja „apt upgrade”. See pole ka parim lähenemisviis, sest uuendad reaalajas keskkonda, mitte tingimata kettale juba installitud süsteemi. See võib tekitada segadust ja teatud tingimustel mõjutada isegi pakette, mis võivad mõjutada installijat või alglaadimisfaile.

Kui arvuti pärast installimist jääb BIOS-i ja Minti käivitusvalikute vahelisse tsüklisse kinni ning iga kord, kui proovite seda käivitada, jõuab see kerneli paanikasse, on üks võimalik lahendus Taaskäivitage reaalajas seanss USB-draivilt, ühendage juba installitud süsteem ja kontrollige EFI partitsiooni, /boot/efi sisu, fstab-i konfiguratsiooni ja GRUB-i kirjeid.Mõnel juhul on kiirem ja puhtam installi korrata, tagades, et GPT partitsioonitabel ja EFI partitsioon on algusest peale õigesti konfigureeritud.

Samuti saate kontrollida BIOS-i/UEFI-d, et näha, kas käivitamist võivad mõjutada suvandid, näiteks MOK ja turvaline käivitamineUEFI vs Legacy/CSM režiim või alglaadimisjärjekordKuigi kerneli teates mainitakse "SGX keelatud", pole see rida tavaliselt konkreetse VFS-i probleemi jaoks oluline; oluline on see, et püsivara leiaks ja käivitaks õige GRUBi ning et see osutaks õigele kernelile ja initramfsile.

Millal andmete taastamiseks kasutada välist seadet või reaalajas süsteemi?

Kõigis neis stsenaariumides on väga levinud murekoht kui kettale juurdepääsuks ja failide taastamiseks on vaja välist seadetVastus sõltub kiireloomulisusest ja sellest, kas süsteemil on endiselt toimiv kernel, kust käivitada, kas "Lisavalikute" alt või vana GRUB-i kirje kaudu.

Kui arvuti saab ikka veel vanema kerneli versiooniga käivituda (nagu Ubuntuga virtuaalmasina või mõne töölauainstallatsiooni puhul), on kõige mugavam variant kasutage seda toimivat kerneli ära täielike varukoopiate tegemiseks Enne millegi tõsisema puudutamist võite ühendada välise USB-draivi ja kopeerida /home või mis tahes kriitilise kataloogi või isegi kloonimistööriistu kasutada, kui soovite salvestada kogu süsteemipildi.

Kui ükski kernel ei käivitu ja süsteem satub pidevalt kerneli paanikasse, siis on see seda väärt. Käivitamine väliselt andmekandjalt: USB-draiv reaalajas distributsiooniga, pääste-ISO, CD/DVD jne.Sellest reaalajas keskkonnast saate sisemise kõvaketta paigaldada, pääseda juurde partitsioonidele (tavaliselt ext4 või muud) ja soovitud andmed välja võtta kas välisele kettale, võrgu kaudu või muul viisil.

Sama elav meedium teenib ka parandage paigaldus kohapealSee hõlmab selliste käskude nagu chroot käivitamist, kerneli uuesti installimist, initramfsi taasloomist või GRUBi parandamist. Tegelikult soovitavad paljud juhendid seda lähenemisviisi, eriti kui süsteem on tõsiselt kahjustatud või kui eelmise kerneli abil installitud keskkond pole ligipääsetav.

Oluline on seda rõhutada Kerneli paanika iseenesest ei hävita andmeid ega kustuta partitsioone.See on kerneli turvamehhanism, mis lülitab süsteemi välja tõsiste vigade korral, mis ohustavad selle terviklikkust. Prioriteediks peaks olema sundsulgemiste või ebatavaliste kettamanipulatsioonide vältimine ning kui on olulisi andmeid, tuleks enne mis tahes paranduste tegemist keskenduda esmalt varukoopiate turvamisele.

Kõike seda teades lakkab seda tüüpi viga olemast "maailmalõpp" ja muutub tehniliseks tagasilöögiks, mida saab peaaegu alati lahendada: vanast kernelist või päästekeskkonnast käivitamine, initramfide taasgenereerimine, kerneli uuesti installimine või GRUBi konfiguratsiooni ja partitsioonide parandamineSee võimaldab süsteemil oma juurkataloogi uuesti kokku panna ja tavapäraselt käivitada ilma teavet kaotamata.

Seotud artikkel:

GRUB-i viga "Tundmatu failisüsteem": põhjused, tegelikud juhtumid ja kuidas seda samm-sammult parandada

Isaac

Kirglik kirjanik baitide maailmast ja üldse tehnoloogiast. Mulle meeldib jagada oma teadmisi kirjutamise kaudu ja just seda ma selles ajaveebis teengi, näitan teile kõike kõige huvitavamat vidinate, tarkvara, riistvara, tehnoloogiliste suundumuste ja muu kohta. Minu eesmärk on aidata teil digimaailmas lihtsal ja meelelahutuslikul viisil navigeerida.