Máquina virtual do Azure Linux falha ao inicializar após aplicar alterações no kernel

Artigo
04/15/2024

Observação

O CentOS referenciado neste artigo é uma distribuição do Linux e chegará ao EOL (End Of Life). Considere seu uso e planeje de acordo. Para obter mais informações, confira Diretrizes de Fim de Vida do CentOS.

Este artigo fornece soluções para um problema no qual uma VM (máquina virtual) do Linux não pode inicializar depois de aplicar alterações no kernel.

Pré-requisitos

Verifique se o console serial está habilitado e funcional na VM do Linux.

Como identificar o problema de inicialização relacionado ao kernel

Para identificar um problema de inicialização relacionado ao kernel, marcar a cadeia de caracteres de pânico do kernel específica. Para fazer isso, use a CLI do Azure ou o portal do Azure para exibir a saída de log do console serial da VM no painel inicial diagnóstico ou console serial.

Um pânico de kernel se parece com a seguinte saída e aparecerá no final do log do console serial:

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

Solução de problemas on-line

Dica

Se você tiver um backup recente da VM, restaure a VM do backup para corrigir o problema de inicialização.

O console serial é o método mais rápido para resolve o problema de inicialização. Ele permite que você corrija diretamente o problema sem precisar apresentar o disco do sistema a uma VM de recuperação. Verifique se você atende aos pré-requisitos necessários para sua distribuição. Para obter mais informações, confira Console serial de máquina virtual para Linux.

Identifique o problema de inicialização específico relacionado ao kernel.
Use o console serial do Azure para interromper sua VM no menu GRUB e selecione qualquer kernel anterior para inicializar. Para obter mais informações, confira Sistema de inicialização na versão mais antiga do kernel.
Vá para a seção correspondente para resolve o problema de inicialização específico relacionado ao kernel:
Depois que o problema de inicialização relacionado ao kernel for resolvido, reinicie a VM para que ela possa inicializar a versão mais recente do kernel.

Solução de problemas off-line

Dica

Se você tiver um backup recente da VM, restaure a VM do backup para corrigir o problema de inicialização.

Se o console serial do Azure não funcionar na VM específica ou não for uma opção em sua assinatura, resolva o problema de inicialização usando uma VM de resgate/reparo. Para fazer isso, siga estas etapas:

Use comandos de reparo vm para criar uma VM de reparo que tenha uma cópia anexada do disco do sistema operacional da VM afetada. Monte a cópia dos sistemas de arquivos do sistema operacional na VM de reparo usando chroot.

Observação

Como alternativa, você pode criar uma VM de resgate manualmente usando o portal do Azure. Para obter mais informações, consulte Solucionar problemas de uma VM do Linux anexando o disco do sistema operacional a uma VM de recuperação usando o portal do Azure.
Identifique o problema de inicialização específico relacionado ao kernel.
Vá para a seção correspondente para resolve o problema de inicialização específico relacionado ao kernel:
Depois que o problema de inicialização relacionado ao kernel for resolvido, execute as seguintes ações:
1. Saia do chroot.
2. Desmonte a cópia dos sistemas de arquivos da VM de resgate/reparo.
3. Execute o comando az vm repair restore para trocar o disco reparado do sistema operacional pelo disco original do sistema operacional da VM. Para obter mais informações, consulte a Etapa 5 em Reparar uma VM do Linux usando os comandos de reparo da Máquina Virtual do Azure.
4. Valide se a VM pode inicializar examinando o console serial do Azure ou tentando se conectar à VM.
Se houver conteúdos importantes relacionados ao kernel, a partição inteira /boot ou outros conteúdos importantes estiverem ausentes e eles não puderem ser recuperados, recomendamos restaurar a VM de um backup. Para obter mais informações, consulte Como restaurar dados de VM do Azure no portal do Azure.

Sistema de inicialização na versão mais antiga do kernel

Usar o console serial do Azure

