Run #4282's enriched diagnostic pinpointed the exact remaining drift:
diagnose: first ISO byte difference at offset 205152 (LBA 100)
205153 7 10
205154 27 0
205155 57 3
205156 52 55
Decoded as decimal, those are the day/hour/minute/second fields of an
ISO9660 7-byte directory record date:
A: dd=7 hh=23 mm=47 ss=42 (May 7 23:47:42 UTC)
B: dd=8 hh=0 mm=3 ss=45 (May 8 00:03:45 UTC)
Match the wall-clock mtime of /live/filesystem.squashfs that the TOC
diff also still showed:
-/live/filesystem.squashfs ... May 7 23:47
+/live/filesystem.squashfs ... May 8 00:03
Why iter34's `-alter_date_r all "=N" /` didn't catch it: xorriso
applies `-alter_date_r` to the in-memory ISO node table, but `-update
<src> <iso_path>` writes the directory record's mtime at `-commit`
time using the SOURCE FILE's mtime — overriding whatever was in the
node table. So the relevant mtime is on `/tmp/silvermetal-rebuilt-
XXXXXX.squashfs` (the freshly-`mksquashfs`d file), and that has
wall-clock mtime.
Fix: touch the source file to SOURCE_DATE_EPOCH right before xorriso
reads it.
sudo touch -d "@${SOURCE_DATE_EPOCH}" "${new_sqfs}"
Bonus: diagnose-divergence.sh now falls back to `od -t x1z` when xxd
isn't available — silvermetal-builder ships coreutils but not
vim-common, so the iter34 xxd window was silently empty. The new
od-based dump is what landed the actual byte values in run #4282.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
SysAdmin
1b1a1eabed