¿Qué es el dracut emergency shell?

Es el shell mínimo que abre el initramfs cuando no puede encontrar o montar el sistema de archivos raíz. Después de un cambio de hipervisor casi siempre significa que al initramfs le falta el driver del controlador de disco nuevo, no que el disco esté dañado.

No. El disco y sus volúmenes LVM están intactos. El initramfs simplemente no llega a ellos a través del controlador VirtIO hasta que se reconstruye.

Migré con una versión anterior de Moov y la VM se queda en el emergency shell. ¿Qué hago?

Las VMs Oracle Linux y RHEL migradas con la v1.0.39 a la v1.0.42 necesitan que ejecutes una vez dracut -f --regenerate-all dentro de la VM. Arranca la entrada de rescate para entrar, ejecútalo y reinicia. Está corregido desde la v1.0.43.

¿Pasa en Ubuntu y Debian?

Rara vez, porque su initramfs es genérico por defecto y ya incluye los drivers VirtIO. Pasa cuando el sistema quedó con MODULES=dep, y el arreglo es update-initramfs después de agregar los módulos VirtIO.

¿Por qué RHEL 10 o Rocky 10 no arrancan aunque el initramfs esté bien?

Porque exigen el conjunto de instrucciones x86-64-v3. Una VM con un modelo de CPU virtual más antiguo, como x86-64-v2-AES, se detiene al comienzo del arranque. Define el tipo de CPU como host o como un modelo con x86-64-v3.

Moov · Guías prácticas

Linux no arranca después de migrar de VMware a Proxmox: dracut emergency shell

Una VM con Linux que arrancaba bien en VMware se detiene en el dracut emergency shell en su primer arranque en Proxmox VE, oVirt / OLVM o cualquier hipervisor KVM cuando su initramfs se construyó solo para el hardware de VMware y no trae ningún driver de almacenamiento VirtIO. El kernel inicia, no encuentra el sistema de archivos raíz y se rinde. El disco está intacto. La solución es arrancar una vez desde algo que el initramfs antiguo pueda leer, reconstruir el initramfs con los drivers VirtIO y volver a cambiar.

Por qué pasa

El initramfs es la imagen pequeña que usa el kernel para encontrar y montar el sistema de archivos raíz. En RHEL, Oracle Linux, Rocky, AlmaLinux y SLES, dracut lo construye por defecto en modo host-only: incluye solo los drivers del hardware que el sistema tenía en ese momento. En VMware eso es el controlador VMware Paravirtual o el LSI Logic. En KVM el disco cuelga de VirtIO SCSI o VirtIO Block, el initramfs no tiene virtio_scsi ni virtio_blk, y el volumen raíz nunca aparece.

El kernel no es el problema: todas las distribuciones soportadas traen los drivers VirtIO como módulos. Simplemente no están dentro del initramfs. Por eso el arreglo es reconstruirlo, no instalar nada.

Debian y Ubuntu construyen por defecto un initramfs genérico, así que normalmente arrancan. Fallan igual cuando el sistema se configuró con MODULES=dep.

Hay una segunda causa, sin relación con la anterior, que se parece en sistemas recientes: el modelo de CPU. RHEL 10 y Rocky 10 exigen el conjunto de instrucciones x86-64-v3, y una VM creada con un modelo de CPU virtual más antiguo, como x86-64-v2-AES en Proxmox, no pasa del comienzo del arranque.

Cómo arreglarlo a mano

Los pasos están escritos para Proxmox VE y valen igual para cualquier hipervisor KVM. La entrada de rescate es el camino más corto en la familia RHEL. La ISO de instalación sirve en todas las distribuciones.

01
Define un modelo de CPU que el sistema acepte
Para RHEL 10, Rocky 10 y otros sistemas compilados para x86-64-v3, define el tipo de CPU de la VM como host, o como un modelo que incluya x86-64-v3. En Proxmox es el campo Type, en Processors.
02
Arranca la entrada de rescate
En la familia RHEL, GRUB conserva una entrada con rescue en el nombre. Su initramfs es genérico e incluye los drivers VirtIO, así que arranca donde la entrada normal no. Abre el menú de GRUB al iniciar y elígela.
03
Si no hay entrada de rescate, arranca desde el controlador que el initramfs antiguo conoce
Si la VM usaba el controlador VMware Paravirtual, define el controlador SCSI de la VM como VMware PVSCSI e iníciala. El initramfs construido en VMware trae ese driver, así que el volumen raíz vuelve a aparecer. Si usaba otro controlador, pasa al paso de la ISO de instalación.
04
Reconstruye el initramfs
Con el sistema arriba, reconstruye el initramfs de todos los kernels instalados con los drivers VirtIO incluidos, y comprueba que quedaron adentro.
```
dracut -f --regenerate-all --add-drivers "virtio_blk virtio_scsi virtio_pci virtio_net"
lsinitrd | grep virtio
```

