In Ubuntu Server, systemd includes a highly specific, low-level service known as systemd-boot-system-token.service. This unit is responsible for generating and storing a cryptographic “system token” in an EFI variable. During subsequent boots, the systemd-boot bootloader uses this token to implement a randomized, secure boot seed, which helps protect against certain classes of early-boot entropy starvation and replay attacks. While cryptographically beneficial for standard deployments, it introduces a volatile EFI variable write operation during the OS lifecycle. In highly strict, immutable, or forensically sterile environments—such as embedded systems with read-only NVRAM, or ephemeral virtual machines where NVRAM writes trigger hypervisor alarms—this service must be completely disabled to prevent unauthorized hardware-level state changes.
This guide explains how to completely disable the systemd-boot-system-token service in Ubuntu Server, ensuring absolute suppression of automated EFI variable modifications.
Warning: Disabling this service prevents the OS from seeding the bootloader with a randomized token. This should only be done if you are not using systemd-boot, or if your hypervisor/hardware explicitly forbids guest NVRAM modifications.
Stop and Mask the systemd-boot-system-token Service
To guarantee that this service cannot execute and modify the EFI variables during boot or runtime, we must disable and explicitly mask the unit file.
- Log into your Ubuntu Server via SSH using an account with
sudoprivileges. - First, stop the active service immediately (though it typically runs only briefly):
sudo systemctl stop systemd-boot-system-token.service - Next, disable the service to remove it from the systemd boot schedule:
sudo systemctl disable systemd-boot-system-token.service - For absolute certainty, explicitly mask the service. This symlinks the unit file to
/dev/null, creating a hard block against it starting under any circumstances:sudo systemctl mask systemd-boot-system-token.service
Verify the Service Lockdown
By masking systemd-boot-system-token.service, you guarantee that systemd will completely ignore the unit, preventing any automated interactions with the motherboard’s NVRAM.
To verify the lockdown is successful, attempt to start the service manually:
sudo systemctl start systemd-boot-system-token.serviceSystemd will return a fatal error stating that the unit is masked (e.g., Failed to start systemd-boot-system-token.service: Unit systemd-boot-system-token.service is masked). You have successfully neutralized the boot token generator, hardening your server’s EFI pathways and ensuring compliance with read-only NVRAM policies.