Problemas de arranque en configuraciones solo NVMe: comprobar UEFI, initramfs y fstab

Problemas de arranque en configuraciones solo NVMe suelen ocurrir en entornos productivos tras actualizaciones del kernel, cambios de almacenamiento o actualizaciones de firmware. Este Runbook está pensado para administradores, System Engineers y operadores y describe un orden de comprobación probado: visibilidad del hardware NVMe, UEFI/ESP, bootloader y Kernel-Cmdline, contenido del initramfs y /etc/fstab. Cada medida incluye los riesgos relevantes, comandos prácticos y una estrategia de retroceso.

¿Por qué actuar de forma sistemática? La interacción de la cadena de arranque

La cadena de arranque no es un único artefacto, sino varias capas que colaboran: el firmware (UEFI) lee la partición del sistema EFI (ESP) y arranca un cargador EFI; el bootloader (p. ej. GRUB2 o systemd-boot) carga el kernel y el initramfs y transmite la Kernel-Cmdline; el initramfs (un sistema raíz temporal) inicializa controladores y utilidades (controlador NVMe, LVM, mdadm, cryptsetup) y monta el sistema de archivos raíz; solo después /etc/fstab se encarga de los demás puntos de montaje. Los fallos en una capa a menudo parecen errores de hardware — por eso el orden de comprobación es importante.

Clasificar los síntomas y sopesar las consecuencias

Antes de realizar cambios, clasifique el síntoma. Esto ahorra tiempo y evita intervenciones incorrectas:

• Firmware/UEFI informa “No bootable device”: enfoque en ESP, entradas NVRAM y tipos de partición.
• El bootloader inicia el kernel y a continuación se produce un drop a la shell del initramfs: enfoque en la Kernel-Cmdline y el contenido del initramfs.
• Root montado, más tarde systemd en modo de emergencia: /etc/fstab, montajes faltantes o tiempos de espera son lo más probable.

Antes de intervenir: medidas de seguridad

Minimizar riesgos, limitar el tiempo de inactividad:

• Disponer de consola remota (IPMI/iDRAC/iLO/consola de VM) para ver y controlar los mensajes de arranque.
• Conservar entradas de kernels anteriores; no elimine nada que no pueda respaldar de forma reproducible.
• Hacer una copia de la ESP y del initramfs antes de escribir.
• Reservar cambios críticos para ventanas de mantenimiento y documentar los pasos.

Paso de comprobación 1: NVMe-Hardware und Kernel-Sichtbarkeit

Objetivo: comprobar si el sistema y el kernel detectan los dispositivos NVMe. Si faltan los dispositivos /dev/nvme*, la reparación del bootloader no ayudará.

# Geräte und Partitionen anzeigen
lsblk -e7 -o NAME,TYPE,SIZE,MODEL,SERIAL,FSTYPE,UUID,MOUNTPOINTS

# Dateisystem-UUIDs
blkid

# Kernel-Meldungen nach NVMe/PCIe-Fehlern durchsuchen
dmesg | grep -iE 'nvme|pcie|iommu|timeout|reset' | tail -n 200

Interpretación: Si lsblk no muestra dispositivos NVMe, compruebe la configuración del BIOS/UEFI (modo PCIe, ACS/ASPM, hotplug), actualizaciones de firmware de la placa base/controlador NVMe o conexiones físicas (backplane). A veces en el Rescue-Kernel falta el controlador NVMe adecuado.

Paso de comprobación 2: UEFI, ESP y entradas NVRAM

La ESP (EFI System Partition) debe ser una partición válida con tipo EF00 (GPT) y formateada en FAT32. Si la ESP está dañada o contiene rutas incorrectas, UEFI no encontrará un cargador.

# ESP mounten und Inhalt prüfen
mkdir -p /mnt/esp
mount -t vfat /dev/nvme0n1p1 /mnt/esp
ls -la /mnt/esp

# NVRAM-Einträge anzeigen (Rescue muss im UEFI-Modus gebootet sein)
efibootmgr -v

Puntos críticos:

• Al clonar una NVMe puede cambiar la tabla de particiones; entonces las entradas NVRAM apuntarán a PARTUUIDs inexistentes.
• Secure Boot puede bloquear cargadores sin firma; compruebe el estado de las firmas y de MOK.

Paso de comprobación 3: Bootloader, kernel-cmdline y root=

