Solucionar problemas de inicialização da máquina virtual Linux devido a erros do sistema de arquivos
Aplica-se a: ✔️ VMs linux
Este artigo fornece orientação para solucionar problemas de inicialização da máquina virtual (VM) do Linux causados por erros do sistema de arquivos.
Sintomas
Você não pode se conectar a uma máquina virtual (VM) Linux do Azure usando o protocolo Secure Shell (SSH) ou o status do agente VM no portal do Azure não está pronto. Ao executar o Diagnóstico de inicialização no portal do Azure ou conectar-se ao Console serial, você verá entradas de log semelhantes aos seguintes exemplos:
Observação
- Nem todos os exemplos estarão presentes.
- Uma falha de montagem nem sempre resulta em uma VM entrando no modo de emergência. Se o problema for com determinados sistemas de arquivos críticos, a VM pode não usar o modo de emergência.
Exemplo 1: Falha ao montar o sistema de arquivos 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.
Exemplo 2: Falha ao montar o dispositivo ext Logical Volume Manager (LVM)
[ 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.
Exemplo 3: Falha ao montar o sistema de arquivos 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.
Exemplo 4: inicialize no modo de emergência
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):
Motivo
As entradas de log acima indicam corrupção de disco. Em determinadas situações, a corrupção do disco impedirá a inicialização completa da VM. Vários problemas podem causar corrupção de disco, como problemas de kernel do Linux, erros de driver, erros no hardware físico ou virtual subjacente e assim por diante.
Resolução
Para resolver os problemas de inicialização da VM do Linux causados por erros do sistema de arquivos, recupere a VM reparando a corrupção do disco. Para reparar a corrupção do disco, siga estas etapas:
Prepare o ambiente de recuperação de acordo com o modo de recuperação selecionado:
Use ferramentas de linha de comando para reparar o sistema de arquivos problemático no disco.
Observação
- É importante fazer backup de dados críticos porque pode ocorrer perda de dados no disco recuperado.
- Antes de fazer alterações em um disco, tire um instantâneo para preservar o estado atual do disco, mesmo que esteja em estado de erro. Corrigir a corrupção do disco alterará os dados no disco, o que acarretará riscos.
Identifique qual disco está corrompido
Para determinar qual disco está corrompido, baixe o log serial para sua VM usando o console serial ou o diagnóstico de inicialização, examine as entradas do log durante a inicialização e procure o erro específico chamando qual disco ou montagem está falhando.
Aqui estão três exemplos de entrada de log. Nesses exemplos, observe o texto entre parênteses, que relata o dispositivo corrompido.
No exemplo a seguir, o dispositivo corrompido é 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.
No exemplo a seguir, a partição onde ocorre um erro de sistema de arquivos é 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.
No exemplo a seguir, o dispositivo corrompido é dm-2. É um dispositivo Linux Device Mapper, que indica um 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‧o‧dispositivo‧de‧disco‧chamado‧usar‧um‧nome‧no‧formato‧"sdXN",‧onde‧X‧é‧uma‧letra‧de‧a-z‧e‧N‧é‧um‧número‧de‧partição‧opcional,‧isso‧significa‧que‧o‧disco‧é‧bruto‧e‧pode‧ser‧operado‧usando‧o‧caminho‧/‧dev/sdXN.
Se o dispositivo de disco sendo montado usar um nome como /dev/mapper/vgname/lvname, /dev/vgname/lvname ou dm-N, significa que um dispositivo LVM é usado. Tome cuidado para reconhecer todos os volumes físicos de disco (PVs) que podem estar em uso.
Não há suporte para o grupo de volumes LVM (VG) conter o disco do sistema operacional e qualquer número de discos de dados. Nesse cenário, há um alto risco de perda de dados. No entanto, vários discos de dados são permitidos em um LVM VG.
Ao determinar o mapeamento de referências de disco do sistema operacional para objetos de disco do Azure:
- Para imagens do mercado, o sistema de arquivos raiz (/), /boot e /boot/efi está localizado no disco do sistema operacional.
- Para imagens baseadas em LVM, muitas outras montagens de sistema podem existir, como /home, /tmp, /usr, /var, /var/log e /opt.
- Sistemas de arquivos extras criados para aplicativos estão localizados em discos de dados, por exemplo, /data, /datadisk ou /sap. Configure-os corretamente para que o sistema possa inicializar mesmo se houver um erro. Se um disco de dados for um dispositivo que inicializa no modo de emergência, consulte evitar falha na inicialização.
Identifique o tipo de sistema de arquivos
Ao fazer a identificação inicial, o único método para determinar o tipo de disco é usar o log serial conforme examinado anteriormente em Identifique qual disco está corrompido. Quando o dispositivo de disco for relatado no log serial, serão exibidos erros do módulo do kernel do Linux para o sistema de arquivos. Observe cada linha em que EXT4-fs ou XFS é especificado. Para qualquer outro tipo de sistema de arquivos, o log está na mesma área. O sistema de arquivos observado nas entradas de log é determinado pelo arquivo /etc/fstab. Tome cuidado para verificar se o formato especificado está correto ao executar um reparo.
Depois de ter acesso a um shell interativo, execute o comando lsblk com o sinalizador -f da seguinte maneira para mostrar dispositivos, caminhos (se o sistema de arquivos estiver montado) e o tipo de sistema de arquivos que é lido no próprio disco.
[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
Aqui estão alguns pontos importantes na saída:
- Usando a exibição de arte ASCII, você pode ver que há volumes LVM presentes porque há um LVM2_MEMBER FSTYPE para sda4 contendo objetos com nomes como
rootvg-rootlverootvg-homelv. rootvg-homelvnão está montado, o que é indicado pelo campo MOUNTPOINT vazio.rootvg-homelvtem tipo de sistema de arquivos XFS. É um contraste com o erro de montagem EXT4 durante a inicialização. Se o tipo de sistema de arquivos for inconsistente, confie na saídalsblkem vez do conteúdo de fstab.
Selecione o modo de recuperação
Você pode recuperar uma VM online por meio do modo de emergência ou modo de usuário único ou offline usando uma VM de resgate.
Requisitos para recuperação online
O Console Serial acessa a VM.
Se o modo de emergência for usado, o console serial deve exibir um prompt de modo de emergência, a conta root deve ser desbloqueada e a senha deve ser conhecida.
Se o modo de usuário único for usado, a senha root não é necessária. O modo de usuário único pode ser usado quando um sistema de arquivos diferente das partições de sistema necessárias, como raiz (
/) ou/usr, está corrompido.
Requisitos para recuperação off-line
Se os requisitos do console serial para recuperação online não puderem ser atendidos, execute a recuperação offline usando uma VM de resgate. Para executar a recuperação offline, é necessária a capacidade de criar uma VM e gerenciar discos no Azure. Como alternativa, você pode usar uma VM do Linux em funcionamento com acesso no nível do Azure aos discos corrompidos.
Prepare o ambiente para recuperação online
Quando o modo de emergência for exibido no prompt de login da seguinte maneira, digite a senha 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 a senha root não for conhecida ou a conta root estiver bloqueada, como na saída a seguir, use o modo de usuário único:
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 o ambiente de recuperação online estiver inutilizável, prossiga para a recuperação offline.
Prepare o ambiente para recuperação offline
Em VMs de disco único ou quando a montagem com falha é uma partição do sistema, como o sistema de arquivos raiz (/) ou/usr, o método mais confiável para reparar o disco é usar uma VM de resgate para obter acesso ao disco. Você pode criar uma VM de resgate automaticamente ou manualmente.
Para a criação automatizada de uma VM de resgate, consulte Reparo de Máquina Virtual do Azure. Para a criação manual de uma VM de resgate, consulte criando uma VM de recuperação. Em ambos os casos, não monte os volumes do disco com problema porque um sistema de arquivos não deve ser montado para que os utilitários de reparo funcionem.
Execute o reparo do sistema de arquivos
Antes de reparar o sistema de arquivos, certifique-se de que as seguintes etapas foram concluídas:
- O problema de disco e partição, ou estrutura de volume LVM, foi identificado.
- O tipo de sistema de arquivos foi determinado.
- (Opcional) Uma cópia do disco com problema, ou discos em um grupo de volumes LVM estendido, foi anexada a uma VM de resgate.
- O acesso a um shell interativo foi garantido usando o acesso ao disco.
Para executar o reparo do sistema de arquivos, vá para Reparar sistema de arquivos ext4 ou Reparar sistema de arquivos XFS de acordo com o tipo de sistema de arquivos.
Independentemente do modo de recuperação usado, os comandos para executar o reparo do sistema de arquivos são os mesmos. A concha de emergência pode ter limitações. Se os comandos não estiverem disponíveis em um ambiente de modo de emergência ou houver erros sobre tipos de sistema de arquivos desconhecidos, prepare o ambiente para recuperação offline.
Os comandos para reparar o sistema de arquivos podem não corrigir todos os erros. Eles contornam corrupções de disco, mas ainda pode ocorrer perda de dados. Assim que a saída do comando indicar que o sistema de arquivos está limpo, remonte a VM original com o disco reparado e inicialize a VM para verificar os dados.
Nas seções a seguir, /dev/sdc1 é o sistema de arquivos corrompido no modo bruto e o LV homelv no VG rootvg é o volume LVM. Substitua esses valores pelo sistema de arquivos corrompido real em todas as instâncias.
Reparare o sistema de arquivos ext4
Use o comando fsck [-y] FILESYSTEM para reparar um sistema de arquivos ext4. Especifique o sistema de arquivos como uma partição de disco para um sistema de arquivos bruto, por exemplo /dev/sdc1, ou o caminho do volume lógico LVM/dev/rootvg/homelv.
Aqui está um exemplo de saída de 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 ~]#
A saída mostra que a confirmação para modificar o sistema de arquivos é solicitada três vezes. Se houver muitos pedidos, pressione CTRL C e reinicie fsck com o sinalizador -y para assumir "sim" para todas as perguntas. Se algum arquivo for relatado como sendo colocado em lost+found, identifique-o manualmente e coloque-o nos locais apropriados.
Se alguns erros ocorrerem e forem corrigidos posteriormente, execute o comando fsck novamente. Repita até que o comando fsck saia com o esatdo clean. Consulte a saída a seguir para ver um exemplo:
[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 ~]#
Repare o sistema de arquivos xfs
Aqui estão os comandos para reparar um sistema de arquivos XFS:
xfs_repair [-n] FILESYSTEMxfs_repair [-L] FILESYSTEMmount FILESYSTEM MOUNTPOINT
Para reparar um sistema de arquivos XFS, siga estas etapas:
Verifique os erros do sistema de arquivos usando o comando
xfs_repair -n, conforme a seguir:xfs_repair -n /dev/rootvg/homelvSe a verificação for bem-sucedida, continue com o modo de reparo removendo o sinalizador
-n, que tentará corrigir os erros encontrados, conforme a seguir:xfs_repair /dev/rootvg/homelv
Para sistemas de arquivos XFS, as alterações registradas, mas não confirmadas, são tratadas montando o sistema de arquivos. Se você encontrar o seguinte erro durante a solução de problemas, tente uma montagem e veja os resultados.
ERRO: O sistema de arquivos tem alterações valiosas de metadados em um registro que precisa ser repetido
Se uma VM de recuperação for usada, crie um diretório para um ponto de montagem temporário, como /recovery, e monte o sistema de arquivos. Se o ambiente de recuperação estiver em modo de emergência ou de usuário único, monte o sistema de arquivos no local pretendido. Consulte os comandos a seguir para ver um exemplo.
mount /dev/rootvg/homelv /recovery
ou
mount /home
Se as alterações registradas não forem gravadas quando você montar os sistemas de arquivos, use o sinalizador -L para descartar o diário e montar o sistema de arquivos como se todas as alterações fossem concluídas com êxito. Quando o sinalizador -L é usado, ocorrerá perda de dados porque o log mostra que operações de arquivo incompletas estão sendo descartadas.
xfs_repair -L /dev/rootvg/homelv /recovery
Evitar falha de inicialização
Se a opção nofail for especificada ao montar sistemas de arquivos, a corrupção de um sistema de arquivos não crítico pode não impedir que o Linux inicialize totalmente. Para obter mais informações sobre nofail, consulte Montar o disco. A maioria das montagens além da raiz (/), /usr e /var podem ser feitas com nofail.
Entre em contato conosco para obter ajuda
Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.