Debian 13: entrada UEFI desaparecida — restaura el arranque con efibootmgr en minutos

Qué se rompió realmente cuando la entrada UEFI desapareció

El arranque UEFI es un taburete de tres patas:

1. Entradas en NVRAM del firmware (variables Boot####) que apuntan a un ejecutable EFI en un disco.
2. La partición del sistema EFI (ESP), una partición FAT32 que contiene binarios .efi y configuraciones.
3. Una cadena de cargador de arranque (a menudo shimx64.efi → grubx64.efi → tu kernel).

Cuando pierdes una entrada de arranque, normalmente solo pierdes la pata nº 1. Los archivos en disco siguen existiendo. El firmware simplemente “olvidó” dónde vive Debian, o decidió dejar de preocuparse.

¿Por qué ocurre esto? Causas comunes incluyen:

• Reinicios del firmware tras pérdida de energía, problemas con la batería CMOS o una actualización de BIOS/UEFI.
• El almacenamiento NVRAM está lleno o corrupto (sí, eso existe).
• El instalador de otro sistema operativo reescribe “amablemente” BootOrder.
• Algunas plataformas eliminan silenciosamente entradas que apuntan a discos temporalmente ausentes (USB/NVMe hot swap, drama del controlador RAID).
• Los cambios en Secure Boot que alteran la ruta preferida (shim vs GRUB directo) y hacen que tu entrada parezca “incorrecta” al firmware.

La buena noticia: esto se puede arreglar rápida y seguramente. La mala noticia: debes ser preciso, porque UEFI te permitirá crear una entrada perfecta que apunte al disco equivocado, lo que es básicamente equivalente a no hacer nada pero con más seguridad en ti mismo.

Datos interesantes y un poco de historia (porque importa)

• UEFI reemplazó al BIOS no solo por menús más bonitos, sino para estandarizar el arranque más allá de las limitaciones de 2 TB/MBR y proporcionar un entorno pre-arranque programable.
• La partición del sistema EFI es FAT a propósito: los proveedores de firmware necesitaban algo universalmente legible sin llevar un zoológico de sistemas de archivos.
• Las entradas de arranque UEFI viven en NVRAM, que normalmente está respaldada por flash SPI en la placa base, no en tu disco. Por eso reinstalar GRUB no siempre arregla una entrada perdida.
• Existe una ruta de “reserva” estandarizada: \EFI\BOOT\BOOTX64.EFI en x86_64. Si el firmware no encuentra entradas, puede probar esta ruta. Algunos proveedores dependen de ella más de lo que admiten.
• Secure Boot no “asegura Linux”; asegura qué binarios pueden ejecutarse en el pre-arranque. El sistema operativo aún puede estar mal configurado o comprometido tras el arranque. Es una herramienta de cadena de confianza, no un amuleto mágico.
• efibootmgr habla con la NVRAM vía efivarfs (normalmente montado en /sys/firmware/efi/efivars). Si arrancaste en modo legacy, no puede gestionar variables UEFI porque no están disponibles.
• Algunos firmwares tienen cuotas de NVRAM pequeñas, y los proveedores a veces almacenan registros de fallos o diagnósticos en el mismo espacio. Tus entradas de arranque pueden perder un combate contra “telemetría útil”.
• El ejecutable UEFI de GRUB no es la configuración. La configuración suele estar en /boot/grub/grub.cfg en tu sistema Linux, mientras que el binario EFI en la ESP es solo el stub del cargador.
• La cadena firmada de Debian suele usar shimx64.efi para satisfacer Secure Boot mientras permite que GRUB se cargue, con claves firmadas controladas por Debian en lugar de obligarte a construir tu propia cadena.

Guion de diagnóstico rápido: encuentra el cuello de botella en 5 minutos

Primero: ¿realmente arrancaste en modo UEFI?

Si estás en un entorno de rescate (ISO live, PXE rescue, manos remotas con una consola), confirma si el kernel ve variables UEFI. Si no, detente y vuelve a arrancar el medio de rescate en modo UEFI. Nada más va a permanecer.

Segundo: ¿tienes una ESP y contiene cargadores de Debian?

Encuentra la ESP, móntala y busca \EFI\debian\. Si los archivos faltan, el problema está en el disco: reinstala grub-efi-amd64 (y posiblemente shim-signed) y regenera.

Tercero: ¿la NVRAM es escribible y no está llena?

Si efibootmgr no puede crear entradas, tu firmware puede estar bloqueando escrituras, el filesystem de variables puede no estar montado, Secure Boot puede restringir actualizaciones de variables (menos común), o la NVRAM puede estar llena/corrupta. En ese caso, cambia de táctica: usa la ruta de reserva EFI/BOOT/BOOTX64.EFI, o limpia entradas de NVRAM si puedes.

Cuarto: valida BootOrder y la ruta del dispositivo real

Incluso cuando creas una entrada, puede apuntar al disco/partición equivocados si adivinaste. Confirma los números de disco y partición. Luego establece BootOrder deliberadamente. “Deja que el firmware lo ordene” es como terminas viendo un servidor que arranca Windows otra vez.

Tareas prácticas: comandos, salidas, decisiones (el guion operativo)

Estas son las tareas que realmente ejecuto. Cada una tiene tres partes: el comando, qué significa la salida y la decisión que tomas. Ejecútalas desde un shell de rescate Debian si el sistema no arranca. También puedes hacerlo desde un sistema instalado, pero el escenario de entrada desaparecida normalmente significa que no puedes.

Tarea 1: Confirmar que el modo UEFI está disponible

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

Significado: Si el directorio existe, has arrancado en modo UEFI. Si falta, estás en modo legacy/CSM.

Decisión: Si falta, reinicia el medio de rescate y elige la opción de arranque UEFI en el menú del firmware. No procedas con efibootmgr hasta que esto esté presente.

Tarea 2: Confirmar que efivarfs está montado (acceso a NVRAM)

cr0x@server:~$ mount | grep -E 'efivars|efi'
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Significado: efivarfs es la interfaz del kernel a las variables UEFI.

Decisión: Si no está montado, móntalo (Tarea 3) o arregla por qué tu kernel de rescate no lo soporta.

Tarea 3: Montar efivarfs si es necesario

cr0x@server:~$ sudo mount -t efivarfs efivarfs /sys/firmware/efi/efivars
cr0x@server:~$ mount | grep efivars
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Significado: Sin esto, efibootmgr puede mostrar “EFI variables are not supported” o fallar al escribir.

Decisión: Si el montaje falla, puede que estés en modo legacy o ejecutando un kernel sin soporte para variables EFI.

Tarea 4: Inspeccionar BootOrder y entradas actuales

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0007,0001,0002
Boot0001* UEFI: Built-in EFI Shell	HD(1,GPT,8f2c0f9f-6c7f-4f84-9b8c-9f5f3b2f0b0a,0x800,0x32000)/File(\EFI\tools\Shell.efi)
Boot0002* UEFI PXEv4 (MAC:001122334455)	PciRoot(0x0)/Pci(0x1,0x1)/MAC(001122334455,0)
Boot0007* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Significado: Puedes ver si existe una entrada “debian” y a qué ruta de archivo apunta.

Decisión: Si falta la entrada Debian, la recrearás. Si existe pero apunta a un archivo inexistente, arregla el contenido de la ESP o corrige la ruta.

Tarea 5: Encontrar la partición del sistema EFI

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINTS
NAME        SIZE FSTYPE PARTTYPE                             PARTLABEL     MOUNTPOINTS
nvme0n1   953.9G
├─nvme0n1p1   512M vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System
├─nvme0n1p2     2G ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 boot
└─nvme0n1p3 951.4G crypto_LUKS 0fc63daf-8483-4772-8e79-3d69d8477de4 root

Significado: La ESP suele ser vfat con tipo GPT c12a7328-f81f-11d2-ba4b-00a0c93ec93b.

Decisión: Anota el dispositivo (aquí /dev/nvme0n1p1). Si no ves una ESP, podrías estar en arranque legacy, el diseño del disco puede estar mal (o estás en hardware de proveedor raro).

Tarea 6: Montar la ESP e inspeccionar contenidos

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount -t vfat /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo find /mnt/esp/EFI -maxdepth 2 -type f -name '*.efi' | sort
/mnt/esp/EFI/BOOT/BOOTX64.EFI
/mnt/esp/EFI/debian/grubx64.efi
/mnt/esp/EFI/debian/shimx64.efi

Significado: Si ves los binarios EFI de Debian, el lado del disco está bien y la entrada NVRAM es probablemente el problema.

Decisión: Si /mnt/esp/EFI/debian/ falta o está vacío, necesitas reinstalar GRUB/shim en la ESP.

Tarea 7: Verificar el archivo cargador al que apunta la entrada del firmware

cr0x@server:~$ sudo test -f /mnt/esp/EFI/debian/shimx64.efi && echo "shim present"
shim present
cr0x@server:~$ sudo test -f /mnt/esp/EFI/debian/grubx64.efi && echo "grub present"
grub present

Significado: Confirma que el archivo exacto existe. Esto evita el clásico desajuste “la entrada apunta a grubx64.efi pero solo existe shim”.

Decisión: Si falta, reinstala paquetes y ejecuta grub-install (Tarea 10–11).

Tarea 8: Comprobar si el sistema de archivos ESP está dañado

cr0x@server:~$ sudo umount /mnt/esp
cr0x@server:~$ sudo fsck.vfat -n /dev/nvme0n1p1
fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkfs.fat"
Media byte 0xf8 (hard disk)
...
/dev/nvme0n1p1: 12 files, 1024/130560 clusters

Significado: La ejecución con -n es de solo lectura. Estás buscando corrupción obvia sin modificar nada.

Decisión: Si reporta errores, programa una reparación adecuada (quita -n) y espera reinstalar archivos de arranque si estaban dañados.

Tarea 9: Revisar logs del kernel para fallos al escribir variables EFI

cr0x@server:~$ dmesg | grep -i -E 'efivars|efi:|secure|nvram' | tail -n 20
[    0.214321] efi: EFI v2.80 by American Megatrends
[    0.214322] efi: ESRT=0xb7f3c000 ACPI=0x9b5f4000 ACPI 2.0=0x9b5f4000 SMBIOS=0xb7f2e000
[    1.902114] efivars: Registered efivars operations

Significado: Quieres ver una inicialización EFI normal. Si ves “efivars: write error” o “no space left on device”, ese es tu culpable.

Decisión: Si hay errores de escritura, planifica arranque por la ruta de reserva o limpieza de entradas NVRAM (Tarea 14–15).

Tarea 10: Preparar un chroot (al reparar desde rescate)

cr0x@server:~$ sudo cryptsetup open /dev/nvme0n1p3 cryptroot
Enter passphrase for /dev/nvme0n1p3:
cr0x@server:~$ sudo vgchange -ay
  2 logical volume(s) in volume group "vg0" now active
cr0x@server:~$ sudo mount /dev/vg0/root /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi

Significado: El root de tu sistema instalado, /boot y la ESP están montados en los lugares estándar para Debian.

Decisión: Si /boot/efi no está montado en el chroot, grub-install puede escribir en el lugar equivocado y no arreglarás nada.

Tarea 11: Bind-montar directorios del sistema y chroot

cr0x@server:~$ for d in /dev /dev/pts /proc /sys /run; do sudo mount --bind $d /mnt$d; done
cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# mount | grep -E '/boot/efi|efivars'
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/sys/firmware/efi/efivars on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Significado: El chroot ve la ESP real y efivars. Bien. Estás operando sobre el estado real del sistema.

Decisión: Si efivars no es visible en el chroot, bind-monta /sys correctamente y confirma que arrancaste el entorno de rescate en modo UEFI.

Tarea 12: Reinstalar los paquetes de arranque UEFI de Debian (cadena firmada)

cr0x@server:/# apt-get update
Hit:1 cdrom://Debian GNU/Linux 13.0.0 _Trixie_ - Official amd64 NETINST 20251201-10:22  trixie InRelease
Reading package lists... Done
cr0x@server:/# apt-get install --reinstall grub-efi-amd64 shim-signed
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 0 not upgraded.
Setting up shim-signed (1.60+15.8-1) ...
Setting up grub-efi-amd64 (2.12-2) ...

Significado: Estás restaurando binarios EFI y scripts conocidos como buenos. Los paquetes de Debian normalmente también activan pasos postinst apropiados.

Decisión: Si Secure Boot está deshabilitado y no quieres shim, puedes omitirlo. Pero en entornos mixtos, reinstalar shim evita sorpresas más adelante.

Broma #1: La NVRAM de UEFI es como un armario pequeño: todo cabe hasta que necesitas un abrigo más, y entonces no cabe nada y todos culpan al abrigo.

Tarea 13: Ejecutar grub-install explícitamente (cuando los paquetes no bastaron)

cr0x@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: Esto escribe el cargador en la ESP bajo /boot/efi/EFI/debian/, y además puede crear una entrada en NVRAM.

Decisión: Si da error con “cannot find EFI directory”, tu ESP no está montada donde crees. Detente y arregla los montajes.

Tarea 14: Regenerar la configuración de GRUB (por coherencia, no por superstición)

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

Significado: Esto valida que tu sistema instalado ve kernels y puede generar un menú coherente.

Decisión: Si no puede encontrar kernels, estás resolviendo el problema equivocado: puede que tengas un /boot mal montado o paquetes de kernel faltantes.

Tarea 15: Crear (o recrear) la entrada de arranque UEFI con efibootmgr

cr0x@server:/# efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian" -l '\EFI\debian\shimx64.efi'
BootCurrent: 0007
BootOrder: 0007,0001,0002
Boot0008* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Significado: Esto escribe una nueva variable Boot#### apuntando al cargador. Fíjate en el disco (-d) y el número de partición (-p); eso es lo esencial.

Decisión: Si tiene éxito, pon BootOrder para que lo prefiera (Tarea 16). Si falla con “No space left on device”, ve a limpieza de NVRAM o arranque por fallback (secciones posteriores).

Tarea 16: Poner Debian primero en BootOrder (sé mandón)

cr0x@server:/# efibootmgr
BootCurrent: 0007
BootOrder: 0007,0001,0002,0008
Boot0008* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)
cr0x@server:/# efibootmgr -o 0008,0007,0001,0002
BootOrder: 0008,0007,0001,0002

Significado: Ordenas explícitamente los objetivos de arranque. De lo contrario, el firmware puede seguir arrancando PXE o un shell primero.

Decisión: Siempre establece BootOrder deliberadamente en servidores. Los menús amigables para humanos no son una estrategia de fiabilidad.

Tarea 17: Arranque único hacia la nueva entrada (prueba segura)

cr0x@server:/# efibootmgr -n 0008
BootNext: 0008

Significado: BootNext establece un arranque por única vez. Es una forma de bajo riesgo para probar sin reorganizar todo permanentemente.

Decisión: Usa BootNext cuando estés con manos remotas y quieras que el sistema vuelva a un valor conocido si tu cambio falla.

Tarea 18: Verificar que existe el cargador de reserva (seguro)

cr0x@server:/# ls -l /boot/efi/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 1249280 Dec 28 09:26 /boot/efi/EFI/BOOT/BOOTX64.EFI

Significado: Algunas plataformas arrancarán esto automáticamente cuando faltan entradas NVRAM. Otras no. Pero tenerlo es útil cuando improvisas.

Decisión: Si falta, considera crearlo (sección de fallback) después de restaurar la entrada principal.

Tarea 19: Salir del chroot limpiamente y reiniciar

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

Significado: Estás vaciando escrituras y desmontando para evitar estado sucio. Especialmente importante si ejecutaste comprobaciones de sistema de archivos o tocaste la ESP.

