Megoldás a kernel pánikra, amikor a VFS nem tudja a root fs-t csatolni az ismeretlen blokkra (0,0)

Amikor a rettegett üzenet megjelenik a képernyőn „Kernel pánik – nem szinkronizál: VFS: nem lehet root fs-t csatolni az ismeretlen blokkra (0,0)” Teljesen normális, ha idegessé válsz. Hirtelen a Linux rendszered nem indul el, a konzol lefagy egy szövegfallal, és úgy tűnik, mintha mindent elveszítettél volna. A jó hír az, hogy a legtöbb esetben nem veszítettél el semmilyen adatot, és a helyzet orvosolható, ha higgadtan követsz néhány lépést.

Ez a probléma különböző esetekben fordulhat elő: új disztribúció (például Linux Mint) telepítésekor, Ubuntu frissítésekor, CentOS szerver indításakor, vagy virtuális gép Ubuntuval vagy más disztribúcióval történő indításakorBár a kontextusok eltérőek lehetnek, a kernelhiba hasonló, és az okok általában ugyanazon probléma körül forognak: a kernel nem tudja csatolni a root fájlrendszert. Ebben a cikkben részletesen és a lehető legvilágosabb nyelven ismertetjük, hogy mit jelent ez a hiba, és hogyan lehet kijavítani az egyes valós forgatókönyvekben.

Mit jelent a „kernel panic – VFS: unable to mount root fs on unknown-block(0,0)” hiba?

Amikor a kernel elindul, az egyik első feladata a következő: Keresse meg és csatlakoztassa azt a partíciót, amely a „/” gyökérfájlrendszert fogja tartalmazni.Ehhez tudni kell, hogy melyik eszközön található (például /dev/sda2), milyen típusú fájlrendszert használ (ext4, xfs stb.), és rendelkezni kell az eszköz eléréséhez szükséges modulokkal (lemezvezérlők, vezérlőillesztők stb.).

Az üzenet „VFS: nem sikerült a root fs-t csatolni az ismeretlen blokkra (0,0)” Ez azt jelzi, hogy a kernel virtuális fájlrendszere (VFS) nem tudta csatolni a gyökérkönyvtárat. Az "unknown-block(0,0)" azt mutatja, hogy még azt a blokkeszközt sem tudta helyesen azonosítani, amelyről indítania kellene. Más szóval, a kernel számára a "/" karaktert tartalmazó lemez gyakorlatilag láthatatlan vagy elérhetetlen abban a pillanatban.

Ez a kudarc több okból is kialakulhat: Hiányzó vagy sérült initramfs kép, változások az UUID-ban vagy a lemezképezésben, nem betöltődő illesztőprogramok, rendszerbetöltő (GRUB) hibák vagy akár partíció- és partíciós tábla konfigurációs problémák.

Egy fontos szempont, ami általában sok embert megnyugtat, az az, hogy A kernel pánik önmagában nem jelent adatvesztéstA rendszerindítási fázis sikertelen volt, de a partíciók az esetek túlnyomó többségében épek maradtak, és arra várnak, hogy elindítsunk egy mentési környezetet vagy egy működő kernelt az elérésére.

Sok hibaüzenet másodlagos üzeneteket is megjelenít, például „SGX letiltva” vagy más moduloktól származó figyelmeztetések, amelyek félrevezetőek lehetnek. Ezek a sorok általában nem a probléma kiváltó okát jelentik, hanem egyszerűen tájékoztató üzenetek a processzor vagy a rendszer jellemzőiről. A kulcs mindig a VFS-hez és a root mounthoz kapcsolódó kifejezésben rejlik.

Tipikus esetek: Linux Mint telepítés, Ubuntu frissítés, CentOS és virtuális gépek

Ez a kernel pánik hiba általában nagyon specifikus helyzetekben fordul elő. Ezen forgatókönyvek ismerete segít megérteni, hogy mi mehetett félre, és milyen lépéseket kell tenni. Az egyik leggyakoribb eset a Egy újonnan telepített rendszer, például a Linux Mint 21.2 Cinnamon első indításának megkísérlése a partíciók manuális létrehozása után.

