Come risolvere un problema di avvio causato da una configurazione fstab errata da GRUB

Quando un sistema GNU/Linux non si avvia o impiega un'eternità ad avviarsi, molti pensano subito di reinstallare la distribuzione. Tuttavia, in un'altissima percentuale di casi, il problema ha una causa specifica: errori in /etc/fstab o nel bootloader GRUBLa buona notizia è che, con un po' di pazienza e seguendo una serie di passaggi, è possibile ripristinare il sistema senza perdere dati.

In questa guida vedremo, in modo pratico, come Rileva e correggi un problema di avvio causato da una configurazione fstab errata da GRUBInizieremo con esempi concreti (macchine fisiche, VM su Google Cloud e Azure e persino dual boot con Windows). Esamineremo anche altri comuni errori di avvio di Linux e come gestirli senza impazzire.

Che cos'è fstab e perché potrebbe impedire l'avvio del sistema Linux?

il file /etc/fstab È una tabella di configurazione in cui è definito quali file system vengono montati all'avvio, in quale punto di montaggio, con quali opzioni e in quale ordineSi tratta di un file statico che il sistema legge durante l'avvio; se qualcosa non va, il kernel e systemd possono bloccarsi in attesa di dispositivi che non esistono o non rispondono.

Un errore molto tipico è che, dopo formatear o disconnettere un disco, fstab continua a puntare a una partizione o UUID inesistenteIl risultato è un messaggio come questo:

Timed out waiting for device dev-incorrect.device
Dependency failed for /data
Dependency failed for Local File Systems
Welcome to emergency mode!

Nelle macchine virtuali (Google Cloud, Azure, ecc.) il sintomo è quasi identico: il kernel tenta di montare un file system definito in fstab per un punto come /dati o /distribuzioneNon riesce a trovarlo, finisce. il tempo Il sistema entra in modalità di emergenza e chiede la password. radice o lasciarti bloccato in GRUB.

Inoltre, una singola opzione scritta in modo errato può bloccare la tua startup. Ad esempio, invece di usare errori=rimontare-ro (che imposta la radice in sola lettura se ci sono errori), qualcuno scrive errori=remount-rwQuesta opzione non è valida e può causare comportamenti anomali, da errori di montaggio a sistemi che si avviano in modo intermittente o si bloccano durante il processo di avvio.

Esempi reali di errori di avvio causati da fstab e GRUB

Per comprendere appieno il problema, è utile esaminare alcuni casi reali che riassumono quasi tutto ciò che può andare storto con fstab e GRUB su un sistema Linux desktop o server.

Nel primo caso, un utente installa Linux Mint su un HDD da 1 TB, quindi si rende conto che desidera il sistema su SSDreinstallare sull'SSD e formattare il vecchio HDDIl sistema impiega circa due minuti per avviarsi, si blocca dopo GRUB e il logo di Mint, visualizza un messaggio di modalità di emergenza e infine si avvia. Dopo aver indagato, scopre che nel suo file fstab c'è una riga:

UUID=745C-ACA6 /boot/efi vfat umask=0077 0 1

Il problema è questo Quell'UUID non esiste più e la partizione /dev/sda2 è scomparsa Durante la riconfigurazione dei dischi, la voce rimane. Il sistema tenta di montare la partizione EFI che non è più presente, attende, la dipendenza fallisce, da qui il ritardo e la modalità di emergenza.

In un altro caso, qualcuno collega un'unità esterna, lascia che uno strumento grafico aggiorni fstab per montarla automaticamente, quindi la disconnette o la riformatta. Al riavvio successivo, il sistema si blocca perché fstab contiene una voce che punta a un dispositivo USB che non esiste più., senza l'opzione appropriata per consentire l'avvio in caso di errore.

Inoltre, questa stessa persona trova la radice montata con l'opzione errori=remount-rw al posto di errori=rimontare-roDopo aver modificato manualmente in "ro", riesce ad avviarsi, ma ogni volta che si tocca il disco esterno e si aggiorna fstab, il problema si ripresenta: la nuova voce viene aggiunta, il sistema non viene montato correttamente, fstab rimane in sola lettura e non può salvare le modifiche senza rimappare il file system in lettura-scrittura.

