josch/mmdebstrap
2
3
Fork 6
Code Issues 7 Pull requests Projects Releases Wiki Activity

ConditionFirstBoot is never triggered #10

New issue
Closed
opened 2021-08-16 18:35:13 +00:00 by indebtedness_maple · 4 comments
indebtedness_maple commented 2021-08-16 18:35:13 +00:00
Copy link

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`.
josch commented 2021-08-16 18:44:04 +00:00
Owner
Copy link

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

Ui, nice catch! Thank you for bringing this up! I'll fix this with the next release.
indebtedness_maple commented 2021-08-16 18:59:33 +00:00
Author
Copy link

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).
josch commented 2021-08-16 19:00:35 +00:00
Owner
Copy link

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
indebtedness_maple commented 2021-10-18 15:52:41 +00:00
Author
Copy link

Looks like this is resolved by 3c37d692a0. Thanks!

Looks like this is resolved by 3c37d692a0d0bbc829b0832ad20ff472c74a7a62. Thanks!
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
develop
1.5.7
1.5.6
1.5.5
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.3
1.4.2
1.4.1
1.4.0
1.3.8
1.3.7
1.3.6
1.3.5
1.3.4
1.3.3
1.3.2
1.3.1
1.3.0
1.2.5
1.2.4
1.2.3
1.2.2
1.2.1
1.2.0
1.1.0
1.0.1
1.0.0
0.8.6
0.8.5
0.8.4
0.8.3
0.8.2
0.8.1
0.8.0
0.7.5
0.7.4
0.7.3
0.7.2
0.7.1
0.7.0
0.6.1
0.6.0
0.5.1
0.5.0
0.4.1
0.4.0
0.3.0
0.2.0
0.1.0
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: josch/mmdebstrap#10
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?