Diagnostika problémů se spouštěním Linuxu a selhání hardwaru

Informatec Digital » Zdroje » Diagnostika problémů se spouštěním Linuxu a selhání hardwaru

Když se systém Linux nespustí nebo se začne chovat nepravidelně, přirozenou reakcí je myslet si, že „Linux je nefunkční“. V praxi jsou však většinou základními problémy konfigurační chyby, plné disky, poškození souborového systému nebo hardwarové problémy, které lze s trochou metodologie lokalizovat. Účelem tohoto článku je právě to: demonstrovat jasný postup, podporovaný konkrétními příkazy, pro diagnostiku a opravu nejčastějších problémů se spouštěním a hardwarem v Linuxu, a to jak na fyzických, tak na virtuálních počítačích.

Pokud se setkáte se zprávami jako „kořenový souborový systém nenalezen“, „Na zařízení nezbývá místo“, „Chyba EXT4-fs“, „XFS: Chyba CRC metadat“ nebo obávanou chybu Kernel Panic , zde se dozvíte, jak je interpretovat, jaké příkazy použít a v jakém pořadí jednat. Také se podíváme, jak zjistit, zda je problém skutečně softwarový, nebo zda je hardware (RAM, SSD/HDD, síťová karta atd.) na konci svého života, a jak minimalizovat riziko ztráty dat při řešení problémů.

Typické příčiny problémů se spouštěním v Linuxu

Než se začnete bezhlavě pouštět do věcí, je dobré pochopit nejčastější důvody, proč se Linux nemusí spustit nebo se spustí nesprávně . Pochopení hlavní příčiny vám ušetří hodiny řešení problémů a zkoušení neúspěšných řešení.

První sada problémů pramení ze správce spouštění a konfigurace BIOSu/UEFI : nesprávně generované položky GRUBu, přepsaný MBR po instalaci Windows v režimu duálního spouštění , nekompatibilita zabezpečeného spouštění s vaší distribucí nebo pokus systému BIOS o spuštění z nesprávného disku. V těchto případech často ani neuvidíte nabídku GRUBu, nebo když vyberete svou distribuci Linuxu, systém se zasekne nebo se vrátí k původnímu firmwaru.

Další důležitý blok se týká diskový a souborový systémPoškozené oddíly, vadné sektory, poškození EXT4 nebo XFS, plné systémové disky nebo chyby LVM. To se obvykle projevuje jako zprávy během bootování, například „Nepodařilo se připojit /…","Chyba EXT4-fs","XFS: Odpojení a spuštění xfs_repair„nebo dokonce skončí v nouzovém režimu a bude vás žádat o provedení journalctl -xb.

Problémy jsou také velmi časté po aktualizaci jádra nebo špatně aplikované záplatě . Neúplné stahování, uvolněné moduly, ovladače, které již nejsou kompatibilní s vaším hardwarem, nebo změny v souboru initramfs mohou způsobit zamrznutí systému uprostřed bootování nebo spuštění Kernel Panic při spuštění.

Nesmíme zapomenout na sekci o konfiguraci samotného systému : příliš přísná pravidla bezpečného bootování (například auditd nakonfigurovaný s HALT, když je /var/log/audit plný), kritické služby, které selhávají kvůli nedostatku místa, nebo změny v konfiguračních souborech, které brání spuštění nezbytných démonů (network, systemd, cloud-init v cloudech jako Azure atd.).

Nakonec je tu hardwarová vrstva: disky s červenými příznaky SMART, RAM s chybami ECC, síťové karty, které ztrácejí pakety, nebo SSD, které se přehřívají . Stopa se často skrývá ve zprávách jádra (dmesg) nebo v čítačích SMART a EDAC, takže se podíváme, jak je pečlivě číst.

Jak identifikovat zdroj poruchy spouštění

Klíčem k vyhnutí se slepému řešení problémů je povolení podrobného bootovacího režimu a kontrola protokolů . Ve výchozím nastavení mnoho distribucí zobrazuje pěknou úvodní obrazovku, která zakrývá zprávy, což vypadá působivě, ale nepomůže, když se něco pokazí.

Na systémech používajících GRUB můžete tichý režim vypnout úpravou souboru /etc/default/grub . Hledejte řádek:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

a nahraďte jej tímto:

GRUB_CMDLINE_LINUX_DEFAULT=""