En Debian y Ubuntu

Agrega los módulos VirtIO a la configuración del initramfs y reconstrúyelo para todos los 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
Vuelve a VirtIO SCSI
Apaga, define el controlador SCSI como VirtIO SCSI e inicia la VM desde su entrada normal de GRUB. Si /etc/fstab monta por nombre de dispositivo y no por UUID o nombre de LVM, corrígelo antes: con VirtIO Block los discos se llaman vda, vdb y así sucesivamente.
07
Si nada arranca, usa la ISO de instalación
Arranca la ISO de instalación de la misma distribución en modo rescate, deja que monte el sistema instalado y reconstruye el initramfs desde adentro. En la familia RHEL el sistema instalado queda montado en /mnt/sysimage o en /mnt/sysroot: la pantalla de rescate dice cuál.
```
chroot /mnt/sysimage
dracut -f --regenerate-all --add-drivers "virtio_blk virtio_scsi virtio_pci virtio_net"
exit
```

Moov v1.0.44

Cómo lo evita Moov

Moov reconstruye la imagen de arranque de la VM mientras la prepara para KVM, sin iniciarla y contra el disco montado, así que el primer arranque en el destino ya encuentra su volumen raíz. No hay entrada de rescate que elegir ni segundo arranque.

Descargar el appliance

La imagen de arranque reconstruida se verifica antes de reemplazar la original. Si falta algo esencial, la migración se detiene con el motivo y el disco original queda intacto.
Cubre los esquemas de discos del campo: LVM repartido en varios discos, /boot en un disco distinto de la raíz y el archivo de dispositivos LVM de EL9 y posteriores.
Validado en OLVM y HPE VM Essentials con Oracle Linux 8, 9 y 10 en BIOS y UEFI, RHEL, Rocky, SLES y Ubuntu.
En Proxmox VE la VM recibe por defecto el modelo de CPU del host, así que RHEL 10 y Rocky 10 arrancan. Puedes cambiarlo por VM si tu clúster es heterogéneo.
La red también se conserva: bonds, bridges, VLAN y alias con NetworkManager, netplan, systemd-networkd y SUSE, y placas llamadas eth0, eth1 y así sucesivamente.
Después de migrar, Moov enciende la VM y espera al QEMU Guest Agent. La ola informa verificada, no concluyente o fallida, en vez de ponerse en verde solo porque los discos se copiaron.

Preguntas frecuentes

¿Qué es el dracut emergency shell?: Es el shell mínimo que abre el initramfs cuando no puede encontrar o montar el sistema de archivos raíz. Después de un cambio de hipervisor casi siempre significa que al initramfs le falta el driver del controlador de disco nuevo, no que el disco esté dañado.
¿Perdí mis datos?: No. El disco y sus volúmenes LVM están intactos. El initramfs simplemente no llega a ellos a través del controlador VirtIO hasta que se reconstruye.
Migré con una versión anterior de Moov y la VM se queda en el emergency shell. ¿Qué hago?: Las VMs Oracle Linux y RHEL migradas con la v1.0.39 a la v1.0.42 necesitan que ejecutes una vez dracut -f --regenerate-all dentro de la VM. Arranca la entrada de rescate para entrar, ejecútalo y reinicia. Está corregido desde la v1.0.43.
¿Pasa en Ubuntu y Debian?: Rara vez, porque su initramfs es genérico por defecto y ya incluye los drivers VirtIO. Pasa cuando el sistema quedó con MODULES=dep, y el arreglo es update-initramfs después de agregar los módulos VirtIO.
¿Por qué RHEL 10 o Rocky 10 no arrancan aunque el initramfs esté bien?: Porque exigen el conjunto de instrucciones x86-64-v3. Una VM con un modelo de CPU virtual más antiguo, como x86-64-v2-AES, se detiene al comienzo del arranque. Define el tipo de CPU como host o como un modelo con x86-64-v3.

Guías relacionadas

← Volver al inicio de Moov