ISO and VM images still ship the fab bootstrap's machine-id #24
Labels
No labels
accessibility
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Keel-Linux/tracker#24
Loading…
Add table
Add a link
Reference in a new issue
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?
buildtasks#15 empties /etc/machine-id in every bt-layer layer, which covers the tar.zst that keel assemble builds. bt-container, bt-iso and bt-vm build from the ISO and do not pass through bt-layer, so an ISO install or a VM image still carries the bootstrap's id (f0e97605...) unless the installer regenerates it. Check tkl-installer and apply the same reset (empty file, /var/lib/dbus/machine-id symlink) where Keel ships those images. Also from the review: reword the comment at bin/layer-lib:583 (a first boot only enables units), add a test for the child-layer case in tests/layer, and decide whether an empty 0644 file should be reset to 0444.
Fixed by Keel-Linux/buildtasks#16: ISO and ISO-derived outputs reset /etc/machine-id (empty, 0444, D-Bus link) before the squashfs is built, with a check on the built ISO. A real install from the ISO is still to be tested.