fix(linux/build): explicit -alter_date all on updated squashfs node (M1.1 iter36)
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 33m27s

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>
This commit is contained in:
2026-05-08 01:44:58 +01:00
parent 1b1a1eabed
commit 60384e70c8

View File

@@ -260,12 +260,27 @@ post_process_for_reproducibility() {
# `--` terminates the variable-length path list of -alter_date_r;
# without it the following -volume_date is consumed as a path and
# xorriso bails with "Cannot find path '/-volume_date'" (run #4279).
# Run #4283's diagnostic decoded the residual divergence as the
# Rock Ridge TF (Timestamps) entry on the just-replaced
# /live/filesystem.squashfs node. The byte pattern was:
# flags=0x0e → CREATION + MODIFICATION + ACCESS (short form)
# CREATION: `7e 05 08 00 06 2d 00` (=SOURCE_DATE_EPOCH ✅)
# MODIFICATION: A=`7e 05 08 00 18 10 00` B=`7e 05 08 00 28 14 00`
# ACCESS: A=`7e 05 08 00 18 0f 00` B=`7e 05 08 00 28 13 00`
# MODIFICATION/ACCESS each leaked the wall-clock time of -commit.
# So `-alter_date_r all` only fixed b (creation) on the updated
# node, and -update overwrote a and m at -commit.
#
# Add an explicit `-alter_date all` for /live/filesystem.squashfs
# AFTER -update — this way the override is the very last thing
# applied to that node before -commit.
sudo --non-interactive xorriso \
-return_with SORRY 0 \
-indev "${iso_file}" \
-outdev "${new_iso}" \
-boot_image any keep \
-update "${new_sqfs}" /live/filesystem.squashfs \
-alter_date all "=${SOURCE_DATE_EPOCH}" /live/filesystem.squashfs -- \
-alter_date_r all "=${SOURCE_DATE_EPOCH}" / -- \
-volume_date c "=${SOURCE_DATE_EPOCH}" \
-volume_date m "=${SOURCE_DATE_EPOCH}" \