Reinicie a VM usando o console serial do Azure.
1. Selecione o botão de desligamento na parte superior da janela do console serial.
2. Selecione a opção Reiniciar VM (Hard).
Depois que a conexão do console serial for retomada, você verá um contador de contagem regressiva no canto superior esquerdo da janela do console serial. Pressione a tecla ESCAPE para interromper sua VM no menu GRUB.
Pressione a tecla de seta para baixo para selecionar qualquer versão anterior do kernel.
Altere a GRUB_DEFAULT variável no arquivo /etc/default/grub conforme instruído em Alterar a versão padrão do kernel manualmente. Essa é uma alteração persistente.

Observação

Se houver apenas uma versão do kernel listada no menu GRUB, siga a abordagem de solução de problemas offline para solucionar esse problema de uma VM de reparo.

Usar A VM de reparo (scripts ALAR)

Execute o seguinte comando bash no Azure Cloud Shell para criar uma VM de reparo. Para obter mais informações, consulte Usar o ALAR (Reparo Automático) do Linux do Azure para corrigir uma Opção de VM do Linux – kernel.
```
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
```

Execute o seguinte comando para substituir o kernel quebrado pela versão instalada anteriormente:

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

Observação

Se houver apenas uma versão do kernel instalada no sistema, siga a abordagem de solução de problemas offline para solucionar esse problema de uma VM de reparo.

Alterar manualmente a versão padrão do kernel

Para modificar a versão padrão do kernel de uma VM de reparo (dentro do chroot) ou em uma VM em execução, siga estas etapas:

Observação

Se uma reversão de downgrade do kernel for feita, selecione a versão mais recente do kernel em vez da mais antiga.

RHEL 7, Oracle Linux 7 e CentOS 7
1. Valide a lista de kernels disponíveis no arquivo de configuração do GRUB executando um dos seguintes comandos:
  - VMs gen1:
```
cat /boot/grub2/grub.cfg | grep menuentry
```
  - VMs gen2:
```
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
```
2. Defina o novo kernel padrão e especifique o título do kernel correspondente executando o seguinte comando:
```
# grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64'
```
  Observação
  
  Substitua Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 pelo título de entrada do menu correspondente.
3. Valide se o novo kernel padrão é o desejado executando o seguinte comando:
```
grub2-editenv list
```
4. Verifique se o valor da GRUB_DEFAULT variável no arquivo /etc/default/grub está definido como saved. Para modificá-lo, certifique-se de regenerar o arquivo de configuração grub para aplicar as alterações.
RHEL 8/9 e CentOS 8
1. Liste os kernels disponíveis executando o seguinte comando:
```
ls -l /boot/vmlinuz-*
```
2. Defina o novo kernel padrão executando o seguinte comando:
```
grubby --set-default /boot/vmlinuz-4.18.0-372.19.1.el8_6.x86_64
```
  Observação
  
  Substitua 4.18.0-372.19.1.el8_6.x86_64 pela versão correspondente do kernel.
3. Valide se o novo kernel padrão é o desejado executando o seguinte comando:
```
grubby --default-kernel
```
SLES 15/12, Ubuntu 18.04/20.04
1. Liste os kernels disponíveis no arquivo de configuração grub executando o seguinte comando:
  - VMs gen1:
    - SLES 15/12:
```
cat /boot/grub2/grub.cfg | grep menuentry
```
    - Ubuntu 18.04/20.04:
```
cat /boot/grub/grub.cfg | grep menuentry
```
  - VMs gen2:
```
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
```
2. Defina o novo kernel padrão modificando o valor da GRUB_DEFAULT variável no arquivo /etc/default/grub . Para a versão mais recente do kernel instalada no sistema, o valor padrão é 0. O próximo kernel disponível está definido como "1>2".
```
vi /etc/default/grub
GRUB_DEFAULT="1>2"
```
  Observação
  
  Para obter mais informações sobre como configurar a GRUB_DEFAULT variável, consulte SUSE Boot Loader GRUB2 e Ubuntu Grub2/Setup. Como referência: o valor de menu de nível superior é 0, o primeiro valor de submenu de nível superior é 1 e cada valor de menu aninhado começa com 0. Por exemplo, "1>2" é a terceira menuentry do primeiro submenu.
3. Regenerar o arquivo de configuração grub para aplicar as alterações. Siga as instruções em Reinstalar GRUB e regenerar o arquivo de configuração grub para a distribuição e a geração de VM do Linux correspondentes.

Pânico do kernel – não sincronização: VFS: não é possível montar fs raiz em bloco desconhecido(0,0)

Esse erro ocorre devido a uma atualização recente do sistema (kernel). É mais comumente visto em distribuições baseadas em RHEL. Você pode identificar esse problema no console serial do Azure. Você verá qualquer uma das seguintes mensagens de erro:

"Pânico do kernel – não sincronização: VFS: não é possível montar fs raiz em bloco desconhecido(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)

"erro: arquivo '/initramfs-*.img' não encontrado"

erro: o arquivo '/initramfs-3.10.0-1160.36.2.el7.x86_64.img' não foi encontrado.

Esse tipo de erro indica que o arquivo initramfs não é gerado, o arquivo de configuração grub tem a entrada initrd ausente após um processo de patch ou uma configuração incorreta manual do GRUB.

Antes de reiniciar um servidor, recomendamos validar a configuração e /boot o conteúdo do GRUB se houver uma atualização do kernel executando um dos seguintes comandos. É importante garantir que a atualização seja feita e não haja arquivos initramfs ausentes.

Bios based - Gen1 systems

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

UeFI based - Gen2 systems

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

Regenerar initramfs ausentes usando scripts da VM ALAR de reparo do Azure

Crie uma VM de reparo executando a linha de comando bash a seguir com o Azure Cloud Shell. Para obter mais informações, consulte Usar o ALAR (Reparo Automático) do Azure Linux para corrigir uma VM do Linux – opção initrd.
```
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
```
Regenerar a imagem initrd/initramfs e regenerar o arquivo de configuração grub se ele tiver a entrada initrd ausente. Para fazer isso, execute o seguinte 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
```
Depois que o comando de restauração tiver sido executado, reinicie a VM original e valide se ele é capaz de inicializar.

Regenerar initramfs ausentes manualmente

Importante

Se você conseguir inicializar a VM usando uma versão anterior do kernel ou dentro do chroot da VM de reparo/resgate, regenerar initramfs ausentes manualmente.
Para regenerar initramfs ausentes manualmente de uma VM de reparo, verifique se a etapa 1 na solução de problemas offline já foi seguida e esses comandos são executados dentro do chroot.

Identifique a versão específica do kernel que tem problemas com inicialização. Você pode extrair as informações de versão do erro de pânico do kernel correspondente.

Consulte a captura de tela a seguir como um exemplo. O erro de pânico do kernel mostra que a versão do kernel é "3.10.0-1160.59.1.el7.x86_64":
Regenera o arquivo initramfs ausente executando um dos seguintes comandos:
- 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
  
  Substitua 3.10.0-1160.59.1.el7.x86_64 pela versão correspondente do kernel.
- SLES 15/12
```
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
  
  Substitua 5.3.18-150300.38.53-azure pela versão correspondente do kernel.
- Ubuntu 18.04
```
sudo depmod -a 5.4.0-1077-azure
sudo mkinitramfs -k -o /boot/initrd.img-5.4.0-1077-azure
```
  Importante
  
  Substitua 5.4.0-1077-azure pela versão correspondente do kernel.
Regenerar o arquivo de configuração grub. Siga as instruções em Reinstalar GRUB e regenerar o arquivo de configuração grub para a distribuição e a geração de VM do Linux correspondentes
Se as etapas acima forem executadas a partir de uma VM de reparo, siga a etapa 3 na solução de problemas offline. Se as etapas acima forem executadas no console serial do Azure, siga o método de solução de problemas online .
Reinicialize sua VM na versão mais recente do kernel.

Pânico do kernel - não sincronização: tentativa de matar init

Identifique esse problema no console serial do Azure. Você verá a saída como a seguinte:

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

Esse tipo de pânico de kernel ocorre devido às seguintes possíveis causas:

Arquivos e diretórios importantes ausentes.
Faltam bibliotecas e pacotes importantes do sistema
Permissões de arquivo erradas
Partições ausentes
Problemas do SELinux

Consulte as seções a seguir para obter detalhes e soluções de causa. Verifique se os comandos são executados de uma VM de reparo/resgate dentro de um ambiente chroot, conforme instruído na solução de problemas offline.

Arquivos e diretórios importantes ausentes

Arquivos e diretórios importantes do Linux estão ausentes devido a um erro humano. Por exemplo, os arquivos são excluídos acidentalmente ou corrupção do sistema de arquivos.

Valide o conteúdo do disco do sistema operacional depois de anexar a cópia do disco do sistema operacional a uma VM de reparo e montar os sistemas de arquivos correspondentes usando chroot. Você pode comparar as saídas com as de uma VM em funcionamento que executa a mesma versão do sistema operacional.
```
ls -l /
ls -l /usr/lib
ls -l /usr/lib64
ls -lR / | more
```
Restaure os arquivos ausentes de um backup. Para obter mais informações, consulte Recuperar arquivos do backup da máquina virtual do Azure. Dependendo do número de arquivos ausentes, talvez seja melhor fazer uma restauração completa da VM. Para obter mais informações, consulte Como restaurar dados de VM do Azure no portal do Azure.

Faltam bibliotecas e pacotes importantes do sistema

Bibliotecas, arquivos ou pacotes importantes do sistema são excluídos do sistema ou corrompidos. Para resolve esse problema, reinstale as bibliotecas, arquivos ou pacotes afetados. Essa solução funciona em distribuições baseadas em RPM, como VMs Red Hat/CentOS/SUSE. Para outras distribuições do Linux, recomendamos restaurar a VM do backup.

Para executar a reinstalação, siga estas etapas:

Crie uma VM de resgate usando uma imagem bruta com a mesma versão e geração do sistema operacional que a VM afetada.
Acesse o ambiente chroot na VM de resgate para solucionar o problema.
```
sudo chroot /rescue
```
A saída de comando indicará qual biblioteca está ausente ou corrompida, conforme mostrado abaixo:
```
/bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
```

Verifique todos os pacotes do sistema e seus status correspondentes na VM de resgate. Compare a saída com uma VM saudável que executa a mesma versão do sistema operacional.

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

Aqui está um exemplo da saída de 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

A linha missing /lib64/libc-2.28.so de saída está relacionada ao erro anterior na etapa 2 e indica que o pacote libc-2.28.so está ausente. No entanto, o pacote libc-2.28.so pode ser modificado. Nesse caso, a saída será exibida .M..... em vez de missing. O pacote libc-2.28.so é referenciado como um exemplo nas etapas a seguir.

Na VM de resgate, verifique qual pacote contém a biblioteca /lib64/libc-2.28.soo.
```
sudo rpm -qf /lib64/libc-2.28.so
```
```
glibc-2.28-127.0.1.el8.x86_64
```
Observação

A saída mostrará o pacote que precisa ser reinstalado, incluindo o nome do pacote e a versão. A versão do pacote pode ser diferente da instalada na VM afetada.

Na VM afetada, verifique qual versão do pacote glibc está instalada.

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

Baixe o pacote glibc-2.28-211.0.1.el8.x86_64. Você pode baixá-lo no site oficial do fornecedor do sistema operacional ou na VM de resgate usando uma ferramenta de gerenciamento de pacotes como yumdownloader ou zypper install --download-only <packagename> dependendo do sistema operacional em execução.