Egy valós példa: egy Windows laptop felhasználója úgy dönt, hogy telepíti a Linux Mintet a következővel: BalenaEtcher az ISO 16 GB-os USB-meghajtóra írásáhozEllenőrizd a Windowsban, hogy a számítógép UEFI firmware-t használ-e, lépj be a BIOS-ba, válaszd ki a bootolható USB-meghajtót, és lépj be a Mint live munkamenetbe. Eddig minden normálisnak tűnik. A probléma akkor merül fel, amikor a telepítés során manuálisan létrehoznak egy partíciót a következővel: új partíciós tábla létrehozása a /dev/sda könyvtárban (1 TB), egy 512 MB-os EFI partíció a /dev/sda1 könyvtárban, 2 GB swap terület, egy körülbelül 10 GB-os root (/) partíció ext4 fájlrendszerben, és a lemez többi részének használata a /home könyvtárban.

Ebben a konkrét esetben azt is kiválasztják /dev/sda1 (az EFI partíció) a rendszerbetöltő telepítéséhez használt eszközkéntA telepítés befejeződik, olyan opciók, mint a kodek telepítése, kiválasztásra kerülnek, és létrejön a felhasználó. Ezután az újraindítás helyett úgy döntenek, hogy egy programot futtatnak az élő munkamenetben. „apt frissítés” és „apt frissítés” hogy a rendszer már frissítve legyen, és kilépjen. Újraindításkor a megfelelő bootolás helyett a hírhedt kernel pánik jelenik meg, és a felhasználó csapdába esik a BIOS és a Mint boot opciói között.

Egy másik tipikus forgatókönyv játszódik le miután frissítettem az Ubuntut egy magasabb verzióraElméletileg ennek egy átlátható folyamatnak kellene lennie: az új kernel letöltődik, a szükséges fájlok generálódnak, és a GRUB frissül. Azonban néha a generálási lépés a Az újonnan telepített kernel initramfs folyamata meghibásodik vagy nem fut megfelelően.A rendszer látszólag problémamentesen frissül, de újraindításkor a „Kernel Panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)” hiba jelenik meg, és nincs mód az új kernelbe való betöltésre.

Szerverkörnyezetekben is nagyon gyakoriak az esetek, például CentOS 6.x frissítések alkalmazása utánNéhány szerveren egy `yum update` vagy hasonló parancs kiadása után az új kernel megsérülhet vagy helytelenül települhet. Indításkor a rendszer kernelpánikot tapasztal és összeomlik. Ilyen környezetekben nyilvánvalóan a szolgáltatás mielőbbi helyreállítása a legfontosabb, ezért erre vonatkozóan speciális eljárások vannak érvényben. mentő mód és a kernel csomag újratelepítése.

Végül nem szabad elfelejtenünk a virtuális gépek (VM) Ubuntuval vagy más disztribúciókkalElőfordulhat, hogy a virtuális gép indításakor a rendszer a következő üzenetet jeleníti meg: „end kernel panic: not syncing: VFS: unable to mount root fs on unknown-block(0,0)” (kernel végi pánik: nem szinkronizálható: VFS: unable to mount root fs on unknown-block(0,0)”), és teljesen lefagy. Ilyen esetekben általában lehetséges egy régebbi kernel használatával indítani a rendszert a virtuális gép GRUB menüjének „Advanced options for Ubuntu” (Ubuntu speciális beállításai) menüpontjában, míg az újabb kernel mindig ugyanazzal a hibával hibázik.

A root fs csatolási hibájának fő technikai okai

Mindezen esetek mögött számos visszatérő technikai ok áll. Az egyik leggyakoribb ok, különösen az Ubuntu frissítések vagy új kernelek után, a a betöltött kernel verziónak megfelelő initramf-ek hiánya vagy sérüléseAz initramfs egy minimális fájlrendszert tartalmazó kép, amely tartalmazza a tényleges root csatlakoztatásához szükséges modulokat és eszközöket.

Ha az initramfs hiányzik, sérült, vagy nem tartalmazza a megfelelő modulokat a gyökérpartíciót tartalmazó lemez eléréséhez, a kernel soha nem fogja csatolni a „/” jeletEzért hangsúlyozza számos, ezzel a hibával foglalkozó oktatóanyag az „initramfs újragenerálását” és annak biztosítását, hogy a GRUB helyesen vegye fel az érintett rendszerképet.

Egy másik gyakori ok a következővel függ össze: GRUB rendszerbetöltő problémákHelytelenül konfigurált elérési utak, megváltozott UUID-k, helytelen lemezre vagy partícióra mutató bejegyzések, vagy olyan telepítések, ahol az EFI partíció helytelenül lett felcsatolva. A manuális particionálású Linux Mint példájában egy nagyon gyakori hiba a következő: A GRUB telepítése rossz EFI partícióra, vagy az UEFI/Legacy beállítások figyelmen kívül hagyásaEmiatt a firmware vagy a GRUB nem a megfelelő kernelt indítja, vagy a megfelelő paraméterek nélkül teszi ezt.

