3️⃣1️⃣ Here's the 31st post highlighting key new features of the recently published v262 release of systemd. #systemd262 #systemd

For a long time systemd has known a concept of "first boot" conditioning: units and certain code paths are only run on the first boot of a system, but not the others. The first boot is determined by looking at /etc/machine-id: if that file has a fully populated UUID at boot, then it's not a first boot, otherwise it is.

Various components hook into this concept:

For example there's "systemd-homed-firstboot.service", which queries the user interactively to create a user account on first boot. But the most prominent usecase is "systemd-firstboot.service" which queries the user for a hostname, locale or keymap settings on first boot, but not on regular boots. And there are a couple more things like this.

If you read the above closely, you'll notice that the two examples are about interactivity, i.e. making changes to the system by expecting a human user…

@pid_eins Oh this is sounds highly valuable for Image based distributions like raspberry Pi OS which currently use self-deleting services to mimic this behavior.

…in front of the screen, to make explicit choices interactively.

That's great for many usecases, but for an unattended server it's a poor choice. Now, since a long time we had "systemd.firstboot=0" on the kernel cmdline to disable the logic, and thus ensure that no question is ever asked interactively. Great. Except that it turns off the *whole* logic, not just the interactivity of it.

With systemd v262 this changes. There's now "systemd.firstboot=headless". If you boot with that, then…

…only the interactivity of these tools is disabled, but not the tools as a whole.

How does this effectively matter? As it turns out these tools can also be driven via systemd creddentials, passed in via IMDS, SMBIOS Type #11, the ESP or similar. And hence it makes sense to operate on that, without necessarily allowing interactive queries.