Avvio di Ubuntu Server in modalità di emergenza: una guida passo passo per il ripristino

Scenario illustrativo: Casey gestisce una macchina virtuale Ubuntu Server ipotetica che entra in modalità di emergenza dopo un riavvio, poco dopo l'aggiunta di un mount di volume dati opzionale /etc/fstab. Casey ha accesso alla console ma non a una sessione SSH. La modifica del mount è un indizio, non una causa comprovata: la modalità di emergenza può verificarsi dopo diversi errori di avvio, quindi Casey controlla i log della macchina corrente prima di apportare qualsiasi modifica. I pannelli del terminale sottostanti mostrano layout rappresentativi e output segnaposto, non una riparazione o un test reali.

Cosa significa la modalità di emergenza

Su un'installazione di Ubuntu Server che utilizza systemd, emergency.targetviene avviata una shell minimale sulla console principale. È più limitata rispetto a rescue.target, che avvia il sistema base e monta i mount di sistema con solo i servizi essenziali. A seconda del percorso in cui si accede alla modalità di emergenza, il filesystem root potrebbe essere già montato in sola lettura o in lettura/scrittura. Verificalo invece di presumere uno di questi stati. Consulta la documentazione di systemd relativa ai target speciali .

Innanzitutto, distinguete il prompt. Una shell di emergenza di systemd in genere visualizza il messaggio "Benvenuti in modalità di emergenza!" e potrebbe richiedere la password di root per la manutenzione. Un prompt di BusyBox, ad esempio, (initramfs)indica che l'avvio non è ancora passato al filesystem root installato; un prompt grub>o grub rescue>indica un problema del bootloader. Questi casi richiedono percorsi di ripristino diversi. Se l'account root è bloccato o il server è remoto, utilizzate la console seriale/VNC del provider di hosting o l'ambiente di ripristino; SSH di solito non è disponibile in questa fase. Non premete Ctrl+D per continuare finché non avrete compreso e risolto l'errore segnalato.

Salvataggio passo passo

1. Mantenere l'accesso alla console e registrare l'errore esatto

Rimanete nella console di emergenza. Annotate l'ultimo mount o nome del servizio non riuscito e qualsiasi percorso del dispositivo o UUID visualizzato sopra il prompt. fstabVale la pena controllare la recente modifica di Casey, ma non commentate ogni riga non riuscita né eseguite un comando di ripristino basandovi solo sulla parola "emergenza". Se il sistema è una macchina virtuale, tenete aperta la console del provider durante il ripristino e il successivo riavvio.

2. Leggere il registro di avvio corrente e le unità guaste

Nella shell di emergenza, esegui:

journalctl -xb -p err --no-pager
systemctl --failed --no-pager

-bLimita la query del registro a questo avvio e -p errfiltra in base alla priorità di errore e a quelle superiori. Cerca il primo errore rilevante, non semplicemente l'ultima cascata di messaggi "dipendenza non riuscita". Se un'unità di montaggio non è riuscita, annota il suo nome unità con escape e il percorso di destinazione; se un servizio non è riuscito, identifica se è la causa o solo una conseguenza di un mount mancante. journalctl(1)Il manuale di Ubuntu documenta il filtraggio all'avvio e alle unità.

3. Verificare il punto di montaggio principale e lo spazio disponibile.

Prima di modificare i file o tentare riparazioni, verificare come è montato il filesystem root e se il sistema ha esaurito i blocchi o gli inode:

findmnt -no SOURCE,FSTYPE,OPTIONS /
df -h /
df -i /

Nell'output findmnt, roindica sola lettura e rwindica lettura/scrittura. Una root di sola lettura può essere intenzionale durante una fase di ripristino, oppure può riflettere un problema del filesystem. Non forzare immediatamente un rimontaggio in modalità lettura/scrittura se i log del kernel segnalano errori di I/O o del filesystem. Un filesystem pieno o una tabella degli inode esaurita possono anche causare il fallimento di servizi e mount non correlati. Il findmnt(8)manuale di Ubuntu descrive come ispezionare i filesystem montati.

4. Convalidare /etc/fstabe verificare gli identificativi del dispositivo

Poiché Casey ha recentemente apportato delle modifiche /etc/fstab, verifica sia la sua sintassi sia l'esistenza dei dispositivi a cui fa riferimento:

findmnt --verify --verbose
lsblk -f
blkid

findmnt --verify --verboseControlla le voci di fstab per problemi di analisi e usabilità. Confronta ogni elemento UUID=nella riga sospetta con l'UUID mostrato da lsblk -fo blkid. Controlla anche il punto di montaggio, il tipo di filesystem e le opzioni. Un UUID copiato da un altro disco, un dispositivo non collegato o un'opzione non valida possono impedire il completamento di un montaggio richiesto. Non fare supposizioni su una partizione come /dev/sda1; i nomi dei dispositivi possono cambiare tra un avvio e l'altro.

5. Correggere solo il problema di montaggio confermato

Se il filesystem di root è scrivibile e il controllo fstab rileva una riga danneggiata, esegui un backup prima di modificarlo:

cp -a /etc/fstab /etc/fstab.before-rescue
nano /etc/fstab

