Debian 13 atascado en initramfs: qué significa realmente y cómo recuperar tu sistema

noviembre 26, 2025 • febrero 3, 2026 • Lectura: 26 min • Views: 7

¿Te fue útil?

Reinicias tras una actualización del kernel o un cambio rutinario de almacenamiento y, en lugar del prompt de inicio de sesión, obtienes una pequeña consola que parece diseñada en la era punto-com: (initramfs). Sin red. Sin servicios. Solo tú y un sistema de archivos que no se monta.

Esto no es que “Linux se rompió”. Es Linux siendo honesto: la cadena de arranque encontró una dependencia crítica (normalmente almacenamiento) y se negó a fingir que todo está bien. Tu tarea es identificar qué dependencias fallaron, arreglarlo con el menor impacto posible y luego reconstruir los artefactos de arranque para no volver a ver esta consola en el siguiente reinicio.

Qué es realmente “initramfs” (y qué no es)

Cuando Debian te deja en (initramfs), todavía no estás “en Debian”. Estás en un pequeño entorno de ejecución temporal cargado en RAM por el kernel. Su trabajo es realizar el trabajo de arranque temprano: descubrir tu almacenamiento, cargar módulos del kernel, ensamblar RAID/LVM, desbloquear cifrado y montar el sistema de archivos raíz real. Una vez que eso succeed, switch_root (o su equivalente) entrega el control al espacio de usuario real.

Si ese traspaso no puede realizarse, initramfs se detiene. Te ofrece una shell porque es el último lugar seguro para solucionar problemas: antes de los servicios, antes de la rotación de logs, antes de que algo se monte en lectura/escritura y complique la recuperación.

La mayoría de las veces, “atascado en initramfs” significa una de estas cosas:

El kernel no puede ver el dispositivo que debería ser la raíz (falta un driver/módulo, cambió el nombre del dispositivo, falló el disco).
El dispositivo existe, pero el identificador no coincide (UUID/PARTUUID equivocado en GRUB o /etc/fstab).
La raíz está en capas (LUKS, LVM, RAID con mdadm, multipath) y las capas no se ensamblaron en initramfs.
El sistema de archivos está tan dañado que el montaje falla y initramfs se niega a continuar.

Verdad simple: la shell de initramfs no es un castigo. Es una puerta corta de emergencia. Puedes usarla metódicamente o entrar en pánico y copiar comandos al azar hasta empeorar las cosas. Elige el camino metódico.

Broma #1: La shell de initramfs es como la fila de seguridad del aeropuerto: no es donde querías estar, pero es donde se detectan las cosas faltantes.

Guía rápida de diagnóstico (comprueba primero/segundo/tercero)

Esta es la secuencia para “detener la hemorragia”. No empieces reinstalando GRUB. No empieces editando UUIDs al azar. Empieza demostrando qué existe, luego qué debería existir y finalmente por qué difieren.

Primero: ¿vemos los discos y los módulos de kernel correctos?

Comprueba qué dispositivos de bloque existen (lsblk).
Verifica si el módulo del controlador esperado está cargado (lsmod).
Busca “timed out” o “unknown-block” en el registro del kernel (dmesg).

Segundo: ¿podemos identificar el dispositivo raíz previsto sin ambigüedades?

Lista los UUIDs/PARTUUIDs de los sistemas de archivos (blkid).
Revisa qué usa la línea de comandos del kernel (cat /proc/cmdline).
Confirma si la raíz está en una partición simple, LVM, RAID con mdadm o LUKS.

Tercero: ¿podemos ensamblar las capas y montar la raíz en solo lectura?

Si hay RAID: mdadm --assemble --scan, y luego vuelve a comprobar /proc/mdstat.
Si hay LVM: vgscan, vgchange -ay, luego lvs.
Si hay LUKS: cryptsetup luksOpen, y luego monta el dispositivo mapeado.
Monta la raíz en solo lectura e inspecciona logs/config: mount -o ro … /mnt.

Una vez que puedas montar la raíz, puedes reparar la configuración y reconstruir initramfs/GRUB desde un chroot. Ese es el punto de inflexión: de “misterio” a “reparación controlada”.

Hechos e historia interesantes (lo que explica las fallas actuales)

El comportamiento de arranque moderno de Debian parece una pila de decisiones tomadas durante dos décadas. Las fallas que ves en initramfs son básicamente esas decisiones mostrando sus costuras. Un poco de contexto te ayuda a diagnosticar más rápido.

