L'avvio della macchina virtuale Linux di Azure non riesce e entra nella shell di emergenza dracut

  • Articolo

Si applica a: ✔️ macchine virtuali di Linux

Nota

CentOS a cui si fa riferimento in questo articolo è una distribuzione Linux e raggiungerà End Of Life (EOL). Valutare le proprie esigenze e pianificare di conseguenza. Per altre informazioni, vedere Indicazioni sulla fine della vita di CentOS.

Questo articolo fornisce soluzioni a un problema in cui non è possibile avviare una macchina virtuale Linux di Azure perché il file system del sistema operativo non è accessibile dal disco RAM. La macchina virtuale si trova nel guscio di emergenza dracut.

Prerequisiti

Assicurarsi che la console seriale sia abilitata e funzionale nella macchina virtuale Linux.

Come identificare il problema di avvio dracut

Per identificare un problema di avvio dracut, usare il portale di Azure per visualizzare l'output del log della console seriale della macchina virtuale nel riquadro di diagnostica di avvio, nel riquadro della console seriale o nell'interfaccia della riga di comando di Azure.

Tutte le macchine virtuali con il problema di avvio verranno visualizzate nella shell di emergenza dracut o initramfs e verranno visualizzate alla fine del log della console seriale:

  • RHEL/CentOS/SLES/Oracle Linux:

    [  201.935612] dracut-initqueue[455]: Warning: dracut-initqueue timeout - starting timeout scripts
[  201.941153] dracut-initqueue[455]: Warning: Could not boot.
         Starting Setup Virtual Console...
