Pamatuješ, říkal jsem ti o zpackaném notebooku? No, pojďme to upřesnit, ano. Prováděl jsem nějaké testování se softwarem pro zobrazování a obnovu, a jakmile jsem skončil, chtěl jsem vidět, jak dobře proces probíhal. Ne dobře, ukázalo se. GRUB tam byl, ale žádná položka v nabídce zpočátku nefungovala. Jakmile jsem to okamžitě opravil, viděl jsem, že se Windows 10 nespustí a nebude se automaticky opravovat a polovina distribucí v systému (z celkových osmi) v nastavení s více spouštěním se také nespustí. přejde do nouzového režimu. Mluvíme o plném podílu distribucí, vyberte si.
Obnova GRUB byla docela složitá - žádná z metod, na kterou jsem mohl myslet, nefungovala a nakonec jsem nainstaloval testovací distribuci, abych správně nakonfiguroval bootloader. Pak jsem spustil jednu z distribucí, která fungovala, a všiml jsem si, že nedošlo ke ztrátě dat. Všechno tam bylo, všechny oddíly byly zdravé a celistvé a soubory byly na svém správném místě, včetně Linuxu a Windows. V tomto článku bych vám rád ukázal, jak jsem na tento problém postupoval a jak jsem ho vyřešil – a v pokračování uděláme totéž pro Windows 10. Užitečné cvičení. Následujte mě.
Problém podrobněji
Provedl jsem následující cvičení s neonem jako startér, ale týká se téměř každého distra zhruba od roku 2011-2012. Takže se stane, že KDE neon začne bootovat a pak spadne do nouzového prostředí. Systém mi řekl, že bych měl spustit journalctl -xb, abych viděl spouštěcí protokol a zjistil, co bylo špatně. Není to poprvé, co jsme se s tím setkali. Ne tak dávno jsem řešil podobný problém s Fedorou.
Ale tady byl problém trochu jiný. Ano, boot log ukazoval problémy s /boot/efi, ale proč se to stalo, pramenilo z jiného problému. Pokud vás zajímá, jak jsem získal a zkopíroval protokoly v nouzové relaci (pokud něco takového potřebujete), můžete zkopírovat obsah do souboru a poté jej získat prostřednictvím živé relace (pomocí přesměrování> nebo pomocí příkazu tee ), nebo jakmile problém vyřešíte, můžete vypsat poslední mínus jeden protokol pomocí journalctl -x --boot=-1. To je pro vás moderní technologie.
Prosinec 06 12:57:09 tester systemd[1]:Selhala závislost kontroly systému souborů na /dev/disk/
-- Předmět:Jednotka systemd-fsck@dev-disk-by\x2duuid-641C\x2d39CE. služba selhala
-- Defined-By:systemd
-- Podpora:http://www.ubuntu.com/support
--
-- Unit systemd-fsck@ dev-disk-by\x2duuid-641C\x2d39CE.service se nezdařilo.
--
-- Výsledek je VÝSLEDEK.
Prosinec 06 12:57:09 tester systemd[1]:Závislost selhala pro /boot/efi.
-- Předmět:Unit boot-efi.mount selhal
-- Defined-By:systemd
-- Podpora:http://www.ubuntu.com/support
--
- Unit boot-efi.mount selhal.
Řešení
Přemýšlel jsem, co se mohlo pokazit. Celý dev-disk-by byl velkou nápovědou. Pamatujete si, když jsem vám ukázal, jak opravit problémy s pomalým spouštěním, když se změnil UUID odkládacího oddílu? Zdálo se to docela tak, až na to, že /boot/efi je kritický v procesu spouštění systému.
Otevřel jsem /etc/fstab a skutečně, uvedené UUID pro odkládací oddíl (dev/sda10) NEBYLO správné. Soubor má dokonce komentář, který říká, že položka oddílu bývala číslem zařízení a pak byla změněna na údajně "moderní" a "užitečný" nesmysl UUID, který způsobuje pouze problémy.
# swap byl na /dev/sda10 během instalace
UUID=8140c8d0-1e33-42c1-8c3c-828449adfe08 žádný swap swap 0 0
Změnil jsem UUID na /dev/sda10, restartoval a všechno bylo broskvové!
Příkazy, které k tomu budete potřebovat
Teď na chvíli zpomalíme. Takto můžete ověřit, zda váš systém používá správná čísla nebo identifikátory zařízení. Nejprve můžete vypsat oddíly pomocí fdisk -l. Tento příkaz vám poskytne přehled o všech různých oddílech a jejich souborových systémech. Tímto způsobem můžete získat základní představu o vašem systému. Zejména potřebujete kořenový oddíl (/), můžete mít samostatný oddíl /boot, což je často případ na systémech UEFI, můžete používat samostatný /home a můžete mít také volitelný a samostatný odkládací oddíl. Ty budou označeny čísly zařízení, jako /dev/sda2, /dev/sda8 atd.
Problém začíná v tom, jak novější verze distribucí Linuxu mapují zařízení do /etc/fstab, což je soubor, který je analyzován při spuštění systému pro informace o tom, která zařízení by měla být automaticky připojena. V minulosti byla zařízení označována jako fdisk, dev/XdYZ, kde X znamenalo typ disku (obvykle písmena h nebo s), Y bylo písmeno zařízení (podle pořadí vašeho systému BIOS, např. a, b nebo podobné) a Z by bylo číslo oddílu. Například /dev/sdb3 znamená třetí oddíl na druhém disku s typem připojení SATA/SCSI/PCI-E.
„Moderní“ distribuce skutečně používají UUID – jedná se o lidsky nesmyslný řetězec čísel a písmen, něco jako a45f-cc9a, určený k jedinečnému mapování diskových oddílů, takže pokud se pořadí disků nějak změní, systém může stále nabootovat. Možná to dává smysl v podniku, ale v domácím prostředí je to absolutní a naprostý nesmysl – jako skoro KAŽDÉ „moderní“ řešení, jako systemd, nová konvence pojmenování síťového rozhraní, nové nástroje pro správu sítě a tak dále. Více o filozofii později.
Nyní, pokud máte nesprávné UUID uvedené v /etc/fstab, systém nemůže tyto oddíly připojit - mechanismus je velmi nefunkční, protože nemá schopnost kontrolovat, hledat nebo léčit poškozenou konfiguraci - můžete skončit s nespouštěcí Systém. Tuto situaci také není možné rychle vyřešit, protože řetězce UUID jsou pro lidi naprosto k ničemu.
Seznam UUID zařízení můžete ověřit pomocí příkazu blkid, například:
blkid
/dev/mapper/sda3_crypt:UUID="TpZGKB-31Lq-U1Ap-BZJCcX" TYPE="LVM2_member"
/dev/mapper/kubuntu--vg-root:UUID="dcae17fd-7cfe -c0b721e" TYPE="ext4"
Musíte vizuálně porovnat a pak zjistit, co chybí. A pak ručně opravit /etc/fstab.
Moderní, stále používáte to slovo ...
Jednoduchá realita je následující:S Linuxem pracuji více než 15 let. V určitém okamžiku života jsem měl na starosti krásné nastavení HPC se zhruba 50 000 fyzickými servery rozmístěnými v přibližně 40 datových centrech. Měl jsem svůj podíl na podnikových a domácích systémech se starými a novými technologiemi.
S nefunkčními systémy jsem se setkal většinou od doby, kdy jsme přešli ze starého BIOSu + MBR + GRUB + init na nový UEFI + GPT + GRUB2 + systemd. V těchto řešeních není nic magického, odolného ani vylepšeného. Řeší některá skutečná technická omezení v oboru, pravda. Ale také představují mnohem méně robustní nastavení, které je pro lidi nekonečně obtížnější ladit a řešit problémy. Například jsem NIKDY neviděl rozbitý systém, protože se pokazilo pořadí disků. Ale viděl jsem MNOHO příkladů systémů zničených použitím UUID namísto jednoduchého zápisu čísla zařízení.
Oprava GRUB byla v nejhorším případě triviální věcí zkopírovat 512 bajtů dat sem nebo tam a upravit textový soubor. Nyní je to téměř vědecké náboženství přistupovat k novým rozhraním, pracovat s EFI a tak. Oprava nefunkčního spouštění Linuxu nebyl problém a teď musím analyzovat binární protokoly do textu a pak přijít na to, proč mohou být mé systémy nemotorné, jen abych zjistil, že je to všechno proto, že jsem nucen používat „řešení“ “ k problémům, které neexistují. Například věc UUID. Věc ip versus ifconfig. Proč je enp0s0 nebo jakýkoli nový identifikátor síťové karty lepší nebo chytřejší nebo intuitivnější než eth0? Dříve bylo logické, ethernet =eth.
Jaký je scénář, kdy musí domácí uživatelé často přidávat nebo odebírat pevné disky ze svých krabic nebo si hrát s nastavením systému BIOS? To není. Proč tedy domácí systémy přicházejí s řešeními, která jsou nedostatečná? Protože Linux ze své podstaty není určen jako domácí řešení a já si připadám jako idiot.
A to je jen začátek. Postupem času budeme mít více abstrakce, abstrakce, abstrakce, automatizace, strojově optimalizovaného svinstva a vy se budete muset spolehnout a záviset na milosti jakékoli entity, která pumpuje jejich nejnovější Whatever as a Service. Přijde okamžik, kdy celý tento nesmysl vybuchne, protože jej nelze odladit. Nebo to bude ponecháno na strojích, aby si to spravovaly samy za použití svých ošklivých protokolů, které lidé původně neměli vidět ani zažít. Mluvíme o špatném designu.
Závěr
Za prvé, doufám, že vám tento článek bude užitečný. Ve většině případů, kdy se systém Linux nespouští, pravděpodobně čelíte problémům s něčím, co souvisí s /boot nebo /boot/efi. Pokud k tomu dojde, měli byste si být trochu jisti čtením protokolů a pak se pokusit zjistit, zda nemáte chybějící nebo poškozené součásti, jak jsem vám ukázal s chybami initrd a initramfs (odkaz výše), nebo zda je konfigurace systému nesprávná a pokouší se odkazovat na neexistující zdroje. V našem případě, stejně jako problém s pomalým spouštěním, bylo na vině použití falešného UUID pro oddíly.
To by se mělo řešit na systémové úrovni. Ale jak jsem již mnohokrát poznamenal, ověřování v Linuxu prostě není věc. Vývojáři dělají svou věc a jdou dál. Nikdo se neobtěžuje přemýšlet o širším obrazu, o filozofii. Ale to je softwarové myšlení:funkce -> výstup. Nikoho nezajímá, co žije mimo funkci a zapouzdřuje funkcionalitu.
Robustní systém by ve skutečnosti prozkoumal existující zařízení a souborové systémy a pokusil se zjistit, zda není problém v konfiguraci. Robustní systém by měl zálohu kritických souborů a snažil by se na ně odkazovat. Robustní systém by se o něco pokusil několika různými způsoby a uvedl věci do vzájemného vztahu, než by selhal smysluplným způsobem. Nic z toho dnes neexistuje, ani v Linuxu ani v žádném jiném systému, protože udržovat hordu chudých techniků je levnější než vymýšlet chytré, samoopravné mechanismy. A pokud se vám to stane u vás doma, jste jen zástava. Takže když lidé mluví o svobodě a open-source, mluví o špatné věci. K čemu je open-source dobrý, když se používá k vývoji zatemněných řešení? Jsem smutný. Musím plakat.