Come risolvere un errore di avvio di /etc/fstab con journalctl

Livello: Principiante / Intermedio
Tempo stimato: ~15 minuti
Obiettivo: Analizzare i log di sistema con journalctl per individuare e correggere un errore in /etc/fstab che impedisce l'avvio del sistema.

Introduzione

Un semplice errore di sintassi in /etc/fstab può impedire l'avvio di un server e farvi finire in una shell di manutenzione di emergenza. Per il ripristino è necessario analizzare i log di sistema per individuare il punto esatto del guasto. In questo tutorial useremo journalctl per interrogare il journal di systemd e visualizzare i log di sistema che Linux genera durante l'avvio. Comprendere i log di systemd è una competenza fondamentale per la gestione dei log in Linux, che garantisce un ripristino rapido e un'elevata disponibilità dei vostri servizi. È richiesta una conoscenza di base dei comandi journalctl per individuare il punto di mount che ha causato l'errore.

Gestione dei log in Linux e stack di logging

Prima di passare al ripristino, è importante comprendere i componenti coinvolti. Systemd (il sistema di init e gestore dei servizi di Linux) utilizza Systemd-journald (il servizio di sistema che raccoglie e archivia i dati di log). Questo servizio raccoglie ogni log (la registrazione degli eventi che si verificano nel sistema) nel Journal (i dati di log in formato binario archiviati da Systemd-journald). Tra questi rientrano i log di sistema (registrazioni degli eventi e dei cambiamenti di stato a livello di sistema), i log di avvio (registrazioni del processo di avvio del sistema) e i log del kernel (messaggi generati dal kernel del sistema operativo).

A seconda della configurazione, possono essere log volatili (log conservati in memoria e persi al riavvio) oppure log persistenti (log che sopravvivono ai riavvii, in genere memorizzati su disco). Il journal cresce continuamente, motivo per cui la rotazione dei log (il processo di archiviazione e gestione dei vecchi file di log per risparmiare spazio su disco) viene gestita automaticamente da systemd.

Prerequisiti

Prima di iniziare, assicuratevi che siano soddisfatte le seguenti condizioni:

• Sistema operativo: Testato su Ubuntu 22.04/24.04 LTS, Debian 12/13, AlmaLinux/Rocky 9/10
• Accesso: Accesso diretto alla console (IPMI, VNC o console fisica) per raggiungere la shell di emergenza
• Conoscenze richieste: Uso sicuro della riga di comando di Linux e modifica di base di file di testo

Passaggio 1: Individuare l'errore di avvio

Un errore di sintassi, un refuso o un dispositivo mancante in /etc/fstab attiva la modalità di emergenza, interrompe il processo di avvio e mostra un messaggio come il seguente:

Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

Inserite la password di root per accedere al prompt. In questa fase alcuni file system potrebbero non essere montati o essere montati in sola lettura.

Passaggio 2: Usare journalctl per visualizzare e analizzare i log di sistema generati da Linux

Per individuare la causa dell'errore dobbiamo controllare i log dell'avvio corrente.

Eseguite il comando seguente:

sudo journalctl -xb

Qui utilizziamo Journalctl (un'utilità da riga di comando per interrogare il journal di systemd). È uno dei comandi journalctl più importanti. Indica allo strumento di mostrare i log dell'avvio corrente (-b) e di includere testo esplicativo aggiuntivo (-x).

L'output può essere molto lungo. Dobbiamo eseguire il filtraggio dei log (il processo di restringere l'output dei log in base a criteri specifici) per trovare l'errore.

Per cercare all'interno del pager (che usa less), digitate /fstab oppure /mount e premete Invio.

Estratto dell'output previsto:

-- Subject: A start job for unit mnt-data.mount has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit mnt-data.mount has finished with a failure.
--
-- The job identifier is 123 and the job result is failed.

Ciò indica che una unit (un file di configurazione che descrive come gestire una risorsa in systemd) responsabile del mount di /mnt/data è fallita. In particolare, la mount unit (un file di configurazione di unit che codifica le informazioni su un processo gestito da systemd) non è riuscita ad avviarsi.

Passaggio 3: Filtrare i log di systemd per trovare errori specifici

Se scorrere l'intero log di avvio è troppo lento, possiamo analizzare i log con journalctl usando filtri specifici.

Eseguite il comando seguente per visualizzare solo gli errori ad alta priorità:

sudo journalctl -p err -b

Output previsto:

May 23 10:00:01 server systemd[1]: Failed to mount mnt-data.mount - /mnt/data.
May 23 10:00:01 server systemd[1]: Dependency failed for Local File Systems.