initrd precede a initramfs. El Linux temprano usaba un initial ramdisk (imagen de dispositivo de bloque). initramfs pasó luego a un archivo cpio desempaquetado en tmpfs. La “shell de initramfs” que ves es descendiente de ese cambio.
Los UUIDs se hicieron populares porque los nombres de dispositivos mienten. /dev/sda puede convertirse en /dev/sdb según el orden de controladores, el tiempo de hotplug o peculiaridades del firmware. Identificadores estables (UUID/PARTUUID) redujeron montajes accidentales del disco equivocado.
Los problemas de timing de udev son reales. Gran parte de “raíz no encontrada” es solo “raíz encontrada tarde”. Por eso existen rootdelay= y los mensajes de initramfs que esperan el dispositivo raíz.
El ensamblado de RAID con mdadm se movió más temprano en el arranque por una razón. Si tu raíz está en RAID1, no puedes iniciar el espacio de usuario sin ensamblar el arreglo. Por eso existen hooks de mdadm en initramfs.
LVM son dos problemas: descubrimiento de metadatos y activación. initramfs debe incluir tanto las herramientas como la configuración para encontrar VGs y luego activar LVs para que aparezcan como dispositivos de bloque.
LUKS convirtió el “prompt de contraseña de raíz” en una característica de arranque. Una raíz cifrada significa que initramfs necesita cryptsetup y reglas para material de claves. Si faltan esos hooks, el sistema ni siquiera puede pedir correctamente la frase de contraseña.
Secure Boot cambió expectativas de drivers/módulos. Kernels/módulos firmados y cadenas de arranque más estrictas significan que un módulo faltante o desajustado puede ser fatal más temprano que antes.
Las comprobaciones de sistema de archivos se volvieron más conservadoras. Ext4 y XFS se comportan diferente ante la corrupción; los scripts de initramfs a menudo se niegan a montar un sistema de archivos que consideran inconsistente, porque continuar puede causar más daño.
GRUB no es todo el arranque. GRUB carga un kernel e initramfs; después de eso, GRUB está básicamente fuera de la historia. La gente aún lo culpa porque es lo último que recuerdan ver.

Modos de fallo principales que te dejan en initramfs

1) Dispositivo raíz no encontrado (módulo/driver faltante o hardware cambiado)

Patrón clásico: cambiaste el modo SATA en la BIOS, moviste un disco a otro controlador, cambiaste el tipo de almacenamiento de la VM (virtio ↔ SCSI) o instalaste un kernel/initramfs que no incluye el módulo correcto. El kernel arranca, pero los nodos de dispositivo para tu raíz nunca aparecen.

2) UUID/PARTUUID equivocado en GRUB o `/etc/fstab`

Quizá clonaste un disco, restauraste desde backup, regeneraste un sistema de archivos o reemplazaste una partición. Los identificadores cambiaron. El cargador de arranque y la tabla de sistemas de archivos siguen apuntando a los antiguos.

3) RAID no ensamblado lo suficientemente pronto

Si la raíz está en RAID con mdadm, initramfs debe ensamblar el arreglo. La falta de /etc/mdadm/mdadm.conf dentro de initramfs, un arreglo degradado o metadatos cambiados pueden detener el ensamblado. Los dispositivos existen, pero la raíz (el arreglo) no.

4) LVM no activado

Puedes ver los PVs, pero no los volúmenes lógicos. Sin que vgchange -ay se ejecute (o sin las herramientas LVM), la raíz nunca aparece.

5) LUKS no desbloqueado (o keyfiles no disponibles)

La raíz cifrada añade una dependencia temprana de cryptsetup y la capacidad de pedir o recuperar una clave. Si dependías de un keyfile en una partición separada y esa partición no se montó, se crea un bloqueo circular.

6) El sistema de archivos no se monta (corrupción, driver equivocado o incompatibilidad de características)

Ext4 suele montarse incluso en mal estado (a veces con demasiada facilidad). XFS puede ser estricto. Btrfs puede negarse si faltan dispositivos. ZFS raíz tiene su propia lógica de importación. En todos los casos: initramfs se detiene porque no puede montar la raíz de forma segura.

7) El propio initramfs está mal (hooks obsoletos, binarios faltantes, configuración incorrecta)

La gente reconstruye initramfs menos a menudo de lo que debería. O lo reconstruyen una vez y se olvidan del siguiente kernel. O actualizan /etc/crypttab pero no regeneran initramfs. Entonces reinician en una falla perfectamente consistente.

Tareas prácticas: comandos, salidas, decisiones (12+)

