Solucionar problemas de falhas de inicialização uefi em máquinas virtuais do Azure Linux

Aplica-se a: ✔️ Linux VMs

Observação

CentOS mencionado neste artigo é uma distribuição Linux e em breve atingirá seu status de fim de suporte (End Of Life - EOL). Considere seu uso e planeje adequadamente. Para obter mais informações, consulte Diretrizes de fim da vida útil do CentOS.

Resumo

As imagens de parceiro do Linux em Azure Marketplace são marcadas e configuradas para inicialização de geração 1 do BIOS e inicialização da UEFI (Unified Extensible Firmware Interface) geração 2.

Quando você implanta VMs (máquinas virtuais) linux de geração 2 em Azure, você pode encontrar falhas de inicialização UEFI. Este artigo discute alguns cenários em que ocorrem falhas de inicialização UEFI e fornece soluções.

Sintomas

Quando você implanta uma VM Linux de geração 2 em Azure, a inicialização falha e o servidor fica inacessível.

Identificar erros de inicialização UEFI

Verifique o estado atual da VM usando o diagnóstico de inicialização Azure.

A captura de tela do diagnóstico de inicialização mostra as seguintes mensagens de erro:

  • Erro 1

    Resumo de inicialização da máquina virtual

    1. Dispositivo desconhecido
      O carregador de inicialização não carregou um sistema operacional.
    2. Disco SCSI (0,0)
      O carregador de inicialização não carregou um sistema operacional.
    3. Disco SCSI (0,1)
      O carregador de inicialização não carregou um sistema operacional.
    4. Adaptador de rede (000D3A4DD64D)
      Uma imagem de inicialização não foi encontrada.

    Nenhum sistema operacional foi carregado. Sua máquina virtual pode estar configurada incorretamente. Saia e configure novamente sua VM ou clique em reiniciar para repetir a sequência de inicialização atual novamente.

    Captura de tela da mensagem de erro do hyper-V para imagem de inicialização UEFI ausente.

  • Erro 2

    Iniciar PXE por IPv4

    Captura de tela da transição do erro do hyper-V para o problema de inicialização PXE.

Antes de solucionar problemas

Para executar o reparo de VM offline necessário para Scenario 1: a partição UEFI na imagem de inicialização está ausente e Scenario 2: a partição UEFI na imagem de inicialização está corrompida, Verifique se você tem acesso a CLI do Azure ou Azure Cloud Shell.

Cenário 1: a partição UEFI na imagem de inicialização está ausente

Se a partição do carregador de inicialização UEFI estiver ausente ou excluída, a VM Linux de geração 2 falhará ao inicializar.

Para resolver esse problema, siga estas etapas:

  1. Use o comando az vm repair create para criar uma VM de reparo. A VM de reparo terá uma cópia do disco do sistema operacional para a VM não funcional anexada. Para obter mais informações, consulte Repair uma VM Linux usando os comandos de reparo da máquina virtual Azure.

  2. Recrie a partição usando os seguintes comandos:

    root@repair-centos7:~# gdisk /dev/sdc
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sdc: 134217728 sectors, 64.0 GiB
Model: Virtual Disk    
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): <Disk GUID>
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 1019837 sectors (498.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1         1026048         3123199   1024.0 MiB  0700  
   2         3123200       134215679   62.5 GiB    8E00  
  14            2048           10239   4.0 MiB     EF02  

Command (? for help): n
Partition number (3-128, default 3): 
First sector (34-134217694, default = 10240) or {+-}size{KMGTP}: 10240
Last sector (10240-1026047, default = 1026047) or {+-}size{KMGTP}: 1026047
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): ef00
Changed type of partition to 'EFI System'

