From 84179b3642507802d68b7e4aa6f075736f654945 Mon Sep 17 00:00:00 2001
From: SysAdmin <sysadmin@silverlabs.uk>
Date: Thu, 7 May 2026 22:09:55 +0100
Subject: [PATCH] fix(linux/build): xorriso -return_with SORRY 0 to tolerate
 MBR size warning (M1.1 iter30)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

iter29 wired up the chroot scrub + squashfs rebuild + ISO patch.
Run #4277 confirmed every actual operation succeeded:

    Updating '/tmp/silvermetal-rebuilt-MFqm7S.squashfs' to '/live/filesystem.squashfs'
    xorriso : UPDATE : Added/overwrote '/live/filesystem.squashfs'  (899m)
    Differences detected and updated. (runtime 0.5 s)
    xorriso : NOTE : Keeping boot image unchanged
    ISO image produced: 506049 sectors
    Writing to '...silvermetal-clean.iso' completed successfully.

…then xorriso re-assessed the freshly-written ISO and raised:

    libburn : SORRY : Read start address 525977s larger than
      number of readable blocks 506240
    libisofs: NOTE : Found Protective MBR with size range larger
      than the medium capacity
    xorriso : NOTE : Tolerated problem event of severity 'SORRY'
    xorriso : NOTE : -return_with SORRY 32 triggered by problem
      severity SORRY

That's the protective MBR header recording the *original* ISO size
(525977 sectors) but our replaced squashfs is smaller, so the new ISO
totals 506240 sectors. The protective MBR is purely a compatibility
shim for tools that don't understand GPT — bootloaders consult the
GPT and El Torito tables, both of which are self-consistent in the
new ISO. The diagnostic is genuinely benign.

xorriso's default `-return_with SORRY 32` made it exit 32, which `set
-e` in build-inner.sh propagated up, killing the build. Add
`-return_with SORRY 0` to the post-process xorriso invocation: keep
the warning visible in the log but accept a SORRY as exit-zero given
the operation reported `completed successfully` for the write itself.

Note: this scoping is *only* on the post-process xorriso. Anywhere
else upstream in derivative-maker can still use xorriso's default
strictness.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---
 linux/build/scripts/build-inner.sh | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/linux/build/scripts/build-inner.sh b/linux/build/scripts/build-inner.sh
index 820f244..10763fc 100755
--- a/linux/build/scripts/build-inner.sh
+++ b/linux/build/scripts/build-inner.sh
@@ -185,10 +185,24 @@ post_process_for_reproducibility() {
     # rewrites just the named file then re-emits the ISO; -boot_image
     # any keep preserves the existing El Torito + GPT/UEFI bits so the
     # image stays bootable.
+    #
+    # -return_with SORRY 0: by default xorriso exits 32 when it raises
+    # a SORRY-severity diagnostic, even when the write itself succeeded.
+    # The post-write re-assessment of the new ISO produces one
+    # unavoidably:
+    #   libburn : SORRY : Read start address 525977s larger than
+    #     number of readable blocks 506240
+    # …because we just shrunk the ISO (smaller squashfs) and the
+    # protective MBR header still records the *original* size. The
+    # GPT and El Torito records inside are correct and self-consistent;
+    # the protective MBR is vestigial and bootloaders don't consult its
+    # size field. Demoting SORRY -> exit 0 lets xorriso warn but still
+    # report success on the actually-completed write.
     local new_iso="${iso_file%.iso}.silvermetal-clean.iso"
     sudo --non-interactive rm -f "${new_iso}"
     echo "post-process: replacing /live/filesystem.squashfs in ISO"
     sudo --non-interactive xorriso \
+        -return_with SORRY 0 \
         -indev   "${iso_file}" \
         -outdev  "${new_iso}" \
         -boot_image any keep \