ConditionFirstBoot is never triggered #10

Systemd units which have ConditionFirstBoot in their unit file will never run, even on the first boot. This is because systemd determines that it is the first boot if and only if /etc/machine-id does not exist, or /etc/machine-id contains the value uninitialized. However, mmdebstrap simply replaces /etc/machine-id with an empty file. Instead, mmdebstrap should replace the contents of /etc/machine-id with uninitialized. This will preserve the ability to bind-mount over /etc/machine-id while still triggering ConditionFirstBoot.

Systemd units which have `ConditionFirstBoot` in their unit file will never run, even on the first boot. This is because systemd [determines that it is the first boot if and only if `/etc/machine-id` does not exist, or `/etc/machine-id` contains the value `uninitialized`](https://github.com/systemd/systemd/blob/d178203d8e2dae9bba48790a93031f2e776a2f83/src/core/main.c#L2071). However, `mmdebstrap` simply [replaces `/etc/machine-id` with an empty file](https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/bef4c890d8fcc10d4ac5e709e7bd31746fbcd9e3). Instead, `mmdebstrap` should replace the contents of `/etc/machine-id` with `uninitialized`. This will preserve the ability to bind-mount over `/etc/machine-id` while still triggering `ConditionFirstBoot`.

Ui, nice catch! Thank you for bringing this up! I'll fix this with the next release.

Note that upon further investigation, it appears that this behavior was introduced in v247. I don't know if there is a way to fix this for systems using older versions of systemd (e.g. Buster). If /etc/machine-id is missing and the system comes up with a read-only root, systemd complains:

[    8.377310] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only.
[    8.386624] systemd[1]: Booting up is supported only when:
[    8.392280] systemd[1]: 1) /etc/machine-id exists and is populated.
[    8.398619] systemd[1]: 2) /etc/machine-id exists and is empty.
[    8.404680] systemd[1]: 3) /etc/machine-id is missing and /etc is writable.

Although, despite the first message, the system boots anyway (but /etc/machine-id is not populated). I think the fix proposed in my initial report is still OK, since the behavior for pre-v247-systems is the same as with an empty file (ConditionFirstBoot is never triggered, but the machine-id gets generated correctly).

Note that upon further investigation, it appears that this behavior [was introduced in v247](https://github.com/systemd/systemd/pull/16939). I don't know if there is a way to fix this for systems using older versions of systemd (e.g. Buster). If `/etc/machine-id` is missing and the system comes up with a read-only root, systemd complains: ``` [ 8.377310] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only. [ 8.386624] systemd[1]: Booting up is supported only when: [ 8.392280] systemd[1]: 1) /etc/machine-id exists and is populated. [ 8.398619] systemd[1]: 2) /etc/machine-id exists and is empty. [ 8.404680] systemd[1]: 3) /etc/machine-id is missing and /etc is writable. ``` Although, despite the first message, the system boots anyway (but `/etc/machine-id` is not populated). I think the fix proposed in my initial report is still OK, since the behavior for pre-v247-systems is the same as with an empty file (`ConditionFirstBoot` is never triggered, but the `machine-id` gets generated correctly).

Funnily, the man page referenced from the commit you cite, also explains the uninialized value. I should've RTFM. :D

Funnily, the man page referenced from the commit you cite, also explains the `uninialized` value. I should've RTFM. :D

Looks like this is resolved by 3c37d692a0. Thanks!

Looks like this is resolved by 3c37d692a0d0bbc829b0832ad20ff472c74a7a62. Thanks!

Labels Milestones

ConditionFirstBoot is never triggered #10