Před třemi lety jsem napsal článek, který vysvětloval, jak se zotavit z neúspěšného bootování po velké aktualizaci verze ve Fedoře. V té době jsem pracoval s Fedorou 25 a najednou jsem se už nemohl dostat na plochu. Ukázalo se, že problém je chybný initramfs, což je problém, se kterým jsem se v minulosti setkal pouze jednou, v Ubuntu, v roce 2009. Od té doby je klid.
Kolo času nás vrátilo na začátek. Stejný problém se opakoval. Nedávno jsem (poněkud) upgradoval instanci Fedory 29 na Fedoru 30 a ejhle, zjistil jsem, že čelím stejnému problému. Téměř. Měl jsem černou obrazovku a zprávu, která říkala:Nelze otevřít přístup ke konzole, účet root je uzamčen. V tomto okamžiku pokus o cokoli nepřinesl žádné výsledky. Mohl jsem pouze restartovat. Zkusil jsem jiné jádro a pomohlo to - dostal jsem se na plochu. I když se zdá, že problém je podobný, musel jsem to vyřešit trochu jiným způsobem.
Příznaky problému podrobněji
Zjistil jsem, že jsem byl docela zaskočen nedostatkem dostupných diagnostických nástrojů nebo použitelného prostředí, ve kterém bych mohl problém vyřešit. Nutnost restartovat znamená ztrátu možná cenných informací. Přinejmenším jsem mohl nabootovat do jiných jader, což znamenalo, že jsem měl s čím pracovat.
V jádře nejnovější-1 jsem se poprvé pokusil řídit vlastní radou z doby před dvěma lety, ale příkaz systemctl status boot-efi.mount neukázal nic užitečného. Vždy mě ohromí, jak křehký, složitý a ve skutečnosti není člověku přívětivý nový a moderní zaváděcí framework. Předchozí vydání mě přimělo napsat svůj článek Pokrok prostřednictvím složitosti a jeho závěry platí i po letech.
Nejjednodušší překážkou je dostupnost informací pod /var/log. Zpátky v dobách dobrého init, byste tam obvykle našli následující:syslog/messages, boot, staré boot a protokoly jádra. Byly to textové soubory, které jste mohli snadno a okamžitě zkontrolovat pomocí cat, méně, cokoliv.
Ve Fedoře některé získáte – ale ne všechny tyto soubory. Je tam například boot.log, ale pak:
sudo less boot.log
"boot.log" může být binární soubor. Vidíte to přesto?
Zajímavé je, že je to textový soubor (s některými podivnými znaky) a můžete jej zobrazit pomocí cat. Tento soubor však nepřinesl žádné užitečné informace, které by mi pomohly určit problém.
Potom jsem strávil trochu více času čtením různých možností pro journalctl a dává vám možnost vidět předchozí protokoly spouštění. Můžete to provést zadáním záporné celočíselné hodnoty, abyste viděli staré protokoly. Není to příliš intuitivní, ale alespoň mi to dalo to, co jsem potřeboval, i když zásadně nesnáším myšlenku formátu binárního protokolu. Viděli jste to nedávno, když jsem ladil problém s borkovaným notebookem. Podobné téma.
journalctl --boot=-1
Zde jsem procházel řádky a hledal chyby. Zatímco systemctl thingie dříve nepomohl, s tímto příkazem jsem nakonec narazil na kritický problém se zaváděním:
11. července 13:55:07 tester systemd[1]:Připojování /boot/efi...
11. července 13:55:07 připojení testeru[899]:připojení:/boot/efi:neznámý typ souborového systému 'vfat '.
Jul 11 13:55:07 tester systemd[1]:boot-efi.mount:Proces připojení ukončen, code=exited, status=32/n/a
Jul 11 13:55:07 tester systemd[1]:boot-efi.mount:Selhalo s výsledkem 'exit-code'.
Jul 11 13:55:07 tester systemd[1]:Nepodařilo se připojit /boot/efi.
Červenec 11 13:55:07 tester systemd[1]:Závislost selhala pro místní souborové systémy.
Červenec 11 13:55:07 tester systemd[1]:local-fs.target:Úloha local-fs.target/start se nezdařila s výsledkem 'závislost'.
Jul 11 13:55:07 tester systemd[1]:local-fs.target:Triggering OnFailure=dependencies.
Velmi podobné tomu, co se stalo před třemi lety. Opět se tedy zdá, že máme špatně sestavený initramfs, což se na můj vkus zdá být příliš často. Navíc to souvisí s upgradem verze. Zajímalo by mě, co může být na modulu FAT32 tak složitého, ale pak, to je otázka pro někoho jiného. Pokud jde o soubory initramfs, měl jsem pod /boot:
ls -ltr initramfs*
-rw-------. 1 kořenový kořen 73443963 19. května 2018 initramfs-0-rescue-efe3eec4bb6646fe864735812f4d094b.img
-rw--------. 1 kořenový kořen 22953495 2. dubna 15:54 initramfs-5.0.4-200.fc29.x86_64.img
-rw-------. 1 kořenový kořen 22961687 20. května 13:11 initramfs-5.0.16-200.fc29.x86_64.img
-rw-------. 1 kořenový kořen 23015208 20. května 21:17 initramfs-5.0.16-300.fc30.x86_64.img
Poslední byl viníkem, zatímco ten předtím (výše) fungoval dobře. Cokoli se stalo během aktualizace, způsobilo poškození druhého initramfs, bez modulu vfat, který by umožnil správné připojení souborového systému. Ze zvědavosti jsem se rozhodl obrázky extrahovat, abych viděl rozdíly – což potvrdilo mé podezření. Opět, toto nebylo to nejtriviálnější cvičení, protože nemůžete použít zcat a cpio k extrahování souborů initarmfs jako v minulosti, potřebujete složitější kombinaci:
/usr/lib/dracut/skipcpio initramfs-"version".img | zcat | cpio -id
Řešení
No, tady máte několik možností. Za prvé, pokud máte druhou kopii Fedory ve stejném boxu a funguje to, můžete zkopírovat její soubor initramfs a použít jej, jako jsem to dělal v Ubuntu. Toto není triviální možnost, ale pokud ji máte, máte štěstí!
Pokud to neuděláte, pak by měla pomoci starší jádra - jako tomu bylo v mém scénáři. Poté můžete spustit aktualizaci systému nebo ručně znovu vytvořit soubory initramfs. Podrobnosti o tom, jak to udělat, si můžete přečíst v mém článku o pomalém spouštění Ubuntu. Pokud nemůžete nabootovat do žádného jiného jádra a na hostiteli nemáte žádné další instance Linuxu, pak poslední možností je použít živou relaci a tam provést obnovu – nebo přeinstalovat.
Závěr
Jsem překvapen a poněkud zděšen touto situací - vším. Samotná chyba, nemožnost ladit naživo, skutečnost, že se mi to stalo po upgradu Fedory (opět), skutečnost, že jsem po běžných činnostech systému skončil s nenabootovatelným distrem, celková složitost systemd. To vše ve mně vyvolává pocit neklidu.
V roce 2020 není svět technologií o nic abstraktnější, robustnější a odolnější než před deseti lety. Naopak, chyby se neustále dějí, a když se projeví, okolní ekosystém je mnohem obtížnější používat a pracovat v něm než v minulosti. Díky tomu je odstraňování problémů a řešení problémů více frustrující. Takže ano, opravil jsem to a možná to je to, co se počítá, ale pak ne, to není to, co se počítá. Konečným cílem je bezproblémová uživatelská zkušenost. Bohužel, den za dnem se linuxový desktop pomalu vzdaluje tomuto ušlechtilému poslání a stává se stále více irelevantním v širším schématu věcí. Každopádně po technické stránce doufám, že byl tento článek užitečný. Opatruj se.