SysAdmin 1b1a1eabed fix(linux/build): touch squashfs to SOURCE_DATE_EPOCH before xorriso (M1.1 iter35) ...

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>

2026-05-08 01:06:45 +01:00

16 KiB

Executable File

Raw Blame History

View Raw