Entradas de arranque UEFI y estado de Secure Boot en Linux y Windows

Objetivo

Inspeccionar y, si hace falta, reparar la lista de entradas de arranque del firmware UEFI, y confirmar el estado de Secure Boot en un sistema Linux o Windows que no arranca desde el disco o el cargador esperado.

Requisitos previos

Firmware UEFI (no BIOS heredado); acceso root en Linux o un símbolo del sistema con privilegios elevados en Windows, desde el sistema en ejecución, un medio de rescate o la pantalla de configuración del firmware; en Linux, efivarfs montado (lo normal en sistemas que arrancan con UEFI).

Pasos

1. Para listar las entradas en Linux, efibootmgr -v muestra el número, la etiqueta y la ruta de dispositivo de cada entrada, el BootOrder que sigue el firmware y BootCurrent, la entrada usada en este arranque. Para crear una entrada: efibootmgr -c -d <disk> -p <partition> -L "<label>" -l '\EFI\<dir>\shimx64.efi' (-c también añade la nueva entrada a BootOrder, normalmente al principio). Para eliminar una: efibootmgr -b <bootnum> -B. Para reordenar: -o <bootnum>,<bootnum>,.... Cada modificación escribe de inmediato las variables del firmware; no existe un paso de aplicación aparte. Conviene guardar antes la salida de -v para poder restaurar el orden anterior con -o.
2. Para probar una entrada nueva una sola vez sin cambiar el orden, use efibootmgr -n <bootnum> (BootNext); el firmware la usa solo en el siguiente arranque y después vuelve a BootOrder.
3. En Windows, bcdedit /enum firmware lista las entradas del administrador de arranque del firmware (distintas de las entradas del cargador del sistema operativo que muestra un simple bcdedit /enum); en PowerShell hay que poner entre comillas identificadores como '{fwbootmgr}'. Lo habitual es recrear la entrada de Windows con bcdboot <drive>:\Windows (con privilegios elevados) en lugar de editarla directamente.
4. Si, tras reinstalar el cargador de arranque, el sistema arranca en la configuración del firmware o en un sistema operativo equivocado, la causa habitual es que falta la entrada o que no es la primera del orden; se corrige con efibootmgr -o o con el ajuste de orden de arranque del firmware.
5. Antes de atribuir a Secure Boot un error de tipo «not trusted», compruebe su estado: mokutil --sb-state en Linux; en Windows, Confirm-SecureBootUEFI en un PowerShell con privilegios elevados devuelve $True o $False, y muestra "Cmdlet not supported on this platform" en BIOS o en firmware no compatible.
6. Con Secure Boot activado, la cadena en Linux es la siguiente: el firmware confía en un shim firmado, y shim confía además en las Machine Owner Keys (MOK). mokutil --import <key.der> pide una contraseña de un solo uso y solo deja la clave preparada; en el siguiente arranque, MokManager de shim pide en la consola que se confirme el registro con esa contraseña, de modo que alguien debe estar presente en la consola. Este artículo no cubre la generación ni la firma de claves.
7. Tras cualquier modificación, reinicie y confirme con efibootmgr -v o bcdedit /enum firmware que el orden ha surtido efecto.

Resultado esperado

La entrada deseada existe y es la primera en BootOrder; el estado de Secure Boot notificado coincide con lo que necesita la carga de trabajo: preferiblemente activado, con la clave del módulo de terceros registrada mediante MOK en lugar de desactivar Secure Boot.

Límites y base de verificación

efibootmgr modifica directamente la NVRAM: eliminar la entrada equivocada surte efecto al instante, así que compruebe los números de arranque en la salida de -v antes de usar -B. Las implementaciones de firmware difieren en cómo tratan las entradas añadidas o mal formadas (algunas las descartan o las reordenan), por lo que conviene verificar el comportamiento en el hardware real.