Todo lo siguiente está escrito para la shell de initramfs (estilo BusyBox) salvo indicación. Algunos comandos pueden faltar según cómo se construyó tu initramfs. Esa ausencia es en sí misma una señal.

Tarea 1: Identifica dónde estás y qué herramientas existen

cr0x@server:~$ uname -a
Linux (none) 6.12.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.6-1 (2025-01-05) x86_64 GNU/Linux
cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.12.0-1-amd64 root=UUID=4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1 ro quiet
cr0x@server:~$ busybox
BusyBox v1.36.1 (Debian 1:1.36.1-9) multi-call binary.

Qué significa: La versión del kernel importa para la disponibilidad de drivers. La línea de comandos te dice qué cree que es la raíz. BusyBox confirma que estás en un entorno mínimo.

Decisión: Si root=UUID=... no coincide con ningún UUID de dispositivo de bloque que puedas ver más adelante, te diriges a “arreglar identificadores”. Si la cmdline usa /dev/sdX, planifica migrar a UUID/PARTUUID después de la recuperación.

Tarea 2: Revisa los mensajes del kernel por fallos en el descubrimiento de almacenamiento

cr0x@server:~$ dmesg | tail -n 40
[    2.011234] virtio_blk virtio0: [vda] 83886080 512-byte logical blocks (42.9 GB/40.0 GiB)
[    2.022110]  vda: vda1 vda2
[    6.104990] EXT4-fs (vda2): mounted filesystem with ordered data mode. Quota mode: none.
[    9.887650] VFS: Cannot open root device "UUID=4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1" or unknown-block(0,0): error -6
[    9.887690] Please append a correct "root=" boot option; here are the available partitions:
[    9.887720] 0100            4096 ram0
[    9.887740] 00ff          1048575 ram15
[    9.887760] 0b00        83886080 vda  driver: virtio_blk
[    9.887780]   0b01          1048576 vda1
[    9.887800]   0b02        82838528 vda2

Qué significa: El kernel ve vda2, pero no el UUID especificado como raíz. Eso suele indicar “UUID equivocado”, no “disco faltante”.

Decisión: Pasa a blkid y compara UUIDs. Si el disco en sí no aparece listado, cambia a problemas de driver/módulo.

Tarea 3: Enumera dispositivos de bloque y sistemas de archivos

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINT
NAME   SIZE TYPE FSTYPE UUID                                 MOUNTPOINT
vda     40G disk
├─vda1   1G part vfat   2C1A-9F33
└─vda2  39G part ext4   7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a

Qué significa: Tienes un candidato a raíz ext4 con UUID 7e3b…, pero la cmdline de arranque quería 4b3f….

Decisión: O actualizas el root= de GRUB al nuevo UUID, o reviertes el cambio de disco/partición que lo causó. Normalmente: arregla la configuración y reconstruye initramfs/GRUB para que el cambio persista.

Tarea 4: Confirma los UUIDs a la manera tradicional

cr0x@server:~$ blkid
/dev/vda1: UUID="2C1A-9F33" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="2f1e3e1b-01"
/dev/vda2: UUID="7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2f1e3e1b-02"

Qué significa: blkid es tu verdad fundamental para los UUIDs de sistemas de archivos.

Decisión: Si la cmdline del kernel usa UUID, actualízala. Si usa PARTUUID, compara esos en su lugar. No adivines; copia/pega con cuidado.

Tarea 5: Intenta montar la raíz sospechada en solo lectura

cr0x@server:~$ mkdir -p /mnt
cr0x@server:~$ mount -o ro /dev/vda2 /mnt
cr0x@server:~$ ls /mnt
bin  boot  dev  etc  home  lib  lib64  proc  root  run  sbin  usr  var

Qué significa: El sistema de archivos se monta. Excelente: esto es mayormente una descoincidencia de configuración, no corrupción.

Decisión: Procede a inspeccionar /mnt/etc/fstab y la configuración del cargador de arranque, luego reconstruye initramfs y GRUB desde un chroot o entorno de rescate.

Tarea 6: Inspecciona `/etc/fstab` buscando desajustes que te afectarán después

cr0x@server:~$ sed -n '1,120p' /mnt/etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/disk/by-uuid/4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1 / ext4 defaults,errors=remount-ro 0 1
UUID=2C1A-9F33  /boot/efi vfat umask=0077 0 1

Qué significa: fstab aún referencia el UUID antiguo de la raíz (4b3f…). Incluso si arreglas GRUB, fallarán los montajes después o acabarás en modo emergencia tras el switch_root.