Command (? for help): p
Disk /dev/sdc: 134217728 sectors, 64.0 GiB
Model: Virtual Disk    
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): <Disk GUID>
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1         1026048         3123199   1024.0 MiB  0700  
   2         3123200       134215679   62.5 GiB    8E00  
   3           10240         1026047   496.0 MiB   EF00  EFI System
  14            2048           10239   4.0 MiB     EF02  

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sdc.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

    Importante

    • Substitua /dev/sdc pela cópia correspondente do dispositivo de disco do sistema operacional (SO).
    • A escolha do número da partição não importa, desde que os pontos inicial e final do setor estejam corretos. Os pontos inicial e final corretos do setor são escolhidos porque o sistema operacional é capaz de determinar os setores ausentes.
    • Verifique se o setor final não está ocupado por nenhuma outra partição dentro do disco. A escolha de valores padrão deve ser suficiente aqui.

    As imagens de parceiros do Linux no Azure têm o seguinte número de partição, setor de início e setor de fim:

    Distribuição do sistema operacional Linux Número da partição EFI Início do Setor Fim do Setor
    CentOS 7 15 10240 1024000
    CentOS 8 15 10240 1024000
    Debian 10 15 8192 262143
    Debian 11 15 8192 262143
    RHEL 7 1 2048 1026047
    RHEL 8 15 10240 1024000
    Oracle Linux 7 15 10240 1024000
    Oracle Linux 8 15 10240 1024000
    Ubuntu 18.04 15 10240 227327
    Ubuntu 20.04 15 10240 227327
    SLES 12 2 6144 1054719
    SLES 15 2 6144 1054719

  3. Depois que a partição for recriada, restaure a VM trocando o disco do sistema operacional reparado pelo disco do sistema operacional original da VM usando o comando az vm repair restore . Para obter mais informações, consulte a etapa 5 em Recuperar uma VM Linux usando os comandos de reparo da máquina virtual Azure.

Cenário 2: a partição UEFI na imagem de inicialização está corrompida

Se a partição de inicialização UEFI estiver corrompida, a VM Linux de geração 2 não será inicializada. Para resolver esse problema, siga estas etapas:

  1. Use o comando az vm repair create para criar uma VM de reparo. A VM de reparo terá uma cópia do disco do sistema operacional para a VM não funcional anexada. Para obter mais informações, consulte Repair uma VM Linux usando os comandos de reparo da máquina virtual Azure.

  2. Limpe a partição corrompida usando os seguintes comandos:

    root@repair-centos7:~# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 134217728 sectors, 64.0 GiB
Model: Virtual Disk    
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): <Disk GUID>
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1         1026048         3123199   1024.0 MiB  0700  
   2         3123200       134215679   62.5 GiB    8E00  
   3           10240         1026047   496.0 MiB   EF00  EFI System
  14            2048           10239   4.0 MiB     EF02 

root@repair-centos7:~# fsck.vfat -n /dev/sdc3
fsck.fat 4.1 (2017-01-24)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
Leaving filesystem unchanged.
/dev/sdc3: 19 files, 1438/63326 clusters

root@repair-centos7:~# fsck.vfat /dev/sdc3
fsck.fat 4.1 (2017-01-24)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n) y
/dev/sdc3: 19 files, 1438/63326 clusters
root@repair-centos7:~# fsck.vfat /dev/sdc3
fsck.fat 4.1 (2017-01-24)
/dev/sdc3: 19 files, 1438/63326 clusters

    Importante

    • Substitua /dev/sdc pela cópia correspondente do dispositivo de disco do sistema operacional.
    • Sempre faça um backup do disco do sistema operacional e execute uma simulação com a opção -n antes de realizar a verificação do sistema de arquivos mencionada acima.
    • O dosfsck comando pode ser usado para executar a verificação do sistema de arquivos vfat. Ambos os comandos são iguais. Para obter mais informações, consulte fsck.vfat.

  3. Depois que a partição for limpa, restaure a VM trocando o disco do sistema operacional reparado pelo disco do sistema operacional original da VM usando o comando az vm repair restore . Para obter mais informações, consulte a etapa 5 em Recuperar uma VM Linux usando os comandos de reparo da máquina virtual Azure.

Cenário 3: todo o conteúdo da partição /boot é excluído

Se toda a partição /boot ou outros conteúdos importantes estiverem ausentes e não puderem ser recuperados, restaurar a VM de um backup será a única opção. Para obter mais informações, consulte Como restaurar dados de VM do Azure no portal do Azure.

  • Last updated on