Error en el TPM
oct 19, 2026 21:00 • 218 visitas
Me lancé a la aventura de instalar un sistema operativo estable, que estuviera bien actualizado y que diera pie al bricolaje. Elegí Arch Linux, pero me llevé una desagradable sorpresa al iniciarlo, pues durante el arranque, el sistema mostró un error: "Failed to start TPM MvPCR Product ID Measurement". Para quien todavía no lo sepa, el Trusted Platform Module (TPM) es una especie de "caja fuerte" donde se almacenan huellas digitales de lo que ocurre en el ordenador. Esa caja fuerte puede estar implementada como chip físico o como parte del firmware.
Dentro del TPM tenemos el Platform Configuration Register (PCR) y su versión no volátil, el NvPCR, donde se almacena una huella de algo que se midió, generalmente parte del arranque. Al iniciar la sesión, los PCRs usados para el arranque vuelven a empezar con las mediciones de esa sesión, casi siempre con la operación extend:
nuevovalor = hash(previovalor + nuevovalor)
Para empezar a investigar el problema, tenemos que consultar el estado del servicio systemd-pcrproduct.service y sus logs emitidos:
[user@localhost ~]$ systemctl status systemd-pcrproduct.service --no-pager
journalctl -b -u systemd-pcrproduct.service --no-pager
ls -l /dev/tpm*
× systemd-pcrproduct.service - TPM NvPCR Product ID Measurement
Loaded: loaded (/usr/lib/systemd/system/systemd-pcrproduct.service; static)
Active: failed (Result: exit-code) since Mon 2026-10-19 09:18:27 CEST; 25min ago
Invocation: d39c13610eed5e42bb5a3fd3dd50c97a
Docs: man:systemd-pcrproduct.service(8)
Process: 477 ExecStart=/usr/lib/systemd/systemd-pcrextend --graceful --product-id (code=exited, status=1/FAILURE)
Main PID: 477 (code=exited, status=1/FAILURE)
Mem peak: 2.2M
CPU: 13ms
localhost systemd[1]: Starting TPM NvPCR Product ID Measurement...
localhost systemd-pcrextend[477]: Could not extend NvPCR: No such file or directory
localhost systemd[1]: systemd-pcrproduct.service: Main process exited, code=exited, status=1/FAILURE
localhost systemd[1]: systemd-pcrproduct.service: Failed with result 'exit-code'.
localhost systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
localhost systemd[1]: Starting TPM NvPCR Product ID Measurement...
localhost systemd-pcrextend[321]: Could not extend NvPCR: No such file or directory
localhost systemd[1]: systemd-pcrproduct.service: Main process exited, code=exited, status=1/FAILURE
localhost systemd[1]: systemd-pcrproduct.service: Failed with result 'exit-code'.
localhost systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
localhost systemd[1]: Starting TPM NvPCR Product ID Measurement...
localhost systemd-pcrextend[477]: Could not extend NvPCR: No such file or directory
localhost systemd[1]: systemd-pcrproduct.service: Main process exited, code=exited, status=1/FAILURE
localhost systemd[1]: systemd-pcrproduct.service: Failed with result 'exit-code'.
localhost systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
crw-rw---- 1 tss root 10, 224 oct 19 09:18 /dev/tpm0
crw-rw---- 1 root tss 252, 65536 oct 19 09:18 /dev/tpmrm0
Revisando la información del cargador de arranque con sudo bootctl status, queda descartado cualquier problema relacionado con el arranque systemd-boot o la configuración de las imágenes UKI. El problema -como queda de manifiesto- es que systemd-pcrextend no encuentra el recurso o índice NvPCR que necesita para registrar el ID del producto. Este mensaje no significa que el TPM esté ausente, sino que no puede completar la medición del NvPCR:
Could not extend NvPCR: No such file or directory
Más adelante, los registros también muestran fallos relacionados con las mediciones NvPCR de usuarios y con la inicialización de índices NvPCR. El SRK -la clave raíz del almacenamiento TPM- ya está guardado, lo que falla es la inicialización de los NvPCRs, así que ya podemos empezar. Instalamos los paquetes que permiten consultar el TPM y generar imágenes UKI con utilidades de systemd:
sudo pacman -S tpm2-tools systemd-ukify
Creamos el archivo /etc/kernel/uki.conf con esta configuración:
[UKI]
SignInitrdPCRs=yes
[PCRSignature:initrd]
PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key-initrd.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-public-key-initrd.pem
Después, generamos el par de claves y reconstruimos las imágenes del kernel, con cuidado de mantener protegida la clave privada y no compartirla públicamente:
sudo ukify genkey --config=/etc/kernel/uki.conf
sudo mkinitcpio -P
Finalmente, actualizamos el sistema y reiniciamos la máquina:
sudo pacman -Syu
sudo reboot
Tras el reinicio, volvemos a consultar el estado del servicio y la lista de unidades fallidas:
systemctl status systemd-pcrproduct.service --no-pager
systemctl list-units --state=failed
sudo bootctl status
Esta vez, systemd-pcrproduct.service termina correctamente:
Active: active (exited)
...
status=0/SUCCESS
El registro muestra el mensaje:
NvPCR 'hardware' is not initialized, skipping gracefully.
Además, systemctl list-units --state=failed devuelve:
0 loaded units listed.
bootctl status indica que el TPM está disponible y está midiendo el UKI y el sistema operativo. Secure Boot sigue desactivado, pues la configuración de firma PCR del initrd no lo habilita automáticamente. El error de arranque queda resuelto en el sentido más práctico: el servicio funciona y systemd no muestra unidades fallidas. Sin embargo, NvPCR sigue sin inicializarse. La diferencia es que systemd ahora lo omite de forma controlada, en lugar de terminar con un error. Las claves UKI no crearon ni activaron el NvPCR. Configurar y firmar las mediciones PCR del initrd es una cosa, e inicializar el NvPCR es otra. La salida final confirma el comportamiento correcto del servicio, no que el NvPCR se haya provisionado.
Si ve el error "Failed to start TPM NvPCR Product ID Measurement" al arrancar su máquina, compruebe primero el servicio y las unidades fallidas. En mi equipo, después de configurar la firma PCR del initrd, regenerar el UKI, actualizar Arch y reiniciar, el servicio pasa a terminar con éxito y systemd deja de marcar unidades como fallidas. El NvPCR no queda inicializado, pero su ausencia no interrumpe el arranque, ni produce fallos en el servicio.
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme: