Run #4283's enriched diagnostic gave us a precise, low-level reading
of what's still drifting:
Hex around first ISO divergence:
flag=0x0e → CREATION + MODIFICATION + ACCESS (Rock Ridge TF, short form)
CREATION: `7e 05 08 00 06 2d 00` (=SOURCE_DATE_EPOCH, both A and B ✅)
MODIFICATION:
A=`7e 05 08 00 18 10 00` → 2026-05-08 00:24:16
B=`7e 05 08 00 28 14 00` → 2026-05-08 00:40:20
ACCESS:
A=`7e 05 08 00 18 0f 00` → 2026-05-08 00:24:15
B=`7e 05 08 00 28 13 00` → 2026-05-08 00:40:19
The MODIFICATION/ACCESS times match the wall-clock minute when each
build's xorriso -commit fired. So:
* iter35's `touch -d "@${SDE}" "${new_sqfs}"` did nothing for
mtime — xorriso doesn't propagate the source file's mtime
through -update.
* iter34's `-alter_date_r all "=N" /` updated creation (btime →
Rock Ridge TF CREATION) but not mtime/atime — possibly because
-update runs at -commit time and re-stamps the node's a/m
timestamps with the actual write time, after `-alter_date_r`'s
in-memory update.
Fix: add an explicit, narrowly-scoped `-alter_date all "=N"
/live/filesystem.squashfs --` AFTER `-update` and BEFORE the global
`-alter_date_r`. Per-file alter_date appears to be the last word
xorriso processes against that specific node.
Keep -alter_date_r all and the full -volume_date c/m/x/f/u/s as
belt-and-suspenders.
If this clears, M1.1 reproducibility gate passes. If not, we'll know
xorriso's `-update` is genuinely stamping at commit time independent
of any in-memory date setting, and the move is to skip -update and
do an mkisofs-style full rewrite from the chroot directly.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
SysAdmin
60384e70c8