Aqui está um exemplo de como usar a yumdownloader ferramenta:
```
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    
```

Reinstale o pacote afetado na VM de resgate.

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%]

Acesse o ambiente chroot na VM de resgate para validar a reinstalação.
```
sudo chroot /rescue
```
Desative a VM de resgate e troque o disco do sistema operacional para a VM afetada.

Permissões de arquivo erradas

Permissões de arquivo em todo o sistema erradas são modificadas devido a um erro humano (por exemplo, alguém é executado chmod 777 em ou em outros sistemas de arquivos importantes do / sistema operacional). Para resolve esse problema, restaure as permissões de arquivo. Essa solução funciona em distribuições baseadas em RPM, como VMs Red Hat/CentOS/SUSE. Para outras distribuições do Linux, recomendamos restaurar a VM do backup.

Para restaurar as permissões de arquivo, execute o seguinte comando depois de anexar a cópia do disco do sistema operacional a uma VM de reparo e montar os sistemas de arquivos correspondentes 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

Observação

Não execute esse comando na execução de sistemas de produção.

Se o problema ainda existir depois de recuperar manualmente as permissões de arquivo correspondentes, execute uma restauração do backup.

Partições ausentes

Nos casos /usrem que os sistemas de arquivos , /opt, /var, /home, /tmpe / são espalhados por diferentes partições, os dados podem ser inacessíveis devido a problemas no nível de partições, que podem ser causados por erros durante operações de redimensionamento de partição ou outros.

Nesse cenário, se você documentar o layout da tabela de partição original, com os setores de início e final exatos para cada uma das partições originais, e nenhuma modificação adicional for feita no sistema, como a criação de novos sistemas de arquivos, recrie as partições usando o mesmo layout original com ferramentas como fdisk (para tabelas de partição MBR) ou gdisk (para tabelas de partição GPT) para obter acesso ao sistema de arquivos ausente.

Se essa abordagem não funcionar, execute uma restauração do backup.

Problemas do SELinux

Permissões SELinux erradas podem impedir que o sistema acesse arquivos importantes. Para resolver esse problema, siga estas etapas:

Para verificar se o sistema tem problemas devido a permissões SELinux erradas, inicie o sistema com SELinux desabilitado adicionando a opção selinux=0 kernel à linha GRUB linux16.
Se o sistema for capaz de inicializar, execute o seguinte comando para disparar um relançamento SELinux na hora da inicialização e reinicializar o sistema:
```
touch /.autorelabel
```
Se a VM ainda não puder inicializar, faça uma restauração de VM completa do backup. Para obter mais informações, consulte Como restaurar dados de VM do Azure no portal do Azure.

Outros problemas de inicialização relacionados ao kernel

Este artigo aborda os pânicos de kernel linux mais comuns identificados no Azure. Para obter mais informações sobre cenários comuns de pânico do kernel, confira Pânico do Kernel em VMs linux do Azure – eventos comuns de pânico do kernel.

Há alguns outros possíveis pânicos de kernel importantes que podem causar nenhum cenário de inicialização ou nenhum SSH (shell seguro).

Execute todos os comandos de uma VM de reparo dentro de um ambiente chroot, conforme instruído na solução de problemas offline. Se o sistema já estiver inicializado em uma versão anterior do kernel, esses comandos também poderão ser executados na VM original usando privilégios raiz ou sudo, conforme instruído na solução de problemas online.

Atualização recente do kernel

Se o kernel entrar em pânico após uma atualização recente do kernel, inicialize a VM na versão anterior do kernel. Para obter mais informações, confira Sistema de inicialização na versão mais antiga do kernel.

Você também pode marcar se já houver uma versão mais recente do kernel lançada pelo fornecedor de distribuição do Linux e instalá-la. Para obter mais informações sobre como instalar a versão mais recente do kernel, consulte Processo de atualização do Kernel.

Downgrade recente do kernel