La kernel-cmdline determina qué dispositivo actúa como root. Si root= está mal configurado, el sistema cae inmediatamente en la shell initramfs. Compruebe la configuración del Bootloader, no solo el argumento del kernel que se está ejecutando actualmente.

# Aktuelle Kernel-Cmdline prüfen
cat /proc/cmdline

# GRUB-Konfiguration im gemounteten System untersuchen
grep -R "Linux .*root=" -n /mnt/sysroot/boot/grub*/grub.cfg | head -n 50

# systemd-boot Einträge lesen
find /mnt/esp/loader -maxdepth 2 -type f -name "*.conf" -exec sed -n '1,120p' {} ;

Consejo práctico: Use UUID= o PARTUUID= en root=; /dev/nvme0n1p2 puede desplazarse con cambios de hardware. PARTUUID se refiere a las entradas de la tabla de particiones y se mantiene más estable ante reparticionamientos.

Paso de comprobación 4: initramfs – comprobar el contenido, regenerar y causas de error

El initramfs es una raíz temporal que contiene los controladores y herramientas necesarios para preparar el dispositivo root. Hay dos herramientas comunes para generar initramfs: update-initramfs (Debian/Ubuntu) y dracut (RHEL/Alma/Rocky). Si falta, por ejemplo, el controlador NVMe o cryptsetup, el sistema no podrá desbloquear ni montar.

# Beispiel: initramfs-Inhalt prüfen (Debian/Ubuntu)
lsinitramfs /mnt/sysroot/boot/initrd.img-$(ls /mnt/sysroot/lib/modules | sort -V | tail -n 1) | grep -iE 'nvme|lvm|crypt|mdadm|ext4|xfs|btrfs'

# Beispiel: initramfs-Inhalt prüfen (RHEL/Rocky/Alma)
lsinitrd /mnt/sysroot/boot/initramfs-*.img | grep -iE 'nvme|lvm|crypt|mdraid|ext4|xfs|btrfs'

Regenerar el initramfs desde el chroot del sistema objetivo y haga siempre una copia de seguridad del archivo anterior:

# In chroot (Debian/Ubuntu)
cp -a /boot/initrd.img-$(uname -r) /boot/initrd.img-$(uname -r).bak.$(date +%F)
update-initramfs -u -k all

# In chroot (RHEL/Rocky/Alma)
KVER=$(ls /lib/modules | sort -V | tail -n 1)
cp -a /boot/initramfs-${KVER}.img /boot/initramfs-${KVER}.img.bak.$(date +%F)
dracut -f /boot/initramfs-${KVER}.img ${KVER}

Causas comunes de error al regenerar:

• /etc/crypttab falta o está incorrecto: los parámetros de cryptsetup no se incluyen en el initramfs.
• Los filtros LVM-PVG en /etc/lvm/lvm.conf impiden detectar los Volume-Groups.
• Módulos de dracut deshabilitados por una dracut.conf personalizada; compruebe /etc/dracut.conf.d.

Paso de comprobación 5: chroot limpio y activación de dependencias

Siempre que sea posible, trabaje en el chroot del sistema objetivo. Esto evita que las rutas del sistema del entorno de rescate distorsionen la reparación. Monte /dev, /proc, /sys y /run con –bind.

mount /dev/nvme0n1p2 /mnt/sysroot
mount -t vfat /dev/nvme0n1p1 /mnt/sysroot/boot/efi
mount --bind /dev  /mnt/sysroot/dev
mount --bind /proc /mnt/sysroot/proc
mount --bind /sys  /mnt/sysroot/sys
mount --bind /run  /mnt/sysroot/run
chroot /mnt/sysroot /bin/bash

Si se utiliza LUKS/LVM/RAID, ábralos/actívelos previamente:

# LUKS öffnen
cryptsetup luksOpen /dev/nvme0n1p3 cryptroot

# LVM aktivieren
pvscan
vgscan
vgchange -ay

# mdadm-RAIDs zusammenbauen
mdadm --assemble --scan

Comprobar /etc/fstab: estabilidad en lugar de archivos de dispositivo frágiles

/etc/fstab controla los montajes persistentes. Entradas erróneas o que bloquean son una causa frecuente de que el sistema arranque en modo de emergencia más tarde, incluso si la raíz se montó correctamente.

# fstab und Geräteliste prüfen
cat /etc/fstab
lsblk -f
blkid

Recomendaciones:

• Use UUID= o PARTUUID= en lugar de /dev/nvme0n1pX, porque los nombres de dispositivos /dev pueden desplazarse cuando cambian las enumeraciones.
• Para montajes no críticos, establezca temporalmente nofail para que el arranque no se detenga por cada montaje fallido.
• Para montajes de red o volúmenes con riesgo de spindown, utilice x-systemd.automount.
• Verifique las entradas de resume y swap: dispositivos de resume incorrectos provocan timeouts prolongados.

# Beispiel fstab-Eintrag mit UUID und nofail
UUID=1111-2222  /data   ext4  defaults,nofail,x-systemd.device-timeout=10  0 2

Problemas de temporización e inicialización

Algunos controladores NVMe o backplanes requieren más tiempo para iniciarse. El initramfs intenta por defecto durante un periodo determinado localizar los dispositivos. Si la inicialización es lenta, puede establecer temporalmente rootdelay=30 o parámetros de reintento específicos, hasta que se implementen soluciones de firmware/BIOS. Las medidas permanentes son actualizaciones de firmware, ajustes del BIOS (p. ej. desactivar Fast Boot) o cambios físicos en el hardware.

Casos especiales: Secure Boot, kernels/Loader firmados y MOK

Secure Boot verifica las firmas de los EFI-Loaders y los kernels. Si utiliza kernels propios o loaders sin firmar, el arranque fallará sin que el sistema entre en la shell del initramfs. Compruebe:

• Si el Loader en la ESP está firmado.
• Si el kernel tiene una firma válida (al usar Shim/MOK).
• Si MOK (Machine Owner Key) se ha iniciado y aceptado.

Si es necesario, puede desactivar temporalmente Secure Boot para realizar una reparación — respete las políticas de seguridad y registre la medida.

Reparación del gestor de arranque: GRUB vs. systemd-boot

Dependiendo del gestor de arranque, la reparación difiere. Ejemplos:

# GRUB UEFI neu installieren (im chroot, ESP gemountet)
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
update-grub

# systemd-boot installieren
bootctl --path=/boot/efi install

Importante: documente efibootmgr -v antes de realizar cambios y haga copias de seguridad de la ESP. Un grub-install incorrecto puede sobrescribir entradas NVRAM.

Docker-Hosts: Por qué los problemas de arranque NVMe son especialmente críticos

Los hosts de contenedores suelen ser sistemas mínimos y manejan muchos volúmenes estáticos. Las fallas de arranque afectan no solo a servicios individuales, sino a la orquestación de contenedores, la disponibilidad de volúmenes y el logging. Aspectos adicionales:

• Docker (o containerd) usa el sistema de archivos raíz del host para el almacenamiento de contenedores (p. ej. /var/lib/docker). Problemas con el montaje del root conducen a volúmenes en readonly o inexistentes.
• Overlay2 y device-mapper son sensibles a estados inconsistentes del sistema de archivos; un initramfs dañado que monte el root con retraso puede causar cuellos de botella en el arranque de contenedores.
• En entornos clusterizados, los orquestadores sincronizan el estado y deberían disponer de health checks para desencadenar failover.

Comprobaciones prácticas en un Docker-Host (tras un chroot exitoso):

# Docker-Status prüfen
systemctl status docker
docker info | sed -n '1,120p'

# Storage-Pfade überprüfen
ls -la /var/lib/docker
df -h /var/lib/docker

Buenas prácticas antes de cambios en el kernel/arranque:

• Haga copias de seguridad de los volúmenes de contenedores (snapshots, rsync, registry-push para imágenes).
• Pruebe los cambios de arranque primero en una réplica o en servidores canary.
• Trate los artefactos de arranque como objetos de configuración: versionarlos, revisarlos y registrar el cambio.

Estrategia de recuperación y reversión

Si la causa sigue sin estar clara, actúe de forma mínima y reversible:

1. Intente arrancar con un kernel más antiguo, en lugar de reconstruirlo.
2. Establezca entradas críticas de fstab en nofail, en lugar de eliminarlas.
3. Realice copias de seguridad de ESP e initramfs y exporte la salida de efibootmgr.
4. Proceda de forma gradual: primero la visibilidad de la NVMe, luego Bootloader/Kmdline, después initramfs y fstab.
5. En emergencias: desplegar una réplica a partir de una copia de seguridad o imagen y planificar la migración de IP/servicios.