CentOS szervereken és hasonló környezetekben az initramfs mellett más tényezők is befolyásolhatók. sérült kernelcsomagok vagy inkonzisztenciák az RPM adatbázisbanHa a csomagadatbázis sérült, a csomagkezelő hiányos vagy hiányzó alapvető fájlokat hagyhat a kernelben, ami a következő újraindításkor kernelpánikhoz vezethet.

Virtuális gépekben a már említett problémákon túl a következők konfigurációja is felmerülhet: virtuális lemezek, vezérlők (IDE, SATA, SCSI, VirtIO) és virtuális hardverváltozásokHa megváltoztatjuk a virtuális gép lemezvezérlőjének típusát, és a kernel initramfs fájljában nincs megfelelő modul, akkor pontosan ugyanez történhet a rendszerindításkor: Nem látja a lemezt és egy unknown-block(0,0)-val végződik.

Minden esetben van egy állandó: A kernel nem talál érvényes blokkeszközt használható root fájlrendszerrel.A javítás kulcsa a kernel és a root közötti elérési út visszaállítása lesz: az initramfs javítása, a kernel újratelepítése, a GRUB konfigurációjának korrigálása, vagy a látható partíciók és eszközök módosítása.

Megoldás Ubuntuban: az initramfs regenerálása és a GRUB frissítése

Amikor a probléma megjelenik a következő után Frissítsd az Ubuntut egy újabb verzióra, vagy telepíts egy modernebb kerneltAz egyik leghatékonyabb megoldás az érintett kernel initramfs képének újragenerálása és a rendszerbetöltő frissítése. Ez a folyamat azon a tényen alapul, hogy általában van egy korábbi, működő kernel, amely lehetővé teszi a rendszer indítását.

Az első dolog, amit meg kell tenni, az az, hogy a GRUB menü megnyitásaEhhez indítsa újra a számítógépet, és közvetlenül a BIOS/UEFI boot után nyomja meg ismételten a Shift billentyűt (sok BIOS rendszeren) vagy az Esc billentyűt (egyes UEFI rendszereken), amíg meg nem jelenik a GRUB képernyő. Ott látni fog egy fő bejegyzést, például az „Ubuntu”-t, és egy másikat, amelynek az a neve, hogy „Speciális beállítások Ubuntuhoz”.

Az „Ubuntu speciális beállításai” részben található egy lista a következőkről: minden telepített kernel verzióAz ötlet az, hogy egy régebbi verziót válassz, amelyről ismert, hogy működött a frissítés előtt. Általában a legújabb bejegyzés okoz kernel pánikot, ezért a legjobb, ha a közvetlenül előtte lévőt választod (például, ha az 5.15.x nem működik, próbáld ki az 5.13.x verziót). Válaszd ki ezt a bejegyzést, és nyomd meg az Enter billentyűt a rendszerindításhoz.

Miután a rendszer sikeresen elindult a régi kernellel, meg kell nyitnod egy terminált. Innen folytasd a következővel: a hibás kernel initramf-jeinek regenerálásaAz Ubuntuban a tipikus parancs valami ilyesmi lenne:

sudo update-initramfs -c -k

Csere a problémás verzió pontos karakterláncához, például 4.15.0-36 generikus vagy az, amelyik a hibaüzenetben vagy a kimenetében megjelenik uname-r Ha ellenőrizni kell. Ez a parancs létrehozza (vagy újraalkotja) az initramfs képfájlt az adott kernel verzióhoz, beleértve a root csatolásához szükséges modulokat és segédprogramokat is.

Az initramfok regenerálása után elengedhetetlen GRUB frissítése hogy az helyesen érzékelje az új rendszerképet, és beállítsa a rendszerindítási paramétereket. Ehhez futtassa a következő parancsot:

sudo update-grub

Ez a parancs átvizsgálja a rendszert, megkeresi a különböző kernel verziókat, újraépíti a GRUB menüt, és helyesen összekapcsolja az egyes kernelt a megfelelő initramfs-szel. A folyamat befejezése után egyszerűen indítsa újra a számítógépet a szokásos módon, a GRUB módosítása nélkül, hogy ellenőrizze, hogy a rendszer most már az új kernellel indul-e kernel pánik nélkül.

