Share via

L'avvio della macchina virtuale Linux di Azure non riesce dopo l'applicazione delle modifiche al kernel

  • Articolo

Nota

CentOS a cui si fa riferimento in questo articolo è una distribuzione Linux e raggiungerà End Of Life (EOL). Prendere in considerazione l'uso e pianificare di conseguenza. Per altre informazioni, vedere Indicazioni sulla fine del ciclo di vita di CentOS.

Questo articolo fornisce soluzioni a un problema in cui una macchina virtuale Linux (VM) non può essere avviata dopo l'applicazione delle modifiche al kernel.

Prerequisiti

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

Come identificare il problema di avvio correlato al kernel

Per identificare un problema di avvio correlato al kernel, controllare la stringa di panico del kernel specifica. A tale scopo, usare l'interfaccia della riga di comando di Azure o il portale di Azure per visualizzare l'output del log della console seriale della macchina virtuale nel riquadro di diagnostica di avvio o nel riquadro della console seriale.

Un panico del kernel è simile all'output seguente e verrà visualizzato alla fine del log della console seriale:

Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[  300.206297] Kernel panic - xxxxxxxx
[  300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.xxx.x86_64 #1

Risoluzione dei problemi in linea

Consiglio

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 il problema di avvio. 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 macchina virtuale per Linux.

  1. Identificare il problema di avvio specifico correlato al kernel.

  2. Usare la console seriale di Azure per interrompere la macchina virtuale dal menu GRUB e selezionare qualsiasi kernel precedente per avviarla. Per altre informazioni, vedere Sistema di avvio nella versione precedente del kernel.

  3. Passare alla sezione corrispondente per risolvere il problema di avvio specifico correlato al kernel:

  4. Dopo aver risolto il problema di avvio correlato al kernel, riavviare la macchina virtuale in modo che possa eseguire l'avvio con la versione più recente del kernel.

Risoluzione dei problemi offline

Consiglio

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

Se la console seriale di Azure non funziona nella macchina virtuale specifica o non è un'opzione nella sottoscrizione, risolvere il problema di avvio usando una macchina virtuale di salvataggio/ripristino. A tal fine, attenersi alla seguente procedura:

  1. Utilizza i comandi di riparazione vm per creare una VM di riparazione a cui è collegata una copia del disco del sistema operativo della VM interessata. Montare la copia dei file system del sistema operativo nella macchina virtuale di ripristino utilizzando chroot.

    Nota

    In alternativa, è possibile creare manualmente una macchina virtuale di salvataggio 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 tramite il portale di Azure.

  2. Identificare il problema di avvio specifico correlato al kernel.

  3. Passare alla sezione corrispondente per risolvere il problema di avvio specifico correlato al kernel:

  4. Dopo aver risolto il problema di avvio correlato al kernel, eseguire le azioni seguenti:

    1. Uscire da chroot.
    2. Smontare la copia dei file system dalla macchina virtuale di salvataggio/ripristino.
    3. Eseguire il comando az vm repair restore per scambiare il disco del sistema operativo ripristinato con il disco del sistema operativo originale della macchina virtuale. Per altre informazioni, vedere il passaggio 5 in Riparare una macchina virtuale Linux usando i comandi di riparazione della macchina virtuale di Azure.
    4. Verificare se la macchina virtuale è in grado di avviarsi dando un'occhiata alla console seriale di Azure o provando a connettersi alla macchina virtuale.

  5. Se sono presenti contenuti importanti correlati al kernel, manca l'intera /boot partizione o altri contenuti importanti e non possono essere ripristinati, è consigliabile ripristinare la macchina virtuale da un backup. Per ulteriori informazioni, vedere Come ripristinare i dati delle macchine virtuali di Azure nel portale di Azure.

Sistema di avvio nella versione precedente del kernel

Usare la console seriale di Azure

  1. Riavviare la macchina virtuale usando la console seriale di Azure.

    1. Selezionare il pulsante di arresto nella parte superiore della finestra della console seriale.
    2. Selezionare l'opzione Riavvia macchina virtuale (hard).

  2. Una volta ripresa la connessione alla console seriale, verrà visualizzato un contatore del conto alla rovescia nell'angolo superiore sinistro della finestra della console seriale. Premere il tasto ESCAPE per interrompere la macchina virtuale dal menu GRUB.

  3. Premere il tasto freccia GIÙ per selezionare qualsiasi versione precedente del kernel.

    GIF animata che mostra il processo di interruzione del processo di avvio a livello di menu GRUB per selezionare un kernel precedente in cui avviare il sistema.

  4. Modificare la GRUB_DEFAULT variabile nel file /etc/default/grub come indicato in Modificare manualmente la versione predefinita del kernel. Si tratta di una modifica persistente.

Nota

Se nel menu GRUB è elencata una sola versione del kernel, seguire l'approccio alla risoluzione dei problemi offline per risolvere questo problema da una macchina virtuale di ripristino.

Usare la macchina virtuale di ripristino (script ALAR)

  1. Eseguire il comando bash seguente in Azure Cloud Shell per creare una macchina virtuale di ripristino. Per altre informazioni, vedere Usare il ripristino automatico di Azure Linux (ALAR) per correggere un'opzione VM - kernel Linux.

    az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy

  2. Eseguire il comando seguente per sostituire il kernel interrotto con la versione installata in precedenza:

    az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters kernel --run-on-repair

az vm repair restore --verbose -g $RGNAME -n $VMNAME

Nota

Se nel sistema è installata una sola versione del kernel, seguire l'approccio alla risoluzione dei problemi offline per risolvere il problema da una macchina virtuale di ripristino.

Modificare manualmente la versione del kernel predefinita

Per modificare la versione del kernel predefinita da una macchina virtuale di ripristino (all'interno di chroot) o in una macchina virtuale in esecuzione, seguire questa procedura:

Nota

Se viene eseguito il rollback del downgrade del kernel, selezionare la versione più recente del kernel anziché quella precedente.

  • RHEL 7, Oracle Linux 7 e CentOS 7

    1. Convalidare l'elenco dei kernel disponibili nel file di configurazione GRUB eseguendo uno dei comandi seguenti:

      • Macchine virtuali gen1:

        cat /boot/grub2/grub.cfg | grep menuentry

      • Macchine virtuali di seconda generazione:

        cat /boot/efi/EFI/*/grub.cfg | grep menuentry

    2. Impostare il nuovo kernel predefinito e specificare il titolo del kernel corrispondente eseguendo il comando seguente:

      # grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64'

      Nota

      Sostituire Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 con il titolo della voce di menu corrispondente.

    3. Verificare che il nuovo kernel predefinito sia quello desiderato eseguendo il comando seguente:

      grub2-editenv list

    4. Assicurarsi che il valore della GRUB_DEFAULT variabile nel file /etc/default/grub sia impostato su saved. Per modificarlo, assicurarsi di rigenerare il file di configurazione GRUB per applicare le modifiche.

  • RHEL 8/9 e CentOS 8

    1. Elencare i kernel disponibili eseguendo il comando seguente:

      ls -l /boot/vmlinuz-*

    2. Impostare il nuovo kernel predefinito eseguendo il comando seguente:

      grubby --set-default /boot/vmlinuz-4.18.0-372.19.1.el8_6.x86_64

      Nota

      Sostituire 4.18.0-372.19.1.el8_6.x86_64 con la versione del kernel corrispondente.

    3. Verificare che il nuovo kernel predefinito sia quello desiderato eseguendo il comando seguente:

      grubby --default-kernel

  • SLES 12/15, Ubuntu 18.04/20.04

    1. Elencare i kernel disponibili nel file di configurazione GRUB eseguendo il comando seguente:

      • Macchine virtuali gen1:

        • SLES 12/15:

          cat /boot/grub2/grub.cfg | grep menuentry

        • Ubuntu 18.04/20.04:

          cat /boot/grub/grub.cfg | grep menuentry

      • Macchine virtuali di seconda generazione:

        cat /boot/efi/EFI/*/grub.cfg | grep menuentry

    2. Impostare il nuovo kernel predefinito modificando il valore della GRUB_DEFAULT variabile nel file /etc/default/grub . Per la versione più recente del kernel installata nel sistema, il valore predefinito è 0. Il kernel disponibile successivo è impostato su "1>2".

      vi /etc/default/grub
GRUB_DEFAULT="1>2"

      Nota

      Per altre informazioni su come configurare la GRUB_DEFAULT variabile, vedere SUSE Boot Loader GRUB2 e Ubuntu Grub2/Setup. Come riferimento: il valore di menuentry di primo livello è 0, il primo valore del sottomenu di primo livello è 1 e ogni valore di menuentry annidato inizia con 0. Ad esempio, "1>2" è la terza voce di menu del primo sottomenu.

    3. Rigenerare il file di configurazione GRUB per applicare le modifiche. Seguire le istruzioni in Reinstallare GRUB e rigenerare il file di configurazione GRUB per la distribuzione e la generazione di macchine virtuali Linux corrispondenti.

Panico del kernel : non è possibile eseguire la sincronizzazione: VFS: impossibile montare fs radice in blocco sconosciuto(0,0)

Questo errore si verifica a causa di un recente aggiornamento del sistema (kernel). È più comune nelle distribuzioni basate su RHEL. È possibile identificare questo problema dalla console seriale di Azure. Verrà visualizzato uno dei messaggi di errore seguenti:

  1. "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"

    [  301.026129] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[  301.027122] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.10.0-1160.36.2.el7.x86_64 #1
[  301.027122] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008  12/07/2018
[  301.027122] Call Trace:
[  301.027122]  [<ffffffff82383559>] dump_stack+0x19/0x1b
[  301.027122]  [<ffffffff8237d261>] panic+0xe8/0x21f
[  301.027122]  [<ffffffff8298b794>] mount_block_root+0x291/0x2a0
[  301.027122]  [<ffffffff8298b7f6>] mount_root+0x53/0x56
[  301.027122]  [<ffffffff8298b935>] prepare_namespace+0x13c/0x174
[  301.027122]  [<ffffffff8298b412>] kernel_init_freeable+0x222/0x249
[  301.027122]  [<ffffffff8298ab28>] ? initcall_blcklist+0xb0/0xb0
[  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
[  301.027122]  [<ffffffff8237235e>] kernel_init+0xe/0x100
[  301.027122]  [<ffffffff82395df7>] ret_from_fork_nospec_begin+0x21/0x21
[  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
[  301.027122] Kernel Offset: 0xc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

  2. "error: file '/initramfs-*.img' not found"

    error: file '/initramfs-3.10.0-1160.36.2.el7.x86_64.img' non trovato.

Questo tipo di errore indica che il file initramfs non viene generato, il file di configurazione GRUB ha la voce initrd mancante dopo un processo di applicazione di patch o una configurazione manuale GRUB.

Prima di riavviare un server, è consigliabile convalidare la configurazione grub e /boot il contenuto se è presente un aggiornamento del kernel eseguendo uno dei comandi seguenti. È importante assicurarsi che l'aggiornamento venga eseguito e che non siano presenti file initramfs mancanti.

  • Basato su BIOS - Sistemi Gen1

    # ls -l /boot
# cat /boot/grub2/grub.cfg

  • Basato su UEFI - Sistemi Gen2

    # ls -l /boot
# cat /boot/efi/EFI/*/grub.cfg

Rigenerare gli initramfs mancanti usando gli script ALAR della macchina virtuale di Ripristino di Azure

  1. Creare una macchina virtuale di ripristino eseguendo la riga di comando Bash seguente con Azure Cloud Shell. Per altre informazioni, vedere Usare il ripristino automatico di Azure Linux (ALAR) per correggere un'opzione VM Linux - initrd.

    az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy

  2. Rigenerare l'immagine initrd/initramfs e rigenerare il file di configurazione GRUB se manca la voce initrd. A tale scopo, utilizzare il seguente comando:

    az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters initrd --run-on-repair

az vm repair restore --verbose -g $RGNAME -n $VMNAME

  3. Dopo aver eseguito il comando di ripristino, riavviare la macchina virtuale originale e verificare che sia in grado di eseguire l'avvio.

Rigenerare manualmente gli initramfs mancanti

Importante

  • Se è possibile avviare la macchina virtuale usando una versione precedente del kernel o all'interno di chroot dalla macchina virtuale di ripristino/salvataggio, rigenerare manualmente gli initramfs mancanti.
  • Per rigenerare manualmente gli initramfs mancanti da una macchina virtuale di ripristino, assicurarsi che il passaggio 1 della risoluzione dei problemi offline sia già stato seguito e che tali comandi vengano eseguiti all'interno di chroot.

  1. Identificare la versione specifica del kernel che presenta problemi con l'avvio. È possibile estrarre le informazioni sulla versione dall'errore di panico del kernel corrispondente.

    Fare riferimento allo screenshot seguente come esempio. L'errore di panico del kernel mostra che la versione del kernel è "3.10.0-1160.59.1.el7.x86_64":

    Screenshot che mostra come identificare la versione specifica del kernel con l'immagine initramfs mancante.

  2. Rigenerare il file initramfs mancante eseguendo uno dei comandi seguenti:

    • RHEL/CentOS/Oracle Linux 7/8

      sudo depmod -a 3.10.0-1160.59.1.el7.x86_64
sudo dracut -f /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img 3.10.0-1160.59.1.el7.x86_64

      Importante

      Sostituire 3.10.0-1160.59.1.el7.x86_64 con la versione del kernel corrispondente.

    • SLES 12/15

      sudo depmod -a 5.3.18-150300.38.53-azure
sudo dracut -f /boot/initrd-5.3.18-150300.38.53-azure 5.3.18-150300.38.53-azure

      Importante

      Sostituire 5.3.18-150300.38.53-azure con la versione del kernel corrispondente.

    • Ubuntu 18.04

      sudo depmod -a 5.4.0-1077-azure
sudo mkinitramfs -k -o /boot/initrd.img-5.4.0-1077-azure

      Importante

      Sostituire 5.4.0-1077-azure con la versione del kernel corrispondente.

  3. Rigenerare il file di configurazione GRUB. Seguire le istruzioni in Reinstallare GRUB e rigenerare il file di configurazione GRUB per la distribuzione e la generazione di macchine virtuali Linux corrispondenti

  4. Se i passaggi precedenti vengono eseguiti da una macchina virtuale di ripristino, seguire il passaggio 3 in Risoluzione dei problemi offline. Se i passaggi precedenti vengono eseguiti dalla console seriale di Azure, seguire il metodo di risoluzione dei problemi online .

  5. Riavviare la macchina virtuale con la versione più recente del kernel.

Panico del kernel - non sincronizzazione: tentativo di uccidere init

Identificare questo problema dalla console seriale di Azure. Verrà visualizzato un output simile al seguente:

dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 2.6.32-754.17.1.el6.x86_64 #1
Call Trace:
 [<ffffffff81558bfa>] ? panic+0xa7/0x18b
 [<ffffffff81130370>] ? perf_event_exit_task+0xc0/0x340
 [<ffffffff81086433>] ? do_exit+0x853/0x860
 [<ffffffff811a33b5>] ? fput+0x25/0x30
 [<ffffffff81564272>] ? system_call_after_swapgs+0xa2/0x152
 [<ffffffff81086498>] ? do_group_exit+0x58/0xd0
 [<ffffffff81086527>] ? sys_exit_group+0x17/0x20
 [<ffffffff81564357>] ? system_call_fastpath+0x35/0x3a
 [<ffffffff8156427e>] ? system_call_after_swapgs+0xae/0x152

Questo tipo di panico kernel si verifica a causa delle seguenti possibili cause:

Per informazioni dettagliate sulla causa e soluzioni, vedere le sezioni seguenti. Assicurarsi che i comandi vengano eseguiti da una macchina virtuale di ripristino/salvataggio all'interno di un ambiente chroot, come indicato in Risoluzione dei problemi offline.

File e directory importanti mancanti

I file e le directory Linux importanti mancano a causa di un errore umano. Ad esempio, i file vengono eliminati accidentalmente o il file system viene danneggiato.

  1. Convalidare il contenuto del disco del sistema operativo dopo aver allegato la copia del disco del sistema operativo a una macchina virtuale di ripristino e aver montato i file system corrispondenti usando chroot. È possibile confrontare gli output con quelli di una macchina virtuale funzionante che esegue la stessa versione del sistema operativo.

    ls -l /
ls -l /usr/lib
ls -l /usr/lib64
ls -lR / | more

  2. Ripristinare i file mancanti da un backup. Per altre informazioni, vedere Ripristinare i file dal backup della macchina virtuale di Azure. A seconda del numero di file mancanti, potrebbe essere preferibile eseguire un ripristino completo della macchina virtuale. Per ulteriori informazioni, vedere Come ripristinare i dati delle macchine virtuali di Azure nel portale di Azure.

Librerie e pacchetti principali di sistema mancanti

Importanti librerie, file o pacchetti principali del sistema vengono eliminati dal sistema o danneggiati. Per risolvere questo problema, reinstallare le librerie, i file o i pacchetti interessati. Questa soluzione funziona in distribuzioni basate su RPM come le macchine virtuali Red Hat/CentOS/SUSE. Per altre distribuzioni Linux, è consigliabile ripristinare la macchina virtuale dal backup.

Per eseguire la reinstallazione, seguire questa procedura:

  1. Creare una macchina virtuale di salvataggio usando un'immagine non elaborata con la stessa versione e generazione del sistema operativo della macchina virtuale interessata.

  2. Accedere all'ambiente chroot nella macchina virtuale di salvataggio per risolvere il problema.

    sudo chroot /rescue

    L'output del comando indicherà quale libreria è mancante o danneggiata, come illustrato di seguito:

    /bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

  3. Verificare tutti i pacchetti di sistema e il relativo stato corrispondente nella macchina virtuale di salvataggio. Confrontare l'output con una macchina virtuale integra che esegue la stessa versione del sistema operativo.

    sudo rpm --verify --all --root=/rescue

    Ecco un esempio dell'output del comando:

    error: Failed to dlopen /usr/lib64/rpm-plugins/systemd_inhibit.so /lib64/librt.so.1: undefined symbol: __pthread_attr_copy, version GLIBC_PRIVATE
S.5....T.  c /etc/dnf/dnf.conf
S.5....T.  c /etc/ssh/sshd_config
.M.......    /boot/efi/EFI/BOOT/BOOTX64.EFI
.M.......    /boot/efi/EFI/BOOT/fbx64.efi
.M.......    /boot/efi/EFI/redhat/BOOTX64.CSV
.M.......    /boot/efi/EFI/redhat/mmx64.efi
.M.......    /boot/efi/EFI/redhat/shimx64-redhat.efi
.M.......    /boot/efi/EFI/redhat/shimx64.efi
missing     /run/motd.d
.M.......  g /var/spool/anacron/cron.daily
.M.......  g /var/spool/anacron/cron.monthly
.M.......  g /var/spool/anacron/cron.weekly
missing     /lib64/libc-2.28.so     <-------
.M.......    /boot/efi/EFI/redhat
S.5....T.  c /etc/security/pwquality.conf

    La riga missing /lib64/libc-2.28.so di output è correlata all'errore precedente nel passaggio 2 e indica che il pacchetto libc-2.28.so è mancante. È tuttavia possibile modificare il pacchetto libc-2.28.so . In questo caso, l'output verrà visualizzato .M..... anziché missing. Viene fatto riferimento al pacchetto libc-2.28.so come esempio nei passaggi seguenti.

  4. Nella macchina virtuale di salvataggio verificare quale pacchetto contiene la libreria /lib64/libc-2.28.so.

    sudo rpm -qf /lib64/libc-2.28.so

    glibc-2.28-127.0.1.el8.x86_64

    Nota

    L'output mostrerà il pacchetto che deve essere reinstallato, inclusi il nome e la versione del pacchetto. La versione del pacchetto potrebbe essere diversa da quella installata nella macchina virtuale interessata.

  5. Nella macchina virtuale interessata verificare quale versione del pacchetto glibc è installata.

    sudo rpm -qa --all --root=/rescue | grep -i glibc

    glibc-common-2.28-211.0.1.el8.x86_64
glibc-gconv-extra-2.28-211.0.1.el8.x86_64
glibc-2.28-211.0.1.el8.x86_64     <----  
glibc-langpack-en-2.28-211.0.1.el8.x86_64

  6. Scaricare il pacchetto glibc-2.28-211.0.1.el8.x86_64. È possibile scaricarlo dal sito Web ufficiale del fornitore del sistema operativo o dalla macchina virtuale di salvataggio usando uno strumento di gestione dei pacchetti come yumdownloader o zypper install --download-only <packagename> a seconda del sistema operativo in esecuzione.

    Ecco un esempio di uso dello yumdownloader strumento:

    cd /tmp
sudo yumdownloader glibc-2.28-211.0.1.el8.x86_64

    Last metadata expiration check: 0:03:24 ago on Thu 25 May 2023 02:36:25 PM UTC.
glibc-2.28-211.0.1.el8.x86_64.rpm               8.7 MB/s | 2.2 MB     00:00

  7. Reinstallare il pacchetto interessato nella macchina virtuale di salvataggio.

    sudo rpm -ivh --root=/rescue /tmp/glibc-*.rpm --replacepkgs --replacefiles

    warning: /tmp/glibc-2.28-211.0.1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID ad986da3: NOKEY
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:glibc-2.28-211.0.1.el8           ################################# [100%]

  8. Accedere all'ambiente chroot nella macchina virtuale di salvataggio per convalidare la reinstallazione.

    sudo chroot /rescue

  9. Disattivare la macchina virtuale di salvataggio e scambiare il disco del sistema operativo con la macchina virtuale interessata.

Autorizzazioni di file non valide

Le autorizzazioni di file a livello di sistema non valide vengono modificate a causa di un errore umano, ad esempio un utente viene eseguito chmod 777 in / o in altri file system importanti del sistema operativo. Per risolvere questo problema, ripristinare le autorizzazioni per i file. Questa soluzione funziona in distribuzioni basate su RPM come le macchine virtuali Red Hat/CentOS/SUSE. Per altre distribuzioni Linux, è consigliabile ripristinare la macchina virtuale dal backup.

Per ripristinare le autorizzazioni per i file, eseguire il comando seguente dopo aver allegare la copia del disco del sistema operativo a una macchina virtuale di ripristino e aver montato i file system corrispondenti usando chroot:

rpm -a --setperms
rpm --setugids --all
chmod u+s /bin/sudo
chmod 660 /etc/sudoers.d/*
chmod 644 /etc/ssh/*.pub
chmod 640 /etc/ssh/*.key

Nota

Non eseguire questo comando nei sistemi di produzione in esecuzione.

Se il problema persiste dopo il ripristino manuale delle autorizzazioni di file corrispondenti, eseguire un ripristino dal backup.

Partizioni mancanti

Nei casi in cui /usri file system , /opt, /var/home, /tmp, e / sono distribuiti tra partizioni diverse, i dati potrebbero non essere accessibili a causa di problemi a livello di partizioni, che potrebbero essere causati da errori durante le operazioni di ridimensionamento della partizione o altre.

In questo scenario, se si documenta il layout della tabella di partizione originale, con i settori di inizio e di fine esatti per ognuna delle partizioni originali e non vengono apportate ulteriori modifiche al sistema, come la creazione di nuovi file system, ricreare le partizioni usando lo stesso layout originale 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 mancante.

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

Problemi di SELinux

Autorizzazioni SELinux errate potrebbero impedire al sistema di accedere a file importanti. Per risolvere il problema, seguire la procedura seguente:

  1. Per verificare se il sistema presenta problemi a causa di autorizzazioni SELinux errate, avviare il sistema con SELinux disabilitato aggiungendo l'opzione del kernel selinux=0 alla riga GRUB linux16.

  2. Se il sistema è in grado di eseguire l'avvio, eseguire il comando seguente per attivare una rietichetta SELinux al momento dell'avvio e riavviare il sistema:

    touch /.autorelabel

  3. Se la macchina virtuale non riesce ancora ad avviarsi, eseguire un ripristino completo della macchina virtuale dal backup. Per ulteriori informazioni, vedere Come ripristinare i dati delle macchine virtuali di Azure nel portale di Azure.

Altri problemi di avvio correlati al kernel

Questo articolo illustra i più comuni panico del kernel Linux identificati in Azure. Per altre informazioni sugli scenari di panico del kernel comuni, vedere Panico del kernel nelle macchine virtuali Linux di Azure - Eventi di panico comuni del kernel.

Esistono altri importanti possibili panico del kernel che potrebbero non causare scenari di avvio o di shell sicura (SSH).

Assicurarsi di eseguire tutti i comandi da una macchina virtuale di ripristino all'interno di un ambiente chroot, come indicato in Risoluzione dei problemi offline. Se il sistema è già stato avviato con una versione precedente del kernel, questi comandi possono essere eseguiti anche dalla macchina virtuale originale usando i privilegi radice o sudo, come indicato in Risoluzione dei problemi online.

Aggiornamento recente del kernel

Se il kernel si avvia dopo un recente aggiornamento del kernel, avviare la macchina virtuale sulla versione precedente del kernel. Per altre informazioni, vedere Sistema di avvio nella versione precedente del kernel.

È anche possibile verificare se è già disponibile una versione più recente del kernel rilasciata dal fornitore della distribuzione Linux e installarla. Per altre informazioni su come installare la versione più recente del kernel, vedere Processo di aggiornamento del kernel.

Downgrade recente del kernel

Se il kernel si avvia dopo un recente downgrade del kernel, tornare al kernel installato più recente. È anche possibile verificare se è già disponibile una versione più recente del kernel rilasciata dal fornitore della distribuzione Linux e installarla. Per altre informazioni su come installare la versione più recente del kernel, vedere Processo di aggiornamento del kernel.

Per avviare il sistema sulla versione del kernel più recente, seguire le istruzioni in Modificare manualmente la versione del kernel predefinita, ma selezionare il primo kernel elencato nel menu GRUB. In una modifica manuale è possibile impostare il GRUB_DEFAULT valore su 0 e rigenerare il file di configurazione GRUB corrispondente.

Modifiche al modulo del kernel

È possibile che si verifichi un panico del kernel correlato a un nuovo modulo del kernel o a un modulo kernel mancante. Per ottenere informazioni dettagliate sul modulo kernel specifico che causa eventuali problemi, controllare la traccia di panico del kernel corrispondente.

Per convalidare i moduli kernel caricati e quelli disabilitati nei file /etc/modprobe.d/*.conf , eseguire uno dei comandi seguenti:

  • RHEL/CentOS/Oracle Linux 7/8

    lsinitrd /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img
lsmod
cat /etc/modprobe.d/*.conf

    Importante

    Sostituire 3.10.0-1160.59.1.el7.x86_64 con la versione del kernel corrispondente.

  • SLES 12/15

    lsinitrd /boot/initrd-5.3.18-150300.38.53-azure
lsmod
cat /etc/modprobe.d/*.conf

    Importante

    Sostituire 5.3.18-150300.38.53-azure con la versione del kernel corrispondente.

  • Ubuntu 18.04

    lsinitramfs /boot/initrd.img-5.4.0-1077-azure
lsmod
cat /etc/modprobe.d/*.conf

    Importante

    Sostituire 5.4.0-1077-azure con la versione del kernel corrispondente.

Per rimuovere qualsiasi modulo kernel specifico, eseguire il comando seguente e rigenerare le initramfs , se necessario.

rmmod <kernel_module_name>

Se un servizio di sistema usa il modulo kernel specifico, disabilitarlo eseguendo il systemctl disable <serviceName> comando o systemctl stop <serviceName> .

Modifiche recenti alla configurazione del sistema operativo

Identificare eventuali modifiche recenti alla configurazione del kernel che potrebbero causare problemi. Per risolvere i problemi, modificare tali impostazioni o eseguire il rollback delle modifiche di configurazione.

Eseguire il comando seguente per trovare i parametri del kernel permanenti configurati in uno dei file seguenti:

cat /etc/systctl.conf
cat /etc/sysctl.d/*

Eseguire il comando seguente per analizzare i parametri del kernel correnti e i relativi valori correnti:

sysctl -a

Nota

Eseguire questo comando in un sistema in esecuzione e non da un ambiente chroot.

Possibili file mancanti

Per altre informazioni su questo tipo di problema, vedere File e directory importanti mancanti.

Autorizzazioni non valide per i file

Per altre informazioni su questo tipo di problema, vedere Autorizzazioni di file non valide.

Partizioni mancanti

Per altre informazioni su questo tipo di problema, vedere Partizioni mancanti.

Bug del kernel

Identificare questo problema dalla console seriale di Azure. Questo tipo di problema sarà simile all'output seguente:

[5275698.017004] kernel BUG at XXX/YYY.c:72!
[5275698.017004] invalid opcode: 0000 [#1] SMP

Questo tipo di panico del kernel è associato a bug del kernel o bug del kernel di terze parti.

Per correggere i bug del kernel, eseguire una ricerca nella Knowledge Base del fornitore usando la stringa BUG del kernel e cercare i problemi noti nella versione del kernel corrispondente in esecuzione nel sistema. Ecco alcune risorse importanti per i fornitori:

È consigliabile mantenere aggiornati tutti i sistemi per escludere eventuali bug già corretti nelle versioni più recenti del kernel. Per altre informazioni, vedere Processo di aggiornamento del kernel.

Se è necessaria un'ulteriore analisi da parte del fornitore, configurare e abilitare kdump per generare un dump di base:

Processo di aggiornamento del kernel

Per installare la versione più recente del kernel disponibile, eseguire uno dei comandi seguenti:

  • RHEL/CentOS/Oracle Linux

    yum update kernel

  • SLES 12/15

    zypper refresh
zypper update kernel*

  • Ubuntu 18.04/20.04

    apt update
apt install linux-azure

Per reinstallare una versione specifica del kernel, eseguire uno dei comandi seguenti. Assicurarsi di non essere avviato con la stessa versione del kernel che si sta tentando di reinstallare. Per altre informazioni, vedere Sistema di avvio nella versione precedente del kernel.

  • RHEL/CentOS/Oracle Linux

    yum reinstall kernel-3.10.0-1160.59.1.el7.x86_64

    Importante

    Sostituire 3.10.0-1160.59.1.el7.x86_64 con la versione del kernel corrispondente.

  • SLES 12/15

    zypper refresh
zypper install -f kernel-azure-5.3.18-150300.38.75.1.x86_64

    Importante

    Sostituire kernel-azure-5.3.18-150300.38.75.1.x86_64 con la versione del kernel corrispondente.

    • Ubuntu 18.04/20.04

      apt update
apt install --reinstall linux-azure=5.4.0.1091.68

      Importante

      Sostituire 5.4.0.1091.68 con la versione del kernel corrispondente.

Per aggiornare il sistema e applicare le modifiche più recenti disponibili, eseguire uno dei comandi seguenti:

  • RHEL/CentOS/Oracle Linux

    yum update

  • SLES 12/15

    zypper refresh
zypper update

  • Ubuntu 18.04/20.04

    apt update
apt upgrade

I panico del kernel potrebbero essere correlati a uno degli elementi seguenti. Per altre informazioni, vedere Panico del kernel in fase di esecuzione.

  • Modifiche al carico di lavoro dell'applicazione.
  • Bug di sviluppo di applicazioni o applicazioni.
  • Problemi correlati alle prestazioni e così via.

Passaggi successivi

Se l'errore di avvio specifico non è un problema di avvio correlato al kernel, 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.