Negli ambienti cloud come Google Cloud o Azure, lo schema si ripete: viene aggiunto un disco dati extra, definito in /etc/fstab Utilizzando un dispositivo o UUID, il disco viene cancellato o disconnesso e al successivo avvio La VM si blocca in modalità di emergenza con un messaggio di dipendenza non riuscita per /data, /distribution o simili. Qui, la differenza è che il problema viene solitamente risolto utilizzando serie di console, modalità utente singolo o addirittura strumenti di riparazione automatica (come Azure Linux Auto Repair, ALAR).

Sintomi tipici di un fstab danneggiato e come identificarli da GRUB

Quando il colpevole è fstab, durante l'avvio si noteranno quasi sempre alcuni di questi sintomi:

• Lunga sosta dopo GRUB, con la schermata che mostra i messaggi del kernel e systemd che tenta di montare i file system.
• Messaggi del tipo "Timeout in attesa del dispositivo..." e "Dipendenza fallita per /data", "Dipendenza fallita per file system locali".
• Entrata in modalità di emergenza, che chiede la password di root o ti offre comandi come journalctl -xb, systemctl reboot o systemctl default.
• In alcune distribuzioni, l'opzione di premere Ctrl + D per continuare e per avviare il sistema, ma con alcuni file system non montati.

Se vedi solo il logo della distribuzione o un'animazione di avvio, è altamente consigliato abilitare l'opzione umore prolissoPer fare ciò, puoi modificare temporaneamente una voce di GRUB nel menu stesso o modificare il file /etc/default/grub quando hai accesso:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" → GRUB_CMDLINE_LINUX_DEFAULT=""

Poi esegui update-grubAl successivo avvio, il sistema visualizzerà tutte le linee di avviorendendo più facile vedere esattamente dove si blocca e quale dispositivo sta causando il problema.

Inoltre, per eseguire un'autopsia più approfondita, sono disponibili diversi file di registro molto utili: /var/log/boot.log (messaggi di avvio), / var / log / messages (registro generale), dmesg (messaggi del kernel) e journalctlSe il sistema non si avvia più, è possibile avviarlo con un CD live o una distribuzione Live, monta il disco di sistema e rivedi quei file da lì e applica tecniche di profilazione dell'inizio.

Come risolvere fstab dalla modalità di emergenza o dalla modalità utente singolo

In molte distribuzioni di server e VM, quando fstab fallisce il sistema va direttamente in modalità di emergenzaDa lì, se si dispone di una password di root, è possibile effettuare l'accesso e correggere il file senza bisogno di un Live CD.

I passaggi generali sarebbero:

1. Entra nella console (serie cloud o schermo locale) ed eseguire l'autenticazione come root quando richiesto.
2. Modifica /etc/fstab con il tuo editor preferito: ad esempio, vi /etc/fstab o nano /etc/fstab.
3. Individuare la voce problematica (quella che si riferisce al dispositivo o al punto di montaggio mostrato nel messaggio di errore) e commentalo o correggiloCommentare è semplice come mettere un # all'inizio della riga.
4. Salva le modifiche e esci dall'editor. In vi, ad esempio, ESC + :wq!.
5. corsa mount -a per verificare la presenza di errori di sintassi o di assemblaggio. Se non restituisce nulla di insolito, la configurazione è ragionevole.
6. Ricomincia con reboot e verificare se il sistema si avvia normalmente.

Se non si dispone di una password di root (un caso comune con le immagini cloud), è possibile forzare l' modalità utente singolo Da GRUB o dal boot manager della VM. Il trucco è modificare la riga del kernel in GRUB e aggiungere un parametro extra:

• Su sistemi come RHEL, CentOS, Oracle Linux o SUSE, aggiungi pausa.
• In Ubuntu 18.04, 20.04, 22.04, aggiungi systemd.unit=rescue.target per entrare in modalità di salvataggio.

Una volta in quell'ambiente confinato, bisogna traccia la radice in modalità lettura/scrittura (Per impostazione predefinita, potrebbe essere di sola lettura). Quindi, puoi modificarlo di nuovo. /etc/fstabSi rivedono le voci, si salva e si riavvia. Lo schema è sempre lo stesso: correggere la tabella, controllare con mount -ay restart.

Procedure consigliate per la modifica di /etc/fstab: UUID, nofail ed errors=remount-ro

Prima di apportare modifiche a casaccio, è una buona idea comprendere alcune regole di base su fstab che ti risparmieranno un sacco di problemi in futuro.

La prima è che, quando possibile, dovresti montare i tuoi file system UUIDnon con nomi di dispositivi tradizionali come /dev/sda1Il motivo è che l'ordine dei dischi può cambiare (si aggiungono o rimuovono unità, si cambiano porte, ecc.) e improvvisamente quello che era sda1 diventa sdb1. L'UUID, d'altra parte, è un identificatore univoco che rimane finché non si riformatta la partizione.

Per visualizzare gli UUID delle tue partizioni puoi usare nero o lsblk -fUna tipica voce fstab con un UUID si presenterebbe così:

UUID=<UUID_aquí> /data xfs defaults,nofail 0 0

La seconda raccomandazione fondamentale è quella di utilizzare l'opzione infallibile per tutti i file system che Non sono strettamente necessari per iniziare (ad esempio, dischi dati, unità esterne, ecc.). Con nofailSe un disco è scollegato, danneggiato o semplicemente lento ad apparire, il sistema non si bloccherà all'avvio: semplicemente non monterà quel punto, ma continuerà.

Infine, seleziona sempre l'opzione errori= nella radice. Il modo corretto in ext4 è usare errori=rimontare-roche fa sì che il file system torni in modalità di sola lettura se vengono rilevati errori, al fine di proteggere i dati. Inserire qualcosa di simile errori=remount-rw È una cattiva idea: non è un'opzione valida e può causare esattamente l'opposto di ciò che si desidera, oltre a impedire al sistema di rispondere correttamente ai guasti.

Quando anche GRUB si rompe: riparare il boot manager passo dopo passo