CentOS szerver helyreállítás mentési módban

A szerverek világában, különösen a CentOS 6.x (és a RHEL hasonló verziói)Egy frissítés utáni kernelpánik elég riasztó lehet, de van egy meglehetősen egyszerű megoldás a rescue mód használatával. Az általános elképzelés az, hogy külső adathordozóról indítunk, felcsatoljuk a telepített rendszert, chroot-olunk bele, és szükség esetén kijavítjuk a kernelt és a csomagadatbázist.

Az első lépés az, hogy a szerver indítása egy helyreállító lemezrőlEz lehet CD/DVD vagy a szerver adminisztrációs konzoljáról (iLO, iDRAC, távoli KVM stb.) felcsatolt ISO lemez. Amikor erről az adathordozóról indítunk, a normál telepítés helyett válasszuk a „Telepített rendszer mentése” vagy hasonló lehetőséget. Ha ez a lehetőség nem jelenik meg közvetlenül, a rendszerindító parancssorba beírva a következő parancsot válthat mentési módba:

rendszerindítás: linux mentés

Innentől az asszisztens megkéri, hogy válasszon nyelv és billentyűzetkiosztásLehetőséget kínál a hálózat aktiválására is, például DHCP-n keresztül. A hálózat aktiválása hasznos lehet, ha csomagokat kell letöltenie vagy külső adattárakat kell elérnie a javítási folyamat során.

Miután a mentési környezet észlelte a telepített rendszert, felcsatolja a root partíciót a /mnt/sysimageAmikor ebben a környezetben elindítunk egy shellt, a következő lépés a rendszerbe való bejelentkezés, mintha ténylegesen elindítottuk volna, a következő parancs használatával:

chroot /mnt/sysimage

Ettől a ponttól kezdve minden végrehajtott parancs a tényleges szerverrendszert fogja érinteni, nem a mentési környezetet. Itt jön képbe a yum-mal történő javítás. Egy tipikus probléma, hogy az RPM adatbázis sérültEz megakadályozza a kernel csomagok megfelelő kezelését. Ennek ellenőrzéséhez először a következőket próbálhatja ki:

finom, tiszta

Ha ez a parancs az adatbázisok megnyitásával kapcsolatos hibákat ad vissza, manuálisan kell törölnie azokat. Ehhez nyissa meg azt a könyvtárat, ahol tárolva vannak:

cd /var/lib/rpm

És az ideiglenes adatbázisfájlok törlődnek:

rm -f __db.00*

A törlés után újabb kísérlet történik a yum kiürítésére, ezúttal alaposabban:

tisztítsd meg mindet

Ha most már működik, az azt jelenti, hogy az RPM adatbázist sikeresen újraépítették. A következő kulcsfontosságú lépés a következő: telepítse újra a kernel csomagotami általában kernel pánikot okoz, ha a fájlok sérültek vagy hiányoznak. Ehhez futtassa a következő parancsot:

yum telepítsd újra a kernelt

Ez a parancs kikényszeríti az összes aktuális kernelfájl letöltését és telepítését, beleértve magát a kernel bináris fájlt, az initramfs-t és az összes kapcsolódó függőséget. Az újratelepítés befejezése után lépjen ki a chrootból, állítsa le a mentési környezetet, és indítsa újra a szervert a szokásos módon. Ha minden jól ment, A szervernek kernelpánik és adatvesztés nélkül kell elindulnia.

Indítási problémák virtuális gépeken Ubuntu alatt

Virtuális gépek esetében az üzenet „kernel végi pánik: nem szinkronizálható: VFS: nem sikerült a root fs-t csatolni az ismeretlen blokkra (0,0)” Ez a hiba általában a virtuális gép indításakor jelentkezik, teljesen lefagyva hagyva a rendszert. Ez a helyzet nagyon frusztráló lehet, mivel a rendszerhez csak egy régebbi kernel verzión keresztül lehet hozzáférni, amelyet a GRUB "Speciális beállítások Ubuntuhoz" menüjéből lehet kiválasztani.

Ha a virtuális gép engedélyezi a régebbi kernellel való indítást, a stratégia nagyon hasonló ahhoz, amit az Ubuntu esetében a bare metal környezetben leírtunk: Indítsd el a működő kernelt, regeneráld a problémás kernel initramfs-eit, és frissítsd a GRUB-ot.Ez általában elég ahhoz, hogy az új kernel visszanyerje a gyökérkönyvtár csatolásának képességét, és a rendszer újra normálisan elinduljon.

