In Ubuntu Server and other systemd-based Linux distributions, systemd-firstboot.service is an early-boot initialization daemon designed to interactively or automatically configure basic system settings (like hostname, timezone, locale, and machine ID) during the very first boot of an unconfigured system image. While essential for general-purpose OS installers or consumer deployments, this service introduces a significant security and automation liability in immutable infrastructure environments, heavily provisioned cloud instances, or declarative configuration setups (like Terraform/Ansible). In these environments, the system configuration is injected statically via cloud-init or pre-baked into the image. Allowing systemd-firstboot to run adds unnecessary execution time to the critical boot path and risks overwriting or conflicting with pre-injected cryptographic machine IDs or locale configurations.
This guide explains how to completely disable the systemd-firstboot service in Ubuntu Server, enforcing an absolute block on late-stage, automated initialisation and ensuring the system relies entirely on predefined static configurations.
Stop and Mask the systemd-firstboot Service
Because systemd-firstboot is deeply integrated into the sysinit.target and uses ConditionFirstBoot=yes to determine its execution, a simple systemctl disable is fundamentally insufficient (and often impossible, as it lacks an [Install] section). To guarantee the init system is physically prevented from executing this configuration daemon under any circumstances—even if the /etc/machine-id file is missing—we must explicitly mask the unit.
- Log into your Ubuntu Server via SSH using an account with
sudoprivileges. - Stop the service to clear any active configuration attempts in memory (though it generally only runs during early boot):
sudo systemctl stop systemd-firstboot.service - For absolute certainty, explicitly mask the service unit. This symlinks the unit file to
/dev/null, creating a hard cryptographic block against it being invoked dynamically during the startup sequence or triggered by missing configuration files:sudo systemctl mask systemd-firstboot.service
Verify the Service Lockdown
By masking the service, you guarantee that systemd will completely bypass local automated configuration, optimizing the boot phase for declarative infrastructure operations.
To verify the lockdown is successful, attempt to start the service manually:
sudo systemctl start systemd-firstboot.serviceSystemd will return a fatal error stating that the unit is masked (e.g., Failed to start systemd-firstboot.service: Unit systemd-firstboot.service is masked). Furthermore, running systemctl status systemd-firstboot.service will show the service state as masked, confirming the neutralization of the early-boot configuration daemon.