Re-enroll TPM2 tras actualizar mkinitcpio systemd hook: Guía para sysadmins

septiembre 23, 2026 Alfonso Moreno | Sysadmin Senior 56 Visitas 11 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Por qué Arch publicó este aviso el 22 de septiembre

El 22 de septiembre de 2026, David Runge publicó en archlinux.org/news un aviso corto pero con impacto inmediato para quienes usan TPM2 para desbloquear LUKS: a partir de mkinitcpio 42-1, el hook systemd de la imagen de arranque ahora incluye systemd-pcrosseparator.service, una unidad que systemd v261 introdujo el 19 de junio de 2026 y que Arch recién ahora está activando en su initramfs.

Lo que hace esa unidad es escribir mediciones extra en los registros PCR del TPM2: concretamente PCR 0, 1, 2, 3, 4, 5, 6, 7, 9, 12, 13 y 14. Esas mediciones son la “huella” que el TPM2 compara en cada arranque para decidir si desbloquea la partición LUKS. Si tu política de desbloqueo automático quedó registrada con los valores viejos, ahora no van a coincidir, y el sistema te va a soltar al shell de initramfs pidiéndote la passphrase manual. Eso, en un servidor remoto sin consola IPMI, es un dolor de cabeza importante.

La buena noticia: Arch no cambió la API, ni rompió compat. La política vieja sigue siendo válida para volúmenes ya enrollados; lo que hay que hacer es re-enrollar con los valores nuevos de PCR. La mala: si no lo hacés antes del próximo reboot que cargue la nueva imagen de arranque, el sistema no va a arrancar solo.

Qué cambió exactamente en mkinitcpio

Hasta la versión 41, el hook systemd de mkinitcpio construía un initramfs que arrancaba con systemd, montaba la partición cifrada y desbloqueaba el TPM2 sin más. A partir de 42-1, el hook agrega systemd-pcrosseparator.service a la lista de unidades que corren al inicio.

El propósito de esa unidad es separar visualmente las mediciones que ya produjo el firmware UEFI de las que vienen del initramfs. En la práctica, agrega eventos extra al event log del TPM2, que se traducen en hashes distintos en los PCR que listamos arriba. Esto le sirve a systemd-pcrlock para distinguir con más precisión qué fase del boot midió qué cosa.

Si te suena a sutileza teórica, no lo es: la consecuencia directa es que cualquier política de TPM2 basada en esos PCR deja de coincidir con el estado del chip al boot.

Qué PCR se ven afectados

Los PCR (Platform Configuration Registers) son registros internos del chip TPM2 que acumulan hashes de los componentes medidos durante el arranque. Cada uno tiene un propósito definido en el Linux TPM PCR Registry:

PCR	Qué mide
0	BIOS / firmware code
1	BIOS / firmware configuration
2	Option ROM code
3	Option ROM configuration
4	MBL (Master Boot Loader) code
5	MBL configuration
6	Event de transición desde MBL al siguiente stage
7	Secure Boot state
9	Initramfs / kernel command line
12, 13, 14	Boot loader y componentes post-boot

El aviso de Arch menciona explícitamente “PCR values 0-7, 9 and 12-14”, que son los que systemd-pcrosseparator.service toca. Si enrollaste tu TPM2 con --tpm2-pcrs=0+7 o un set más amplio, todos esos valores cambiaron y tienes que re-enrollar.

Para verificar el estado actual del chip antes de tocar nada, lo más útil es leer los PCR desde el sistema vivo. El paquete tpm2-tools provee la utilidad tpm2_pcrread, aunque para LUKS el flujo más simple es dejar que systemd-cryptenroll mismo lea los valores al re-enrollar.

Cómo saber si te afecta

Hay dos grupos de usuarios a los que este aviso les pega distinto:

usas TPM2 con política pinnada (la default): incluiste un set explícito de PCR al ejecutar systemd-cryptenroll --tpm2-pcrs=.... Esta es la configuración que el aviso recomienda re-enrollar siguiendo systemd-cryptenroll(1).
usas pcrlock con política generada dinámicamente: tienes systemd-pcrlock-make-policy.service activo y la política se recalcula en cada kernel nuevo. En este caso el aviso remite a systemd-pcrlock(8) y a disabled systemd-pcrlock-make-policy.service como workflow a seguir.

Si usas solo FIDO2 o passphrase, no te afecta: el TPM2 no participa del desbloqueo y los PCR extra son inocuos.