Decisión: Actualiza fstab a 7e3b… (el UUID real de la raíz), y luego reconstruye initramfs/GRUB en el sistema instalado para mantener todo consistente.

Tarea 7: Arregla fstab de forma segura (edición mínima, sin creatividad)

cr0x@server:~$ cp -a /mnt/etc/fstab /mnt/etc/fstab.bak
cr0x@server:~$ sed -i 's/4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1/7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a/' /mnt/etc/fstab
cr0x@server:~$ grep ' / ' /mnt/etc/fstab
/dev/disk/by-uuid/7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a / ext4 defaults,errors=remount-ro 0 1

Qué significa: Has alineado fstab con la realidad.

Decisión: Ahora debes asegurarte de que la cmdline del kernel (root=) coincida también. Eso suele ser trabajo de GRUB.

Tarea 8: Comprueba si hay RAID (mdadm)

cr0x@server:~$ cat /proc/mdstat
Personalities : 
unused devices: <none>
cr0x@server:~$ mdadm --examine --scan
mdadm: No devices listed in conf file were found.

Qué significa: Actualmente no hay dispositivos RAID ensamblados. Si esperabas arreglos md, esto es un problema.

Decisión: Si tu raíz está en RAID, intenta ensamblar: mdadm --assemble --scan y vuelve a comprobar /proc/mdstat. Si no hay RAID, sigue adelante.

Tarea 9: Ensambla arreglos mdadm (cuando aplique)

cr0x@server:~$ mdadm --assemble --scan
mdadm: /dev/md0 has been started with 2 drives.
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 vda2[0] vdb2[1]
      41361408 blocks super 1.2 [2/2] [UU]
unused devices: <none>

Qué significa: El RAID ya está activo y sano ([UU]).

Decisión: Si la raíz debería estar en /dev/md0, móntalo y arregla la configuración de arranque para referenciarlo correctamente (UUID del sistema de archivos en el dispositivo md, o UUID del md).

Tarea 10: Activa LVM (cuando aplique)

cr0x@server:~$ vgscan
  Found volume group "vg0" using metadata type lvm2
cr0x@server:~$ vgchange -ay
  2 logical volume(s) in volume group "vg0" now active
cr0x@server:~$ lvs
  LV    VG  Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root  vg0 -wi-a----- 30.00g
  swap  vg0 -wi-a-----  8.00g

Qué significa: Los LVs ya están presentes. La raíz podría estar en /dev/vg0/root.

Decisión: Si tu sistema usa LVM para la raíz, debes asegurarte de que initramfs incluya los hooks de LVM y que root= apunte al LV correcto (por UUID es más seguro que por nombre en algunas configuraciones).

Tarea 11: Desbloquea LUKS (cuando aplique)

cr0x@server:~$ cryptsetup luksDump /dev/vda2 | head
LUKS header information
Version:        2
Epoch:          5
Metadata area:  16384 [bytes]
Keyslots:
  0: luks2
cr0x@server:~$ cryptsetup luksOpen /dev/vda2 cryptroot
Enter passphrase for /dev/vda2:
cr0x@server:~$ ls -l /dev/mapper/cryptroot
brw-------    1 root     root      253,   0 Dec 28 09:01 /dev/mapper/cryptroot

Qué significa: Has creado un mapeo descifrado. La raíz puede residir dentro de él (posiblemente con LVM encima).

Decisión: Si esto funciona manualmente pero falla en el arranque, probablemente tengas un /etc/crypttab roto o un initramfs sin los hooks de cryptsetup o sin material de claves. Planea arreglar y reconstruir initramfs desde un chroot.

Tarea 12: Revisa la salud del sistema de archivos cuando el montaje falla

cr0x@server:~$ mount -o ro /dev/vda2 /mnt
mount: mounting /dev/vda2 on /mnt failed: Structure needs cleaning
cr0x@server:~$ fsck.ext4 -fy /dev/vda2
e2fsck 1.47.1 (20-May-2024)
/dev/vda2: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vda2: 245321/2621440 files (0.3% non-contiguous), 1987654/10485760 blocks

Qué significa: “Structure needs cleaning” indica corrupción del sistema de archivos que impedía el montaje. fsck reparó cosas.

Decisión: Intenta montar de nuevo en solo lectura y continúa. Si la corrupción se repite, sospecha del hardware o problemas del dispositivo subyacente (SMART, errores del controlador) y planea el reemplazo.

Tarea 13: Si puedes montar la raíz, recopila los logs reales de arranque