Lista de comprobación práctica (referencia rápida)

1. Determinar la clase de síntoma: UEFI / initramfs / fstab.
2. ¿NVMe visible? (lsblk, dmesg)
3. Preparar chroot y activar LUKS/LVM/RAID.
4. Montar la ESP y guardar efibootmgr -v.
5. Comprobar Kernel-Cmdline: root=UUID/PARTUUID.
6. Comprobar el contenido de initramfs y regenerarlo desde chroot (con copia de seguridad).
7. Corroborar /etc/fstab con blkid, usar nofail.
8. Reinstalar el bootloader si es necesario (grub-install / bootctl).
9. Realizar un arranque de prueba, verificar los logs, redactar el postmortem y el registro de cambios.

Conclusión

En problemas de arranque en entornos exclusivamente NVMe, el diagnóstico exitoso es una combinación de un enfoque metódico, conocimiento de la cadena de arranque y actuación conservadora. NVMe rara vez es el único culpable; normalmente intervienen UEFI/NVRAM, Kernel-Cmdline, módulos initramfs ausentes o entradas erróneas en fstab. Trabaje con chroot, haga copias de seguridad de los artefactos de arranque, regenere initramfs con cuidado y planifique medidas de reversión. Para hosts Docker se aplican además requisitos estrictos sobre volúmenes y la resiliencia del orquestador — pruebe los cambios primero en réplicas o servidores canary.

Con el orden de comprobaciones descrito aquí y los comandos concretos reducirá los tiempos de inactividad y evitará reinstalaciones innecesarias. La documentación y el control de cambios son tan importantes como la reparación técnica.

Problemas de arranque en entornos exclusivamente NVMe: operación, monitorización y automatización

Aparte de la reparación clásica, es crucial diseñar la operación de modo que los fallos de arranque se detecten temprano, puedan reproducirse en pruebas y volver atrás de forma segura. Tres áreas resultan prácticamente siempre rentables: copia de seguridad de artefactos (ESP, NVRAM, GPT), telemetría de arranque observable y validación automatizada en la pipeline CI/CD.

Respaldar artefactos y metadatos

Antes de efectuar cambios, siempre respalde la partición EFI, las entradas NVRAM y la tabla GPT. Estos metadatos suelen ser el camino más rápido para restaurar un estado funcional.

# GPT-Backup
sgdisk --backup=gpt-backup-$(date +%F).bin /dev/nvme0n1

# NVRAM/efibootmgr sichern
efibootmgr -v > /root/efibootmgr-$(date +%F).txt

# ESP snapshot
mount /dev/nvme0n1p1 /mnt/esp
tar -c -C /mnt/esp . | gzip -c > /root/esp-backup-$(date +%F).tar.gz

Observabilidad: registro temprano y acceso remoto

• Active una consola serie o Netconsole para mensajes iniciales del kernel. Así verá si se inicializan los controladores NVMe.
• Configure systemd-journal en modo persistente para que los logs se conserven entre arranques.
• Para volúmenes root cifrados, planifique un método de desbloqueo remoto (p. ej., SSH‑Dropbear en el initramfs o un key escrow central) y regule estrictamente el acceso y la auditoría.

CI/CD y estrategia Canary para Kernel/initramfs

Construya initramfs y artefactos del cargador de arranque de forma reproducible en su pipeline y verifique de forma automatizada que se incluyan los módulos necesarios (nvme, nvme_core, lvm, dm‑crypt, etc.). Distribuya las actualizaciones de kernel y firmware inicialmente a hosts Canary con monitorización del tiempo de arranque, errores de dmesg y la salud de los contenedores (en hosts Docker).

Elemento especial: cabecera LUKS y gestión de claves

# LUKS-Header sichern
cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file /root/luks-header-$(date +%F).bin

Sin copia de seguridad del header, los volúmenes LUKS tras operaciones de escritura desafortunadas a menudo no son recuperables. Documente los procesos y mantenga claves/respaldos en un Vault seguro con control de acceso.

Estas medidas operativas reducen considerablemente el riesgo de indisponibilidad: asegurar metadatos, activar telemetría temprana, construir artefactos reproducibles y desplegarlos de forma gradual suelen ser más eficaces que las reparaciones ad hoc en situaciones de emergencia.

Para este tema también son importantes Uefi Boot y la regeneración de initramfs. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en el día a día.