Para chequear qué método tienes activo en tu volumen, listá los keyslots:

# systemd-cryptenroll /dev/sda2
SLOT TYPE
   0 password
   1 tpm2

Si ves tpm2 en la lista, te afecta. Si no, puedes seguir actualizando tranquilo.

Cómo re-enrollar con systemd-cryptenroll

El flujo más directo es usar systemd-cryptenroll para borrar el slot TPM2 viejo y crear uno nuevo con los PCR correctos. Antes de empezar, asegurate de tener una passphrase o recovery key válida en otro slot: si algo sale mal, necesitas una forma manual de desbloquear.

verifica el estado actual y los slots disponibles:

# cryptsetup luksDump /dev/sda2 | grep -A2 "Keyslots"
# systemd-cryptenroll /dev/sda2
SLOT TYPE
   0 password
   1 tpm2

El flag clave es --wipe-slot=tpm2, que borra los slots TPM2 existentes en el mismo comando que crea el nuevo. Esto evita inconsistencias si la operación se interrumpe a mitad de camino.

# systemd-cryptenroll /dev/sda2 
    --wipe-slot=tpm2 
    --tpm2-device=auto 
    --tpm2-pcrs=0+1+2+3+4+5+6+7+9+12+13+14

El set de PCR 0+1+2+3+4+5+6+7+9+12+13+14 replica los que Arch menciona en el aviso. Si tu enroll original usaba un set más chico (lo común es 0+7 o 7), puedes mantenerlo para minimizar la superficie: el TPM2 sigue midiendo todos los PCR, pero tu política sólo exige que coincidan los que tú listaste.

Un patrón de seguridad útil es combinar el set de PCR con un PCR lock policy más estricto. Si tu hardware soporta TPM 2.0 v1.38 o superior (casi todo lo posterior a 2019), puedes usar la opción --tpm2-pcrlock= que ata el desbloqueo a la política generada por systemd-pcrlock en lugar de a PCRs aislados. Eso evita que un cambio menor de firmware te rompa el boot.

Verificación post-enroll

Después de re-enrollar, reiniciá y comprobá que el desbloqueo automático funciona. Si vuelves a caer al shell de initramfs, recuperate con la passphrase del slot 0, montá el rootfs y revisa el journal:

# journalctl -b -u [email protected]

Ahí vas a ver el motivo del fallo: PCR no coinciden, chip no responde, etc. Si el journal muestra que systemd-cryptsetup reintentó con el slot TPM2 pero no pudo, lo más probable es que falte algún PCR en tu set o que el chip esté midiendo algo distinto a lo que esperaba el evento del hook.

Si usas pcrlock: regenerar la política

Para quienes delegan la política en systemd-pcrlock, el aviso de Arch remite a la manpage systemd-pcrlock(8) y específicamente al caso en que systemd-pcrlock-make-policy.service está deshabilitado. La razón es que pcrlock aprende el estado del TPM2 leyendo el event log combinado de firmware y userspace, predice los PCR que va a medir en el próximo arranque, y genera una política que sólo es válida para esos valores.

Si tienes pcrlock activo, el flujo es regenerar después de cada cambio de initramfs:

# systemd-pcrlock make-policy
# systemd-pcrlock show-policy

El primer comando vuelve a generar la política desde el estado actual del chip; el segundo te la muestra legible. Si la política tiene más componentes de los que esperabas, es probable que el event log esté capturando ahora las mediciones del pcrosseparator y que necesites actualizar el set de componentes definidos en /usr/lib/systemd/pcrlock.d/.

Para los servidores en producción donde no quieres sorpresas, una opción intermedia es combinar ambos mundos: política pinnada al set clásico de PCR (0+7) más pcrlock para los casos donde el firmware cambia. Eso te da lo mejor de los dos: previsibilidad y flexibilidad.

Problemas comunes y troubleshooting

El primer síntoma de que algo va mal es quedarse pegado en el initramfs. Estos son los errores más frecuentes y cómo resolverlos:

No aparece ningún slot TPM2 al listar

Si systemd-cryptenroll /dev/sda2 no muestra tpm2 en la lista, el TPM2 puede estar deshabilitado en BIOS/UEFI o el driver no estar cargando. verifica:

# ls /dev/tpm* 
/dev/tpmrm0
# dmesg | grep -i tpm

