Diagnosi dei problemi di avvio di Linux e dei guasti hardware

Informatec Digital » Risorse » Diagnosi dei problemi di avvio di Linux e dei guasti hardware

Quando un sistema Linux non si avvia o inizia a comportarsi in modo anomalo, la reazione naturale è pensare che "Linux sia guasto". In pratica, tuttavia, il più delle volte i problemi di fondo sono errori di configurazione, dischi pieni, danneggiamento del file system o problemi hardware che possono essere individuati con un po' di metodo. Lo scopo di questo articolo è proprio questo: dimostrare una procedura chiara, supportata da comandi specifici, per diagnosticare e riparare i problemi di avvio e hardware più comuni in Linux, sia su macchine fisiche che virtuali.

Se ti imbatti in messaggi come "file system root non trovato", "Spazio insufficiente sul dispositivo", "Errore EXT4-fs", "XFS: errore CRC dei metadati" o il temuto Kernel Panic , qui imparerai come interpretarli, quali comandi utilizzare e in quale ordine agire. Vedremo anche come determinare se il problema è effettivamente legato al software o se l'hardware (RAM, SSD/HDD, scheda di rete, ecc.) è ormai obsoleto e come ridurre al minimo il rischio di perdita di dati durante la risoluzione dei problemi.

Cause tipiche dei problemi di avvio in Linux

Prima di iniziare a smanettare a caso, è una buona idea capire le ragioni più comuni per cui Linux potrebbe non avviarsi o avviarsi in modo errato . Capire la causa principale ti farà risparmiare ore di risoluzione dei problemi e tentativi di soluzioni che non portano a nulla.

La prima serie di problemi deriva dal boot manager e dalla configurazione del BIOS/UEFI : voci GRUB generate in modo errato, un MBR sovrascritto dopo l'installazione di Windows in una configurazione dual boot , Secure Boot incompatibile con la distribuzione in uso o il BIOS che tenta di avviare il sistema dal disco sbagliato. In questi casi, spesso non si visualizza nemmeno il menu GRUB, oppure, quando si seleziona la distribuzione Linux, il sistema si blocca o torna al firmware.

Un altro blocco importante riguarda il disco e file systemPartizioni danneggiate, settori corrotti, corruzione di EXT4 o XFS, dischi di sistema pieni o errori LVM. Questo di solito si manifesta con messaggi durante l'avvio come "Impossibile montare /…","errore EXT4-fs","XFS: Smontare ed eseguire xfs_repair"o addirittura finire in modalità di emergenza chiedendoti di eseguire journalctl -xb.

I problemi sono molto comuni anche dopo un aggiornamento del kernel o una patch applicata in modo errato . Download incompleti, moduli non caricati, driver non più compatibili con l'hardware o modifiche all'initramfs possono causare il blocco del sistema durante l'avvio o provocare un Kernel Panic all'avvio.

Non dobbiamo dimenticare la sezione relativa alla configurazione del sistema stesso : regole di avvio sicuro eccessivamente restrittive (ad esempio, auditd configurato con HALT quando /var/log/audit è pieno), servizi critici che falliscono per mancanza di spazio o modifiche ai file di configurazione che impediscono l'avvio di daemon essenziali (rete, systemd, cloud-init in cloud come Azure, ecc.).

Infine, c'è il livello hardware: dischi con flag SMART rossi, RAM con errori ECC, schede di rete che perdono pacchetti o SSD che si surriscaldano . Spesso, l'indizio si trova nei messaggi del kernel (dmesg) o nei contatori SMART ed EDAC, quindi vedremo come leggerli attentamente.

Come identificare la causa del problema di avviamento

La chiave per evitare avvii alla cieca è abilitare la modalità di avvio dettagliata e analizzare i log . Di default, molte distribuzioni mostrano una schermata iniziale accattivante che nasconde i messaggi, il che è esteticamente gradevole ma non è di alcun aiuto quando qualcosa va storto.

Sui sistemi che utilizzano GRUB, è possibile disabilitare la modalità silenziosa modificando il file /etc/default/grub . Cercare la riga:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

e sostituirlo con:

GRUB_CMDLINE_LINUX_DEFAULT=""

Successivamente, esegui `update-grub` (o il comando equivalente nella tua distribuzione) per rigenerare la configurazione. Al successivo avvio, vedrai tutti i messaggi del kernel e di systemd visualizzati, il che ti permetterà di individuare l'errore esatto che ha causato il blocco del sistema.

Se il sistema riesce ad avviarsi parzialmente o se è possibile accedervi da un ambiente di produzione, saranno disponibili diversi log importanti in /var/log :

• /var/log/boot.logRegistra tutto ciò che accade durante la fase di avvio; se il problema si verifica in questa fase, è il primo punto da controllare.
• / var / log / messages o / Var / log / syslog (a seconda della distribuzione): eventi di sistema generali, molto utili per visualizzare gli errori nei servizi, nei daemon, ecc.
• dmesg: visualizza i messaggi del kernel, inclusi guasti hardware, problemi dei moduli, errori del bus, errori PCI, ecc.
• journalctlNei sistemi che utilizzano systemd, è lo strumento di base per attraversare l'intero registro; con journalctl -xb Potrete ammirare la partenza finale in tutto il suo splendore.

Se il sistema non raggiunge il desktop ma accede a una TTY o alla modalità di ripristino, è possibile eseguire `journalctl -xb` direttamente da lì. Se ciò non funziona, sarà necessario avviare il sistema da una Live USB , montare il disco di sistema e leggere i file dall'ambiente live.

Verifica se il problema è di natura hardware o software.

Prima di iniziare a scervellarti modificando le configurazioni, vale la pena verificare se il problema non risieda direttamente nell'hardware : disco, memoria, CPU, scheda madre o alimentatore . Molte installazioni che si corrompono "casualmente" in realtà rivelano un SSD difettoso o una RAM malfunzionante.

Il primo passo, se il computer non riconosce nemmeno l'unità, è accedere al BIOS/UEFI e verificare che l'unità sia presente nell'elenco. Se l'unità non viene visualizzata affatto, o viene visualizzata solo a intermittenza, controllare i collegamenti, i cavi SATA e l'alimentatore, oppure presumere che l'unità debba essere smaltita.

Se riesci ad accedere a GRUB o a un avvio Live, puoi avviare MemTest86+ dal menu di GRUB per controllare la RAM. Lascia che il test venga eseguito per almeno otto cicli; se vedi delle linee rosse, la memoria è difettosa e i moduli devono essere sostituiti. Una RAM difettosa è un terreno fertile per la corruzione dei dati.

Per verificare lo stato dei dischi in Linux, utilizzare smartmontools . Dopo averlo installato, abilitare SMART e analizzare gli attributi più importanti:

• Settore_trasferito_Ct: numero di settori riassegnati; se è maggiore di 0, quel disco ha già iniziato ad avere settori danneggiati.
• Settore_in_attesa_corrente_Ct: settori in attesa di riassegnazione; qualsiasi valore superiore a 0 indica un alto rischio di guasto imminente.
• Ore di accensione: ore di utilizzo accumulate; maggiore è il numero, maggiore è la probabilità di guasto del disco.

Utilizzando il comando `smartctl -H /dev/sdX` è possibile verificare rapidamente se il disco supera o meno il test di integrità. Se il risultato non è SUPERATO, è necessario eseguire un backup dei dati il ​​prima possibile e iniziare a valutare la sostituzione del disco.