Decisión: Si el reinicio cae de nuevo en el firmware, no te asustes: vuelve a la Tarea 4 y confirma que la entrada todavía existe. Si desaparece otra vez, probablemente tengas problemas de firmware/NVRAM o protección de escritura.

Recrear la entrada UEFI de Debian con efibootmgr (la solución quirúrgica)

El comando que más importa es:

• -c crear una nueva entrada
• -d el dispositivo de disco (no una partición)
• -p el número de partición de la ESP en ese disco
• -L etiqueta mostrada en los menús del firmware
• -l ruta del cargador dentro de la ESP, usando barras invertidas y una ruta absoluta desde la raíz de la ESP

Dos patrones que uso:

Patrón A: Compatible con Secure Boot (shim)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian" -l '\EFI\debian\shimx64.efi'
Boot0009* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Usar cuando: Secure Boot está habilitado, o no controlas la política de la flota y quieres una entrada que funcione en cualquier caso.

Patrón B: GRUB directo (sin shim)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian (grub)" -l '\EFI\debian\grubx64.efi'
Boot0010* debian (grub)	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\grubx64.efi)

Usar cuando: Secure Boot está desactivado y quieres la cadena más simple. También puede ser útil para depurar fallos relacionados con shim.

Cuando efibootmgr “funciona” pero el arranque sigue fallando