Poté spusťte příkaz `update-grub` (nebo ekvivalentní příkaz ve vaší distribuci) pro regeneraci konfigurace. Při dalším spuštění se zobrazí všechny zprávy jádra a systemd, což vám umožní přesně určit chybu způsobující pád systému.

Pokud se systému podaří částečně nabootovat nebo k němu máte přístup z živého prostředí, budete mít v souboru /var/log k dispozici několik protokolů klíčů :

• /var/log/boot.log: zaznamenává vše, co se děje během fáze spouštění; pokud je chyba v této fázi, je to první místo, kde je třeba hledat.
• / var / log / zprávy o / var / log / syslog (v závislosti na distribuci): obecné systémové události, velmi užitečné pro zobrazení chyb ve službách, démonech atd.
• dmesg: zobrazuje zprávy jádra, včetně selhání hardwaru, problémů s moduly, chyb sběrnice, chyb PCI atd.
• journalctlV systémech používajících systemd je to primární nástroj pro procházení celého registru; s journalctl -xb Vidíte finální start v celé jeho kráse.

Pokud se systém nedostane na plochu, ale dostane se do TTY nebo režimu obnovy, můžete odtud přímo spustit příkaz `journalctl -xb` . Pokud to nefunguje, budete muset spustit systém z Live USB , připojit systémový disk a načíst tyto soubory z živého prostředí.

Zkontrolujte, zda je problém hardwarový nebo softwarový

Než se začnete pouštět do úprav nastavení, je dobré zkontrolovat, zda problém není přímo v hardwaru: disku, paměti, procesoru, základní desce nebo zdroji napájení . Mnoho instalací, které se „náhodně“ poškodí, ve skutečnosti odhaluje vadný SSD nebo vadnou RAM.

Prvním krokem, pokud počítač disk ani nerozpozná, je vstup do systému BIOS/UEFI a ověření, zda je disk v seznamu uveden. Pokud se disk vůbec nezobrazí nebo se zobrazuje přerušovaně, zkontrolujte připojení, kabely SATA a napájecí zdroj, případně předpokládejte, že disk bude možná nutné recyklovat.

Pokud se dostanete do GRUBu nebo do Live Bootu, můžete z nabídky GRUBu spustit program MemTest86+ a zkontrolovat tak paměť RAM. Nechte jej běžet alespoň osmkrát; pokud vidíte červené čáry, paměť je vadná a je třeba vyměnit moduly. Vadná paměť RAM je živnou půdou pro poškození dat.

Pro kontrolu stavu disků v Linuxu použijte smartmontools . Po jeho instalaci povolte SMART a zkontrolujte nejdůležitější atributy:

• Přemístěný_sektor_Ct: počet přeřazených sektorů; pokud je větší než 0, disk již začal mít vadné sektory.
• Aktuální_čekající_sektor_Ct: sektory čekající na přeřazení; jakákoli hodnota větší než 0 značí vysoké riziko bezprostředního selhání.
• Hodiny_v_zapnutí: souhrn hodin používání; čím vyšší číslo, tím větší je pravděpodobnost selhání disku.

Pomocí příkazu `smartctl -H /dev/sdX` můžete rychle zjistit, zda disk testem stavu prošel, či ne. Pokud výsledek neprošel, je třeba co nejdříve zálohovat data a začít uvažovat o jeho výměně.

