fix(images): force null UUID into machine-id before dracut#47
Open
passcod wants to merge 1 commit into
Open
Conversation
The 10systemd dracut module copies /etc/machine-id verbatim into the initramfs. Truncating to zero bytes earlier in configure.sh is not enough — something between that truncate and the dracut invocation repopulates the file, baking a fixed UUID into the initramfs that then propagates to every flashed install via systemd-machine-id-commit at switch-root (observed in the field: two Pis from one image with identical /etc/machine-id, matching the value bundled in /boot/firmware/current/initrd.img). Write systemd's all-zeros "uninitialized" marker right before dracut runs so whatever value leaked back in is overwritten with one systemd will regenerate per install on first boot. The post-chroot truncate in build.sh keeps the rootfs copy at zero bytes per the spec. Adds a test that the initramfs's /etc/machine-id is uninitialized (empty or all zeros) so this can't regress silently.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two pis flashed from the same image ended up with the same
/etc/machine-id. Tracing it back:/boot/firmware/current/initrd.imgcontained a 33-byte/etc/machine-idmatching the rootfs value bit-for-bit.inst_multiple ... /etc/machine-idwith a 0-byte fallback only when the file is missing) copies the host's
/etc/machine-idverbatim — it does not regenerate./etc/machine-idwas non-empty in the chroot at the momentdracut --forceran, despite the explicit truncate earlier inconfigure.sh. Something between the two is repopulating it. Atswitch-root,
systemd-machine-id-commitpropagates the baked value tothe empty rootfs copy, so every flashed install inherits the same ID.
I haven't pinned down which step does the repopulation (the window is
narrow — hostname writes, KVER detection, then dracut — and none of
those should touch the file), but the fix doesn't depend on knowing: we
just write systemd's all-zeros "uninitialized" marker into
/etc/machine-idimmediately beforedracut --force. Whatever valueleaked back in gets overwritten with one systemd recognises as
uninitialized and regenerates per-install on first boot. The
post-chroot truncate in
build.shkeeps the rootfs copy at zero bytesper spec.
Adds a structure-test check that the initramfs's
/etc/machine-idisuninitialized (empty or all zeros) so this can't regress silently. Spec
extended at
r[image.base.machine-id]to document the initramfs sideof the contract.
Recovery for already-flashed pis
— but only after deleting
/etc/machine-idfirst, since the commitpath won't overwrite a populated file:
sudo rm /etc/machine-id sudo systemd-machine-id-setup sudo systemctl restart systemd-journald # picks up the new ID