Las entradas UEFI pueden ser engañosamente correctas. El firmware almacena una ruta de dispositivo que incluye un GUID de partición GPT. Si clonaste discos, restauraste imágenes o cambiaste hardware, el GUID puede cambiar. A veces las entradas del firmware siguen apuntando al GUID antiguo y se quedan muertas.

En la práctica: si tu entrada muestra una ruta HD() con un GUID que no coincide con el PARTUUID de la ESP actual, recréala usando efibootmgr en vez de intentar editarla.

Una cita para tener en la pared (idea para recordar)

Idea para recordar: Gene Kranz enfatizó que ante una falla debes mantener la calma, trabajar el problema y evitar improvisaciones impulsadas por el pánico.

Usar la ruta de reserva: BOOTX64.EFI (cuando la NVRAM es hostil)

A veces la NVRAM no conserva entradas. Creas una, reinicias y desaparece como un commit culpable. O efibootmgr devuelve “No space left on device”. O la plataforma bloquea escrituras de variables a menos que uses herramientas del proveedor.

Aquí es donde la ruta de reserva UEFI merece su lugar: \EFI\BOOT\BOOTX64.EFI para x86_64. Muchos firmwares arrancarán esta ruta cuando faltan entradas, o puedes seleccionar manualmente la opción “UEFI: dispositivo” del disco y el firmware elegirá la reserva.