Se o kernel entrar em pânico começar após um downgrade recente do kernel, retorne ao kernel instalado mais recente. Você também pode marcar se já houver uma versão mais recente do kernel lançada pelo fornecedor de distribuição do Linux e instalá-la. Para obter mais informações sobre como instalar a versão mais recente do kernel, consulte Processo de atualização do Kernel.

Para inicializar o sistema na versão mais recente do kernel, siga as instruções em Alterar manualmente a versão padrão do kernel, mas selecione o primeiro kernel listado no menu GRUB. Em uma modificação manual, você pode definir o GRUB_DEFAULT valor como 0 e regenerar o arquivo de configuração grub correspondente.

Alterações no módulo kernel

Você pode ter um pânico de kernel relacionado a um novo módulo do kernel ou a um módulo de kernel ausente. Para obter detalhes sobre o módulo de kernel específico que causa problemas (se houver), marcar o rastreamento de pânico do kernel correspondente.

Para validar os módulos de kernel carregados e os desabilitados em arquivos /etc/modprobe.d/*.conf , execute um dos seguintes comandos:

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

Substitua 3.10.0-1160.59.1.el7.x86_64 pela versão correspondente do kernel.
SLES 15/12
```
lsinitrd /boot/initrd-5.3.18-150300.38.53-azure
lsmod
cat /etc/modprobe.d/*.conf
```
Importante

Substitua 5.3.18-150300.38.53-azure pela versão correspondente do kernel.
Ubuntu 18.04
```
lsinitramfs /boot/initrd.img-5.4.0-1077-azure
lsmod
cat /etc/modprobe.d/*.conf
```
Importante

Substitua 5.4.0-1077-azure pela versão correspondente do kernel.

Para remover qualquer módulo de kernel específico, execute o comando a seguir e regenera os initramfs , se necessário.

rmmod <kernel_module_name>

Se um serviço do sistema usar o módulo de kernel específico, desabilite-o executando o systemctl disable <serviceName> comando ou systemctl stop <serviceName> .

Alterações de configuração recentes do sistema operacional

Identifique as alterações recentes de configuração do kernel que possam causar problemas. Para resolve os problemas, ajuste essas configurações ou reverta as alterações de configuração.

Execute o seguinte comando para encontrar parâmetros de kernel persistentes configurados em qualquer um dos seguintes arquivos:

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

Execute o seguinte comando para analisar os parâmetros atuais do kernel e seus valores atuais:

sysctl -a

Observação

Execute esse comando em um sistema em execução e não em um ambiente chroot.

Possíveis arquivos ausentes

Para obter mais informações sobre esse tipo de problema, consulte Arquivos e diretórios importantes ausentes.

Permissões erradas em arquivos

Para obter mais informações sobre esse tipo de problema, consulte Permissões de arquivo erradas.

Partições ausentes

Para obter mais informações sobre esse tipo de problema, consulte Partições ausentes.

Bugs do Kernel

Identifique esse problema no console serial do Azure. Esse tipo de problema será semelhante à seguinte saída:

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

Esse tipo de pânico do kernel está associado a bugs do kernel ou bugs de kernel de terceiros.

Para corrigir bugs do kernel, pesquise a Base de Conhecimento do fornecedor usando a cadeia de caracteres BUG do kernel e procure problemas conhecidos na versão do kernel correspondente que seu sistema está executando. Aqui estão alguns recursos importantes do fornecedor:

Analisador de Oops do Kernel do Red Hat

Essa ferramenta foi projetada para ajudar você a diagnosticar uma falha no kernel. Quando você insere um texto, vmcore-dmesg.txtou um arquivo, incluindo uma ou mais mensagens de oops do kernel, ele o acompanhará diagnosticando o problema de falha do kernel.
Red Hat base de dados de conhecimento

Para obter acesso aos recursos do Red Hat, vincule suas contas do Microsoft Azure e Red Hat. Para obter mais informações, confira Como os clientes do Microsoft Azure podem acessar o Portal do Cliente do Red Hat.
SUSE base de dados de conhecimento
Ubuntu base de dados de conhecimento

Recomendamos manter todos os sistemas atualizados para descartar possíveis bugs já corrigidos nas versões mais recentes do kernel. Para obter mais informações, confira Processo de atualização do Kernel.

Se for necessária uma análise adicional do fornecedor, configure e habilite o kdump para gerar um despejo principal:

Processo de atualização do Kernel

Para instalar a versão mais recente do kernel disponível, execute um dos seguintes comandos:

RHEL/CentOS/Oracle Linux
```
yum update kernel
```
SLES 15/12
```
zypper refresh
zypper update kernel*
```
Ubuntu 18.04/20.04
```
apt update
apt install linux-azure
```

Para reinstalar uma versão específica do kernel, execute um dos seguintes comandos. Verifique se você não está inicializado na mesma versão do kernel que está tentando reinstalar. Para obter mais informações, confira Sistema de inicialização na versão mais antiga do kernel.

RHEL/CentOS/Oracle Linux
```
yum reinstall kernel-3.10.0-1160.59.1.el7.x86_64
```
Importante

Substitua 3.10.0-1160.59.1.el7.x86_64 pela versão correspondente do kernel.
SLES 15/12
```
zypper refresh
zypper install -f kernel-azure-5.3.18-150300.38.75.1.x86_64
```
Importante

Substitua kernel-azure-5.3.18-150300.38.75.1.x86_64 pela versão correspondente do kernel.
- Ubuntu 18.04/20.04
```
apt update
apt install --reinstall linux-azure=5.4.0.1091.68
```
  Importante
  
  Substitua 5.4.0.1091.68 pela versão correspondente do kernel.

Para atualizar o sistema e aplicar as alterações disponíveis mais recentes, execute um dos seguintes comandos:

RHEL/CentOS/Oracle Linux
```
yum update
```
SLES 15/12
```
zypper refresh
zypper update
```
Ubuntu 18.04/20.04
```
apt update
apt upgrade
```

Os pânicos do Kernel podem estar relacionados a qualquer um dos itens a seguir. Para obter mais informações, confira Pânicos do Kernel em tempo de execução.

Alterações na carga de trabalho do aplicativo.
Desenvolvimento de aplicativos ou bugs de aplicativo.
Problemas relacionados ao desempenho e assim por diante.

Próximas etapas

Se o erro de inicialização específico não for um problema de inicialização relacionado ao kernel, consulte Solucionar problemas do Azure Linux Máquinas Virtuais erros de inicialização para obter mais opções de solução de problemas.

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.

Máquina virtual do Azure Linux falha ao inicializar após aplicar alterações no kernel

Pré-requisitos

Como identificar o problema de inicialização relacionado ao kernel

Solução de problemas on-line

Solução de problemas off-line

Sistema de inicialização na versão mais antiga do kernel

Usar o console serial do Azure

Usar A VM de reparo (scripts ALAR)

Alterar manualmente a versão padrão do kernel

Pânico do kernel – não sincronização: VFS: não é possível montar fs raiz em bloco desconhecido(0,0)

Regenerar initramfs ausentes usando scripts da VM ALAR de reparo do Azure

Regenerar initramfs ausentes manualmente

Pânico do kernel - não sincronização: tentativa de matar init

Arquivos e diretórios importantes ausentes

Faltam bibliotecas e pacotes importantes do sistema

Permissões de arquivo erradas

Partições ausentes

Problemas do SELinux

Outros problemas de inicialização relacionados ao kernel

Atualização recente do kernel

Downgrade recente do kernel

Alterações no módulo kernel

Alterações de configuração recentes do sistema operacional

Possíveis arquivos ausentes

Permissões erradas em arquivos

Partições ausentes

Bugs do Kernel

Processo de atualização do Kernel

Próximas etapas

Entre em contato conosco para obter ajuda

Comentários

Comentários

Recursos adicionais