Risolvere i problemi di avvio delle macchine virtuali Linux dovuti a errori del filesystem.
Questo articolo fornisce indicazioni per la risoluzione dei problemi di avvio delle macchine virtuali Linux (VM) causati da errori del filesystem.
Sintomi
Non è possibile connettersi a una macchina virtuale (VM) di Azure Linux usando il protocollo Secure Shell (SSH) oppure lo stato dell'agente di macchine virtuali nel portale di Azure non è Pronto. Quando esegui la Diagnostica di avvio nel portale di Azure o ti connetti alla Console seriale, vengono visualizzate voci di log simili ai seguenti esempi:
Nota
- Non tutti gli esempi saranno presenti.
- Un errore di montaggio non comporta sempre l'accesso della VM alla modalità di emergenza. Se il problema riguarda alcuni file system critici, la macchina virtuale potrebbe non utilizzare la modalità di emergenza.
Esempio 1: impossibile montare il filesystem ext4
EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.
Esempio 2: Impossibile montare il dispositivo LVM (Logical Volume Manager) ext
[ 14.382472] EXT4-fs error (device dm-0): ext4_iget:4398: inode #8: comm mount: bad extra_isize 4060 (inode size 256)
[ 14.389648] EXT4-fs (dm-0): no journal found
<snipped>
[FAILED] Failed to mount /opt/data.
Esempio 3: impossibile montare il filesystem xfs
[ 8.543984] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xd0/0xf0 [xfs], xfs_agi block 0x10
[ 8.553867] XFS (sdc1): Unmount and run xfs_repair
[ 8.558993] XFS (sdc1): First 128 bytes of corrupted metadata buffer:
[ 8.564893] 00000000: 58 41 47 49 00 00 00 01 00 00 00 00 00 1f ff c0 XAGI............
[ 8.572847] 00000010: 00 00 00 40 00 00 00 06 00 00 00 01 00 00 00 3d ...@...........=
[ 8.580476] 00000020: 00 00 00 60 ff ff ff ff ff ff ff ff ff ff ff ff ...`............
[ 8.588219] 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 8.596280] 00000040: ff 07 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 8.603575] 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 8.610849] 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 8.619261] 00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 8.629731] XFS (sdc1): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x10 len 8 error 74
[ 8.637799] XFS (sdc1): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
[FAILED] Failed to mount /data.
See 'systemctl status data.mount' for details.
[DEPEND] Dependency failed for Local filesystems.
Esempio 4: avvio in modalità di emergenza
You are in 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):
Causa
Le voci di registro precedenti indicano il danneggiamento del disco. In determinate situazioni, il danneggiamento del disco impedirà l'avvio completo della VM. Vari problemi possono causare il danneggiamento del disco, come problemi del kernel Linux, errori del driver, errori nell'hardware fisico o virtuale sottostante e così via.
Risoluzione
Per risolvere i problemi di avvio della macchina virtuale Linux causati da errori del filesystem, ripristinare la macchina virtuale riparando il disco danneggiato. Per riparare il danneggiamento del disco, attenersi alla seguente procedura:
Preparare l'ambiente di ripristino in base alla modalità di ripristino selezionata:
Usate gli strumenti da riga di comando per riparare il filesystem problematico sul disco.
Nota
- È importante eseguire il backup dei dati critici perché potrebbe verificarsi una perdita di dati sul disco ripristinato.
- Prima di apportare modifiche a un disco, crea uno snapshot per conservare lo stato corrente del disco, anche se si trova in uno stato di errore. La correzione del danneggiamento del disco cambierà i dati sul disco, il che comporterà dei rischi.
Identifica quale disco è danneggiato
Per determinare quale disco è danneggiato, scarica il registro seriale per la tua macchina virtuale utilizzando la console seriale o la diagnostica di avvio, esamina le voci del registro durante l'avvio e quindi cerca l'errore specifico che indica quale disco o montaggio non riesce.
Di seguito sono riportati tre esempi di voci di registro. In questi esempi, notare il testo tra parentesi, che segnala il dispositivo danneggiato.
Nell'esempio seguente, il dispositivo danneggiato è sdc1:
[ 14.285807] XFS (sdc1): Mounting V5 Filesystem
[ 14.426283] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xde/0x100 [xfs], xfs_agi block 0x10
[ 14.426284] XFS (sdc1): Unmount and run xfs_repair
<snipped>
[FAILED] Failed to mount /opt/parent.
Nell'esempio seguente, la partizione in cui si verifica un errore del file system è sda1:
EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.
<snipped>
[FAILED] Failed to mount /boot.
Nell'esempio seguente, il dispositivo danneggiato è dm-2. È un dispositivo Linux Device Mapper, che indica un volume LVM.
[ 18.014318] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
[FAILED] Failed to mount /home.
See 'systemctl status home.mount' for details.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Mark the need to relabel after reboot.
Se il dispositivo disco richiamato utilizza un nome nel formato "sdXN", dove X è una lettera dalla A alla Z e N è un numero di partizione opzionale, significa che il disco non è formattato e può essere utilizzato utilizzando il percorso /dev/sdXN.
Se il dispositivo disco montato utilizza un nome come /dev/mapper/vgname/lvname, /dev/vgname/lvname o dm-N, significa che viene utilizzato un dispositivo LVM. Prestare attenzione a riconoscere tutti i volumi fisici del disco (PV) che potrebbero essere in uso.
Non è supportato che il gruppo di volumi LVM (VG) contenga il disco del sistema operativo e un numero qualsiasi di dischi dati. Per uno scenario di questo tipo, esiste un rischio elevato di perdita di dati. Tuttavia, in un LVM VG sono consentiti più dischi dati.
Quando si determina il mapping dei riferimenti del disco del sistema operativo agli oggetti disco di Azure:
- Per le immagini del marketplace, il filesystem radice (/), /boot e /boot/efi si trova sul disco del sistema operativo.
- Per le immagini basate su LVM, possono esistere molti altri montaggi di sistema come /home, /tmp, /usr, /var, /var/log e /opt.
- I file system aggiuntivi creati per le applicazioni si trovano sui dischi dati, ad esempio /data, /datadisk o /sap. Configurali correttamente in modo che il sistema possa avviarsi anche se c'è un errore. Se un disco dati è un dispositivo che si avvia in modalità di emergenza, vedere prevenire errori di avvio.
Identificare il tipo del file system
Durante l'identificazione iniziale, l'unico metodo per determinare il tipo di disco consiste nell'utilizzare il log seriale come precedentemente esaminato in Identificare quale disco è danneggiato. Quando il dispositivo disco viene riportato nel registro seriale, gli errori vengono visualizzati dal modulo kernel Linux per il filesystem. Prendere nota di ogni riga in cui è specificato EXT4-fs o XFS. Per tutti gli altri tipi del filesystem, il registro si trova nella stessa area. Il filesystem indicato nelle voci di registro è determinato dal file /etc/fstab. Fare attenzione a verificare che il formato specificato sia corretto durante l'esecuzione di una riparazione.
Una volta ottenuto l'accesso a una shell interattiva, eseguire il comando lsblk con il flag -f come di seguito per visualizzare i dispositivi, i percorsi (se il filesystem è montato) e il tipo del filesystem letto dal disco stesso.
[root@localhost ~]# lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
|-sda1 vfat 93DA-8C20 /boot/efi
|-sda2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d /boot
|-sda3
`-sda4 LVM2_member pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU
|-rootvg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 /tmp
|-rootvg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d /usr
|-rootvg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 /opt
|-rootvg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0
|-rootvg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 /var
`-rootvg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 /
sdb
`-sdb1 ext4 1dac7c4c-bf8e-4964-8a59-7359eef53d0a /mnt
sdc LVM2_member CRWEZQ-iLhH-ev0b-BAaA-dfLD-nbPT-GgtG0r
`-vgapp-lvapp xfs 733e25ee-565f-4bfa-a2a1-2451efd25cd1
sdd
`-sdd1 ext4 704d9fb1-2207-4bb9-998c-029f776dc6d2 /opt/data
Ecco alcuni punti importanti nell'output:
- Utilizzando la visualizzazione grafica ASCII, è possibile vedere che sono presenti volumi LVM perché è presente un FSTYPE LVM2_MEMBER per sda4 contenente oggetti con nomi come
rootvg-rootlverootvg-homelv. -
rootvg-homelvnon è montato, come indicato dal campo vuoto MOUNTPOINT. -
rootvg-homelvha un tipo di filesystem XFS. È in contrasto con l'errore di montaggio EXT4 durante l'avvio. Se il tipo del filesystem è inconsistente, fidarsi dell'outputlsblkpiuttosto che del contenuto di fstab.
Seleziona la modalità di ripristino
È possibile ripristinare una macchina virtuale online tramite la modalità di emergenza o la modalità utente singolo oppure offline usando una macchina virtuale di ripristino.
Requisiti per il recupero online
La Console seriale accede alla VM.
Se si utilizza la modalità di emergenza, la console seriale deve visualizzare un prompt della modalità di emergenza, l'account root deve essere sbloccato e la password deve essere nota.
Se si utilizza la modalità utente singolo, la password di root non è necessaria. La modalità utente singolo può essere utilizzata quando un filesystem diverso dalle partizioni di sistema richieste, come root (
/) o/usr, è danneggiato.
Requisiti per il ripristino offline
Se non è possibile soddisfare i requisiti della console seriale per il ripristino online, eseguire il ripristino offline usando una macchina virtuale di ripristino. Per eseguire il ripristino offline, è necessaria la possibilità di creare una macchina virtuale e gestire i dischi in Azure. In alternativa, puoi usare una macchina virtuale Linux funzionante con accesso a livello di Azure ai dischi danneggiati.
Preparare l'ambiente per il ripristino online
Quando la modalità di emergenza viene visualizzata nella richiesta di accesso come segue, inserisci la password di root:
Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
try again to Give root password for maintenance
(or press Control-D to continue):
Se la password root non è nota o l'account root è bloccato, come nell'output seguente, utilizza la modalità utente singolo:
Welcome to emergency mode! After logging in, typ
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.
Se l'ambiente di ripristino online è inutilizzabile, procedere al ripristino offline.
Preparare l'ambiente per il ripristino offline
Nelle macchine virtuali a disco singolo o quando il montaggio non riuscito è una partizione di sistema come il file system root (/) o/usr, il metodo più affidabile per riparare il disco consiste nell'utilizzare una macchina virtuale di ripristino per ottenere l'accesso al disco. Puoi creare una macchina virtuale di salvataggio automaticamente o manualmente.
Per la creazione automatica di una macchina virtuale di ripristino, vedere Riparazione macchina virtuale di Azure. Per la creazione manuale di una VM di ripristino, vedere creazione di una VM di ripristino. In entrambi i casi, non montare i volumi dal disco problematico perché un filesystem non deve essere montato per far funzionare gli strumenti di riparazione.
Eseguire la riparazione del file system
Prima di riparare il filesystem, assicurarsi di aver completato i seguenti passaggi:
- Il problema del disco e della partizione, o struttura del volume LVM, è stato identificato.
- Il tipo del filesystem è stato determinato.
- (Facoltativo) Una copia del disco problematico o dei dischi in un gruppo di volumi LVM con spanning è stata collegata a una macchina virtuale di ripristino.
- L'accesso a una shell interattiva è stato protetto utilizzando l'accesso al disco.
Per eseguire la riparazione del filesystem, andare su Ripara filesystem ext4 o Ripara filesystem XFS a seconda del tipo di filesystem.
Indipendentemente dalla modalità di ripristino utilizzata, i comandi per eseguire la riparazione del filesystem sono gli stessi. Il guscio di emergenza può avere limitazioni. Se i comandi non sono disponibili in un ambiente in modalità di emergenza o sono presenti errori relativi a tipi di file system sconosciuti, preparare l'ambiente per il ripristino offline.
I comandi per riparare il filesystem potrebbero non correggere tutti gli errori. Funzionano attorno alla corruzione del disco, ma può comunque verificarsi una perdita di dati. Una volta che l'output del comando indica che il filesystem è pulito, riassemblare la macchina virtuale originale con il disco riparato e avviare la macchina virtuale per verificare i dati.
Nelle sezioni seguenti, /dev/sdc1 è il filesystem danneggiato in modalità RAW e LV homelv in VG rootvg è il volume LVM. Sostituire questi valori con il filesystem effettivamente danneggiato in tutte le istanze.
Riparare il file system ext4
Usare il comando fsck [-y] FILESYSTEM per riparare un filesystem ext4. Specificare il filesystem come partizione del disco per un filesystem RAW, ad esempio /dev/sdc1, o il percorso del volume logico LVM /dev/rootvg/homelv.
Ecco un esempio di output del comando:
[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
/dev/sdc1 was not cleanly unmounted, check forced.
Resize inode not valid. Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23508, counted=23509).
Fix<y>? yes
Free blocks count wrong (8211645, counted=8211646).
Fix<y>? yes
/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc1: 11/2097152 files (0.0% non-contiguous), 176706/8388352 blocks
[root@vm1dev ~]#
L'output mostra che la conferma di modificare il filesystem viene richiesta tre volte. In caso di molte richieste, premere CTRL+C e riavviare fsck con il flag -y per rispondere "Sì" a tutte le domande. Se alcuni file vengono segnalati come collocati in lost+found, identificarli manualmente e collocarli nella posizione corretta.
Se si verificano alcuni errori che vengono successivamente corretti, eseguire nuovamente il comando fsck. Ripetere finché il comando fsck non terminerà con lo stato clean. Fare riferimento al seguente output come esempio:
[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdc1: clean, 11/2097152 files, 176706/8388352 blocks
[root@vm1dev ~]#
Riparare il filesystem xfs
Ecco i comandi per riparare un filesystem XFS:
xfs_repair [-n] FILESYSTEMxfs_repair [-L] FILESYSTEMmount FILESYSTEM MOUNTPOINT
Per riparare un file system XFS, attenersi alla seguente procedura:
Controllare gli errori del filesystem utilizzando il comando
xfs_repair -n, come segue:xfs_repair -n /dev/rootvg/homelvSe il controllo ha esito positivo, continuare con la modalità di riparazione rimuovendo il flag
-n, che cercherà di correggere gli errori riscontrati, come segue:xfs_repair /dev/rootvg/homelv
Per i filesystem XFS, le modifiche senza commit nel journal vengono gestite montando il filesystem. Se riscontri il seguente errore durante la risoluzione dei problemi, prova a montare e visualizza i risultati.
ERRORE: il filesystem ha modificato dei metadati importanti in un registro che deve essere riprodotto
Se si utilizza una macchina virtuale di ripristino, creare una directory per un punto di montaggio temporaneo, ad esempio /recovery, e montare il filesystem. Se l'ambiente di ripristino è in modalità di emergenza o utente singolo, montare il filesystem nella posizione prevista. Fare riferimento ai seguenti comandi come esempi:
mount /dev/rootvg/homelv /recovery
oppure
mount /home
Se le modifiche nel journal non vengono scritte quando si monta il filesystem, usare il flag -L per scartare il journal e montare il filesystem come se tutte le modifiche fossero state completate con successo. Quando si utilizza il flag -L, si verifica una perdita di dati perché il registro mostra che le operazioni di file incomplete vengono eliminate.
xfs_repair -L /dev/rootvg/homelv /recovery
Prevenire l'errore di avvio
Se l'opzione nofail è specificata durante il montaggio dei filesystem, il danneggiamento di un filesystem non critico potrebbe non impedire l'avvio completo di Linux. Per ulteriori informazioni su nofail, vedere Montare il disco. La maggior parte dei montaggi, a parte il root (/), /usr e /var, possono essere effettuati con nofail.
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.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per