Haz Debian arrancable via fallback

Si ya tienes el shim de Debian en la ESP, cópialo a la ubicación de reserva. Prefiere shim cuando Secure Boot pueda estar activo.

cr0x@server:~$ sudo mount -t vfat /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo mkdir -p /mnt/esp/EFI/BOOT
cr0x@server:~$ sudo cp -a /mnt/esp/EFI/debian/shimx64.efi /mnt/esp/EFI/BOOT/BOOTX64.EFI
cr0x@server:~$ sudo sync
cr0x@server:~$ sudo ls -l /mnt/esp/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 1249280 Dec 28 10:11 /mnt/esp/EFI/BOOT/BOOTX64.EFI

Significado: Ahora tienes un cargador de reserva arrancable incluso si la NVRAM se borra.

Decisión: Úsalo cuando sospeches que el firmware elimina entradas, cuando la NVRAM esté llena, o cuando estés en un sitio remoto y quieras la red más simple que “arranca aunque olvide”.

¿Y la configuración al usar fallback?

Shim/GRUB aún necesita encontrar la configuración de GRUB y el sistema de archivos Linux. GRUB de Debian suele incluir lógica para localizar /boot/grub. Si tienes disposiciones exóticas (mdadm, LUKS, múltiples ESP), prueba. No supongas.

Broma #2: La ruta de reserva UEFI es como dejar una llave bajo el felpudo—salvo que el felpudo esté estandarizado por un comité.

Realidad de Secure Boot: shim, GRUB firmado y cómo evitar problemas autoinfligidos

Secure Boot cambia los modos de fallo. Con Secure Boot habilitado:

• El firmware solo ejecutará binarios EFI firmados por claves de confianza.
• Debian normalmente usa shimx64.efi firmado de forma que el firmware lo acepte (vía anclas de confianza comunes), y luego shim valida GRUB.
• Si apuntas una entrada directamente a un grubx64.efi sin firmar, puedes obtener un fallo inmediato que parezca “no arrancó” sin registros.

Consejos prácticos:

• Si no conoces el estado de Secure Boot, asume que puede estar habilitado. Crea la entrada apuntando a shim. Es el valor por defecto con menos drama.
• No cambies Secure Boot como “solución”. Eso no es una solución; es un cambio de política. También puede romper otros hosts si lo tratas como una opción de reinicio casual.
• Mantén la ESP legible y aburrida. Algunos intentan “optimizar” comprimiendo o deduplicando contenidos de la ESP (con herramientas raras). No lo hagas. Es FAT32. Déjala ser FAT32.

Tres microhistorias corporativas desde las trincheras del arranque

Microhistoria 1: El incidente causado por una suposición equivocada

El equipo tenía una pequeña flota de servidores Debian que arrancaban desde dispositivos NVMe espejados. Se programó una actualización de firmware de placa base durante una ventana de mantenimiento. Todo parecía rutinario: parchear, reiniciar, verificar servicios, irse a casa.

Tras la actualización, un subconjunto de nodos volvió al shell UEFI. El responsable asumió que el cargador de arranque había sido corrompido por el proceso de actualización. Reinstalaron GRUB desde modo rescate, dos veces, porque la primera reinstalación “no podía haber fallado”. Aún así no arrancaba. Los ánimos se calentaron. El prompt del shell miraba educadamente.

El problema real: la actualización del firmware reinició la NVRAM y además cambió la preferencia de modo de arranque. Los servidores ahora preferían PXE y entradas de shell, y la entrada Debian no estaba presente. Reinstalar GRUB escribió archivos en la ESP correctamente, pero nadie recreó la entrada NVRAM ni ajustó BootOrder.

Una vez que alguien ejecutó efibootmgr -v y miró, la solución fue trivial: crear la entrada apuntando a shim y fijar BootOrder. La lección no fue “las actualizaciones de firmware son malas”. La lección fue: no asumas “corrupción del cargador” cuando el sistema ni siquiera intenta cargar tu cargador.

Microhistoria 2: La optimización que salió mal

Otra organización quiso “particiones de arranque más limpias”. Estandarizaron imágenes y redujeron la ESP al mínimo: un cargador, un directorio del proveedor, sin extras. También limpiaron entradas UEFI “no usadas” agresivamente como parte del aprovisionamiento, porque algunas máquinas llegaban con un zoológico de diagnósticos de fábrica.

Luego añadieron estaciones de trabajo para desarrolladores con arranque dual en el mismo marco de automatización. Un script, reutilizado en todas partes, eliminó todo lo que no estuviera etiquetado exactamente “debian” y reordenó BootOrder. En papel, ordenado. En la realidad, las estaciones tenían Windows usando BitLocker y necesitaban que su entrada de arranque permaneciera estable.

La siguiente actualización de Windows reescribió su propia entrada y BootOrder (como suele hacer). La automatización se ejecutó, la eliminó y volvió a reordenar. Windows entró en recuperación, los usuarios llamaron al helpdesk y el equipo de plataforma tuvo una semana de recordatorio de que “estandarizar” no es lo mismo que “eliminar cosas que no entiendes”.

Lo arreglaron haciendo el script consciente de roles de plataforma, dejando entradas no Linux intactas salvo que se indique explícitamente, y confiando más en la ruta de reserva como válvula de seguridad en vez de tratar de imponer un único BootOrder perfecto en todas partes.

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

Un banco (sí, de verdad) tenía una política: todo servidor Linux con UEFI debe tener tanto una entrada NVRAM adecuada como un cargador de reserva mantenido en \EFI\BOOT\BOOTX64.EFI. Además requerían que la ESP formara parte de los procedimientos de copia/restore, aunque sea pequeña y parezca “no real”.

Un sitio sufrió problemas de energía repetidos. Varios sistemas volvieron con entradas NVRAM borradas. Normalmente esto se convierte en un desastre en cadena: manos remotas, sesiones de consola, ajustes manuales. En cambio, los hosts arrancaron vía fallback, shim cargó GRUB y el sistema operativo arrancó. Las aplicaciones ni siquiera se enteraron. El ticket del incidente fue casi anticlimático.

Después, el equipo recreó las entradas NVRAM durante horas de oficina y encontró la causa raíz (firmware más energía inestable). Pero el resultado inmediato fue aburrido: los servicios se mantuvieron en funcionamiento. Aburrido es el objetivo.

Por eso haces el trabajo poco sexy: rutas de arranque redundantes, comandos de recuperación documentados y una lista de verificación que no dependa de heroísmos.

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