cr0x@server:~$ mount -o ro /dev/vda2 /mnt
cr0x@server:~$ grep -R "ALERT!" -n /mnt/var/log | head
/mnt/var/log/boot.log:37:ALERT! /dev/disk/by-uuid/4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1 does not exist. Dropping to a shell!

Qué significa: El sistema instalado ya registró la falla anteriormente. Usualmente es una descoincidencia de identificadores o una capa faltante.

Decisión: Usa la cadena exacta del error para guiar la reparación. No “optimices”. Repara lo que está nombrado.

Tarea 14: Prepara un chroot para arreglos duraderos (desde initramfs o rescate)

cr0x@server:~$ mount /dev/vda2 /mnt
cr0x@server:~$ mount /dev/vda1 /mnt/boot/efi
cr0x@server:~$ mount -t proc proc /mnt/proc
cr0x@server:~$ mount -t sysfs sys /mnt/sys
cr0x@server:~$ mount -o bind /dev /mnt/dev
cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# cat /etc/debian_version
trixie/sid

Qué significa: Ahora operas dentro del sistema instalado, con acceso a herramientas de paquetes y configuración en su lugar correcto.

Decisión: Reconstruye initramfs y actualiza GRUB desde aquí para que los cambios persistan tras reinicios.

Tarea 15: Reconstruye initramfs correctamente (y para el kernel que usas)

cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# ls /boot
System.map-6.12.0-1-amd64  config-6.12.0-1-amd64  initrd.img-6.12.0-1-amd64  vmlinuz-6.12.0-1-amd64  efi
cr0x@server:/# update-initramfs -u -k 6.12.0-1-amd64
update-initramfs: Generating /boot/initrd.img-6.12.0-1-amd64

Qué significa: Debian regeneró la imagen initramfs para ese kernel específico.

Decisión: Si cambiaste crypttab, mdadm, lvm o módulos, este paso es innegociable. Si hay varios kernels instalados, considera -k all para evitar arrancar una imagen antigua rota luego.

Tarea 16: Actualiza GRUB para que root= coincida con la realidad

cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-1-amd64
Found initrd image: /boot/initrd.img-6.12.0-1-amd64
done
cr0x@server:/# grub-install /dev/vda
Installing for x86_64-efi platform.
Installation finished. No error reported.

Qué significa: Se regeneró la configuración de GRUB; GRUB se instaló en el objetivo correcto (UEFI aquí). En sistemas BIOS verías i386-pc y MBR/embedding de BIOS.

Decisión: Ejecuta grub-install solo cuando sea necesario (disco reemplazado, entradas EFI rotas, cargador de arranque faltante). De lo contrario update-grub normalmente basta y es menos arriesgado.

Tarea 17: Verifica que los identificadores referenciados por fstab sean resolubles

cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# findmnt --verify --verbose
Success, no errors or warnings detected

Qué significa: Tu configuración de montajes es internamente consistente. Esto no garantiza que el hardware funcione, pero elimina errores obvios.

Decisión: Si findmnt --verify se queja, arregla esas entradas antes de reiniciar. No devuelvas a producción una máquina que “arranca pero con montajes rotos”.

Tres mini-historias corporativas desde el campo

Incidente #1: El corte causado por una suposición errónea (los nombres de dispositivo son estables)

Una empresa mediana ejecutaba Debian en una flota de hosts de virtualización on-prem. Las particiones raíz estaban referenciadas en GRUB y /etc/fstab como /dev/sda2. “Llevaba funcionando años”, que es cómo la deuda técnica te hace bajar la guardia.

Añadieron un nuevo HBA para ampliar almacenamiento. Tras un reinicio de mantenimiento, dos hosts cayeron en initramfs. Los discos estaban bien. El SO no. El nuevo controlador cambió el orden de descubrimiento y el anterior /dev/sda pasó a ser /dev/sdb. El sistema intentó montar la partición equivocada como raíz; initramfs se detuvo, rechazando correctamente continuar con tonterías.

El primer interviniente hizo lo que mucha gente hace bajo presión: empezó a editar entradas de GRUB a mano en la consola, cambiando sda2 por sdb2. Arrancó. Repitieron en el segundo host. Todos se relajaron.

Entonces el siguiente reinicio rotó de nuevo el orden de dispositivos en un host y volvió a fallar. Ahí hicieron la reparación aburrida: convertir referencias de raíz a UUIDs, regenerar la configuración de GRUB, reconstruir initramfs y estandarizar la flota.

La lección no fue “no añadas HBAs”. Fue: trata los nombres /dev/sdX como efímeros en cualquier cosa que deba sobrevivir a un reinicio. Linux no promete un alfabeto estable.

Incidente #2: La optimización que salió mal (un “initramfs reducido” que no podía arrancar)

Un equipo SaaS quería tiempos de arranque más rápidos para nodos de autoscaling. Alguien propuso recortar el contenido de initramfs: menos módulos, menos hooks, imagen más pequeña, descompresión más rápida. Es razonable—hasta que recuerdas que el arranque temprano es donde ocurren las comprobaciones de realidad.

Personalizaron la generación de initramfs para omitir lo que “no era necesario”. Funcionó en staging, porque staging usaba un único perfil de almacenamiento: discos virtio, sin cifrado, sin RAID. Producción tenía un conjunto mixto: algunos nodos arrancaban desde NVMe, otros desde SATA, algunos tenían LUKS por una excepción de cumplimiento y unos pocos aún usaban RAID md porque así empezó el clúster años atrás.

Durante un despliegue de kernel, un subconjunto de nodos empezó a caer en initramfs. El initramfs ya no incluía el módulo NVMe en algunas imágenes, ni los hooks de cryptsetup en otras. No eran “servidores rotos”. Eran servidores ejecutando fielmente los artefactos de arranque que recibieron.

La solución no fue “añadir rootdelay” y esperar. Revirtieron el recorte, reconstruyeron initramfs con los hooks correctos y luego introdujeron una matriz controlada: una imagen por perfil de almacenamiento. También añadieron una puerta previa al reinicio: validar que initramfs contiene los módulos requeridos para la plataforma.

La optimización no ahorró tiempo. Trasladó tiempo desde “ruta de arranque” a “respuesta a incidentes”, que es el cómputo más caro que puedes comprar: atención humana a las 2 a. m.

Incidente #3: La práctica aburrida que salvó el día (recuperación documentada + identificadores consistentes)

Una organización financiera ejecutaba Debian en servidores de bases de datos con raíz cifrada y LVM. El entorno era aburrido en el mejor sentido: particionado consistente, montajes basados en UUID y un procedimiento estándar para “fallos de arranque”. Existía porque alguien ya había pagado por el caos una vez.

Una mañana, un evento de energía dejó fuera de servicio un rack. Tras restaurar la energía, un puñado de servidores se quedó en initramfs con mensajes sobre un sistema de archivos no limpio y dispositivos demorados. Nadie entró en pánico porque tenían un playbook y lo probaban trimestralmente.

El de guardia siguió los pasos: comprobar descubrimiento de dispositivos, desbloquear LUKS manualmente, activar LVM, montar la raíz en solo lectura, ejecutar fsck donde fuera necesario, luego chroot y reconstruir initramfs solo para garantizar que los hooks estuvieran correctos. También revisaron contadores SMART antes de declarar victoria.

El resultado no fue glamoroso. No hubo hacks heroicos. Solo recuperación predecible y un informe posincidente limpio: el almacenamiento regresó lentamente, un par de sistemas de archivos necesitaron recuperación de journal y la cadena de arranque hizo exactamente lo que debía: detenerse antes de corromper más datos.

Broma #2: Los sistemas más fiables se construyen sobre hábitos aburridos, por eso rara vez son invitados a reuniones emocionantes.

Errores comunes (síntoma → causa raíz → solución)

Aquí viven la mayoría de los tickets “initramfs para siempre”: no en bugs profundos del kernel, sino en deriva de configuración predecible. Usa esta sección como una tabla de consulta.

“ALERT! /dev/disk/by-uuid/… does not exist” → UUID equivocado → actualizar identificadores y reconstruir

Síntoma: initramfs imprime un ALERT sobre un UUID faltante y cae a shell.
Causa raíz: El UUID del sistema de archivos cambió (clone/restore/reformat) o la configuración apunta al disco antiguo.
Solución: Usa blkid para encontrar los UUID reales; actualiza /etc/fstab y la configuración de GRUB; ejecuta update-initramfs y update-grub.

“Gave up waiting for root device” → el dispositivo aparece tarde o nunca → añade driver, arregla módulos o añade demora

Síntoma: Mensajes sobre esperar la raíz y luego fallo.
Causa raíz: Módulo del controlador faltante en initramfs, o descubrimiento de almacenamiento lento (USB/NVMe con firmware raro).
Solución: Asegura que el módulo se incluya (instala paquetes apropiados, añádelo a /etc/initramfs-tools/modules), reconstruye initramfs. Solo si el hardware es lento-pero-correcto, añade rootdelay=10 temporalmente.

