Debian 13: Tu servidor no arranca tras actualizaciones — la reversión limpia de GRUB que realmente funciona

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

¿Te fue útil?

Tu ventana de mantenimiento terminó hace 20 minutos. El servidor sigue “caído”. La consola del hipervisor muestra un educado prompt grub rescue> que no tiene en cuenta tu SLA. Y alguien en Slack está escribiendo “¿lo dejamos inservible?” con la confianza de quien nunca ha tenido que recuperar un sistema.

Este es el camino de recuperación que funciona en el mundo real: diagnóstico rápido primero, luego una reversión/reinstalación limpia de GRUB sin convertir tu disco en una escena del crimen, y después higiene de kernels/initramfs y de /boot para que no vuelva a ocurrir.

Playbook de diagnóstico rápido (qué comprobar 1.º/2.º/3.º)

Los fallos de arranque tras actualizaciones rara vez son “místicos”. Normalmente pertenecen a una de cuatro categorías: dispositivo/entrada EFI incorrecta, núcleo/configuración de GRUB rota, kernel/initramfs ausente, o fallos al desbloquear/ensamblar almacenamiento (LUKS/RAID/ZFS). Tu tarea es identificar la categoría en minutos, no en horas.

Primero: identifica la etapa de fallo por la pantalla exacta

La firmware UEFI vuelve al menú de BIOS/UEFI: la firmware no puede encontrar una entrada de arranque o el binario EFI falta/no es legible.
grub rescue>: GRUB se cargó pero no puede encontrar sus módulos o configuración; a menudo el prefix apunta mal o el sistema de ficheros se movió.
grub> (prompt completo): GRUB funciona; probablemente pueda cargar un kernel si apuntas a la partición correcta.
El kernel se carga y luego cae al initramfs: initramfs no encuentra la raíz (UUID incorrecto, driver faltante, no aparece el prompt de LUKS, mdraid no se ensambla).
Kernel panic inmediatamente tras la actualización: kernel incorrecto, initramfs roto o un driver/regresión; revertir a un kernel anterior suele ser lo más rápido.

Segundo: recopila un hecho sólido: qué disco y qué modo de arranque

Antes de “arreglar”, decide: ¿UEFI o BIOS heredado? ¿NVMe o SATA? ¿mdraid/LUKS/ZFS? Si adivinas, fallarás bajo presión.

Tercero: decide la ruta de recuperación de menor riesgo

Si puedes acceder al menú de GRUB: arranca primero con un kernel más antiguo. Es la reversión menos invasiva.
Si puedes acceder a un entorno de rescate: monta, chroot, reinstala GRUB limpiamente, regenera initramfs, verifica espacio en /boot.
Si los discos no se ensamblan/desbloquean: arregla mdadm/LUKS primero; reinstalar GRUB en un disco que el sistema no puede leer es arte performativo.

Regla operativa: no escribas en discos hasta que puedas explicar qué vas a escribir y dónde irán los bytes. La forma más rápida de convertir un incidente de arranque en un incidente de recuperación de datos es “simplemente ejecutar grub-install en todas partes”.

Por qué ocurre que Debian “no arranca tras actualizaciones” (y qué está realmente roto)

Las actualizaciones de Debian tocan piezas críticas de arranque de manera robusta pero implacable. Los paquetes hacen lo correcto la mayoría de las veces —hasta que tu configuración es algo inusual, tu /boot está justo de espacio, tu firmware es peculiar o ejecutas pilas de almacenamiento que requieren cooperación de early userspace.

Disparadores comunes:

La actualización del paquete GRUB escribió nuevos archivos core pero tu EFI System Partition (ESP) no estaba montada. La actualización “falla con éxito” y la firmware sigue arrancando un binario antiguo.
/boot se llenó y la generación de kernel o initramfs quedó parcial. Ahora tienes una entrada en el menú de GRUB apuntando a un kernel que existe, pero falta initramfs —o al revés.
Los IDs/UUID de disco cambiaron (clonado, reemplazo de disco, remodelado RAID). La configuración de GRUB referencia UUIDs antiguos, por lo que no puede localizar /boot/grub o el kernel.
Las entradas NVRAM de UEFI se reiniciaron (actualización de firmware, reset de CMOS, firmware del proveedor caprichoso). El disco está bien; la firmware se olvidó de cómo encontrarlo.
Initramfs perdió un driver o hook necesario (especialmente con mdraid, LUKS, HBAs exóticos o ZFS-on-root). El kernel arranca y el early userspace no puede localizar la raíz.
Interacciones con Secure Boot: shim, GRUB firmado o firmas de kernel que no coinciden con lo que espera la firmware. Los síntomas van desde rechazo silencioso a un breve parpadeo y reinicio.