Si el dispositivo existe pero el daemon no responde, el chip puede estar en estado de propietario tomado con una contraseña vieja. tpm2_clear lo resetea, pero ojo: borra todas las claves existentes. Sólo lo usas si quieres empezar de cero.

El enroll falla con “no suitable PCR”

Esto pasa cuando ningún PCR está en estado válido al momento del enroll, usualmente porque el event log tiene inconsistencias o porque el chip está midiendo algo que no esperaba. La salida detallada con --debug ayuda a identificar qué PCR está dando problema.

El sistema no bootea después del reinicio

Si después del re-enroll el sistema no bootea automáticamente, casi siempre es porque:

El set de PCR que especificaste no incluye alguno que está siendo medido por el initramfs nuevo. Solución: ampliar el set o usar pcrlock.
Secure Boot cambió de estado entre el enroll y el boot. PCR 7 refleja Secure Boot; si lo activaste después, el PCR no va a coincidir.
El firmware actualizó entre enroll y boot (muchas laptops modernas actualizan UEFI automáticamente). Solución: usar pcrlock o relajar el set para incluir un componente que tolere múltiples versiones.

El recovery key que generaste con --recovery-key en el slot 0 te salva en cualquiera de estos casos. Por eso es siempre buena idea tener uno antes de empezar.

Cuándo NO te conviene re-enrollar todavía

Hay un caso claro en el que conviene esperar: si tu sistema está corriendo y todavía no actualizaste mkinitcpio a 42-1, el initramfs actual no incluye pcrosseparator.service, y el re-enroll lo único que va a hacer es cambiar la política de TPM2 a apuntar al estado actual del chip. Cuando llegue la actualización de mkinitcpio, los PCR van a cambiar de nuevo y vas a tener que re-enrollar otra vez.

El orden lógico es:

Actualizar mkinitcpio a 42-1.
Regenerar el initramfs con mkinitcpio -P.
Re-enrollar con systemd-cryptenroll.
Reiniciar.

Saltarse el paso 2 después de re-enrollar lleva a un sistema que bootea una vez y después se rompe: la política queda calibrada al estado actual, que ya no es lo que el próximo boot va a producir.

Vale la pena actualizar entonces?

Sí, pero con orden. La razón principal por la que esto se está haciendo es la integración con systemd-pcrlock, que es la dirección que systemd viene tomando para reemplazar políticas de PCR estáticas por algo más mantenible. Si tu sistema depende de TPM2 para desbloquear LUKS, actualizar mkinitcpio sin re-enrollar es la peor combinación: initramfs nuevo + política vieja = un servidor que no va a volver a bootear solo.

El flujo que recomiendo es exactamente el que Arch describe en el aviso, en este orden:

Asegurate de tener un recovery key o passphrase válida en otro slot antes de tocar nada.
Aplicá la actualización de mkinitcpio y regenerá el initramfs.
Re-enrollá con el mismo set de PCR que venías usando, o ampliá si quieres más superficie.
Reiniciá y verifica que el desbloqueo automático funcione.
Si usas pcrlock, regenerá la política después del re-enroll.

Si tu hardware es muy viejo y el TPM2 no soporta PolicyAuthorizeNV (TPM 2.0 v1.38+), quédate con la política pinnada clásica. No hay forma de usar pcrlock ahí, pero el flujo de re-enroll sigue siendo el mismo.

Resumen

mkinitcpio 42-1 introdujo systemd-pcrosseparator.service en el initramfs, lo que cambia las mediciones de PCR 0-7, 9 y 12-14. Si usas TPM2 para desbloquear LUKS, tienes que re-enrollar después de aplicar la actualización, siguiendo la manpage de systemd-cryptenroll si usas política pinnada, o systemd-pcrlock(8) si delegás en pcrlock. Si usas sólo passphrase o FIDO2, este cambio no te afecta. Antes de tocar nada, asegurate de tener un recovery key o passphrase en otro slot: un re-enroll que sale mal con un único método de autenticación te deja afuera del sistema.

Preguntas frecuentes

¿Por qué Re-enroll TPM2 tras actualizar mkinitcpio systemd hook: Guía para sysadmins es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Re-enroll TPM2 tras actualizar mkinitcpio?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Re-enroll TPM2 tras actualizar mkinitcpio?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Re-enroll TPM2 tras actualizar mkinitcpio y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Re-enroll TPM2 tras actualizar mkinitcpio?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.