Virtuális gép esetén azt is ellenőrizni kell, hogy hipervizor konfiguráció (VirtualBox, VMware, KVM, Hyper-V, stb.)A lemezvezérlő típusának (például SATA-ról VirtIO-ra váltás) vagy a lemezelosztás változásai miatt a kernel nem találja meg a megfelelő eszközt, ha az initramfs nem tartalmazza az adott lemezvezérlőhöz szükséges modulokat.

Néhány fórum említi, hogy a probléma „annak ellenére is jelentkezik, hogy a virtualizáció már engedélyezve van” a gazdagép BIOS-ában, ami zavaró lehet. Az igazság az, hogy nagyon kevés kivételtől eltekintve, A processzor virtualizációs beállításai (VT-x, AMD-V) nem kapcsolódnak közvetlenül a kernel VFS hibájához.Engedélyezésük csak azt garantálja, hogy a virtuális gép jobb teljesítménnyel fog futni, de a kernel pánikok általában inkább a virtuális gép belső konfigurációjához (lemezek, vezérlők) vagy a vendégdisztribúción belüli kernelhez/initramfs-hez kapcsolódnak.

Ha a probléma az initramfs újragenerálása és a GRUB frissítése után is fennáll, akkor a következőhöz folyamodhat: Indítsd el a virtuális gépet ISO-ból élő módbanCsatold fel az érintett gép virtuális lemezét, és manuálisan ellenőrizd a GRUB konfigurációs fájljait, a /boot tartalmát, valamint az egyes telepített kernel verzióknak megfelelő initramfs fájlok meglétét.

Hibák a Linux Mint manuális particionálással és UEFI-vel történő telepítésekor

Visszatérve a Linux Mint 21.2 Cinnamon telepítésének esetére BIOS UEFI módban és manuális particionálásSok felhasználó kisebb konfigurációs hibákba esik, amelyek kernel pánikot okoznak a gyökérkönyvtár csatolásakor. A tipikus folyamat magában foglalja egy új partíciós tábla létrehozását a /dev/sda könyvtáron (az összes korábbi tartalom törlésével), egy EFI partíció, a swap, a root és a /home könyvtár definiálását, majd az EFI partíció kiválasztását a rendszerbetöltő telepítési célpontjaként.

Bár ez elvileg helyesnek hangzik, van néhány érzékeny pont. Például a Az EFI partíciónak „EFI System Partition” (ESP) típusúnak kell lennie, FAT32 formátumúnak, és a /boot/efi címre kell csatolni.Ha egyszerűen csak egy sima partícióként hozod létre a telepítőben anélkül, hogy megfelelően megjelölnéd EFI-ként, akkor előfordulhat, hogy a GRUB nem települ megfelelően, és az UEFI firmware nem ismeri fel érvényes rendszerindító partícióként.

Egy másik fontos részlet annak biztosítása, hogy A rendszerbetöltőhöz kiválasztott eszköz vagy a teljes lemez (pl. /dev/sda), vagy a megfelelő EFI partíció.Az adott disztribúciótól és telepítőtől függően a /dev/sda1 manuális kiválasztása célhelyként, amikor a disztribúciónak a GRUB /dev/sda könyvtárra kell telepítenie, azt okozhatja, hogy a rendszer nem tudja létrehozni a megfelelő rendszerindítási struktúrát, ami az újraindításkor a rendszerindítási folyamat hibás működéséhez vezet.

Az a tény, Végezzen el egy „apt update” és „apt upgrade” parancsot az élő munkamenetből az első újraindítás előtt. Ez sem a legjobb megközelítés, mert az élő környezetet frissíted, nem feltétlenül a lemezre már telepített rendszert. Ez zavart okozhat, és bizonyos körülmények között olyan csomagokat is érinthet, amelyek hatással lehetnek a telepítőre vagy a rendszerindító fájlokra.

Amikor a telepítés után a számítógép beragad egy hurokba a BIOS és a Mint rendszerindítási opciók között, és minden alkalommal, amikor megpróbálod elindítani, kernel pánikba kerül, az egyik lehetséges megoldás a következő: Indíts újra egy élő munkamenetet az USB-meghajtóról, csatlakoztasd a már telepített rendszert, és ellenőrizd az EFI partíciót, a /boot/efi tartalmát, az fstab konfigurációt és a GRUB bejegyzéseket.Bizonyos esetekben gyorsabb és tisztább megoldás lehet megismételni a telepítést, biztosítva, hogy a GPT partíciós tábla és az EFI partíció a kezdetektől fogva helyesen legyen konfigurálva.