Non tutti i problemi di avvio hanno origine da fstab. Molto spesso, il problema risiede nel file fstab stesso. GRUB Sembra danneggiato o installato in modo errato: ad esempio, dopo aver ingrandito, spostato o eliminato partizioni, oppure dopo aver installato Windows su un Linux già installato (spesso Windows sovrascrive l'MBR/EFI senza chiedere conferma).

Un esempio abbastanza tipico è vedere un messaggio sullo schermo come «Fase di caricamento di Grub 1.5 – Errore 5» e non essere in grado di avviare né Linux né Windows, o ricevere messaggi come Nessun dispositivo avviabileCiò potrebbe accadere perché GRUB sta tentando di caricare la sua seconda fase da un settore o da un disco che non corrisponde più alla realtà (la tabella delle partizioni è stata spostata o modificata, l'ordine dei dischi SATA è stato alterato, ecc.).

La soluzione classica, che funziona sulla maggior parte delle distribuzioni basate su Debian (Ubuntu, Mint, Debian, Kali, ecc.), consiste in reinstallare GRUB da un LiveCD o LiveUSB prima assemblando il sistema danneggiato e utilizzando chrootIn breve, la ricetta sarebbe:

• Avvia da un LiveCD/LiveUSB compatibile con la tua architettura (amd64, i386, ecc.).
• Identifica quale partizione è la radice del tuo sistema Linux e, se esiste, la partizione /boot, con sudo fdisk -l o lsblk.
• Montare la radice su /mnt, e lo stivale (se ce n'è uno) in /mnt/boot.
• Monta anche /dev, /dev/pts, /proc y /sys all'interno /mnt utilizzando mount --bind.
• corsa sudo chroot /mnt per "entrare" nel sistema come se si fosse partiti da esso.
• Reinstallare GRUB puntando al disco corretto (non alla partizione, ma al disco): /dev/sda(ad esempio) con grub-install --boot-directory=/boot/ --recheck /dev/sda.
• Rigenerare la configurazione con grub-mkconfig -o /boot/grub/grub.cfg.
• Esci da chroot con exit e ricominciare con sudo reboot.

Se tutto è andato bene, dovresti vederlo di nuovo al prossimo avvio. il menu GRUB con i tuoi sistemi operativi e potrai riavviare la tua distribuzione GNU/Linux e persino Windows se utilizzi il dual boot.

Altri problemi comuni di avvio di Linux (oltre a fstab)

Sebbene fstab e GRUB siano in gran parte responsabili, altri fattori possono causare il mancato avvio del sistema Linux. Tenerli a mente aiuta a evitare di concentrarsi esclusivamente su un file quando il problema ha origine altrove.

Tra i motivi più frequenti ci sono:

• Partizione di avvio danneggiata o non configurata correttamente: partizione /boot o ESP corrotta, mancante del flag corretto o con file di avvio incompleti.
• Aggiornamento del kernel non riuscito o incompatibileIl nuovo core non funziona bene con il tuo hardwareoppure l'installazione non è completata.
• Patch o aggiornamento del sistema che interrompe i servizi chiave: systemd non riesce ad avviare tutti i daemon necessari e il sistema si blocca.
• Drivers fastidioso: in particolare driver GPU proprietari o hardware particolare installato manualmente.
• MBR/EFI sovrascritto da Windows nelle configurazioni dual boot.
• Avvio rapido di Windows che mantiene la partizione NTFS semi-ibernato e impedisce a Linux di toccarlo.
• Configurazione UEFI/Secure Boot in conflittoIl BIOS/UEFI non punta al disco corretto oppure la distribuzione non supporta l'avvio protetto.
• Problemi hardware: RAM difettosa, disco rigido sul punto di morire, alimentatore instabile, ecc.

Prima di impazzire con le impostazioni, di solito è una buona idea controllare che BIOS/UEFI rileva correttamente il disco dove è installato Linux, che l'ordine di avvio è coerente e che non vi è alcuna protezione del MBR attivato dal chipset che impedisce la scrittura sul boot manager.

Si consiglia inoltre di trascorrere MemTest86 + da GRUB per controllare la RAM (lasciandolo in esecuzione più volte) e utilizzare strumenti per . (ad esempio, smartmontools da un LiveCD) per verificare lo stato dei dischi. Valori come Reallocated_Sector_Ct o Current_Pending_Sector_Ct maggiori di zero sono un brutto segno e potrebbero indicare che il disco si sta avvicinando alla fine del suo ciclo di vita.

Strumenti di salvataggio: modalità di ripristino, Boot-Repair, fsck e fdisk

Se riesci almeno a raggiungere GRUB e a vedere le "opzioni avanzate" della tua distribuzione, hai a disposizione diverse modalità di ripristino molto utili. La maggior parte delle distribuzioni offre una Modalità di ripristino per ogni kernel installato che consente:

• corsa fsck sulla partizione root e altre, correggendo gli errori del file system.
• varo cavedano per liberare spazio utilizzato inutilmente.
• Applica dpkg per riparare pacchetti danneggiati o installazioni incomplete.
• Aggiornare GRUB dal menu di ripristino stesso.

In altri scenari, soprattutto dopo aver lavorato con le partizioni, gli strumenti classici fdisk y fsck Rimangono essenziali. Da un LiveCD è possibile:

• Elenca le partizioni con fdisk -l per individuare dove è installato Linux (spesso /dev/sda1, /dev/sda2, ecc.).
• Controllare e riparare una partizione con sudo fsck /dev/sda1 (sostituendo sda1 con quello corrispondente).

Tuttavia, è importante tenere presente che fsck e fdisk possono distruggere i dati se usati in modo improprioÈ sempre una buona idea effettuare un backup prima di toccare qualsiasi cosa di fondamentale importanza e, se non ne hai uno, procedi con estrema cautela.

Nel campo dell'automazione, i servizi cloud come Azure offrono meccanismi quali Riparazione automatica di Azure Linux (ALAR)che possono correggere automaticamente i problemi di fstab senza che tu debba intervenire manualmente: montano il disco di sistema in una VM di riparazione, creano una copia di fstab, commentano le voci in conflitto (in particolare quelle con dati non-nofail) e restituiscono il disco riparato alla VM originale.

Cosa fare quando l'unica soluzione sembra essere reinstallare Linux

Se dopo aver lottato con fstab, GRUB, modalità di ripristino e altri strumenti non riesci ancora a far avviare il tuo sistema in modo affidabile, potrebbe essere il momento di prendere in considerazione reinstallare la distribuzioneNon è lo scenario ideale, ma se fatto correttamente non comporta necessariamente la perdita di dati.

Molte distribuzioni moderne (Ubuntu, ad esempio) consentono reinstallare il sistema preservando i dati utente e persino molte delle applicazioni. Il programma di installazione rileva l'installazione esistente e offre l'opzione di reinstallarla senza toccare la cartella home. Ciononostante, è sempre consigliabile eseguire il backup dei documenti importanti in anticipo, nel caso in cui qualcosa vada storto.

Sui computer desktop o Portátiles Quando si controlla la partizione, ha molto senso separarsi dall'inizio. tre partizioni: uno per /boot, un altro per il sistema (/) e un altro per i dati (/home o una partizione dati separata). In questo modo, se mai dovessi reinstallare il sistema, ti basterà formattare solo le partizioni di avvio e di sistema, lasciando intatta la partizione dati.

Nelle macchine virtuali, è possibile ottenere qualcosa di simile montando i dati su dischi separati e utilizzando correttamente UUID e nofail in fstab, in modo che il sistema si avvii anche se uno di quei dischi è temporaneamente assente.

Suggerimenti per evitare che il problema si ripresenti

Dopo aver sperimentato il calvario di un sistema Linux che non si avvia, vale la pena prendere alcune precauzioni per... non rimanere mai più bloccato alla minima operazione di manutenzione.

Uno dei più importanti è prestare particolare attenzione quando modificare i file di configurazione critici come /etc/fstab o i file GRUB e UEFI. Prima di toccare qualsiasi cosa, fai una copia del file originale, ad esempio rinominandolo in fstab.bakSe si verificano errori, è sempre possibile ripristinare la vecchia versione da un LiveCD o da un ambiente di ripristino.

Un'altra buona pratica è Evitare di affidarsi a unità esterne o USB in fstab A meno che non sia assolutamente necessario. Se devi montarli automaticamente, usa sempre UUID, l'opzione nofail E se il file system non è essenziale, valutare se montarlo "su richiesta" dal file manager o con un copione manuale.

A livello di sistema, mantenere Linux e il suo kernel aggiornato Aiuta a correggere errori, bug e problemi di compatibilità che possono causare errori di avvio. Tuttavia, è consigliabile non aggiornare indiscriminatamente negli ambienti di produzione e avere sempre un kernel precedente installato in GRUB per l'avvio se la nuova versione non funziona bene con l'hardware in uso.

In definitiva, nessun meccanismo tecnico può sostituire un buoni backupChe tu utilizzi il computer desktop di casa o lavori con macchine virtuali nel cloud, avere un piano è essenziale. di riserva Naturalmente (su un'altra partizione, su un altro disco, sul cloud) è la differenza tra un breve spavento e un disastro totale il giorno in cui il disco decide di morire o il sistema si corrompe irreparabilmente.

Padroneggiare il suo funzionamento fstab, GRUB e gli strumenti di ripristino di Linux Trasforma un errore di avvio da qualcosa di drammatico in un semplice contrattempo che puoi risolvere in pochi minuti e ti consente di avere molto più controllo sul tuo sistema, sia sul tuo PC personale che sui server fisici o virtuali.