“Volume group not found” → herramientas/hooks LVM faltantes → incluye lvm2 en initramfs

Síntoma: No hay /dev/vg0/root, vgscan falla o no está presente.
Causa raíz: lvm2 no está instalado o no se incluyó en initramfs; o filtro equivocado en la configuración de LVM.
Solución: Desde chroot: instala/arregla lvm2, ejecuta update-initramfs -u -k all. Evita sobre-filtrar dispositivos a menos que sepas por qué.

“Cannot unlock /dev/… (cryptsetup: not found)” → cryptsetup faltante → reconstruir initramfs con cryptsetup

Síntoma: No aparece el prompt de passphrase o hay errores de cryptsetup.
Causa raíz: El paquete/hooks de cryptsetup falta en initramfs, o /etc/crypttab está roto.
Solución: Corrige /etc/crypttab, asegúrate de que cryptsetup-initramfs esté instalado, reconstruye initramfs.

“md0 stopped/does not exist” → RAID no se ensambla → arreglar mdadm e initramfs

Síntoma: Arreglos no presentes en /proc/mdstat.
Causa raíz: Configuración de mdadm no embebida en initramfs, UUID del arreglo cambiado o nombres de dispositivo modificados.
Solución: Ensambla manualmente para probar que funciona; actualiza /etc/mdadm/mdadm.conf; reconstruye initramfs.

“Structure needs cleaning” o error de montaje → corrupción de sistema de archivos → fsck/xfs_repair y revisar salud del disco

Síntoma: Montaje falla; fsck reporta reparaciones.
Causa raíz: Apagado no limpio, errores I/O subyacentes o fallo real del medio.
Solución: Ejecuta la herramienta de reparación adecuada; luego revisa SMART y logs del kernel por errores I/O. Si los errores persisten, deja de confiar en ese disco.

Arranca solo una vez tras ediciones manuales → arreglaste un síntoma, no el sistema → haz los cambios persistentes

Síntoma: Editar GRUB en el arranque te deja entrar, pero al reiniciar vuelve a fallar.
Causa raíz: No regeneraste la configuración de GRUB ni initramfs dentro del sistema instalado.
Solución: Monta la raíz, chroot, aplica los cambios en /etc/default/grub, /etc/fstab, /etc/crypttab, luego ejecuta update-grub y update-initramfs -u -k all.

Listas de verificación / plan paso a paso (volver a verde)

Checklist A: Pasos mínimos para arrancar una vez (modo triage)

En la shell de initramfs, ejecuta cat /proc/cmdline y anota qué se supone que es la raíz.
Ejecuta lsblk y blkid para ver qué existe.
Si la raíz está cifrada: cryptsetup luksOpen.
Si la raíz está en LVM: vgscan luego vgchange -ay.
Si la raíz está en RAID: mdadm --assemble --scan.
Monta la raíz en solo lectura; inspecciona /etc/fstab y /var/log/boot.log en busca de errores explícitos.
Si el montaje falla: ejecuta la herramienta de reparación de sistema de archivos apropiada.
Reinicia solo después de hacer consistentes los identificadores, o volverás a buclear.

Checklist B: Pasos de reparación duradera (los que evitan recurrencia)

Monta la raíz y (si aplica) la partición del sistema EFI en /boot/efi.
Bind-mount /dev, monta /proc y /sys, luego chroot.
Arregla /etc/fstab para usar UUID/PARTUUID correctos (preferir UUID para sistemas de archivos, PARTUUID para particiones en algunos esquemas de arranque).
Arregla /etc/crypttab y /etc/mdadm/mdadm.conf si se usan.
Regenera initramfs para todos los kernels instalados: update-initramfs -u -k all.
Regenera la configuración de GRUB: update-grub.
Instala GRUB solo si el cargador en sí está dañado o las entradas de disco/EFI cambiaron: grub-install ....
Ejecuta findmnt --verify --verbose para validar los montajes.
Reinicia y observa la consola una vez. Si es un servidor remoto, mantén una consola fuera de banda conectada para el primer reinicio.

Checklist C: Si initramfs no tiene las herramientas que necesitas

Arranca desde un instalador/rescue ISO de Debian o un entorno live.
Monta el sistema raíz bajo /mnt (más EFI si es necesario).
Chroot e instala paquetes faltantes: lvm2, mdadm, cryptsetup-initramfs según corresponda.
Reconstruye initramfs y GRUB desde el chroot.