Se sospetti temperature elevate, installa lm-sensori e corri sensors (o watch -n 2 sensors (per visualizzarlo in tempo reale). Per SSD e unità SATA, prima hddtemp Mostra la temperatura attuale, permettendoti di individuare le unità che presentano picchi di temperatura anche quando sono inattive, utile per... ottimizzazione del server.

Diagnostica hardware specializzata in Linux

Oltre a CPU, RAM e disco, Linux dispone di strumenti specifici per valutare la memoria ECC, le schede di rete, le GPU e altri componenti . Dedicare qualche minuto al controllo di questi elementi può farvi risparmiare molte ore di debug.

Se il server o la workstation dispone di memoria ECC , il kernel in genere registra gli errori corretti e non corretti utilizzando EDAC. Un semplice:

dmesg | grep EDAC

Consente di verificare la presenza di errori corretti (CE) o errori non corretti (UE) . Gli errori corretti (CE) indicano che la RAM ha subito dei guasti, ma l'hardware è stato in grado di correggerli; è consigliabile monitorare questi moduli perché di solito è solo questione di tempo prima che si trasformino in errori non correggibili. Gli errori non corretti (UE) spesso terminano con un Kernel Panic per prevenire gravi danneggiamenti dei dati.

Per verificare la struttura e la capacità della memoria, il comando `dmidecode -t memory` mostra il tipo di moduli (DDR3, DDR4, DDR5), le capacità, i banchi occupati e altro ancora. Con `dmidecode -t 16` è possibile visualizzare la capacità massima di RAM supportata dalla scheda madre, utile se si sta pensando di effettuare un aggiornamento.

Nell'ambito del monitoraggio della temperatura e della visualizzazione, è possibile integrare i dati dei sensori e della temperatura degli HDD con strumenti grafici come psensor o xsensors , che tracciano l'andamento della temperatura nel tempo per rilevare picchi anomali o apparecchiature che si trovano costantemente al limite di temperatura.

Per diagnosticare dischi e unità USB , oltre a lsblk e fdisk -l per elencare i dispositivi, è molto utile combinare:

• df -h y df -iPercentuale di spazio e utilizzo degli inode; è possibile avere gigabyte liberi ma il 100% degli inode occupati e il sistema continuerà a segnalare "spazio insufficiente".
• fsck /dev/sdXN -y: ricerca e corregge gli errori logici nei file system (EXT2/3/4, tra gli altri).
• badblocks /dev/my_disk: esegue la scansione dei settori difettosi e li contrassegna in modo che il sistema non li utilizzi (si consiglia vivamente di effettuare un backup prima di procedere).

Nel caso di una scheda di rete , i sintomi tipici includono disconnessioni, latenza o perdita di pacchetti inspiegabile. È possibile utilizzare ethtool per analizzare le statistiche e netstat per verificare i tassi di perdita di pacchetti (RX-DRP e TX-DRP). Se la percentuale di perdita di pacchetti supera lo 0,2% circa , le prestazioni di rete risultano chiaramente compromesse e la scheda di rete potrebbe essere difettosa o non adeguatamente supportata dal driver.

Disco pieno ed errori di spazio: il classico "Spazio insufficiente sul dispositivo"

Su molte macchine (soprattutto server e macchine virtuali ), uno dei problemi più comuni è il riempimento completo del disco di sistema. Quando ciò accade, servizi, file di log, processi di avvio e persino il kernel stesso iniziano a generare errori di I/O.

In ambienti come Azure, è comune visualizzare messaggi di questo tipo nella console o nella diagnostica di avvio:

• Nessuno spazio rimasto sul dispositivo in cloud-init, che può impedire alla macchina virtuale di completare l'avvio.
• Messaggi ripetuti da “Non c’è più spazio sul dispositivo” che influiscono sui servizi critici, incluso l'agente cloud.
• Errori nei registri di sistema che indicano l'impossibilità di scrivere nei registri di controllo o di rete.

Per individuare rapidamente cosa occupa lo spazio, è possibile utilizzare comandi come:

• du -ks /* | sort -n: elenca le directory radice ordinate per dimensione; ripete il processo all'interno di quelle più pesanti finché non viene individuato il vero colpevole.
• ls -altSr /var/log: visualizza i file di registro ordinati per dimensione, dal più piccolo al più grande; spesso vedrai file di registro vecchi e di grandi dimensioni che possono essere ruotati o eliminati.
• trova / -dimensione +500M -esegui ls -alFh {} \;: cerca file individuali di grandi dimensioni; regola quel valore di 500 MB se necessario.

Oltre al tipico riempimento di /var/log o /tmp, esistono configurazioni di sicurezza come auditd che può causare lo spegnimento o l'impossibilità di avviare una macchina quando lo spazio in /var/log/audit è esaurito. Se in /etc/audit/auditd.conf hai:

admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT

Il sistema potrebbe arrestarsi in modo controllato o rifiutarsi di avviarsi se non riesce a scrivere nei log di controllo. Una soluzione temporanea consiste nel modificare questi valori in SUSPEND, IGNORE o altre opzioni valide (mai SINGLE in questo contesto) per consentire l'avvio del sistema e liberare spazio . Dopo aver risolto il problema, è necessario ripristinare i criteri originali se è richiesto il rispetto delle normative.

Quando non è possibile eliminare i file perché il sistema non si avvia, si può ricorrere alle modalità di ripristino : comandi di ripristino automatico del cloud (ad esempio, `az vm repair` in Azure), macchine virtuali di ripristino o modalità utente singolo per montare il disco ed eliminare i file non necessari fino a quando non si dispone di almeno il 10% di spazio libero nel file system che ospita `/var/log` e le altre directory critiche.

File system EXT4 e XFS danneggiati: come riparare i file system corrotti

Se all'avvio visualizzi messaggi come "EXT4-fs error (device sda1)" , "bad extra_isize" , "no journal found" o messaggi XFS come "Metadata CRC error detected… Unmount and run xfs_repair" , non si tratta di un problema isolato: il file system è danneggiato e finché non lo ripari, la macchina non si avvierà normalmente.

Il primo passo consiste nell'identificare il dispositivo interessato . Nei log di avvio, osserva il testo che appare tra parentesi nei messaggi del kernel: sda1, sdc1, dm-0, dm-2, /dev/mapper/vgname/lvname, ecc. Questo ti dirà se hai a che fare con una partizione diretta (sdXN) o un volume logico LVM (dm-N, /dev/vgname/lvname).

Una volta ottenuto l'accesso a una shell (modalità di emergenza, utente singolo o macchina di ripristino), esegui `lsblk -f` per visualizzare la struttura completa: dischi, partizioni, LVM e tipi di filesystem. È molto importante verificare in questa fase se la partizione è effettivamente ext4, xfs, vfat, LVM2_member , ecc., e non affidarsi esclusivamente a quanto riportato in `/etc/fstab` se si sospetta una configurazione errata.

Per riparare i file system EXT4 si utilizza fsck . Come regola generale:

• Assicurati che il file system sia smontato (se si tratta di un disco dati) oppure che si stia lavorando da un ambiente di ripristino in cui non è in uso.
• lancia fsck /dev/sdXN o fsck /dev/vgname/lvnameTi verrà chiesto se desideri correggere le incongruenze, ricreare l'inode di ridimensionamento, regolare i contatori dei blocchi, ecc.
• Se compaiono molte domande, interrompi con CTRL+C ed esegui di nuovo con fsck -y in modo che risponda automaticamente "sì"; così non ti perdi nulla.
• Se sposti i file su perso + trovatoDovrai controllarli più tardi e rimetterli al loro posto.
• Eseguire nuovamente fsck finché l'output non indica che il file system è cavedano.

Nel caso di XFS , lo strumento è xfs_repair . Il flusso di lavoro tipico è il seguente:

• Innanzitutto, un controllo a secco: xfs_repair -n /dev/vgname/homelv per verificare l'entità dei danni senza apportare modifiche.
• Se l'analisi è ragionevole, ripetere senza -n in modo che possa tentare di correggerla: xfs_repair /dev/vgname/homelv.
• Se il comando segnala che il filesystem contiene "modifiche ai metadati importanti in un journal che devono essere riprodotte", prova a montarlo: sui sistemi XFS, molte modifiche in sospeso vengono applicate proprio al momento del montaggio. Se ti trovi su una macchina virtuale di ripristino, puoi farlo in un punto come /recovery.
• Se non c'è altro modo e gli errori del registro non vengono corretti, l'ultima risorsa è usare xfs_repair -L Eliminare il file di log e forzare l'assemblaggio come se tutte le modifiche fossero state applicate. Ciò potrebbe comportare la perdita dei dati recenti, quindi procedere solo come ultima risorsa.

In ogni caso, è fondamentale capire che fsck e xfs_repair non sono magici : riparano la struttura del file system, ma non sempre riescono a recuperare tutti i dati. Ecco perché è così importante avere backup precedenti e, se ci si trova nel cloud o su una macchina virtuale, lavorare da uno snapshot del disco o da una copia collegata a una macchina di ripristino.

GRUB, UEFI, Secure Boot e altri classici di avvio

Quando accendi il computer e non vedi nemmeno il menu GRUB, oppure il BIOS/UEFI restituisce errori come "Impossibile aprire \EFI\ubuntu\grubx64.efi - Non trovato" ed entra in un ciclo infinito tentando di avviare da quella voce, il problema risiede quasi certamente nel boot manager o nella configurazione del firmware.

Questi errori possono verificarsi dopo l'installazione di Windows in una configurazione dual-boot (che spesso sovrascrive l'MBR o le voci UEFI), dopo la cancellazione accidentale di una partizione EFI o dopo aver modificato l'ordine di avvio nel BIOS. Nei laptop moderni, non è raro che il computer si riavvii in un ciclo infinito se la voce UEFI "ubuntu" punta a un file inesistente, tentando di caricarlo.

Il modo più semplice per riparare un bootloader GRUB danneggiato è avviare il sistema da una distribuzione Live (ad esempio, Ubuntu) e utilizzare lo strumento Boot-Repair . La procedura tipica è la seguente:

• Parti da un USB Live e aprire un terminale.
• Aggiungi il repository e aggiorna: sudo apt-add-repository ppa:yannubuntu/boot-repair && sudo apt update.
• Installa lo strumento: sudo apt install -y boot-repair.
• Eseguilo con boot-repair e scegli l'opzione “riparazione consigliata”.

Boot-Repair analizza le partizioni, individua i sistemi installati, riconfigura GRUB, rigenera il file di configurazione e, se necessario, regola le voci UEFI in modo che il computer si avvii dal boot manager appropriato.

Sui sistemi con UEFI, Secure Boot e Fast Boot abilitati, è importante essere a conoscenza di diverse incompatibilità. Non tutte le distribuzioni supportano correttamente Secure Boot e alcune progettate per hardware più datato non funzionano bene nemmeno con UEFI. Se la distribuzione non è firmata o il boot shim è incompatibile, UEFI potrebbe rifiutarsi di caricare il kernel.

In questi casi, la soluzione di solito prevede l'accesso alle impostazioni UEFI, l'attivazione della modalità Legacy/CSM per consentire l'avvio classico in stile BIOS e la disabilitazione di Secure Boot . Tuttavia, se sul computer si utilizza anche Windows 11 o si desidera migrare da Windows a Linux , la disabilitazione di Secure Boot potrebbe compromettere i requisiti di avvio di Windows. Pertanto, è necessario valutare quale sistema ha la priorità o cercare una distribuzione Linux compatibile con Secure Boot per evitare di dover accedere al BIOS ogni volta.

L'avvio rapido di Windows causa problemi anche negli scenari di dual-boot. Quando si spegne il computer con l'avvio rapido abilitato, Windows non si spegne completamente: lascia parte del kernel ibernato sul disco, bloccando l'accesso completo al file system NTFS. Quando Linux tenta di montare queste partizioni, potrebbero verificarsi errori o il sistema potrebbe addirittura bloccarsi. Si consiglia di disabilitare l'avvio rapido sia nelle opzioni di risparmio energia di Windows sia, se l'UEFI lo consente, nel BIOS stesso.

Utilizzo delle modalità di ripristino e degli strumenti di riparazione integrati

Se GRUB viene visualizzato ma il sistema Linux non si avvia, oppure se sospetti che un pacchetto non sia stato completato correttamente o che il sistema sia stato danneggiato dopo un aggiornamento, puoi sfruttare le opzioni avanzate di GRUB e le modalità di ripristino incluse nella maggior parte delle distribuzioni.

Il menu di GRUB di solito ha una voce chiamata " Opzioni avanzate " o qualcosa di simile. Al suo interno, in genere vedrai tutte le versioni del kernel disponibili e, per ognuna, una modalità di ripristino . Seleziona la modalità di ripristino per la versione più recente (e se non funziona, prova quella precedente).

La modalità di ripristino mostra un menu di utilità molto utili per:

• fsck: Verifica e ripara il file system (simile a chkdsk in Windows).
• cavedano: libera spazio eliminando i file temporanei e altri file residui.
• dpkg: correggere pacchetti danneggiati, dipendenze non soddisfatte o installazioni bloccate.
• larva: rigenera la configurazione del gestore di avvio.

L'esecuzione di queste opzioni in ordine solitamente risolve molti problemi causati da interruzioni di corrente durante gli aggiornamenti, pacchetti danneggiati o dischi che stavano per riempirsi . Successivamente, il sistema in genere offrirà di riavviarsi per verificare se il processo di avvio è tornato alla normalità.

In ambienti cloud come Azure , oltre alle modalità di emergenza e a utente singolo, sono disponibili strumenti specifici come Azure Linux Automatic Repair (ALAR) e il comando az vm repair , che automatizzano parte del processo: montano il disco di sistema in una macchina virtuale di ripristino, eseguono azioni come "auditd" per correggere le configurazioni tipiche e consentono di ripristinare facilmente lo stato precedente in caso di problemi.

Strategie per reinstallare Linux senza perdere dati

Ci sono situazioni in cui, per quanto ci si impegni nelle indagini, il sistema è talmente corrotto o l'hardware è talmente insolito (come nel caso dell'HP N150 o dei moderni portatili con controller particolari) che la cosa più sensata da fare è reinstallare la distribuzione . Tuttavia, questo non significa necessariamente perdere tutti i dati.

Molte distribuzioni, come Ubuntu e le sue derivate, offrono durante l'installazione un'opzione chiamata "reinstalla il sistema operativo mantenendo documenti e impostazioni ". Questa opzione reinstalla il sistema di base, ma tenta di preservare la directory /home e, a volte, anche alcune applicazioni installate. È un'opzione comoda, sebbene non infallibile, quindi è consigliabile eseguire manualmente un backup di tutto ciò che non si desidera perdere.

Il metodo più efficace per proteggersi da future reinstallazioni è organizzare il disco in diverse partizioni separate :

• Uno per / (radice): sistema di base.
• Un altro per /avvio (e /boot/efi in UEFI) se si desidera un maggiore controllo sull'avvio.
• Una sezione esclusiva per / Home o per i dati.

In questo modo, se il tuo sistema Linux diventa inutilizzabile, puoi formattare solo le partizioni di sistema e di avvio, lasciando intatta la partizione dati . Anche se hai una sola partizione per tutto, puoi avviare da un ambiente Live, montare il disco, copiare i documenti su un'unità esterna o sul cloud e poi, una volta che tutto è al sicuro, eseguire un'installazione pulita.

Nelle macchine virtuali, siano esse di VirtualBox, VMware o del cloud, è buona norma separare i dischi dati dal disco di sistema . In Azure, ad esempio, si raccomanda di non includere i volumi dati LVM nello stesso gruppo di volumi del disco di sistema, per evitare che un errore del sistema operativo comprometta anche i dati.

Le migliori pratiche per prevenire il ripetersi dei problemi

Una volta risolto il problema dell'avvio non riuscito e recuperato il sistema (o almeno i dati), la cosa più saggia da fare è adottare alcune misure per rendere la prossima volta lo spavento meno grave o per evitarlo del tutto.

Il primo consiglio è quello di mantenere aggiornati sistema e software , ma con criterio. Nelle distribuzioni rolling release come Arch, gli aggiornamenti frequenti sono essenziali; in quelle più conservative (Debian Stable, Ubuntu LTS) è possibile distanziarli un po', ma non è consigliabile lasciarli invariati per anni. Prima di apportare modifiche importanti al kernel o alla versione, effettuate sempre un backup completo.

Un'altra abitudine molto salutare è documentare eventuali modifiche di configurazione importanti: quale file hai modificato, quale riga hai cambiato e com'era prima. Un semplice trucco è salvare sempre una copia del file originale con il suffisso. .bak (per esempio, sshd_config.bak) così puoi ripristinarlo facilmente se lo combini pasticci.

Per quanto riguarda i dati, i backup regolari sono essenziali . È possibile utilizzare rsync per i backup incrementali, tar per comprimere intere directory, oppure soluzioni cloud e NAS. Inoltre, se i dati si trovano su una partizione diversa da quella di sistema, è possibile reinstallare il sistema operativo senza troppi problemi anche se il disco non si avvia.

Infine, è sempre una buona idea monitorare regolarmente lo stato di salute del sistema: eseguire un controllo SMART mensile, monitorare gli inode e lo spazio libero sulle partizioni critiche (/, /var, /home), esaminare i log per individuare messaggi ripetitivi e mantenere basse le temperature e i livelli di polvere sulle apparecchiature fisiche. Una semplice routine di manutenzione evita molte mattine in cui si deve intervenire su macchine che hanno "improvvisamente" smesso di avviarsi.

Con questo arsenale di tecniche, comandi e best practice, diagnosticare e riparare i problemi di avvio e gli errori hardware in Linux smette di essere un atto di fede e diventa un processo piuttosto razionale: prima si identifica se il problema è dovuto al disco, al file system, a GRUB, al kernel, alla configurazione o all'hardware; poi si applica lo strumento appropriato (fsck, xfs_repair, Boot-Repair, smartctl, MemTest, modalità di ripristino, ecc.); e, nel peggiore dei casi, si ha un piano B ben organizzato con partizioni separate e backup che consentono di reinstallare il sistema senza che il mondo finisca.