Si buscas un único villano, normalmente no es “GRUB es malo”. Es “la cadena de custodia de los artefactos de arranque es desordenada”. Tu reversión debe restaurar la cadena, no añadir copias aleatorias de grubx64.efi en lugares sorprendentes.

Datos interesantes y un poco de historia del gestor de arranque

El nombre GRUB es literal: comenzó como “GRand Unified Bootloader” dentro del proyecto GNU, con la intención de unificar el caos de los primeros gestores de arranque en PC.
GRUB en la era BIOS usaba carga en múltiples etapas (stage1 en el MBR, stage1.5 en el “gap” del MBR, stage2 en /boot). Los discos GPT y las herramientas modernas hicieron que ese “gap” fuera poco fiable, empujando a la gente hacia las BIOS Boot Partitions.
UEFI cambió el juego: los cargadores de arranque pasaron a ser archivos normales en un ESP formateado en FAT, lo que es a la vez más sencillo y más frágil (fácil de sobrescribir, fácil de olvidar montar).
La ruta “fallback” de UEFI existe por una razón: \EFI\BOOT\BOOTX64.EFI es la ruta por defecto que muchas firmwares intentan cuando faltan o están corruptas las entradas NVRAM.
El empaquetado de kernels de Debian es conservador comparado con algunas distros: los kernels antiguos permanecen por diseño, por eso a menudo puedes revertir seleccionando una entrada anterior —a menos que /boot se haya quedado sin espacio.
Initramfs no es teatro opcional: para raíz encriptada, RAID o muchos controladores de almacenamiento, es el early userspace que ensambla el sistema antes de que /sbin/init tenga oportunidad.
“update-grub” es un envoltorio amigable alrededor de grub-mkconfig. Lo importante es la configuración generada y los módulos que GRUB puede realmente cargar.
La NVRAM de UEFI es finita y las implementaciones de firmware varían mucho. Los sistemas pueden y suelen “olvidar” entradas de arranque durante actualizaciones de firmware o cuando la NVRAM se llena.

Una cita para mantener la honestidad, atribuida a Werner Vogels: “Everything fails, all the time.” Eso no es nihilismo; es un requisito de diseño.

Triage en consola: tipos de pantalla de GRUB y su significado

Caso A: “No hay dispositivo de arranque” o la firmware entra en setup

Esto suele ser la firmware que no encuentra el cargador EFI (UEFI) o falta el código de arranque (BIOS heredado). El SO puede estar intacto. Tu trabajo es restaurar una ruta de arranque válida.

Caso B: `grub rescue>`

GRUB se está ejecutando en modo reducido. No puede encontrar sus módulos o configuración normal. Causas típicas: prefix erróneo, particiones movidas, /boot/grub faltante o sistema de ficheros que GRUB no puede leer (menos común en las opciones por defecto de Debian, más común con sistemas de ficheros exóticos).

Caso C: aparece el menú de GRUB, el kernel se carga y aterrizas en initramfs

GRUB hizo su trabajo. Ahora initramfs no puede montar el sistema raíz. Razones comunes: UUID de root incorrecto en la línea de comando del kernel, no se ensambló mdraid, dispositivo LUKS no desbloqueado, módulo driver faltante o una regresión. Esto suele parecer “Debian no arranca” pero GRUB es inocente.

Broma #1: GRUB es como un portero: parece intimidante, pero la mayoría de las veces solo hace cumplir una lista que le diste.

La reversión limpia de GRUB que realmente funciona

“Reversión” en el mundo del gestor de arranque no es un único botón. Lo que quieres es un conjunto conocido y bueno de artefactos de arranque: un binario GRUB que la firmware pueda cargar, módulos de GRUB donde GRUB los espera y una configuración que apunte a kernels e initramfs reales. Puedes lograrlo de dos maneras limpias:

Reversión blanda (preferida cuando es posible): arranca un kernel más antiguo desde el menú “Advanced options” de GRUB. Luego reconstruye initramfs y la configuración de GRUB en el sistema en ejecución, y solo entonces reinstala el cargador si hace falta.
Reversión dura (cuando no arranca nada): arranca un entorno de rescate, monta los sistemas de ficheros, chroot, reinstala GRUB limpiamente al objetivo correcto (UEFI o BIOS), regenera initramfs y la configuración de GRUB, y verifica las entradas EFI.

