O que é o dracut emergency shell?

É o shell mínimo que o initramfs abre quando não consegue encontrar ou montar o sistema de arquivos raiz. Depois de uma troca de hipervisor quase sempre significa que falta ao initramfs o driver do novo controlador de disco, e não que o disco esteja danificado.

Não. O disco e seus volumes LVM estão intactos. O initramfs simplesmente não chega a eles pelo controlador VirtIO até ser reconstruído.

Migrei com uma versão anterior do Moov e a VM fica no emergency shell. O que faço?

As VMs Oracle Linux e RHEL migradas com a v1.0.39 até a v1.0.42 precisam que você execute uma vez dracut -f --regenerate-all dentro da VM. Inicie a entrada de resgate para entrar, execute e reinicie. Está corrigido desde a v1.0.43.

Acontece no Ubuntu e no Debian?

Raramente, porque o initramfs deles é genérico por padrão e já inclui os drivers VirtIO. Acontece quando o sistema ficou com MODULES=dep, e a correção é o update-initramfs depois de adicionar os módulos VirtIO.

Por que o RHEL 10 ou o Rocky 10 não iniciam mesmo com o initramfs correto?

Porque exigem o conjunto de instruções x86-64-v3. Uma VM com um modelo de CPU virtual mais antigo, como o x86-64-v2-AES, para logo no começo da inicialização. Defina o tipo de CPU como host ou como um modelo com x86-64-v3.

Moov · Guias práticos

Linux não inicia após migrar do VMware para o Proxmox: dracut emergency shell

Uma VM Linux que iniciava bem no VMware para no dracut emergency shell na primeira inicialização no Proxmox VE, oVirt / OLVM ou qualquer hipervisor KVM quando seu initramfs foi construído só para o hardware do VMware e não traz nenhum driver de armazenamento VirtIO. O kernel inicia, não encontra o sistema de arquivos raiz e desiste. O disco está intacto. A solução é iniciar uma vez por algo que o initramfs antigo consiga ler, reconstruir o initramfs com os drivers VirtIO e trocar de volta.

Por que acontece

O initramfs é a imagem pequena que o kernel usa para encontrar e montar o sistema de arquivos raiz. No RHEL, Oracle Linux, Rocky, AlmaLinux e SLES, o dracut o constrói por padrão em modo host-only: inclui só os drivers do hardware que o sistema tinha naquele momento. No VMware isso é o controlador VMware Paravirtual ou o LSI Logic. No KVM o disco fica em VirtIO SCSI ou VirtIO Block, o initramfs não tem virtio_scsi nem virtio_blk, e o volume raiz nunca aparece.

O kernel não é o problema: todas as distribuições suportadas trazem os drivers VirtIO como módulos. Eles simplesmente não estão dentro do initramfs. Por isso a correção é reconstruí-lo, e não instalar algo.

O Debian e o Ubuntu constroem por padrão um initramfs genérico, então normalmente iniciam. Falham do mesmo jeito quando o sistema foi configurado com MODULES=dep.

Há uma segunda causa, sem relação com a anterior, que parece igual em sistemas recentes: o modelo de CPU. O RHEL 10 e o Rocky 10 exigem o conjunto de instruções x86-64-v3, e uma VM criada com um modelo de CPU virtual mais antigo, como o x86-64-v2-AES no Proxmox, não passa do começo da inicialização.

Como corrigir manualmente

Os passos estão escritos para o Proxmox VE e valem do mesmo jeito para qualquer hipervisor KVM. A entrada de resgate é o caminho mais curto na família RHEL. A ISO de instalação serve em todas as distribuições.

01
Defina um modelo de CPU que o sistema aceite
Para o RHEL 10, o Rocky 10 e outros sistemas compilados para x86-64-v3, defina o tipo de CPU da VM como host, ou como um modelo que inclua x86-64-v3. No Proxmox é o campo Type, em Processors.
02
Inicie a entrada de resgate
Na família RHEL, o GRUB mantém uma entrada com rescue no nome. O initramfs dela é genérico e inclui os drivers VirtIO, então inicia onde a entrada normal não inicia. Abra o menu do GRUB na inicialização e escolha-a.
03
Se não há entrada de resgate, inicie pelo controlador que o initramfs antigo conhece
Se a VM usava o controlador VMware Paravirtual, defina o controlador SCSI da VM como VMware PVSCSI e inicie-a. O initramfs construído no VMware traz esse driver, então o volume raiz volta a aparecer. Se usava outro controlador, vá para o passo da ISO de instalação.
04
Reconstrua o initramfs
Com o sistema no ar, reconstrua o initramfs de todos os kernels instalados com os drivers VirtIO incluídos, e confira se ficaram dentro.
```
dracut -f --regenerate-all --add-drivers "virtio_blk virtio_scsi virtio_pci virtio_net"
lsinitrd | grep virtio
```

