Questo documento ti aiuta a scoprire perché la tua istanza Compute Engine Linux non si avvia e a risolvere i problemi comuni.
Un'istanza di computing che non si avvia di solito mostra uno o più di questi sintomi:
- L'istanza di computing è nello stato
RUNNING, ma non puoi connetterti tramite SSH. - L'output della console seriale si interrompe a metà della sequenza di avvio o termina con un prompt di emergenza o di ripristino.
- L'output della console seriale contiene
FAILED,error:,Kernel panicoemergency mode.
Per risolvere un problema di avvio, identifica prima la causa, quindi risolvila dall'interno dell'istanza di computing se riesci ancora a connetterti oppure risolvila offline collegando il disco di avvio a un'altra istanza di computing.
Se l'istanza di computing termina l'avvio, ma non riesci a connetterti, consulta Risolvere gli errori SSH.
Prima di iniziare
- Assicurati che l'istanza di computing scriva l'output della console seriale. L'output della porta seriale è disponibile durante l'esecuzione dell'istanza di computing; per conservarlo dopo l'arresto dell'istanza di computing, attiva il logging della porta seriale in Cloud Logging. Per saperne di più, consulta Visualizzazione dell'output della porta seriale.
-
Se non l'hai ancora fatto, configura l'autenticazione.
L'autenticazione verifica la tua identità per l'accesso ad API e servizi Google Cloud . Per eseguire
codice o esempi da un ambiente di sviluppo locale, puoi autenticarti su
Compute Engine selezionando una delle seguenti opzioni:
-
Installa Google Cloud CLI, quindi accedi a gcloud CLI con la tua identità federata. Dopo aver eseguito l'accesso, inizializza Google Cloud CLI eseguendo il comando seguente:
gcloud init - Imposta una regione e una zona predefinite.
-
Rileva automaticamente la causa
Prima di leggere manualmente l'output della console seriale, utilizza uno dei seguenti strumenti. Ognuno legge l'output dell'avvio più recente dell'istanza di computing, segnala la causa più probabile e rimanda alla sezione corrispondente di questo documento.
Console
Nella console Google Cloud , vai alla pagina Istanze VM.
Nella riga dell'istanza di computing, fai clic su SSH.
Se la connessione non riesce, fai clic su Risolvi i problemi nella finestra di dialogo della connessione. Lo strumento di risoluzione dei problemi esegue controlli di connettività, incluso un controllo di avvio che analizza l'output della console seriale.
gcloud
Per controllare un'istanza di Compute a cui non riesci a connetterti utilizzando SSH, esegui lo strumento di risoluzione dei problemi SSH di gcloud CLI, che esegue controlli di connettività e un controllo di avvio:
gcloud compute ssh INSTANCE_NAME --zone=ZONE --troubleshoot
Per controllare direttamente la sequenza di avvio, esegui il comando di diagnostica di avvio:
Per utilizzare questo comando, assicurati di aver installato il componente comandi alpha.
gcloud alpha compute diagnose boot INSTANCE_NAME --zone=ZONE
Sostituisci quanto segue:
INSTANCE_NAME: il nome dell'istanza di computing.ZONE: la zona contenente l'istanza di computing.
Se viene rilevato un problema di avvio, l'output indica la causa e fornisce un link alla correzione. Se non viene rilevato alcun problema, continua con i passaggi manuali.
Leggi l'output della console seriale
Se gli strumenti non rilevano un problema o se vuoi confermare la causa, leggi tu stesso l'output della console seriale:
Console
Nella console Google Cloud , vai alla pagina Istanze VM.
Seleziona l'istanza di Compute per cui vuoi visualizzare l'output della porta seriale.
In Log, fai clic su Porta seriale 1 (console).
gcloud
gcloud compute instances get-serial-port-output INSTANCE_NAME --zone=ZONE
Sostituisci quanto segue:
INSTANCE_NAME: il nome dell'istanza di computing.ZONE: la zona contenente l'istanza di computing.
Vai all'ultimo avvio. Le righe utili si trovano in genere immediatamente prima della prima riga [FAILED], della riga Kernel panic o del prompt di emergenza. Confronta i risultati con le firme nelle sezioni seguenti.
Problemi di avvio comuni
Le sezioni seguenti elencano gli errori di avvio comuni sulle istanze di calcolo Linux, le relative firme di output della console seriale e come risolverli. La maggior parte delle soluzioni richiede di collegare il disco di avvio a una VM di soccorso, come descritto in Risolvi il problema del disco offline.
Impossibile montare la voce del file /etc/fstab
Sintomo: l'output della console seriale contiene righe simili alle seguenti,
seguite da You are in emergency mode:
UUID=1234abcd-... does not exist
Timed out waiting for device /dev/sdb1
mount: special device /dev/sdb1 does not exist
[DEPEND] Dependency failed for /mnt/data.mount
Causa: una voce in /etc/fstab fa riferimento a un dispositivo o a un UUID non collegato all'istanza di computing oppure non è possibile montare il file system. Il servizio systemd interrompe l'avvio e passa alla modalità di emergenza.
Risoluzione:nella VM di recupero, correggi la voce in /etc/fstab sul disco montato o rimuovila. Per la procedura, vedi
Risolvi i problemi di avvio della VM Linux dovuti a errori di fstab.
Per l'opzione di montaggio che impedisce a un dispositivo mancante di bloccare l'avvio,
vedi Montare il disco.
GRUB non riesce a caricare la sua configurazione o il kernel
Sintomo: l'avvio si interrompe in corrispondenza di un prompt di GRUB e l'output della console seriale contiene righe simili alle seguenti:
error: file '/boot/grub/grub.cfg' not found
error: file '/vmlinuz-6.1.0-18-amd64' not found
error: no such partition
error: no such device
error: unknown filesystem
error: you need to load the kernel first
grub rescue>
Minimal BASH-like line editing is supported
Causa: il bootloader GRUB non riesce a trovare il file di configurazione, i moduli o il kernel e il disco RAM iniziale a cui fa riferimento la configurazione. Questo problema si verifica dopo un upgrade del pacchetto non riuscito, una modifica al layout della partizione, una partizione /boot riformattata o danneggiata o un disco clonato i cui UUID del file system sono cambiati.
Risoluzione:sulla VM di soccorso, monta il disco di avvio e inserisci un ambiente chroot come descritto in Recuperare una VM, quindi rigenera il file di configurazione GRUB come descritto in Configurare il bootloader.
Se il bootloader non può essere riparato, ripristina il disco da uno snapshot.
Il disco RAM iniziale non può montare il file system root
Sintomo: l'output della console seriale contiene righe simili alle seguenti:
dracut-initqueue[452]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut: FATAL: ...
Failed to mount /sysroot
ALERT! UUID=1234abcd-... does not exist. Dropping to a shell!
Gave up waiting for root file system device
VFS: Unable to mount root fs on unknown-block(0,0)
Causa: il disco RAM iniziale (initramfs) è stato avviato, ma non è stato possibile trovare
o montare il file system root. Le cause comuni sono un parametro del kernel root=
o un UUID che non corrisponde più al disco, un'immagine initramfs
a cui manca il driver per il disco o un'immagine initramfs danneggiata. Nelle serie di macchine che utilizzano l'interfaccia del disco NVMe, una configurazione di avvio che assegna un nome al disco in base a un percorso del dispositivo come /dev/sda non corrisponde più; utilizza l'UUID.
Risoluzione: verifica che il file system root cercato dal disco RAM iniziale esista sul disco montato, quindi ricrea il disco RAM iniziale per il tuo sistema operativo. Per la procedura, vedi Risolvi i problemi di avvio delle VM Linux dovuti a errori di tipo kernel panic e Correggi il disco offline.
Danneggiamento del file system
Sintomo: l'output della console seriale contiene righe simili alle seguenti:
Bad magic number in super-block
EXT4-fs error (device sda1): ...
XFS (sda1): Metadata corruption detected
XFS (sda1): log mount/recovery failed
BTRFS error (device sda1): ...
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Causa: il file system sul disco di avvio è danneggiato, in genere dopo un arresto anomalo, un disco pieno o un errore I/O.
Risoluzione:crea uno snapshot del disco. Poi, nella VM di recupero, controlla e ripara il file system sul disco smontato come descritto in Identifica il motivo per cui il disco di avvio non si avvia. Se il controllo non riesce a riparare il file system, ripristina il disco da uno snapshot.
Kernel panic
Sintomo:l'output della console seriale contiene Kernel panic - not
syncing: seguito dal motivo, ad esempio Attempted to kill init!,
Fatal exception, hung_task: blocked tasks, Out of memory, Fatal
Machine check o NMI: Not continuing. Un'immagine del kernel danneggiata si arresta
prima con -- System halted.
Causa:il kernel ha rilevato un errore irreversibile. Il motivo dopo i due punti identifica la categoria: un init arrestato in modo anomalo, un controllo della macchina hardware, un panic per esaurimento della memoria o un'immagine del kernel danneggiata.
Risoluzione:reimposta l'istanza di computing. Se l'errore kernel panic si ripresenta, consulta Risolvi i problemi di avvio delle VM Linux dovuti a errori di tipo kernel panic.
Impossibile caricare la policy SELinux
Sintomo: l'output della console seriale contiene uno dei seguenti elementi e l'avvio si interrompe:
Failed to load SELinux policy
Unable to load SELinux policy
Potresti anche visualizzare Warning -- SELinux targeted policy relabel is
required, che non è un errore: l'istanza di computing etichetta nuovamente il file system
e poi si riavvia autonomamente.
Causa:l'archivio delle policy SELinux sul disco è mancante o danneggiato oppure le etichette dei file non sono coerenti dopo un ripristino o una modifica offline.
Risoluzione:sulla VM di recupero, contrassegna il disco montato per una nuova etichettatura SELinux completa al successivo avvio oppure reinstalla i pacchetti delle policy SELinux per il tuo sistema operativo se l'archivio delle policy è danneggiato. Sulle immagini sistema operativo basate su RHEL, puoi consentire l'avvio dell'istanza di computing mentre ripari la policy impostando SELinux in modalità permissiva, come descritto in Modifica di SELinux in modalità permissiva.
Il sistema non può avviare la procedura init
Sintomo: l'output della console seriale contiene righe simili alle seguenti:
Failed to switch root
Target filesystem doesn't have requested /sbin/init
No working init found
run-init: /sbin/init: No such file or directory
/sbin/init: error while loading shared libraries: ...
Causa: il file system root è montato, ma il programma init, ad esempio
systemd, è mancante, non è eseguibile o dipende da una libreria condivisa
mancante. Questo problema si verifica in genere dopo un aggiornamento interrotto del pacchetto
o un ripristino incompleto.
Risoluzione: sulla VM di rescue, accedi a un ambiente chroot come descritto in Esegui il rescue di una VM, verifica che il programma init esista e che le relative librerie siano intatte. In caso contrario, reinstalla il pacchetto di sistema init utilizzando il gestore di pacchetti della tua distribuzione.
Modalità di emergenza e account root bloccato
Sintomo: l'output della console seriale termina con uno dei seguenti messaggi:
You are in emergency mode. After logging in, type "journalctl -xb" to view system logs
Give root password for maintenance (or press Control-D to continue):
Cannot open access to console, the root account is locked.
Causa: un'unità ha riscontrato un errore durante l'avvio e systemd si è arrestato in corrispondenza della destinazione di emergenza. Nelle immagini del sistema operativo fornite da Google, l'account root non ha password, quindi
la shell di emergenza non può essere utilizzata dalla console seriale.
Risoluzione:le righe che precedono il nome del prompt di emergenza indicano l'unità che non funziona. Il problema è in genere causato da uno dei seguenti problemi:
- Impossibile montare la voce del file
/etc/fstab - Il disco RAM iniziale non può montare il file system root
- Danneggiamento del file system
Risolvi la causa offline come descritto in Risolvi il problema del disco offline. Non tentare di utilizzare la shell di emergenza.
Il firmware non riesce a trovare un disco avviabile
Sintomo: l'output della console seriale contiene uno dei seguenti prima di qualsiasi messaggio del kernel:
No bootable device.
BdsDxe: failed to load Boot0001
Invalid partition table!
Verification failed: (0x1A) Security Violation
Causa:il disco di avvio non è collegato come dispositivo di avvio, la tabella delle partizioni o il record di avvio è danneggiato oppure, su un'istanza Shielded VM con Avvio protetto, il bootloader o il kernel non è firmato correttamente.
Risoluzione:verifica che il disco sia collegato come disco di avvio dell'istanza di Compute. Consulta Scollegamento e ricollegamento dei dischi. Se la tabella delle partizioni o il record di avvio è danneggiato, ripara il bootloader come descritto in GRUB non riesce a caricare la sua configurazione o il kernel. Una violazione dell'avvio protetto non può essere corretta modificando il disco: ripristina un kernel e un bootloader firmati oppure disabilita l'avvio protetto sull'istanza di Compute come descritto in Modifica delle opzioni di Shielded VM su un'istanza VM.
Correggere il disco offline
La maggior parte dei problemi di avvio non può essere risolta dall'interno dell'istanza di computing, perché l'istanza di computing non raggiunge mai una richiesta di accesso. Collega invece il disco di avvio a una VM di recupero temporanea, montalo, apporta la modifica e sposta di nuovo il disco. Per la procedura, consulta Recupera una VM inaccessibile.
Le soluzioni descritte in questo documento presuppongono che il disco di avvio originale sia collegato e montato su una VM di recupero. Prima di modificare il disco, crea uno snapshot in modo da poterlo ripristinare in caso di errore della riparazione. Per la procedura, vedi Crea snapshot del disco standard e di archiviazione.
Ripristina l'istanza di computing se il disco non può essere riparato
Se nessuna delle soluzioni funziona o se non è possibile riparare il file system, ripristina il disco di avvio da uno snapshot o crea una nuova istanza di computing da uno snapshot o da un'immagine sistema operativo personalizzata e spostaci i dati.