Qué evitar: copiar binarios EFI al tuntún sin entender cuál usa la firmware, reinstalar GRUB en cada disco “por si acaso”, o editar grub.cfg a mano como si fuera 2004. Debian lo sobrescribirá después, lo olvidarás y tu yo futuro merecerá algo mejor.

Elección del entorno de recuperación

Usa lo que esté más cerca del sistema: el instalador de Debian en modo rescue, una imagen live o el sistema remoto de rescate de tu centro de datos. La clave es que puedas montar el sistema de ficheros instalado y ejecutar las herramientas de Debian contra él.

Decide el modo de arranque: UEFI vs BIOS

No supongas. Muchos servidores soportan ambos y un reinicio de firmware puede cambiar la preferencia. Debian puede instalarse de cualquiera de las dos maneras. Tu reinstalación debe coincidir con el modo.

Qué significa “limpio” para GRUB

UEFI: el ESP correcto está montado en /boot/efi en el chroot, instalas grub-efi-amd64 (o el equivalente arm64), ejecutas grub-install una vez apuntando al --efi-directory correcto y confirmas la entrada NVRAM (o el archivo fallback) existe.
BIOS: instalas grub-pc, ejecutas grub-install /dev/sdX en el disco correcto(s), no en particiones, y verificas que exista la BIOS Boot Partition en GPT si es necesaria.

Tareas prácticas: comandos, salida esperada y la decisión que tomas

Estas son las tareas que realmente ejecutas bajo presión. Cada una incluye: comando, qué significa la salida y qué decisión tomas a continuación.

Task 1: Confirmar si estás arrancado en modo UEFI (en rescate/live)

cr0x@server:~$ ls -ld /sys/firmware/efi
drwxr-xr-x 5 root root 0 Dec 28 10:11 /sys/firmware/efi

Significado: el directorio existe → estás actualmente arrancado en modo UEFI. Si falta, estás en modo BIOS heredado/CSM.

Decisión: coincide con el modo de arranque del sistema instalado. Si el servidor fue instalado en UEFI pero tu rescate arrancó en BIOS, reinstalar GRUB para UEFI puede fallar o instalar lo incorrecto.

Task 2: Inventario de discos/particiones y localizar ESP y /boot

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,FSVER,LABEL,PARTLABEL,PARTUUID,MOUNTPOINTS
NAME        SIZE FSTYPE FSVER LABEL PARTLABEL        PARTUUID                             MOUNTPOINTS
nvme0n1   953.9G
├─nvme0n1p1   512M vfat   FAT32       EFI System     7c2f2d6a-7f0a-4d6b-8a8d-1a2d2b8c0c1e
├─nvme0n1p2     2G ext4         boot  Linux filesystem 1b2c3d4e-...                      
└─nvme0n1p3 951.4G crypto_LUKS        luks  Linux filesystem 9a8b7c6d-...

Significado: busca vfat con “EFI System” → ese es tu ESP. Busca ext4 etiquetado boot → probablemente /boot.

Decisión: ahora sabes qué montar dónde. Si no ves un ESP en un sistema UEFI, puede que estés mirando el disco equivocado o que el ESP esté ausente/corrupto.

Task 3: Si usas LUKS, desbloquea root (o el contenedor que contiene root)

cr0x@server:~$ cryptsetup luksOpen /dev/nvme0n1p3 cryptroot
Enter passphrase for /dev/nvme0n1p3:

cr0x@server:~$ ls /dev/mapper/cryptroot
/dev/mapper/cryptroot

Significado: el mapeo existe → el dispositivo de bloque descifrado está disponible.

Decisión: procede a montar LVM o sistemas de ficheros dentro. Si el desbloqueo falla, detente y soluciona claves/TPM/prompting primero—el trabajo del cargador no ayudará.

Task 4: Si usas LVM dentro de LUKS, activa los volume groups

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

Significado: los LVs están activos y aparecerán bajo /dev/vg0/....

Decisión: monta el LV root. Si los VGs no aparecen, puede que falten los nodos del device mapper correctos o que estés desbloqueando el contenedor equivocado.

Task 5: Montar el sistema instalado (root, /boot, ESP) correctamente

cr0x@server:~$ mount /dev/vg0/root /mnt
cr0x@server:~$ mount /dev/nvme0n1p2 /mnt/boot
cr0x@server:~$ mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ findmnt -R /mnt
TARGET        SOURCE           FSTYPE OPTIONS
/mnt          /dev/vg0/root    ext4   rw,relatime
/mnt/boot     /dev/nvme0n1p2   ext4   rw,relatime
/mnt/boot/efi /dev/nvme0n1p1   vfat   rw,relatime,fmask=0022,dmask=0022

Significado: todos los puntos de montaje esperados están presentes. Aquí es donde muchos intentos de “reinstalar GRUB” fallan: el ESP no estaba montado, así que el nuevo binario EFI fue escrito en un directorio del sistema raíz, no en el FAT legible por la firmware.

Decisión: si /mnt/boot/efi no es vfat, corrige tus montajes antes de tocar GRUB.

Task 6: Bind-mount de sistemas de runtime y chroot

cr0x@server:~$ mount --bind /dev /mnt/dev
cr0x@server:~$ mount --bind /proc /mnt/proc
cr0x@server:~$ mount --bind /sys /mnt/sys
cr0x@server:~$ chroot /mnt /bin/bash
root@server:/#

Significado: ahora operas como si hubieras arrancado en el OS instalado, usando sus paquetes y configuraciones.

Decisión: toda la remediación debe usar ahora las herramientas de Debian desde dentro de este chroot.

Task 7: Comprobar un estado dpkg medio configurado (común tras actualizaciones interrumpidas)

root@server:/# dpkg --audit
The following packages are only half configured, probably due to problems configuring them the first time.
 grub-efi-amd64
 linux-image-6.12.0-amd64

Significado: el estado del empaquetado es inconsistente. Esto puede dejar archivos de GRUB faltantes o artefactos de kernel incompletos.

Decisión: ejecuta los pasos de recuperación para dpkg antes de reinstalar el cargador.

Task 8: Terminar la configuración de paquetes interrumpida limpiamente

root@server:/# apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up linux-image-6.12.0-amd64 (6.12.18-1) ...
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64
Setting up grub-efi-amd64 (2.12-5) ...

Significado: la generación de initramfs y la configuración del paquete GRUB se ejecutaron. Observa errores sobre /boot lleno o ESP no montado.

Decisión: si aparecen errores, arréglalos inmediatamente (espacio, montajes) antes de continuar.

Task 9: Comprobar espacio en `/boot` (esto falla constantemente)

root@server:/# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  2.0G  1.9G   42M  98% /boot

Significado: /boot está prácticamente lleno. Las actualizaciones de kernel pueden haber dejado imágenes parciales o negarse a instalar nuevas de forma limpia.

Decisión: elimina kernels antiguos correctamente (no borrando archivos al azar) antes de regenerar initramfs/configuración de GRUB.

Task 10: Listar kernels instalados y eliminar los obsoletos de forma segura

root@server:/# dpkg -l 'linux-image-*' | awk '/^ii/ {print $2 "\t" $3}'
linux-image-6.10.0-amd64	6.10.12-1
linux-image-6.12.0-amd64	6.12.18-1
linux-image-amd64	6.12.18-1

root@server:/# apt-get remove --purge linux-image-6.10.0-amd64
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  linux-image-6.10.0-amd64*
After this operation, 412 MB disk space will be freed.
Removing linux-image-6.10.0-amd64 (6.10.12-1) ...
update-initramfs: Deleting /boot/initrd.img-6.10.0-amd64
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 6.10.0-amd64 /boot/vmlinuz-6.10.0-amd64
Generating grub configuration file ...
done

Significado: espacio recuperado y la configuración de GRUB actualizada como parte de los hooks de eliminación de kernel.

Decisión: revisa de nuevo el espacio en /boot; quieres holgura para al menos un kernel nuevo + initramfs.

Task 11: Regenerar initramfs para el kernel que planeas arrancar

root@server:/# update-initramfs -u -k 6.12.0-amd64
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

Significado: initramfs existe y fue reconstruido con los hooks/módulos actuales.

Decisión: si esto falla, arréglalo antes de tocar GRUB. Un cargador perfecto que apunta a un initramfs roto seguirá sin arrancar.

Task 12: Verificar que los UUID del sistema de ficheros root coinciden con lo que espera el sistema

root@server:/# blkid /dev/vg0/root
/dev/vg0/root: UUID="f3a1f9e4-7d72-4d88-8c7f-2b1b9d1a0d4c" BLOCK_SIZE="4096" TYPE="ext4"

root@server:/# grep -E '^\s*UUID=|^\s*/dev/' /etc/fstab
UUID=f3a1f9e4-7d72-4d88-8c7f-2b1b9d1a0d4c / ext4 defaults 0 1
UUID=2D3A-11F0 /boot/efi vfat umask=0077 0 1

Significado: fstab referencia los UUID actuales. Si no coinciden, el arranque puede fallar en initramfs o más adelante.

Decisión: si los UUID son incorrectos, corrige /etc/fstab y cualquier referencia en crypttab/mdadm antes de volver a construir initramfs.

Task 13: Generar una nueva configuración de GRUB (no edites grub.cfg a mano)

root@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-amd64
Found initrd image: /boot/initrd.img-6.12.0-amd64
done

Significado: GRUB ve el kernel y el initramfs en /boot. Si dice que no encontró kernels, tu /boot no está montado, o faltan kernels, o los scripts no los detectan.

Decisión: solo procede a reinstalar GRUB cuando update-grub produzca una salida sensata.

Task 14: Reinstalar GRUB para UEFI limpiamente (el caso común en servidores Debian 13)

root@server:/# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

Significado: el binario EFI fue escrito en el ESP montado en el árbol de directorios esperado. No dar error es bueno; pero aún debes verificar que existan las entradas de firmware y que los archivos estén realmente en el ESP.

Decisión: comprueba entradas NVRAM y contenidos del ESP a continuación.

Task 15: Comprobar las entradas NVRAM de UEFI y confirmar que Debian está presente

root@server:/# efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0000
Boot0003* debian	HD(1,GPT,7c2f2d6a-7f0a-4d6b-8a8d-1a2d2b8c0c1e,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot0001* UEFI: Built-in EFI Shell
Boot0000* UEFI PXEv4

Significado: la firmware conoce \EFI\debian\grubx64.efi y está en BootOrder.

Decisión: si la entrada falta o apunta al GUID de disco incorrecto, créala/corrígela o coloca un binario fallback en la ruta por defecto como copia pragmática de seguridad.

Task 16: Verificar el layout de archivos del ESP (porque “montado” no siempre es “correcto”)

root@server:/# ls -R /boot/efi/EFI
/boot/efi/EFI:
BOOT  debian

/boot/efi/EFI/BOOT:
BOOTX64.EFI

/boot/efi/EFI/debian:
grubx64.efi  grub.cfg

Significado: existen tanto el fallback neutro del proveedor como la entrada Debian. En servidores con NVRAM inestable, ese archivo fallback es un héroe silencioso.

Decisión: si /boot/efi/EFI está vacío, instalaste en el lugar equivocado o el ESP no está montado. Detente y corrígelo.

Task 17: Reinstalar GRUB para BIOS heredado (solo si ese es tu sistema)

root@server:/# grub-install --target=i386-pc --recheck /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

Significado: el core de GRUB fue escrito en el área de arranque del disco. En GPT/BIOS también necesitas una BIOS Boot Partition; sin ella, las instalaciones pueden “tener éxito” pero no arrancar de forma fiable.

Decisión: si estás en GPT y no tienes una BIOS boot partition, replantea la situación: cambiar a UEFI suele ser más limpio en servidores modernos.

Task 18: Comprobación final: qué kernel cmdline se usará

root@server:/# cat /etc/default/grub | sed -n 's/^GRUB_CMDLINE_LINUX_DEFAULT=//p'
"quiet"

root@server:/# cat /etc/default/grub | sed -n 's/^GRUB_CMDLINE_LINUX=//p'
""

Significado: si necesitas parámetros especiales (mdraid, cryptdevice, rootdelay, console=ttyS0), aquí vive la configuración persistente. No los metas en grub.cfg.

Decisión: si eres solo remoto, configura ahora los parámetros de consola serial, regenera la configuración de GRUB y evítate el próximo incidente a ciegas.

Task 19: Salir del chroot, desmontar limpiamente, reiniciar

root@server:/# exit
cr0x@server:~$ umount -R /mnt
cr0x@server:~$ reboot

Significado: un desmontaje limpio reduce sorpresas en el sistema de ficheros. Reiniciar prueba toda la cadena: firmware → GRUB → kernel → initramfs → root.

Decisión: si aún falla, captura la etapa exacta del nuevo fallo; no repitas la misma solución esperando diferente resultado.

Broma #2: Reiniciar no es una solución. Es un voto. A veces vota por “sigue roto”.

Tres micro-historias corporativas (cómo falla esto en producción)

Micro-historia 1: El incidente causado por una suposición equivocada

Manejaban una flota de servidores Debian en una nube privada. La mayoría estaban instalados en UEFI. Algunos nodos antiguos eran BIOS heredado porque “no importaba” en su momento, y los valores por defecto del instalador eran lo que el técnico había pulsado ese día. Nadie documentó cuál era cuál. Por supuesto que no.

Un ciclo de actualizaciones pasó: actualización de kernel más actualizaciones de GRUB. Un nodo no volvió. La consola mostró un menú de firmware. El ingeniero de guardia arrancó el ISO de rescate, hizo chroot y ejecutó grub-install /dev/sda por costumbre. “Funcionó”. El sistema seguía sin arrancar.

Repitieron con más intensidad: instalaron GRUB en ambos discos (estaban en espejo), reconstruyeron configuraciones, reiniciaron otra vez. Aún menú de firmware. Horas desaparecidas de la manera especial que solo un bucle de arranque puede robar.

El problema era simple y humillante: el nodo estaba instalado en modo UEFI, y la firmware buscaba una entrada EFI y un archivo en el ESP. Instalar GRUB en BIOS al MBR no hizo nada salvo añadir ruido. El ISO de rescate había arrancado en modo BIOS, lo que reforzó la suposición equivocada.

Cuando arrancaron el ISO de rescate en modo UEFI, montaron el ESP y ejecutaron el grub-install dirigido a UEFI, volvió inmediatamente. La acción del postmortem fue igual de sencilla: registrar el modo de arranque en el inventario. No en la cabeza de alguien. No en una página wiki que nadie abre durante un incidente. En hechos del sistema que la automatización pueda consultar.

Micro-historia 2: La optimización que salió mal

Otra empresa tenía una iniciativa de “arranque ligero”. Alguien notó que /boot solo se usa durante el arranque y las actualizaciones, así que lo redujeron agresivamente. Particiones más pequeñas significaban imágenes más rápidas y menos espacio desperdiciado en miles de nodos. Ese fue el argumento.

Funcionó durante meses. Luego una actualización rutinaria incluyó kernel y paquetes de microcódigo. El initramfs creció, como suelen hacerlo cuando el soporte hardware se expande y los hooks se acumulan. El /boot de un nodo se llenó a mitad de actualización. El paquete de kernel instaló sus archivos, pero la generación de initramfs falló. La salida del gestor de paquetes estuvo allí — en algún lugar — pero la automatización no la trató como un fallo serio.

Tras reiniciar, GRUB mostró la nueva entrada de kernel (porque vmlinuz existía) e intentó arrancarla. El initramfs referenciado en el menú no estaba. El nodo cayó en un shell de initramfs, luego agotó tiempo, luego reinició y volvió a ocurrir. Un pequeño outage autosostenible perfecto.

La solución no fue exótica: arranca el kernel anterior, purga kernels antiguos correctamente, reconstruye initramfs y regenera la configuración de GRUB. La lección: la “optimización” que quita holgura al almacenamiento crítico de arranque es un préstamo. Eventualmente lo devuelves con intereses, normalmente durante una ventana de mantenimiento que prometiste sería aburrida.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización del sector financiero gestionaba servidores Debian con raíces encriptadas (LUKS) y control de cambios estricto. Sus actualizaciones eran automatizadas pero deliberadamente gradual: actualizar un canario, esperar y luego desplegar. Además mantenían dos kernels conocidos y buenos instalados en todo momento y monitorizaban el uso de /boot.

Una noche, una actualización de kernel introdujo una regresión para una versión de firmware de un controlador de almacenamiento. El canario reinició y aterrizó en initramfs porque no se encontró la raíz. El servicio estaba caído en ese nodo, pero el incidente no se expandió porque el despliegue se pausó automáticamente tras una comprobación de salud fallida.

Ops utilizó la consola para seleccionar el kernel previo en las opciones avanzadas de GRUB. El nodo volvió. Fijaron temporalmente esa versión de kernel, reconstruyeron initramfs incluyendo un módulo específico y programaron la actualización de firmware del controlador por separado.

No pasó nada heroico. Nadie escribió conjuros mágicos. El sistema sobrevivió porque hicieron las partes aburridas: despliegue por fases, conservar kernels de reversión y tratar el espacio de /boot como un recurso monitorizado. Así es la fiabilidad la mayoría de los días: competencia repetible y poco emocionante.

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

Síntoma: grub-install “tiene éxito” pero tras reiniciar sigues en el menú de firmware.
Causa raíz: el ESP no estaba montado; instalaste dentro de /boot/efi del sistema raíz, no en el ESP.
Solución: monta el ESP real (vfat), verifica con findmnt, vuelve a ejecutar grub-install --efi-directory=/boot/efi, comprueba con efibootmgr -v.
Síntoma: el menú de GRUB muestra kernel nuevo, pero el arranque cae a initramfs con “cannot find UUID”.
Causa raíz: el UUID de root cambió (clonación/reemplazo de disco) o cambió el nombre del mapeo crypt/mdraid; initramfs aún contiene referencias antiguas.
Solución: corrige /etc/fstab, /etc/crypttab y la configuración de mdadm si aplica; ejecuta update-initramfs -u -k all.
Síntoma: update-grub no encuentra kernels.
Causa raíz: /boot no está montado (partición separada), o los kernels fueron eliminados/no se instalaron por errores de dpkg.
Solución: monta /boot; verifica /boot/vmlinuz-*; repara paquetes con dpkg --configure -a y apt-get -f install.
Síntoma: bucle de arranque tras selección en GRUB; kernel panic temprano.
Causa raíz: initramfs roto, driver de almacenamiento faltante, o regresión en el kernel nuevo.
Solución: arranca kernel anterior; reconstruye initramfs; considera fijar la versión del paquete kernel hasta que la regresión se resuelva.
Síntoma: prompt grub rescue>, ls muestra particiones pero normal no puede cargar.
Causa raíz: el prefix de GRUB apunta a la partición equivocada o /boot/grub falta/está corrupto.
Solución: usa rescue/live, monta correctamente, chroot, reinstala GRUB y regenera la configuración; también verifica la integridad del disco/SF.
Síntoma: sistemas con Secure Boot activado se niegan a arrancar tras actualización de GRUB.
Causa raíz: binarios EFI no firmados o cadena shim no coincidente; o conjunto de paquetes instalado incorrecto.
Solución: asegúrate de instalar los paquetes firmados correctos para tu política; desactiva temporalmente Secure Boot solo como paso diagnóstico y luego restaura una cadena de arranque conforme.
Síntoma: sistemas con root en mdraid caen a initramfs sin arrays ensamblados.
Causa raíz: initramfs sin configuración de mdadm o módulos; o mismatch de versión/UUID tras reemplazo de disco.
Solución: confirma arrays con mdadm --examine en rescate; arregla /etc/mdadm/mdadm.conf; reconstruye initramfs.

Listas de verificación / plan paso a paso

Checklist A: Si puedes ver un menú de GRUB

Selecciona Advanced options y arranca el kernel anterior.
Una vez arrancado, comprueba espacio en /boot y estado de paquetes.
Reconstruye initramfs para el kernel más reciente cuando haya espacio suficiente.
Ejecuta update-grub, luego reinicia y prueba el kernel más reciente.
Si la firmware aún no encuentra GRUB de forma consistente, reinstala GRUB (UEFI/BIOS correctamente) y verifica con efibootmgr.

Checklist B: Si estás atascado en el menú de firmware o grub rescue

Arranca un entorno de rescate en el modo correcto (UEFI vs BIOS).
Identifica discos/particiones con lsblk. Localiza root, /boot y ESP.
Desbloquea LUKS / ensambla RAID / importa pools según sea necesario antes de montar.
Monta root en /mnt, luego monta /mnt/boot y /mnt/boot/efi si existen.
Bind-mount /dev, /proc, /sys, luego chroot.
Repara el estado de dpkg: dpkg --audit, apt-get -f install.
Arregla espacio en /boot si hace falta; elimina kernels antiguos correctamente.
Reconstruye initramfs para el kernel objetivo.
Ejecuta update-grub y confirma que encuentra kernels/initrd.
Reinstala GRUB al objetivo correcto (UEFI o BIOS).
Verifica con efibootmgr -v y listando archivos del ESP.
Reinicia y observa la consola hasta el primer arranque exitoso.

Checklist C: Guardarraíles para prevenir la próxima

Monitoriza el uso de /boot y alerta al 70–80%.
Mantén al menos un kernel anterior conocido y bueno instalado.
Realiza actualizaciones por fases con canarios; pausa el despliegue ante fallos de arranque.
Asegúrate de que el ESP esté montado y verificado durante actualizaciones (y en gestión de configuración).
Estandariza el modo de arranque en la flota; regístralo en el inventario.
Para sistemas solo remotos, configura parámetros de consola serial del kernel de forma persistente.

Preguntas frecuentes

1) ¿Es realmente un “problema de GRUB” si acabo en initramfs?

Normalmente no. Si el kernel arrancó y estás en initramfs, GRUB cumplió su función. Centra la atención en el descubrimiento del dispositivo root: UUIDs, desbloqueo LUKS, ensamblado mdraid, drivers faltantes o una regresión del kernel. Reconstruye initramfs y valida /etc/fstab//etc/crypttab.

2) ¿Por qué `grub-install` tiene éxito pero no cambia nada?

Lo más común: el ESP no estaba montado. Escribiste archivos EFI dentro de un directorio en el sistema raíz, no en la partición FAT legible por la firmware. Verifica siempre con findmnt /boot/efi y comprueba el contenido del ESP después.

3) ¿Debo copiar `grubx64.efi` a la ruta fallback?

En servidores con entradas NVRAM poco fiables, tener \EFI\BOOT\BOOTX64.EFI puede salvarte. Pero hazlo deliberadamente: asegúrate de que esté en el ESP y mantén coherencia con tu cadena de cargadores prevista. No dejes tres cargadores en conflicto y llames a eso resiliencia.

4) ¿Puedo simplemente borrar archivos antiguos de `/boot` para liberar espacio?

Puedes, y a veces funciona, y también deja a dpkg pensando que los paquetes siguen instalados. Elimina kernels usando apt-get remove --purge linux-image-X para que los hooks actualicen initramfs y la configuración de GRUB correctamente.