[[0;32m  OK  [0m] Started Setup Virtual Console.
         Starting Dracut Emergency Shell...
Warning: /dev/mapper/rootvg-rootlv does not exist

Generating "/run/initramfs/rdsosreport.txt"


Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.


dracut:/#

  • Ubuntu:

    mdadm: No arrays found in config file or automatically
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mapper/osencrypt does not exist.  Dropping to a shell!


BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

Risoluzione dei problemi in modalità online

Suggerimento

Se si dispone di un backup recente della macchina virtuale, ripristinare la macchina virtuale dal backup per risolvere il problema di avvio.

La console seriale è il metodo più veloce per risolvere i problemi. Consente di risolvere direttamente il problema senza dover presentare il disco di sistema a una macchina virtuale di ripristino. Assicurarsi di soddisfare i prerequisiti necessari per la distribuzione. Per altre informazioni, vedere Console seriale della macchina virtuale per Linux.

  1. Identificare se la macchina virtuale si trova nella shell di emergenza dracut.

  2. Provare a risolvere il problema usando la console seriale di Azure.

    Nota

    Non tutti i problemi possono essere risolti usando la console seriale di Azure.

    1. Attivare Riavvia macchina virtuale (hard) dalla console seriale.
    2. Interrompere la macchina virtuale nel menu GRUB con il tasto ESC .
    3. Selezionare E per modificare la prima voce del kernel nel menu GRUB.
    4. Passare alla linux16 riga e quindi convalidare e correggere la configurazione errata di GRUB come indicato di seguito:

  3. Dopo aver modificato manualmente le impostazioni GRUB, selezionare CTRL+X per avviare la macchina virtuale.

    Qualsiasi modifica eseguita in questa fase è una modifica non persistente. Se la macchina virtuale è in grado di eseguire l'avvio, risolvere questo problema nel file di configurazione GRUB o si verifica di nuovo.

  4. Quando la macchina virtuale è di nuovo online, correggere i problemi di configurazione nel /etc/default/grub file di configurazione e aggiornare la configurazione GRUB. A tale scopo, vedere Reinstallare GRUB e rigenerare il file di configurazione GRUB.

  5. Riavviare la macchina virtuale per assicurarsi che sia in grado di avviarsi senza alcun intervento manuale.

Risoluzione dei problemi in modalità offline

Suggerimento

Se si dispone di un backup recente della macchina virtuale, ripristinare la macchina virtuale dal backup per risolvere il problema di avvio.

  1. Nel caso in cui la console seriale di Azure non funzioni nella macchina virtuale specifica o non sia un'opzione nella sottoscrizione, risolvere questo problema usando una macchina virtuale di ripristino/ripristino. Usare i comandi di ripristino della macchina virtuale per creare una macchina virtuale di ripristino con una copia del disco del sistema operativo della macchina virtuale interessata collegato. Montare la copia dei file system del sistema operativo nella macchina virtuale di ripristino usando chroot.

    Nota

    In alternativa, è possibile creare manualmente una macchina virtuale di ripristino usando il portale di Azure. Per altre informazioni, vedere Risolvere i problemi di una macchina virtuale Linux collegando il disco del sistema operativo a una macchina virtuale di ripristino usando il portale di Azure.

  2. Passare alle sezioni seguenti per risolvere problemi specifici:

  3. Dopo aver risolto il problema di avvio correlato a dracut/initramfs, eseguire le azioni seguenti:

    1. Uscire da chroot.
    2. Smontare la copia dei file system dalla macchina virtuale di ripristino/ripristino.
    3. Eseguire il az vm repair restore comando per scambiare il disco del sistema operativo riparato con il disco del sistema operativo originale della macchina virtuale. Per altre informazioni, vedere Passaggio 5 in Ripristinare una macchina virtuale Linux usando i comandi di ripristino della macchina virtuale di Azure.
    4. Verificare se la macchina virtuale è in grado di eseguire l'avvio esaminando la console seriale di Azure o provando a connettersi alla macchina virtuale.

L'avvio della macchina virtuale crittografata di Azure non riesce perché VFAT è disabilitato

Per altre informazioni, vedere L'avvio delle macchine virtuali crittografate di Ade non riesce.

Driver Hyper-V mancanti

Se i driver Hyper-V inclusi nel kernel Linux di tutte le distribuzioni Linux moderne sono disabilitati, riabilitarli e rigenerare l'immagine initramfs/initrd. Per altre informazioni, vedere Scenario 3: Altri driver Hyper-V sono disabilitati.

Se la macchina virtuale è Red Hat ed è stata eseguita la migrazione da locale, abilitare i driver Hyper-V necessari nell'immagine initramfs. Per altre informazioni, vedere Impossibile includere il driver Hyper-V nel disco RAM iniziale quando si usa un hypervisor non Hyper-V.

Configurazione errata di GRUB

Il rd.break parametro forza l'avvio della macchina virtuale nella shell di emergenza dracut. Assicurarsi che questo parametro non sia hardcoded nel file di configurazione GRUB.

Percorso del dispositivo radice errato nel file di configurazione GRUB

Verificare se il percorso root=/dev/*** radice nel file di configurazione GRUB è corretto. Assicurarsi che venga usato il percorso del dispositivo appropriato.

  • Se ci si trova all'interno di chroot in una macchina virtuale di ripristino/salvataggio:

    1. Seguire il passaggio 1 nella risoluzione dei problemi offline.
    2. Convalidare il /etc/default/grub file, la GRUB_CMDLINE_LINUX voce e cercare il root= parametro nel caso in cui sia hardcoded nel file di configurazione.
    3. Reinstallare GRUB e rigenerare il file di configurazione GRUB.

  • Se si è nella console seriale di Azure:

    1. Seguire il passaggio 3 nella risoluzione dei problemi online.
    2. Convalidare la linux16 riga e quindi cercare il root= parametro e correggerlo.
    3. Selezionare CTRL+X per avviare la macchina virtuale.
    4. Dopo l'avvio della macchina virtuale, modificare il /etc/default/grub file, correggere il root parametro e aggiornare il file di configurazione GRUB, come indicato in Reinstallare GRUB e rigenerare il file di configurazione GRUB.

Durante questa convalida, verificare quanto segue:

  • In Macchine virtuali Ubuntu con crittografia del sistema operativo verificare che il nome del dispositivo sia /dev/mapper/osencrypt.
  • Nelle macchine virtuali con Gestione volumi logici (LVM) nel disco del sistema operativo il volume radice è /dev/mapper/rootvg-rootlv. Lo stesso percorso viene usato nelle macchine virtuali RHEL con disco del sistema operativo ADE crittografato.
  • Assicurarsi che non vengano usati nomi di dispositivo sotto forma di /dev/sdX , perché cambieranno tra riavvii e non sono persistenti in Linux. Per altre informazioni, vedere Risolvere i problemi relativi alle modifiche del nome del dispositivo della macchina virtuale Linux.
  • Se vengono usati UUID, assicurarsi che venga usato l'UUID del file system radice appropriato e che la sintassi sia root=UUID=xxx-yyy-zzz.

Percorso del dispositivo di scambio errato nel file di configurazione GRUB

In questo scenario, una macchina virtuale non riesce a completare il processo di avvio e immette la shell di emergenza dracut con un errore simile al seguente:

[  188.000765] dracut-initqueue[324]: Warning: /dev/VG/SwapVol does not exist
         Starting Dracut Emergency Shell...
Warning: /dev/VG/SwapVol does not exist

Il file di configurazione GRUB in questo esempio è impostato per caricare un volume logico (LV) come scambio con il parametro rd.lvm.lv=VG/SwapVol. Tuttavia, la macchina virtuale non è in grado di individuare l'LV durante il processo di avvio.

È importante notare che l'uso di un dispositivo di scambio in questo modo nelle macchine virtuali Linux di Azure non è consigliato. Per altre informazioni, vedere Creare un file SWAP per una macchina virtuale Linux di Azure.

Per risolvere questo problema, individuare il percorso rd.lvm.lv=VG/SwapVol di scambio nel file di configurazione GRUB (/etc/default/grub) e rimuoverlo. Per farlo, usare uno dei metodi seguenti:

  • Se ci si trova all'interno di chroot in una macchina virtuale di ripristino/salvataggio:

    1. Seguire il passaggio 1 nella risoluzione dei problemi offline.
    2. Modificare il /etc/default/grub file, passare alla GRUB_CMDLINE_LINUX voce, individuare il rd.lvm.lv=VG/SwapVol parametro e quindi rimuoverlo dalla configurazione.
    3. Reinstallare GRUB e rigenerare il file di configurazione GRUB.

  • Se si è nella console seriale di Azure:

    1. Seguire il passaggio 3 nella risoluzione dei problemi online.
    2. Passare alla riga che inizia con linux, individuare il rd.lvm.lv=VG/SwapVol parametro e rimuoverlo.
    3. Selezionare CTRL+X per avviare la macchina virtuale.
    4. Dopo l'avvio della macchina virtuale, modificare il /etc/default/grub file, rimuovere il rd.lvm.lv=VG/SwapVol parametro e quindi aggiornare il file di configurazione GRUB, come indicato nella sezione Reinstallare GRUB e rigenerare il file di configurazione GRUB.

Parametri duplicati nel file di configurazione GRUB

Verificare se nel file di configurazione GRUB sono presenti parametri duplicati:

  • Se ci si trova all'interno di chroot in una macchina virtuale di ripristino/salvataggio:

    1. Seguire il passaggio 1 nella risoluzione dei problemi offline.
    2. Convalidare il /etc/default/grub file e la GRUB_CMDLINE_LINUX voce.
    3. Cercare parametri duplicati e rimuoverli.
    4. Aggiornare il file di configurazione GRUB. Per altre informazioni, vedere Reinstallare GRUB e rigenerare il file di configurazione GRUB.

  • Se si è nella console seriale di Azure:

    1. Seguire il passaggio 3 nella risoluzione dei problemi online.
    2. Convalidare la linux16 riga, cercare parametri duplicati e rimuoverli.
    3. Selezionare CTRL+X per avviare la macchina virtuale.
    4. Dopo l'avvio della macchina virtuale, modificare il /etc/default/grub file di conseguenza, correggere i problemi di configurazione identificati in precedenza e aggiornare il file di configurazione GRUB, come indicato in Reinstallare GRUB e rigenerare il file di configurazione GRUB.

Danneggiamento del file system radice

Quando il file system radice è danneggiato, non è possibile montare dall'immagine initrd/initramfs.

Per correggere il danneggiamento del file system radice, seguire le istruzioni in Risolvere i problemi di avvio della macchina virtuale Linux a causa di errori del file system - Eseguire il ripristino del file system.

Problemi con l'attivazione di LVM

Alcuni problemi possono verificarsi quando si accede al volume fisico LVM (PV), al gruppo di volumi (VG) e/o al volume logico (LV). Non possono essere risolti dalla console seriale di Azure. Per risolverli, usare una macchina virtuale di ripristino/ripristino.

  1. Seguire il passaggio 1 nella risoluzione dei problemi offline.

  2. Per identificare i problemi, eseguire i comandi seguenti ed esaminare gli output dei comandi.

    1. Identificare il dispositivo che corrisponde al disco del sistema operativo e verificare se viene rilevato come pv:

      lsblk
pvs

    2. Verificare se viene rilevato il rootvg gruppo di sicurezza virtuale:

      vgs

    3. Verificare se viene rilevata l'LV:

      lvs

  3. Risolvere gli errori LVM comuni seguenti che causano problemi con l'accesso al volume radice:

    • Pv sconosciuto quando il VG rootvg ha un solo pv (si tratta della configurazione standard di Azure)

      La partizione che contiene il pv viene eliminata, ridimensionata o creata in modo non corretto. Per risolvere questo problema, vedere Partizione radice mancante.

    • Pv sconosciuto quando il VG radice viene modificato e suddiviso in più dischi

      La presenza di 2 VG rootvg non è una configurazione consigliata. In questo scenario, il disco dati potrebbe essere scollegato dalla macchina virtuale e i volumi logici rootvg non sono più accessibili. Per risolvere questo problema, ricollegare il disco originale alla macchina virtuale e riavviarlo.

  4. Se il pv non è ripristinabile, eseguire un ripristino dal backup.

Partizione radice mancante

Il file system radice potrebbe non essere accessibile a causa di alcuni problemi che si verificano a livello di partizione durante le operazioni di ridimensionamento della partizione o altre.

In questo scenario, se è stato documentato il layout originale della tabella di partizione, con i settori di inizio e fine esatti per ognuna delle partizioni originali (e non vengono apportate altre modifiche nel sistema, come la creazione di nuovi file system), ricreare le partizioni usando lo stesso layout originale. È possibile eseguire questa operazione con strumenti come fdisk (per le tabelle di partizione MBR) o gdisk (per le tabelle di partizione GPT) per ottenere l'accesso al file system inaccessibile. Seguire questa operazione di ripristino da una macchina virtuale di ripristino/ripristino. Per altre informazioni, vedere la sezione Risoluzione dei problemi offline.

Se questo approccio non funziona, è consigliabile eseguire un ripristino dal backup.

Danneggiamento initrd o initramfs

L'immagine initrd/initramfs presenta un certo livello di danneggiamento che causa l'esito negativo del montaggio del volume radice e l'avvio del processo di avvio del sistema operativo.

Per risolvere questo problema, seguire questa procedura dall'interno di chroot in una macchina virtuale di ripristino/ripristino:

  1. Seguire il passaggio 1 nella risoluzione dei problemi offline.
  2. Rigenerare manualmente initramfs mancanti.
  3. Riavviare la macchina virtuale per verificare se è in grado di eseguire l'avvio.

Passaggi successivi

Nel caso in cui l'errore di avvio specifico non sia un problema dracut o initramfs, vedere Risolvere gli errori di avvio di Azure Linux Macchine virtuali per altre opzioni di risoluzione dei problemi.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.