Correggi l'UUID o altri campi solo dopo aver confermato il dispositivo previsto. Se il mount è effettivamente opzionale e il server deve comunque avviarsi anche in assenza di tale volume, è possibile utilizzare una riga fstab compatibile con systemd nofaile un'attesa del dispositivo finito, ad esempio:

UUID=VERIFIED-UUID /srv/archive ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

Sostituisci il segnaposto con l'UUID reale e usa il tipo di filesystem effettivo. Non aggiungere nofaila root, boot o altri filesystem necessari al corretto funzionamento della macchina o delle sue applicazioni. Con nofail, l'avvio procede anche se il mount fallisce, quindi i servizi dipendenti potrebbero comunque richiedere attenzione. Il manuale di Ubuntu systemd mount-unit documenta queste opzioni di fstab.

Dopo la modifica, convalida nuovamente prima di tentare il montaggio:

findmnt --verify --verbose
systemctl daemon-reload
mount /srv/archive

Utilizza il punto di mount effettivo nell'ultimo comando. Se l'operazione continua a fallire, leggi il nuovo messaggio di errore e verifica che il disco sia collegato e integro. Se il filesystem di root è di sola lettura, non forzare le modifiche alla cieca; utilizza un ambiente di ripristino del provider o un supporto di avvio di Ubuntu per ispezionare e modificare il sistema installato in modo sicuro.

6. Indagare su un servizio non riuscito solo quando il registro indica uno

La modalità di emergenza non significa che ogni servizio non funzionante abbia causato l'arresto del sistema. Se l'errore in questione menziona un servizio, esaminate tale servizio e i relativi registri anziché mascherarlo o disabilitarlo:

systemctl status example.service --no-pager
journalctl -u example.service -b --no-pager

Sostituire example.servicecon il nome esatto dell'unità. Verificare se mancano il file di configurazione, l'eseguibile, le credenziali o il punto di montaggio necessario. Se l'errore si verifica a valle del volume dati mancante di Casey, correggere prima quel punto di montaggio e poi rivalutare il servizio. Disabilitare un servizio essenziale potrebbe nascondere il sintomo, rendendo il server inutilizzabile.

7. Trattare gli errori del filesystem come un'attività di riparazione offline

Se il registro del kernel segnala danneggiamento del filesystem o errori di I/O di archiviazione, interrompere le operazioni di scrittura laddove possibile e conservare un backup o uno snapshot del provider prima della riparazione. Confermare il dispositivo e il filesystem esatti con lsblk -f. Per un filesystem root, avviare il sistema di ripristino del provider o il supporto di ripristino/live di Ubuntu, assicurarsi che la partizione di destinazione sia smontata e utilizzare lo strumento di verifica appropriato per quel filesystem. Per ext2/3/4, lo strumento è e2fsck; XFS, Btrfs e altri formati hanno procedure diverse.

Non eseguire mai operazioni fsckdi I/O e2fscksu un filesystem montato, inclusa una root di sola lettura montata. Il e2fsck(8)manuale di Ubuntu avverte che controllare un filesystem montato è generalmente pericoloso e che i risultati non sono validi. Se il disco segnala errori di I/O ripetuti, dai la priorità al recupero dei dati o al contatto con il fornitore di servizi di archiviazione piuttosto che tentare ripetutamente riparazioni.

8. Riavviare il sistema normalmente e verificare il risultato.

Una volta risolta la causa accertata, riavviare dalla console:

systemctl reboot

Dopo l'avvio di Ubuntu, verificare il target predefinito configurato, lo stato attuale del sistema, le unità non funzionanti e il nuovo avvio:

systemctl get-default
systemctl is-system-running
systemctl --failed --no-pager
journalctl -b -p err --no-pager
findmnt --verify --verbose

Se si continua intenzionalmente con l'avvio corrente, systemctl defaultchiede a systemd di avviare la destinazione predefinita configurata. Utilizzalo solo dopo aver risolto l'errore bloccante; non ripara un mount non valido o un filesystem danneggiato. systemctl get-defaultMostra la destinazione predefinita configurata; systemctl is-system-runningsegnala se systemd considera lo stato corrente in esecuzione, degradato o altro. Un ripristino pulito significa che i filesystem previsti sono montati, i servizi richiesti sono attivi e la stessa condizione di emergenza non si ripresenta dopo il riavvio.

Se il prompt è (initramfs)invece

Non applicare ciecamente i passaggi della shell di emergenza di systemd nell'initramfs di BusyBox. La fase initramfs tenta di individuare e montare il filesystem root effettivo prima di cedere il controllo al sistema installato. Registra l'errore esatto, verifica se il dispositivo previsto appare in /deve /dev/disk/by-uuid, e confronta il valore della riga di comando di avvio root=con l'UUID root effettivo. Se il disco o il volume crittografato/LVM non è presente, utilizza gli strumenti di archiviazione e ripristino del provider per indagare. Ricostruire l'initramfs o modificare i parametri di GRUB senza identificare il dispositivo mancante può rendere più difficile il ripristino dell'avvio.

Per la macchina virtuale ipotetica di Casey, il risultato utile è una causa verificata e una correzione mirata: ripristinare il volume opzionale previsto, correggere il suo identificatore confermato o configurarlo come opzionale solo se il carico di lavoro lo consente effettivamente. Quindi verificare il successivo avvio dalla console prima di chiudere la sessione di ripristino.