5) Mi sistema usa RAID1 para el ESP. ¿Está bien?

UEFI espera FAT en un ESP; las estrategias de espejo varían. Algunas organizaciones mantienen ESP idénticos en ambos discos y actualizan ambos. Eso puede funcionar, pero debes operacionalizarlo (proceso de actualización, verificación). Si solo actualizas un ESP, has creado un failover que falla hacia una realidad antigua.

6) ¿Qué pasa si `efibootmgr` no está disponible en el chroot?

Instálalo dentro del chroot (apt-get install efibootmgr) si hay red/fuentes de paquetes disponibles. Si no, aún puedes asegurarte de que el ESP tenga los archivos correctos; muchas firmwares arrancarán la ruta fallback incluso sin entrada NVRAM.

7) ¿Cambia Secure Boot los pasos de reversión?

La mecánica es la misma—montar ESP, reinstalar los paquetes correctos, regenerar configuraciones—pero los binarios permitidos difieren. Si Secure Boot está forzado, los binarios EFI no firmados pueden ser rechazados. Trata “desactivar Secure Boot” como un paso diagnóstico, no como una solución permanente, salvo que la política lo permita.

8) ¿Cómo sé en qué disco ejecutar `grub-install` en modo BIOS?

Escoge el disco desde el que la BIOS arranca realmente primero (a menudo el primero en el orden de arranque), y en sistemas en espejo considera instalar en ambos discos intencionalmente. Pero no disperses al azar; confirma con el orden de arranque de la firmware y tu topología RAID. En modo BIOS instalas en el dispositivo disco entero, no en una partición.

9) ¿Por qué pasó justo después de una actualización de firmware?

Las actualizaciones de firmware pueden resetear entradas NVRAM o cambiar el orden de arranque. Tu SO y ESP pueden estar bien; la firmware simplemente olvidó la entrada Debian. Verifica con efibootmgr -v y restaura la entrada de arranque o la ruta fallback.

10) ¿Cuál es la mejor prevención única para “no arranca tras actualizaciones”?

Mantén opciones de reversión: al menos un kernel anterior instalado, espacio suficiente en /boot, despliegues por fases y comprobaciones automatizadas de que el ESP está montado durante las actualizaciones del cargador. La fiabilidad no es un acto heroico; es interés compuesto.

Conclusión: siguientes pasos para reducir incidentes repetidos

Cuando Debian 13 no arranca tras actualizaciones, trátalo como un problema en cadena. La firmware debe encontrar un cargador, el cargador debe encontrar módulos/config, GRUB debe apuntar a un kernel e initramfs que existan, e initramfs debe poder desbloquear/ensamblar/montar la raíz. Arregla el eslabón roto, no toda la cadena con un martillo.

Haz esto a continuación, mientras el incidente está fresco:

Estandariza el modo de arranque en tu flota (preferible UEFI en hardware moderno) y regístralo en el inventario.
Añade monitorización del uso de /boot y alerta antes de que se convierta en fallo de empaquetado.
Mantén al menos un kernel conocido y bueno instalado; no “limpies” tu camino de reversión.
Automatiza una comprobación post-actualización: ESP montado, update-initramfs sin errores, update-grub encontró kernels y efibootmgr muestra una entrada sensata.
Si usas root encriptado, RAID o ZFS: valida que tu initramfs incluya los hooks/módulos correctos tras cada cambio mayor. El early userspace es parte de tu pila de almacenamiento.