Pokud máte podezření na vysoké teploty, nainstalujte lm-senzory a běž sensors (o watch -n 2 sensors (pro zobrazení v reálném čase). U disků SSD a SATA, hddtemp Zobrazuje aktuální teplotu, takže můžete detekovat jednotky, u kterých dochází k prudkému nárůstu teploty i v nečinnosti, což je užitečné pro... optimalizace serveru.

Specializovaná diagnostika hardwaru v Linuxu

Kromě CPU, RAM a disku má Linux specifické nástroje pro vyhodnocování paměti ECC, síťových karet, GPU a dalších komponent . Pokud strávíte několik minut kontrolou těchto bodů, můžete ušetřit mnoho hodin ladění.

Pokud váš server nebo pracovní stanice má paměť ECC , jádro obvykle zaznamenává opravené a neopravené chyby pomocí EDAC. Jednoduché:

dmesg | grep EDAC

Umožňuje vám zjistit, zda se vyskytly opravené chyby (CE) nebo neopravené chyby (UE) . CE indikují, že v paměti RAM se vyskytly chyby, ale hardware je dokázal opravit; je vhodné tyto moduly monitorovat, protože je obvykle jen otázkou času, než se z nich stanou neopravitelné chyby. UE často končí panikou jádra, aby se zabránilo vážnému poškození dat.

Pro kontrolu struktury a kapacity paměti vám příkaz `dmidecode -t memory` zobrazí typ modulů (DDR3, DDR4, DDR5), kapacity, obsazené banky a další. A pomocí `dmidecode -t 16` můžete zobrazit maximální kapacitu RAM podporovanou základní deskou, což je užitečné, pokud uvažujete o upgradu.

V oblasti monitorování teploty a vizuální kontroly můžete data o teplotě senzorů a pevných disků podpořit grafickými nástroji, jako jsou psensor nebo xsensors , které zobrazují teplotu v čase a detekují neobvyklé výkyvy nebo zařízení, která jsou trvale na hranici povolené teploty.

Pro diagnostiku disků a USB jednotek je kromě lsblk a fdisk -l pro zobrazení seznamu zařízení velmi užitečné kombinovat:

• df -h y df -i: procento využití prostoru a inodů; můžete mít volné gigabajty, ale 100 % inodů obsazených a systém si bude stále stěžovat na „nedostatek místa“.
• fsck /dev/sdXN -y: vyhledává a opravuje logické chyby v souborových systémech (mimo jiné EXT2/3/4).
• badblocks /dev/my_disk: prohledává vadné sektory a označuje je, aby je systém nepoužíval (před provedením této akce se důrazně doporučuje vytvořit zálohu).

V případě síťové karty patří mezi typické příznaky odpojení, latence nebo nevysvětlitelná ztráta paketů. Pomocí nástroje ethtool můžete zkontrolovat statistiky a pomocí nástroje netstat zkontrolovat míru ztráty paketů (RX-DRP a TX-DRP). Pokud procento ztráty paketů přesáhne přibližně 0,2 % , je výkon sítě zjevně ovlivněn a síťová karta může být vadná nebo špatně podporovaná ovladačem.

Chyby „Disk je plný a místo na disku“: klasická chyba „Na zařízení není místo“

Na mnoha počítačích (zejména na serverech a virtuálních počítačích ) je jedním z nejčastějších problémů úplné zaplnění systémového disku. Když k tomu dojde, služby, protokoly, bootovací procesy a dokonce i samotné jádro začnou hlásit chyby I/O.

V prostředích, jako je Azure, se v konzoli nebo v diagnostice spouštění běžné zobrazují zprávy, jako je tato:

• Na zařízení nezbývá místo v cloud-init, což může zabránit virtuálnímu počítači v dokončení spouštění.
• Opakované zprávy od „Na zařízení nezbývá místo“ které ovlivňují kritické služby, včetně cloudového agenta.
• Chyby v systémových protokolech označující, že nelze zapisovat protokoly auditu nebo sítě.

Pro rychlé nalezení toho, co zabírá daný prostor, můžete použít příkazy jako například:

• du -ks /* | sort -n: vypíše kořenové adresáře seřazené podle velikosti; opakuje se v rámci těch nejtěžších, dokud není nalezen skutečný viník.
• ls -altSr /var/log: zobrazuje soubory protokolů seřazené podle velikosti od nejmenšího po největší; často uvidíte obrovské staré protokoly, které lze otáčet nebo mazat.
• najít / -size +500M -exec ls -alFh {} \;: vyhledávat velké jednotlivé soubory; upravte těchto 500 MB dle potřeby.

Kromě typického vyplňování /var/log nebo /tmp existují bezpečnostní konfigurace, jako například auditováno které mohou způsobit vypnutí stroje nebo jeho nespuštění, když dochází místo v /var/log/audit. Pokud v /etc/audit/auditd.conf ty máš:

admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT

Systém se může kontrolovaně vypnout nebo odmítnout spustit, pokud nemůže zapisovat do protokolů auditu. Dočasným řešením je změnit tyto hodnoty na SUSPEND, IGNORE nebo jiné platné možnosti (v tomto kontextu nikdy SINGLE), aby se systém mohl spustit a uvolnit místo . Po vyřešení problému byste se měli vrátit k původním zásadám, pokud je vyžadováno dodržování předpisů.

Pokud není možné věci smazat, protože systém se doslova nespustí, můžete se uchýlit k záchranným režimům : automatickým příkazům pro opravu v cloudu (např. az vm repair v Azure), obnově virtuálních počítačů nebo režimu pro jednoho uživatele, který připojí disk a smaže nepotřebné soubory, dokud nebudete mít alespoň 10 % volného místa v souborovém systému, který hostuje /var/log a zbytek důležitých adresářů.

Poškozené EXT4 a XFS: Jak opravit poškozené souborové systémy

Pokud se při spuštění zobrazí zprávy jako „EXT4-fs error (device sda1)“ , „bad extra_isize“ , „no journal found“ nebo zprávy XFS, jako například „Metadata CRC error detected… Unmount and run xfs_repair“ , nejedná se o jednorázový problém: souborový systém je poškozený a dokud jej neopravíte, počítač se normálně nespustí.

Prvním krokem je identifikovat, které zařízení je postiženo . V bootovacích protokolech se podívejte na text, který se objevuje v závorkách v hláškách jádra: sda1, sdc1, dm-0, dm-2, /dev/mapper/vgname/lvname atd. To vám řekne, zda máte co do činění s přímým oddílem (sdXN) nebo logickým svazkem LVM (dm-N, /dev/vgname/lvname).

Jakmile máte přístup k shellu (nouzový režim, režim pro jednoho uživatele nebo záchranný stroj), spusťte příkaz `lsblk -f` a zobrazí se vám kompletní struktura: disky, oddíly, LVM a typy souborových systémů. Je velmi důležité zde ověřit, zda se jedná o oddíl s typy ext4, xfs, vfat, LVM2_member atd., a nespoléhat se pouze na to, co říká `/etc/fstab`, pokud máte podezření, že by mohl být špatně nakonfigurován.

Pro opravu souborových systémů EXT4 se používá příkaz fsck . Obecně platí:

• Ujistěte se, že je souborový systém nenamontované (pokud se jedná o datový disk) nebo že pracujete ze záchranného prostředí, kde se nepoužívá.
• Oštěp fsck /dev/sdXN o fsck /dev/vgname/lvnameDotazuje se vás, zda chcete opravit nekonzistence, znovu vytvořit inode pro změnu velikosti, upravit počítadla bloků atd.
• Pokud se objeví mnoho otázek, přerušte proces stisknutím klávesy CTRL+C a spusťte jej znovu pomocí fsck -y aby automaticky odpověděl „ano“; tímto způsobem vám nic neunikne.
• Pokud přesunete soubory do ztraceno+nalezenoBudete je muset později zkontrolovat a vrátit je tam, kam patří.
• Spouštějte fsck znovu, dokud výstup neukáže, že souborový systém je čistý.

V případě XFS se jedná o nástroj xfs_repair . Typický pracovní postup je zde:

• Nejprve suchá kontrola: xfs_repair -n /dev/vgname/homelv aby se zjistilo, jaké je poškození, aniž by se cokoli upravovalo.
• Pokud je analýza rozumná, opakujte ji bez -n, aby se systém mohl pokusit o opravu: xfs_repair /dev/vgname/homelv.
• Pokud příkaz hlásí, že souborový systém obsahuje „cenné změny metadat v žurnálu, které je třeba reprodukovat“, zkuste jej připojit: na systémech XFS se mnoho čekajících změn aplikuje právě při připojení. Pokud jste na záchranném virtuálním počítači, můžete to provést například v tomto okamžiku. /recovery.
• Pokud neexistuje jiná cesta a chyby v deníku nejsou opraveny, poslední možností je použít xfs_repair -L Zahodit žurnál a vynutit sestavení, jako by byly použity všechny změny. To může vést ke ztrátě nedávných dat, proto to provádějte pouze jako poslední možnost.

Ve všech případech je důležité si uvědomit, že fsck a xfs_repair nejsou žádná kouzla : opraví strukturu souborového systému, ale ne vždy dokážou obnovit všechna data. Proto je tak důležité mít předchozí zálohy a pokud jste v cloudu nebo na virtuálním počítači, pracovat se snapshotem disku nebo kopií připojenou k záchrannému počítači.

GRUB, UEFI, Secure Boot a další klasické metody spouštění

Když zapnete počítač a ani nevidíte nabídku GRUB, nebo BIOS/UEFI vyhodí chyby jako „Nepodařilo se otevřít \EFI\ubuntu\grubx64.efi - Nenalezen“ a spustí se smyčka při pokusu o spuštění z této položky, problém je téměř jistě ve správci spouštění nebo v konfiguraci firmwaru.

K těmto chybám může dojít po instalaci systému Windows v konfiguraci s duálním bootováním (která často přebírá hlavní hlavní záznam (MBR) nebo přepisuje položky UEFI), po nechtěném smazání oddílu EFI nebo po manipulaci s pořadím bootování v systému BIOS. U moderních notebooků není neobvyklé, že se počítač restartuje ve smyčce, pokud položka UEFI „ubuntu“ odkazuje na soubor, který již neexistuje, a pokouší se jej načíst.

Nejjednodušší způsob, jak opravit nefunkční bootloader GRUB, je spustit systém z Live distribuce (například Ubuntu) a použít nástroj Boot-Repair . Typický postup je:

• Začněte od USB Live a otevřete terminál.
• Přidejte repozitář a aktualizujte: sudo apt-add-repository ppa:yannubuntu/boot-repair && sudo apt update.
• Nainstalujte nástroj: sudo apt install -y boot-repair.
• Spusťte to s boot-repair a vyberte možnost „doporučená oprava“.

Boot-Repair analyzuje oddíly, vyhledává nainstalované systémy, překonfiguruje GRUB, regeneruje konfigurační soubor a v případě potřeby upraví položky UEFI tak, aby se počítač spouštěl z příslušného správce spouštění.

V systémech s povolenými funkcemi UEFI, Secure Boot a Fast Boot existuje několik nekompatibilností, na které je dobré si dát pozor. Ne všechny distribuce správně podporují Secure Boot a některé distribuce určené pro starší hardware s UEFI ani dobře nefungují. Pokud vaše distribuce není podepsaná nebo je bootovací modul nekompatibilní, UEFI může odmítnout načíst jádro.

V těchto případech řešení obvykle zahrnuje přístup k nastavení UEFI, povolení režimu Legacy/CSM pro umožnění klasického bootování ve stylu BIOSu a vypnutí funkce Secure Boot . Pokud však na tomto počítači používáte také Windows 11 nebo chcete migrovat z Windows na Linux , může vypnutí funkce Secure Boot narušit požadavky Windows na bootování. Proto byste měli zvážit, který systém má prioritu, nebo hledat distribuci Linuxu kompatibilní se Secure Bootem, abyste se vyhnuli nutnosti pokaždé přistupovat k BIOSu.

Funkce Rychlé spouštění systému Windows způsobuje problémy i v situacích s duálním bootováním. Při vypnutí systému se zapnutou funkcí Rychlé spouštění se systém Windows úplně nevypne: část jádra zůstane v režimu hibernace na disku, čímž se zablokuje plný přístup k souborovému systému NTFS. Když se Linux pokusí tyto oddíly připojit, může dojít k chybám nebo se systém může dokonce zaseknout. Doporučuje se zakázat funkci Rychlé spouštění v možnostech napájení systému Windows a pokud to váš UEFI umožňuje, i v samotném systému BIOS.

Použití režimů obnovy a vestavěných nástrojů pro opravu

Pokud se GRUB zobrazí, ale váš systém Linux se nespustí, nebo pokud máte podezření, že balíček zůstal nedokončený nebo že byl systém po aktualizaci poškozen, můžete využít pokročilé možnosti GRUBu a režimy obnovy, které jsou součástí většiny distribucí.

Nabídka GRUB obvykle obsahuje položku s názvem „ Pokročilé možnosti “ nebo něco podobného. Uvnitř obvykle uvidíte všechny dostupné verze jádra a pro každou z nich i režim obnovení . Vyberte režim obnovení pro nejnovější verzi (a pokud se to nepodaří, zkuste předchozí verzi).

Režim obnovy vám zobrazí nabídku velmi užitečných nástrojů pro:

• fsckZkontrolujte a opravte souborový systém (podobně jako chkdsk ve Windows).
• čistýUvolněte místo smazáním dočasných souborů a dalších zbývajících souborů.
• dpkgOprava poškozených balíčků, nesplněných závislostí nebo zaseknutých instalací.
• bašta: regenerovat konfiguraci bootovacího manažeru.

Spuštění těchto možností v daném pořadí obvykle vyřeší mnoho problémů způsobených výpadky napájení během aktualizací, poškozenými balíčky nebo disky, které se chystaly zaplnit . Poté systém obvykle nabídne restart, aby zkontroloval, zda se proces spouštění vrátil do normálu.

V cloudech, jako je Azure , máte kromě nouzových a jednouživatelských režimů k dispozici specifické nástroje, jako je Azure Linux Automatic Repair (ALAR) a příkaz az vm repair , které automatizují část procesu: připojují systémový disk v záchranném virtuálním počítači, spouštějí akce jako „auditd“ k opravě typických konfigurací a umožňují snadné obnovení, pokud se něco pokazí.

Strategie pro přeinstalaci Linuxu bez ztráty dat

Existují situace, kdy bez ohledu na to, jak moc pátráte, je systém tak poškozený nebo váš hardware tak neobvyklý (jako například HP N150 nebo moderní notebooky s exotickými řadiči), že nejrozumnější je přeinstalovat distribuci . To však nutně neznamená ztrátu všech dat.

Mnoho distribucí, jako například Ubuntu a jeho deriváty, nabízí během instalace možnost s názvem „přeinstalovat operační systém se zachováním dokumentů a nastavení “. Tato funkce přeinstaluje základní systém, ale pokusí se zachovat váš adresář /home a někdy i některé nainstalované aplikace. Je to pohodlná možnost, i když ne zcela spolehlivá, proto je vhodné ručně zálohovat vše, o co nechcete přijít.

Nejspolehlivějším způsobem ochrany před budoucími reinstalacemi je uspořádání disku do několika samostatných oddílů :

• Jeden pro / (kořen)základní systém.
• Další pro / boot (a /boot/efi v UEFI), pokud chcete mít větší kontrolu nad bootováním.
• Exkluzivní sekce pro / Home nebo pro data.

Tímto způsobem, pokud se váš systém Linux stane nepoužitelným, můžete formátovat pouze systémový a bootovací oddíl a datový oddíl ponechat nedotčený . I když máte pouze jeden oddíl pro všechno, můžete bootovat z živého prostředí, připojit disk, kopírovat dokumenty na externí disk nebo do cloudu a poté, jakmile je vše v bezpečí, provést čistou instalaci.

Ve virtuálních strojích, ať už z VirtualBoxu, VMware nebo cloudu, je vhodné oddělit datové disky od systémového disku . Například v Azure se doporučuje, aby datové svazky LVM nebyly míchány ve stejné skupině svazků jako systémový disk, aby se zabránilo ovlivnění dat selháním operačního systému.

Nejlepší postupy pro prevenci opakování problémů

Jakmile se vypořádáte s nefunkčním bootováním a obnovíte systém (nebo alespoň data), je chytré podniknout určité kroky, abyste příště tento strach zmírnili nebo mu úplně zabránili.

Prvním je udržovat systém a software aktuální , ale dělejte to rozumně. V postupně vydávaných distribucích, jako je Arch, jsou časté aktualizace nezbytné; v konzervativnějších (Debian Stable, Ubuntu LTS) je můžete trochu rozložit, ale nedoporučuje se je nechávat roky beze změny. Před většími změnami jádra nebo verze si vždy vytvořte slušnou zálohu.

Dalším velmi zdravým zvykem je dokumentovat všechny hlavní změny konfigurace: kterého souboru jste se dotkli, který řádek jste změnili a jak to vypadalo předtím. Jednoduchý trik je vždy uložit kopii původního souboru s příponou. BAK (například sshd_config.bak), abyste ho mohli snadno opravit, pokud ho pokazíte.

Pokud jde o data, pravidelné zálohy jsou nezbytné . Můžete použít rsync pro inkrementální zálohy, tar pro zabalení celých adresářů nebo cloudová a NAS řešení. Navíc, pokud jsou vaše data na jiném oddílu než systémový oddíl, můžete systém bez větších problémů znovu nainstalovat, i když se disk nespustí.

Konečně je vždy dobré pravidelně sledovat stav systému: měsíčně kontrolovat SMART, sledovat inody a volné místo na kritických oddílech (/, /var, /home), prohlížet si protokoly, zda se v nich neobjevují opakující se zprávy, a udržovat nízkou teplotu a prašnost na fyzickém zařízení. Jednoduchá rutina údržby ušetří mnoho ranních oprav počítačů, které se „náhle“ přestaly bootovat.

S tímto arzenálem technik, příkazů a osvědčených postupů přestává být diagnostika a oprava problémů se spouštěním a hardwarových chyb v Linuxu aktem víry a stává se poměrně rozumným procesem: nejprve zjistíte, zda je selhání způsobeno diskem, souborovým systémem, GRUBem, jádrem, konfigurací nebo hardwarem; poté použijete vhodný nástroj (fsck, xfs_repair, Boot-Repair, smartctl, MemTest, režimy obnovy atd.); a v nejhorším případě máte dobře organizovaný plán B se samostatnými oddíly a zálohami, které vám umožní provést přeinstalaci bez konce světa.