1) Síntoma: efibootmgr dice “EFI variables are not supported”

Causa raíz: Arrancaste el entorno de rescate en modo legacy/CSM, o efivarfs no está disponible.

Solución: Reinicia el medio de rescate en modo UEFI (Tarea 1). Asegura que efivarfs esté montado (Tarea 2–3).

2) Síntoma: la entrada Debian existe, pero aún así arranca a la configuración del firmware

Causa raíz: BootOrder no la incluye, o está después de PXE/shell, o el firmware la salta tras un intento fallido.

Solución: Establece BootOrder explícitamente (Tarea 16). Usa BootNext para probar (Tarea 17).

3) Síntoma: la entrada Debian apunta a grubx64.efi, pero Secure Boot está activado y no arranca

Causa raíz: El firmware se niega a lanzar un cargador no firmado.

Solución: Apunta la entrada a \EFI\debian\shimx64.efi en su lugar (Tarea 15, Patrón A). Reinstala shim-signed si es necesario (Tarea 12).

4) Síntoma: efibootmgr create falla con “No space left on device”

Causa raíz: El almacenamiento de variables NVRAM está lleno.

Solución: Borra entradas obsoletas (efibootmgr -b #### -B) y reintenta, o usa la ruta de reserva (sección fallback) si las escrituras siguen siendo poco fiables.

5) Síntoma: efibootmgr funciona, pero la entrada desaparece tras reiniciar

Causa raíz: Bug del firmware, protección de escritura o reinicios de configuración (a veces por una pila CMOS fallida o políticas agresivas de “restaurar valores por defecto”).

Solución: Usa la ruta de reserva BOOTX64.EFI para resiliencia, y programa remediación de hardware/firmware. Si es posible, actualiza firmware otra vez o deshabilita funciones “OS optimized defaults” que anulan entradas.

6) Síntoma: GRUB arranca, pero no encuentra el kernel / cae a rescue

Causa raíz: Esto no es una entrada UEFI faltante. Es un problema de configuración de arranque de Linux o de almacenamiento: UUID raíz equivocado, /boot faltante, ensamblaje LUKS/mdadm roto.

Solución: Valida montajes en chroot (Tarea 10–11), ejecuta update-grub (Tarea 14), confirma que initramfs tiene módulos necesarios y revisa /etc/fstab y crypttab.

7) Síntoma: la entrada apunta al archivo correcto, el archivo existe, pero aún así no arranca

Causa raíz: La ESP está en un disco que el firmware no puede leer (cambio de modo de controlador, remapeo RAID, cambios de namespace NVMe), o la entrada referencia un GUID de partición obsoleto tras clonar.

Solución: Recrea la entrada con el disco y la partición correctos (Tarea 15). Si el modo del controlador cambió (AHCI/RAID), revierte o asegura que el firmware pueda acceder a la ESP en ese modo.

Listas de verificación / plan paso a paso (aburrido, rápido, repetible)

Lista A: Tienes acceso a consola y un ISO de rescate

1. Arranca el ISO de rescate en modo UEFI (verifica con Tarea 1).
2. Montar efivarfs si hace falta (Tarea 2–3).
3. Inspeccionar entradas NVRAM (Tarea 4). Decide si la entrada Debian falta o está equivocada.
4. Encontrar y montar la ESP (Tarea 5–6). Confirmar que los archivos del cargador existen (Tarea 7).
5. Si los archivos del cargador faltan, chroot y reinstala (Tarea 10–14).
6. Crear o recrear la entrada de arranque (Tarea 15).
7. Establecer BootOrder (Tarea 16). Opcionalmente establecer BootNext para una prueba (Tarea 17).
8. Reiniciar y observar.

Lista B: NVRAM está llena o el firmware sigue olvidando

1. Confirma que la ESP contiene shim/grub de Debian (Tarea 6–7).
2. Crea el cargador de reserva en \EFI\BOOT\BOOTX64.EFI (sección fallback).
3. Intenta limpiar entradas NVRAM solo si puedes hacerlo con seguridad (borra PXE, shells u OS antiguos claramente obsoletos).
4. Programa remediación de firmware: actualizar, resetear con cuidado, reemplazar la batería CMOS si aplica, y documentar el comportamiento.

