iso, rootfs-cleanup: ship the ISO and its images with an empty machine-id #16

Merged

marcos-mendez merged 2 commits from fix/iso-vm-machine-id into 19.x

2026-10-01 16:47:31 -03:00

marcos-mendez commented

2026-10-01 16:31:08 -03:00

(Migrated from github.com)

Closes Keel-Linux/tracker#24 for buildtasks: the ISO, and every image made from the ISO's rootfs, now ship an empty /etc/machine-id, as the layers have since #15.

Why

fab squashes root.patched into /live/10root.squashfs. That tree still had the bootstrap's id, f0e97605....
tkl-installer unpacks that squashfs onto the disk unchanged. It has no machine-id step: tkl_installer/installer.py runs unsquashfs -f -d target and then grub, nothing else. So every machine installed from one ISO shared the id, and with it the DHCP DUID and IAID and MariaDB's server_id.
bt-vm, bt-container, bt-xen, bt-openstack, bt-ec2, bt-otc and bt-docker extract that rootfs and then run apt and patches in a chroot. There, systemd's postinst can write a new id of its own.

What changes

bin/reset-machine-id ROOTFS runs layer_reset_machine_id, the same reset bt-layer does.
bt-iso builds build/stamps/root.patched first, resets it, then runs make for the rest. fab's stamps reuse root.patched, so it is not rebuilt.
bin/iso-machine-id-check ISO reads the squashfs out of the ISO with xorriso and checks the two files with layer_machine_id_is_reset. bt-iso runs it before screenshots and release, -u included.
bin/rootfs-cleanup resets the id as its last step. Every ISO-derived bt-* calls it after its chroot work.
layer-lib's first-boot comment is corrected, as the #15 review asked: on systemd 257 without first-boot-full-preset, preset-all only enables units.

Tests

tests/machine-id is a new suite under kcov in tests/coverage.sh, and CI installs squashfs-tools xorriso for it.
It covers the predicate, both scripts and rootfs-cleanup with a chroot stub that writes an id.
It runs bt-iso end to end against a fake product whose root.patched carries the 2026-09-30 id:
- the released ISO has an empty id;
- -u with an old ISO is refused before iso-release;
- a failed root.patched stops the build.
Reverting the bt-iso or the rootfs-cleanup change each turns the suite red.
Coverage is 100 percent for the three scripts. layer-lib is 390 of 391, the same one line uncovered as on 19.x.

Real build

bt-iso -s -n core ran on the build host from this branch (f2a79a3), in an isolated tree (/var/tmp/keel-testbuild/i2, copies of fab-keel, no key, nothing published). It took 13 minutes, including the wait for the build lock, and made a 444,596,224 byte ISO (sha512 42e1faf1...f21745). The check ran:

INFO [iso-machine-id-check]: build/product.iso: empty /etc/machine-id, each machine makes its own

Inside the ISO's /live/10root.squashfs:

-r--r--r-- root/root   0 2026-10-01 19:43 squashfs-root/etc/machine-id
lrwxrwxrwx root/root  15 2026-10-01 19:43 squashfs-root/var/lib/dbus/machine-id -> /etc/machine-id

An earlier run with longer paths (i1) failed at fab's root.sandbox overlay mount, after the reset and the squashfs had already worked. That is the overlay path-length limit known on that host, not this change.

Not in this PR

bt-vm still cannot build trixie:
- VM_GUESTOS stops at bullseye;
- vm-bundle reads a 4.19 kernel version;
- it needs the proprietary ovftool.
The fab ISO path does not run layer_audit_keys.

Both are steps of the plan in handbook decision 0043 (proposed).

Closes Keel-Linux/tracker#24 for buildtasks: the ISO, and every image made from the ISO's rootfs, now ship an empty `/etc/machine-id`, as the layers have since #15. ## Why - fab squashes `root.patched` into `/live/10root.squashfs`. That tree still had the bootstrap's id, `f0e97605...`. - `tkl-installer` unpacks that squashfs onto the disk unchanged. It has no machine-id step: `tkl_installer/installer.py` runs `unsquashfs -f -d target` and then grub, nothing else. So every machine installed from one ISO shared the id, and with it the DHCP DUID and IAID and MariaDB's `server_id`. - `bt-vm`, `bt-container`, `bt-xen`, `bt-openstack`, `bt-ec2`, `bt-otc` and `bt-docker` extract that rootfs and then run apt and patches in a chroot. There, systemd's postinst can write a new id of its own. ## What changes - `bin/reset-machine-id ROOTFS` runs `layer_reset_machine_id`, the same reset `bt-layer` does. - `bt-iso` builds `build/stamps/root.patched` first, resets it, then runs `make` for the rest. fab's stamps reuse `root.patched`, so it is not rebuilt. - `bin/iso-machine-id-check ISO` reads the squashfs out of the ISO with xorriso and checks the two files with `layer_machine_id_is_reset`. `bt-iso` runs it before screenshots and release, `-u` included. - `bin/rootfs-cleanup` resets the id as its last step. Every ISO-derived `bt-*` calls it after its chroot work. - `layer-lib`'s first-boot comment is corrected, as the #15 review asked: on systemd 257 without `first-boot-full-preset`, preset-all only enables units. ## Tests - `tests/machine-id` is a new suite under kcov in `tests/coverage.sh`, and CI installs `squashfs-tools xorriso` for it. - It covers the predicate, both scripts and `rootfs-cleanup` with a chroot stub that writes an id. - It runs `bt-iso` end to end against a fake product whose `root.patched` carries the 2026-09-30 id: - the released ISO has an empty id; - `-u` with an old ISO is refused before `iso-release`; - a failed `root.patched` stops the build. - Reverting the `bt-iso` or the `rootfs-cleanup` change each turns the suite red. - Coverage is 100 percent for the three scripts. `layer-lib` is 390 of 391, the same one line uncovered as on 19.x. ## Real build `bt-iso -s -n core` ran on the build host from this branch (f2a79a3), in an isolated tree (`/var/tmp/keel-testbuild/i2`, copies of fab-keel, no key, nothing published). It took 13 minutes, including the wait for the build lock, and made a 444,596,224 byte ISO (sha512 `42e1faf1...f21745`). The check ran: ``` INFO [iso-machine-id-check]: build/product.iso: empty /etc/machine-id, each machine makes its own ``` Inside the ISO's `/live/10root.squashfs`: ``` -r--r--r-- root/root 0 2026-10-01 19:43 squashfs-root/etc/machine-id lrwxrwxrwx root/root 15 2026-10-01 19:43 squashfs-root/var/lib/dbus/machine-id -> /etc/machine-id ``` An earlier run with longer paths (`i1`) failed at fab's `root.sandbox` overlay mount, after the reset and the squashfs had already worked. That is the overlay path-length limit known on that host, not this change. ## Not in this PR - `bt-vm` still cannot build trixie: - `VM_GUESTOS` stops at bullseye; - `vm-bundle` reads a 4.19 kernel version; - it needs the proprietary `ovftool`. - The fab ISO path does not run `layer_audit_keys`. Both are steps of the plan in handbook decision 0043 (proposed).