Run #4281 cleared every layer above the ISO9660 wrapper: SHA256 (squashfs payload) caed117ca72c6c1d9204c49dd749d5f7b372f3a19cac1b2a7e66bee452a8d501 /tmp/.../a.squashfs caed117ca72c6c1d9204c49dd749d5f7b372f3a19cac1b2a7e66bee452a8d501 /tmp/.../b.squashfs …squashfs is now byte-identical, ISO TOC is identical, file listing diff is empty, but ISO SHA still differs. The remaining drift is in the ISO9660 metadata region between the system area (first 32 KiB) and the file payload start. Two complementary changes: 1. xorriso post-process now sets *every* date field xorriso writes, not just the obvious two: -alter_date_r all — atime + mtime + btime on all nodes, not just mtime. ISO9660 directory records carry creation+modification timestamps. -volume_date c m x f u s — every volume-descriptor date: c=creation m=modification x=expiration f=effective u=system area s=path table Default for any unset volume_date is "now", which is what was leaking through despite us setting c+m. 2. diagnose-divergence.sh now does whole-file cmp -l (capped at 200 lines so 1 GiB of all-different doesn't drown the report) and on any divergence, dumps a 128-byte xxd window from each ISO around the first differing byte plus a unified diff between the two windows. This tells us in the next failure log "first byte differs at offset N (LBA M), bytes around it look like X" — pinpoints the ISO9660 region without needing artifact download. Workflow tail-into-log step wired up the two new files (iso-cmp-first-200.txt, iso-around-first-diff.diff). If iter34 still fails the gate, the new diagnostic tells us exactly which structure (volume descriptor, path table, directory record, boot catalog…) is still drifting. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
12 KiB
12 KiB