No Debian e no Ubuntu

Adicione os módulos VirtIO à configuração do initramfs e reconstrua-o para todos os kernels.

printf 'virtio_blk\nvirtio_scsi\nvirtio_pci\nvirtio_net\n' | sudo tee -a /etc/initramfs-tools/modules
sudo update-initramfs -u -k all

06
Volte para VirtIO SCSI
Desligue, defina o controlador SCSI como VirtIO SCSI e inicie a VM pela entrada normal do GRUB. Se o /etc/fstab monta por nome de dispositivo e não por UUID ou nome de LVM, corrija antes: com VirtIO Block os discos se chamam vda, vdb e assim por diante.
07
Se nada inicia, use a ISO de instalação
Inicie a ISO de instalação da mesma distribuição em modo de resgate, deixe-a montar o sistema instalado e reconstrua o initramfs de dentro dele. Na família RHEL o sistema instalado fica montado em /mnt/sysimage ou em /mnt/sysroot: a tela de resgate informa qual.
```
chroot /mnt/sysimage
dracut -f --regenerate-all --add-drivers "virtio_blk virtio_scsi virtio_pci virtio_net"
exit
```

Moov v1.0.44

Como o Moov evita isso

O Moov reconstrói a imagem de boot da VM enquanto a prepara para o KVM, sem iniciá-la e contra o disco montado, então a primeira inicialização no destino já encontra seu volume raiz. Não há entrada de resgate para escolher nem segundo boot.

Baixar o appliance

A imagem de boot reconstruída é verificada antes de substituir a original. Se falta algo essencial, a migração para com o motivo e o disco original fica intacto.
Cobre os esquemas de discos de campo: LVM distribuído em vários discos, /boot em um disco diferente da raiz e o arquivo de dispositivos LVM do EL9 e posteriores.
Validado no OLVM e no HPE VM Essentials com Oracle Linux 8, 9 e 10 em BIOS e UEFI, RHEL, Rocky, SLES e Ubuntu.
No Proxmox VE a VM recebe por padrão o modelo de CPU do host, então o RHEL 10 e o Rocky 10 iniciam. Você pode alterá-lo por VM se seu cluster for heterogêneo.
A rede também é mantida: bonds, bridges, VLANs e aliases com NetworkManager, netplan, systemd-networkd e SUSE, e placas chamadas eth0, eth1 e assim por diante.
Depois de migrar, o Moov liga a VM e espera o QEMU Guest Agent. A onda informa verificada, inconclusiva ou com falha, em vez de ficar verde só porque os discos foram copiados.

Perguntas frequentes

O que é o dracut emergency shell?: É o shell mínimo que o initramfs abre quando não consegue encontrar ou montar o sistema de arquivos raiz. Depois de uma troca de hipervisor quase sempre significa que falta ao initramfs o driver do novo controlador de disco, e não que o disco esteja danificado.
Perdi meus dados?: Não. O disco e seus volumes LVM estão intactos. O initramfs simplesmente não chega a eles pelo controlador VirtIO até ser reconstruído.
Migrei com uma versão anterior do Moov e a VM fica no emergency shell. O que faço?: As VMs Oracle Linux e RHEL migradas com a v1.0.39 até a v1.0.42 precisam que você execute uma vez dracut -f --regenerate-all dentro da VM. Inicie a entrada de resgate para entrar, execute e reinicie. Está corrigido desde a v1.0.43.
Acontece no Ubuntu e no Debian?: Raramente, porque o initramfs deles é genérico por padrão e já inclui os drivers VirtIO. Acontece quando o sistema ficou com MODULES=dep, e a correção é o update-initramfs depois de adicionar os módulos VirtIO.
Por que o RHEL 10 ou o Rocky 10 não iniciam mesmo com o initramfs correto?: Porque exigem o conjunto de instruções x86-64-v3. Uma VM com um modelo de CPU virtual mais antigo, como o x86-64-v2-AES, para logo no começo da inicialização. Defina o tipo de CPU como host ou como um modelo com x86-64-v3.

Guias relacionados

← Voltar ao início do Moov