Preguntas frecuentes

1) ¿Initramfs significa que mi instalación está corrupta?

No. Significa que el arranque temprano no pudo montar la raíz. Eso puede ser corrupción, pero más a menudo es un dispositivo faltante, UUID equivocado o una capa de almacenamiento no ensamblada.

2) Veo mi disco en `lsblk`. ¿Por qué no puede montar la raíz?

Porque “el disco existe” no es lo mismo que “el identificador de raíz coincide” o “las capas están ensambladas”. Compara UUIDs con blkid. Si hay cifrado/LVM/RAID, la raíz puede estar dentro de un dispositivo mapeado que aún no existe.

3) ¿Debería añadir `rootdelay=` para arreglarlo?

Sólo si el dispositivo aparece tarde pero de forma consistente (común en arranque por USB o firmware problemático). Si el UUID es incorrecto o falta el driver, rootdelay solo te hará esperar más para el mismo fallo.

4) ¿Por qué pasó justo después de una actualización del kernel?

Las actualizaciones de kernel suelen regenerar initramfs. Si faltan hooks, la configuración cambió o estás arrancando un kernel distinto al que crees, el nuevo initramfs puede no incluir módulos/herramientas que tu pila raíz requiere.

5) Edité GRUB en el arranque y funcionó. ¿Cómo lo hago permanente?

Arranca, monta, chroot, arregla /etc/default/grub o las referencias UUID subyacentes, luego ejecuta update-grub. Si initramfs también necesita cambios, ejecuta update-initramfs -u -k all.

6) ¿Puedo volver a referenciar con estilo `/dev/sda2`?

Puedes, pero estás eligiendo fragilidad. Los identificadores estables existen porque la enumeración de dispositivos no es estable. Usa UUID/PARTUUID a menos que disfrutes la ruleta de arranque.

7) ¿Cuál es la diferencia entre arreglar `/etc/fstab` y arreglar el `root=` de GRUB?

El root= de GRUB controla qué se monta como / durante el arranque temprano. /etc/fstab controla qué se monta después de que el espacio de usuario real arranque. Si cualquiera está mal, puedes fallar—solo en distintos momentos.

8) ¿Es seguro ejecutar reparaciones de sistema de archivos desde initramfs?

A menudo es el lugar más seguro porque hay menos cosas montadas. Aún así: ejecuta solo la herramienta que coincida con tu FS y prefiere montajes de solo lectura y diagnósticos primero. Si sospechas fallo de hardware, las reparaciones pueden no “pegar”.

9) Mi shell de initramfs no tiene `lvm` o `mdadm`. ¿Y ahora?

Arranca un entorno de rescate, monta el sistema, chroot, instala los paquetes faltantes y luego reconstruye initramfs. Si las herramientas no están en initramfs, no podrá ensamblar tu pila de almacenamiento durante el arranque.

10) ¿Cómo sé si esto es hardware?

Mira errores I/O en dmesg, corrupción repetida de sistemas de archivos, dispositivos que desaparecen o fallos SMART (desde un entorno de rescate). Los problemas de configuración fallan de forma consistente; el hardware falla de maneras creativas.

Próximos pasos para evitar incidentes repetidos

El prompt de initramfs es un síntoma, no un diagnóstico. Te está diciendo una cosa: “la raíz no se montó”. Tu trabajo es responder el por qué con evidencia: dispositivos de bloque, identificadores y ensamblado de capas de almacenamiento.

Haz esto a continuación, en este orden:

Haz consistentes los identificadores. Alinea root=, /etc/fstab y cualquier configuración de capas (crypttab, mdadm, LVM) con lo que reporta blkid.
Reconstruye initramfs para todos los kernels que puedas arrancar. Si solo arreglas el kernel que corre ahora, un reinicio posterior puede arrancar una imagen antigua rota.
Regenera la configuración de GRUB. Luego instala GRUB solo si es necesario.
Estandariza y documenta. Si gestionas más de un sistema, fija una pila raíz coherente (UUIDs, mismo particionado, mismo cifrado/LVM/RAID) y mantén una lista de recuperación probada, no admirada.

Una cita para tener en mente durante estos incidentes: “La esperanza no es una estrategia.” (idea parafraseada, repetida a menudo en círculos de ingeniería/operaciones)

Cuando vuelvas a estar en línea, trata el incidente como un regalo: te mostró exactamente dónde tu cadena de arranque depende del conocimiento tribal. Arregla esa dependencia. El tú del futuro tendrá menos sueño.