Con il filtraggio dei log con journalctl per priorità (-p err) eliminiamo i messaggi puramente informativi.

Possiamo anche controllare direttamente i log di un servizio se conosciamo la unit esatta che è fallita. Eseguite:

sudo journalctl -u mnt-data.mount

Quando analizzate i log con journalctl a livello di unit, isolate l'esatto problema di configurazione. Un altro metodo di filtraggio con journalctl consiste nello specificare un intervallo di tempo, ma per i problemi di avvio filtrare per unit è l'approccio più efficiente.

Passaggio 4: Correggere l'errore in /etc/fstab

Ora che il journal di systemd ha confermato che il problema è il punto di mount /mnt/data, dobbiamo correggere il file di configurazione.

Per prima cosa provate a modificare il file. Se durante il salvataggio compare l'errore Read-only file system, dovete rimontare il file system root in lettura e scrittura, poiché la modalità di emergenza lo monta spesso in sola lettura:

sudo mount -o remount,rw /

Quindi eseguite un backup del file di configurazione prima di apportare modifiche:

sudo cp /etc/fstab /etc/fstab.bak

Poi aprite il file (sui sistemi basati su RPM come AlmaLinux, Rocky o RHEL, nano potrebbe non essere installato per impostazione predefinita, quindi installatelo prima con sudo dnf install -y nano):

sudo nano /etc/fstab

Cercate la riga che fa riferimento a /mnt/data (potete trovare l'UUID corretto con blkid):

UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defualts 0 2

Notate il refuso: defualts invece di defaults. Correggete il refuso:

UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defaults 0 2

Salvate il file ed uscite. Poi ricaricate la configurazione del gestore di systemd, in modo che systemd sia a conoscenza delle modifiche apportate a /etc/fstab:

sudo systemctl daemon-reload

Verifica

Prima di riavviare, verificate la sintassi del vostro /etc/fstab con findmnt:

findmnt --verify

Se non vengono segnalati errori, procedete verificando che il punto di mount funzioni:

Eseguite:

sudo mount -a

Se il comando non produce alcun output, la sintassi è corretta e il mount è riuscito. Se è ancora presente un errore, il comando mostrerà un messaggio di errore. Su Debian 13 e AlmaLinux 10 il messaggio può indicare il motivo esatto (ad es. Unknown parameter 'defualts'), mentre su Ubuntu 24.04 l'output è spesso generico (wrong fs type, bad option). Su Ubuntu eseguite sudo dmesg | tail per ottenere dettagli.

Una volta verificato, uscite dalla shell di emergenza per proseguire con l'avvio oppure riavviate il sistema:

sudo systemctl reboot

Dopo il riavvio potete controllare nuovamente i log del servizio con i comandi journalctl per assicurarvi che il mount sia andato a buon fine durante il normale processo di avvio:

sudo journalctl -u mnt-data.mount -b

Risoluzione dei problemi

• La shell di emergenza non è accessibile: Se l'account root è bloccato e non potete accedere alla shell di emergenza, dovete avviare il server con una Live USB o un ambiente di ripristino, montare la partizione root e modificare /etc/fstab direttamente da lì.
• L'UUID è cambiato: Se avete formattato una partizione o sostituito un disco, l'UUID cambierà. Usate sudo blkid per trovare il nuovo UUID e aggiornate /etc/fstab di conseguenza.
• Evitare errori di avvio per dischi non essenziali: Per i volumi che non sono root né di sistema (come unità di backup o di dati), aggiungete l'opzione di mount nofail alla voce di /etc/fstab (ad es. ext4 defaults,nofail 0 2). In questo modo systemd prosegue l'avvio anche se il dispositivo non viene montato.

Ripristino

Se il server si è avviato correttamente ma la riga modificata di /mnt/data causa un comportamento imprevisto delle applicazioni, potete annullare il mount commentando la riga in /etc/fstab:

sudo sed -i 's|^UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|#UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|' /etc/fstab

Poi smontate il volume per ripristinare lo stato precedente:

sudo umount /mnt/data

Conclusione

Un'efficace gestione dei log in Linux si basa in larga misura sulla capacità di muoversi tra i log di systemd. Con journalctl potete visualizzare i log di sistema che Linux genera per analizzarli in modo efficiente e ripristinare il sistema da errori critici di avvio come le configurazioni errate di /etc/fstab. Padroneggiare questi strumenti vi permette di mantenere la disponibilità e di diagnosticare problemi complessi in tutta la vostra infrastruttura.

Versione del documento: 1.0
Ultimo aggiornamento: maggio 2026
Responsabile: Team di documentazione tecnica