Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix machine-id workaround to also work on first boot #242

Merged
merged 2 commits into from
Dec 21, 2024
Merged

Conversation

talyz
Copy link
Collaborator

@talyz talyz commented Dec 15, 2024

To make this work, we have to do two things:

Run the systemd-machine-id-commit service only on first boot

systemd-machine-id-commit does its job just fine if the file contains uninitialized, even if it's bind mounted from persistent storage. It only misbehaves if the file contains an actual machine-id, since it then thinks it needs to be committed.

This can be worked around by only running the service on the first boot.

Create the machine-id file with the string uninitialized in it

Our standard handling of non-existent files is to create a symlink, but this makes systemd behave a bit strangely. It follows the symlink and creates the uninitialized machine-id at the linked location. Then it bind mounts a newly generated machine-id over the file in persistent storage. This works, but it seems to confuse systemd-machine-id-commit since the file is not actually a bind mount over /etc/machine-id, so the machine-id will not be committed on this boot cycle and will still contain uninitialized on the next boot. This makes the next boot also recognized as the “first boot”. This time, however, systemd-machine-id-commit does its job, since the file is a bind mount to persistent storage.

The workaround for this is to just skip the symlinking step and go straight to bind mounting. However, since the file needs to exist to be bind mounted, we also have to create it with the string uninitialized as its contents.

To make this work, we have to do two things:

1. Run the systemd-machine-id-commit service only on first boot

   systemd-machine-id-commit does its job just fine if the file
   contains “uninitialized”, even if it's bind mounted from persistent
   storage. It only misbehaves if the file contains an actual
   machine-id, since it then thinks it needs to be committed.

   This can be worked around by only running the service on the first
   boot.

2. Create the machine-id file with the string “uninitialized” in it

   Our standard handling of non-existent files is to create a symlink,
   but this makes systemd behave a bit strangely. It follows the
   symlink and creates the “uninitialized” machine-id at the linked
   location. Then it bind mounts a newly generated machine-id over the
   file in persistent storage. This works, but it seems to confuse
   systemd-machine-id-commit since the file is not actually a bind
   mount over /etc/machine-id, so the machine-id will not be committed
   on this boot cycle and will still contain “uninitialized” on the
   next boot. This makes the next boot also recognized as the “first
   boot”. This time, however, systemd-machine-id-commit does its job,
   since the file is a bind mount to persistent storage.

   The workaround for this, is to just skip the symlinking step and go
   straight to bind mounting. However, since the file needs to exist
   to be bind mounted, we also have to create it with the string
   “uninitialized” as its contents.
@talyz talyz merged commit c26c95f into master Dec 21, 2024
8 checks passed
@talyz talyz deleted the machine-id-fix branch December 21, 2024 08:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant