Files
SilverMetal/linux/build/scripts
SysAdmin 6bafa85231
Some checks failed
Build SilverMetal Linux ISO (reproducibility-gated) / builder-image (push) Successful in 1s
Build SilverMetal Linux ISO (reproducibility-gated) / build-and-verify (push) Failing after 17m27s
fix(linux/build): byte-patch Rock Ridge TF dates after xorriso (M1.1 iter37)
Run #4284's diagnostic (iter36) confirmed xorriso ignores every
date-setting command we throw at it for the node it just -updated:

    flag=0x0e  →  CREATION + MODIFICATION + ACCESS (short form)
    CREATION   (set from source file btime via touch -d):
        7e 05 08 00 2c 3a 00     (= SOURCE_DATE_EPOCH)
    MODIFICATION   (still wall-clock):
        A=7e 05 08 01 02 2c 00   B=7e 05 08 01 12 33 00
    ACCESS   (still wall-clock):
        A=7e 05 08 01 02 2c 00   B=7e 05 08 01 12 32 00

Tested across iters 34-36:
  * `-alter_date_r all "=N" /`           — only fixed CREATION (b)
  * `-alter_date all "=N" path` after -update — same
  * `-volume_date c m x f u s "=N"`      — volume-level only
  * `touch -d "@N" "${new_sqfs}"` before — fixed CREATION via btime
  * various orderings, with/without `--` terminators
None override xorriso's wall-clock stamping of MOD/ACCESS at -commit.

Concede that fight and just patch the bytes after xorriso writes the
ISO. We KNOW exactly what's wrong — the TF entry for
/live/filesystem.squashfs has its CREATION slot correct (= 7-byte
ISO9660 short-form encoding of SOURCE_DATE_EPOCH) but MODIFICATION
and ACCESS still hold the post-process commit time. So copy the 7
CREATION bytes over the 7 MODIFICATION bytes and 7 ACCESS bytes.

The patcher (embedded Python, since silvermetal-builder ships
python3):
  * Finds every TF entry header (`54 46 1a 01 0e`) near the
    "filesystem.squashfs" NM tag (96-byte window — anchors both
    ends so we don't touch some other file's TF entry).
  * Copies CREATION (offset +5..+12) onto MODIFICATION (+12..+19)
    and ACCESS (+19..+26).
  * Skips entries already correct (so re-running is a no-op).
  * Reports how many entries were patched.

This is surgical: only the entry we know is broken, and only when
its MOD/ACCESS actually differ from the (known-correct) CREATION.

If the next run still drifts, the diagnostic byte-offset will tell
us where the residual leak is (almost certainly in some volume
descriptor field we haven't covered yet — at which point we extend
the patcher).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-08 02:22:56 +01:00
..