Lista C: Arranque dual o múltiples instalaciones de Linux

1. No borres entradas a ciegas. Primero lista las entradas (Tarea 4) y mapea cada una a una ruta ESP.
2. Usa etiquetas explícitas: debian-prod, debian-rescue, windows.
3. Prefiere entradas basadas en shim si Secure Boot puede ser usado por cualquier OS.
4. Mantén un cargador de reserva que arranque tu OS principal, no un instalador.

Preguntas frecuentes

1) ¿Por qué desaparecería una entrada de arranque UEFI?

Porque se almacena en la NVRAM de la placa base, no en el disco. Actualizaciones de firmware, reinicios, eventos de energía o problemas de cuota de NVRAM pueden borrar o podar entradas.

2) Si la ESP está intacta, ¿por qué la máquina no la encuentra sola?

UEFI no suele “escanear y adivinar” como el BIOS antiguo. Sigue las entradas de BootOrder. Algunos firmwares probarán rutas de reserva, pero no puedes confiar en ello a menos que lo configures.

3) ¿Necesito efibootmgr o basta con reinstalar GRUB?

Reinstalar GRUB arregla los archivos del cargador en disco. efibootmgr arregla los punteros en NVRAM. Cuando la entrada desaparece, normalmente necesitas efibootmgr (o arranque por fallback) para reintroducir el puntero.

4) ¿Cuál es el formato correcto de la ruta del cargador en efibootmgr?

Usa una ruta absoluta dentro de la ESP con barras invertidas, como \EFI\debian\shimx64.efi. No uses rutas Linux tipo /boot/efi/... para -l.

5) ¿Debo apuntar a shim o a grub?

Si Secure Boot está activado (o puede activarse luego), apunta a shimx64.efi. Si estás seguro de que Secure Boot está desactivado y permanecerá así, GRUB directo puede estar bien.

6) Mi sistema arranca después de usar BootNext, pero no tras un reinicio normal. ¿Por qué?

BootNext es una anulación de una sola vez. Tu BootOrder persistente aún prefiere otra cosa (PXE, shell, otro disco). Arregla BootOrder (Tarea 16).

7) efibootmgr puede listar entradas pero no puede crear nuevas. ¿Qué pasa?

Leer variables puede funcionar mientras las escrituras fallan, especialmente con agotamiento de cuota de NVRAM o restricciones del firmware. Revisa logs (Tarea 9) y considera el arranque por fallback si las escrituras no se mantienen.

8) ¿Es seguro borrar entradas antiguas Boot#### para liberar NVRAM?

Sí, si sabes lo que son. Borra solo entradas que claramente apunten a discos inexistentes o instaladores antiguos. En entornos mixtos, borrar la equivocada es la manera de provocar otro incidente.

9) ¿Qué pasa si hay múltiples ESPs?

Elige una por política de disco de arranque y sé consistente. El firmware puede preferir la ESP del primer disco enumerado. La estrategia más segura: mantén la ESP primaria en el disco principal de arranque y asegúrate de que tu entrada apunte a ella.

10) ¿Copiar shim a BOOTX64.EFI reemplaza la necesidad de entradas NVRAM?

Frecuentemente funciona como red de seguridad, pero depende del firmware. Trátalo como resiliencia, no como sustituto de entradas NVRAM correctas.

Conclusión: siguientes pasos para evitar una repetición

Si la entrada UEFI de Debian 13 desapareció, la solución más rápida y fiable no es adivinar. Es un bucle ajustado:

1. Arranca en modo UEFI, confirma que efivars funciona.
2. Monta la ESP y verifica que los archivos del cargador existen.
3. Reinstala shim/GRUB solo si faltan archivos.
4. Recrea la entrada NVRAM con efibootmgr y luego establece BootOrder.
5. Añade un cargador de reserva en \EFI\BOOT\BOOTX64.EFI si la plataforma tiene historial de olvidos.

Haz una cosa extra después de volver a estar en línea: escribe el comando efibootmgr exacto que funcionó para este modelo de hardware, incluyendo disco y partición. El tú del futuro agradecerá al tú del presente, y al tú del presente le cuesta trabajo programar citas consigo mismo.