A BIOS/UEFI-ben is ellenőrizheted a rendszerindítást befolyásoló beállításokat, például MOK és biztonságos rendszerindításUEFI vs. Legacy/CSM mód vagy rendszerindítási sorrendBár a kernel üzenete az „SGX letiltva” sort említi, ez a sor általában irreleváns az adott VFS problémához képest; a lényeg az, hogy a firmware megtalálja és elindítja a megfelelő GRUB-ot, és hogy az a megfelelő kernelre és initramfs-re mutasson.

Mikor használjunk külső eszközt vagy élő rendszert az adatok helyreállításához?

Mindezen forgatókönyvekben egy nagyon gyakori aggodalomra ad okot, ha külső eszközre van szükség a lemez eléréséhez és a fájlok visszaállításáhozA válasz a sürgősség szintjétől és attól függ, hogy a rendszernek van-e még működő kernelje, amiről indítható, akár a "Speciális beállítások" alatt, akár egy régi GRUB bejegyzésen keresztül.

Ha a számítógép továbbra is képes egy régebbi kernel verzióval elindulni (mint például egy Ubuntut futtató virtuális gép vagy néhány asztali telepítés esetén), a legkényelmesebb lehetőség a következő: használd ki a működő kernelt a teljes biztonsági mentések elkészítéséhez Mielőtt bármi komolyabbhoz hozzányúlnánk, csatlakoztathatunk egy külső USB-meghajtót, és átmásolhatjuk a /home vagy bármely fontos könyvtárat, vagy akár klónozóeszközöket is használhatunk, ha egy teljes rendszerképet szeretnénk menteni.

Amikor nincs olyan kernel, ami elindul, és a rendszer mindig kernel pánikba esik, akkor megéri. Külső adathordozóról történő indítás: USB-meghajtó élő disztribúcióval, rescue ISO, CD/DVD stb.Ebből az élő környezetből csatlakoztathatja a belső merevlemezt, elérheti a partíciókat (általában ext4 vagy más), és kinyerheti a kívánt adatokat egy külső meghajtóra, a hálózaton keresztül, vagy ahogy Önnek tetszik.

Ugyanez az élő médium arra is szolgál, hogy a telepítés helyszíni javításaEz olyan parancsok futtatását foglalja magában, mint a chroot, a kernel újratelepítése, az initramfs újragenerálása vagy a GRUB javítása. Valójában számos útmutató ajánlja ezt a megközelítést, különösen akkor, ha a rendszer súlyosan sérült, vagy ha a korábbi kernelt használó telepített környezet nem érhető el.

Fontos ezt hangsúlyozni A kernel pánik önmagában nem semmisíti meg az adatokat és nem törli a partíciókat.Ez egy kernel biztonsági mechanizmus, amely leállítja a rendszert, ha súlyos hibákba ütközik, amelyek veszélyeztetik annak integritását. Elsődleges cél a kényszerített leállítások vagy a szokatlan lemezmanipulációk elkerülése, és ha fontos adatok vannak, először a biztonsági mentések biztosítására kell összpontosítani, mielőtt bármilyen javítást megkísérelne.

Mindezek ismeretében ez a fajta hiba már nem "világvége" lenni, hanem egy szinte mindig megoldható technikai nehézséggé válik: régi kernelből vagy mentési környezetből történő indítás, az initramfs újragenerálása, a kernel újratelepítése, vagy a GRUB konfigurációjának és partícióinak javításaEz lehetővé teszi a rendszer számára, hogy újra összerakja a gyökérkönyvtárát és normálisan elinduljon információvesztés nélkül.

Kapcsolódó cikk:

"Ismeretlen fájlrendszer" hiba a GRUB-ban: okok, valós esetek és a javítás lépésről lépésre

Izsák

Szenvedélyes író a bájtok és általában a technológia világáról. Szeretem megosztani tudásomat írásban, és ezt fogom tenni ebben a blogban, megmutatom a legérdekesebb dolgokat a kütyükről, szoftverekről, hardverekről, technológiai trendekről stb. Célom, hogy egyszerű és szórakoztató módon segítsek eligazodni a digitális világban.