iso/calamares: run grub-install + update-grub after bootloader, and fix eggs' own boot-fix from silently going stale

[cyryllo]

What's broken

The iso/ live-build Calamares sequence stops at bootloader:

- grubcfg
- bootloader
- shellprocess@post-install   # snapper only
- umount

Nothing re-runs grub-install/update-grub afterwards, and nothing repairs
the kernel files unpackfs writes. Two already-diagnosed bugs follow directly
from that gap:

• [Bug] ext4 install drops to "grub rescue>" on every boot (typing exit boots normally; needs manual grub-install + update-grub) #20 (hits ext4 and btrfs alike) — with installEFIFallback: true,
  Calamares copies shim/grubx64 into the removable EFI path but not the
  grub.cfg stub that belongs next to them. GRUB started from that path has
  no working prefix and drops to grub rescue> on first boot.
• Automatic installation with Btrfs ends in GRUB rescue (@boot/subvolume error) #12 (btrfs only) — the kernel/initrd unpackfs writes are missing the
  eof flag on their last extent (declared size isn't covered by the extent
  map). GRUB reads the extent tree and stops there ("premature end of file");
  Linux itself reads the same file fine, which is why it only shows at boot.

The fix for both already exists in this repo as
scripts/fix-eggs-calamares-boot.py and system/usr/local/bin/skillfish-fix-boot-extents
— but:

1. That fix only patches the eggs/penguins-eggs build pipeline (templates
   under /etc/penguins-eggs.d/distros/*/calamares/modules and the live
   /etc/calamares/modules on the build machine). It never touches
   iso/config/includes.chroot/etc/calamares/..., so an ISO built the
   documented way (docs/BUILD.md, iso/build.sh, plain live-build) ships
   with neither fix.
2. skillfish-fix-boot-extents lives under system/, which iso/ does not
   sync from — it was never actually shipped in a live-build ISO.
3. fix-eggs-calamares-boot.py itself isn't invoked by anything — not
   scripts/build-iso.sh, not CI. It has to be remembered and run by hand
   before every eggs produce, and a penguins-eggs package upgrade can
   silently overwrite the very templates it patches (as already happened once
   to customize-partitions.js/show.qml, per the comments in that file).

What this PR does

• Add iso/config/includes.chroot/etc/calamares/modules/shellprocess@boot_reconfigure.conf:
  after bootloader, run skillfish-fix-boot-extents, then grub-install
  twice (normal NVRAM entry + --removable), then update-grub. Content
  mirrors the already-verified RECONF_BODY in fix-eggs-calamares-boot.py.
• Ship skillfish-fix-boot-extents under iso/config/includes.chroot/usr/local/bin/
  (copied from system/, 755) so it actually exists on a live-build install.
• Wire shellprocess@boot_reconfigure into settings.conf's exec sequence,
  right after bootloader and before umount.
• scripts/build-iso.sh: run fix-eggs-calamares-boot.py before every
  eggs produce and abort the build if its own verify() fails, instead
  of relying on someone remembering to run it by hand. This closes gap deps(website): bump astro from 5.18.2 to 6.4.4 in /website in the astro group across 1 directory #3
  above for the eggs pipeline without touching the pipeline's logic itself.

How I tested this

I have not built or booted an ISO from iso/ with this change — no BC-250
hardware or VM available in this environment. What I did verify:

• bash -n scripts/build-iso.sh — syntax OK.
• The new shellprocess@boot_reconfigure.conf content is byte-for-byte the
  same script body already exercised and confirmed working in a VM per the
  comments in scripts/fix-eggs-calamares-boot.py ("verificato in VM il
  10/08/2026") — I only relocated it to the module Calamares actually loads
  for the iso/ pipeline, plus adjusted the sequence/settings wiring.
• skillfish-fix-boot-extents is copied unmodified from system/.

This needs a real install test before merging — both an ext4 install and
a btrfs install, checking that the system boots both from the NVRAM entry and
from the removable EFI fallback path. I'm not in a position to do that BC-250
hardware test myself; flagging it explicitly rather than claiming it's
verified.

Fixes #12, Fixes #20 (pending the hardware test above).

[MTSistemi]

Thank you for this — and for being straight about what you did and did not test. That matters more than the patch itself.

What we took: the build-iso.sh part, merged in f983814.

You were right, and the gap was worse than the PR describes: scripts/build-iso.sh went straight to eggs produce and nothing invoked fix-eggs-calamares-boot.py. The fix existed as 411 lines of code that someone had to remember to run. On a one-person project that is not a process, it is a coin flip — and when it lands wrong the ISO ships with a broken GRUB and nobody finds out until a user tries to install it. Which is exactly what happened, publicly, in a review.

One change to your code. You wrote:

[ $RC -ne 0 ] && { echo "FAIL-BOOTFIX rc=$RC" > "$ST"; ...; exit 1; }

build-iso.sh currently has set -u and not set -e, so it works today. But if anyone ever adds set -e, that line aborts the build when everything is fine: with RC=0 the test is false, the AND-list returns 1, and the script dies. Rewritten as if ... fi. In fairness the style was copied from a line that was already ours, so the trap was ours to begin with.

What we left out: the iso/ parts (1–3), and why.

Releases have been built with eggs for a while now; iso/ is the older live-build path and has not been touched since 11 July. Adding the fix there would create a second copy that we never exercise and that quietly rots.

But your underlying point stands and we had missed it: the documentation still describes a pipeline we no longer release from. That is the actual bug in parts 1–3 — not the missing config, but docs/BUILD.md sending people down a road we abandoned. Fixing the docs is worth more than duplicating the patch.

Would you like to take that on? Either updating docs/BUILD.md to describe the eggs pipeline, or — if you think the live-build path should stay supported — making the case for it, in which case parts 1–3 belong in that discussion. Your call; we are happy either way.

Leaving this PR open so you can repurpose the branch if you want it. The install test you asked for (ext4 and btrfs, NVRAM entry and removable EFI fallback) we can run ourselves in a VM, as we did for 26.06.3.

Also: you are now in the README under Contributors, along with the Polish translation work. Overdue.

[MTSistemi]

Correction to my previous comment — I was imprecise about the test, and the distinction matters for how you read your own patch.

26.06.3 was already installed and booted in a VM, on btrfs, before release. That is how #12 and #20 were closed. The install landed on a btrfs root with the @ subvolume, and the snapshot tooling we built on top of it (snapper, and a rollback command that has to tell @ on a Calamares install apart from @rootfs on the board) could not have been developed on anything else. So in the published media GRUB installs correctly and btrfs boots.

I should have said that outright instead of writing that we "can" run the test. Sorry — your PR is premised on the bug still being live in the release, and it is not.

That does not reduce the value of what you found, it changes what it protects. The published ISO is fine. What was not fine is that it stayed fine by luck: the fix had to be remembered and run by hand before every eggs produce, and eggs regenerates /etc/calamares from its own templates every single time. One forgotten step and the next ISO ships broken, silently, exactly as before. Your patch closes that. It protects future builds, not the current one.

Full disclosure on the limits of what I just told you: the VM that install ran in has since been deleted, so the above is reconstructed from the work we did on it rather than something I can show you a screen of right now. We are rebuilding it — a clean install from the published ISO, one on btrfs and one on ext4, checking boot from the NVRAM entry and from the removable EFI fallback path, which is the test you asked for. I will post the result here, whichever way it goes.

[MTSistemi]

Test done, as promised. Fresh install from the published 26.06.3 ISO, UEFI, btrfs, in a clean VM. Result: both bugs are gone from the released media.

Rather than trusting the running system, I shut the VM down and read the disk from the hypervisor — for these two bugs what matters is what Calamares actually wrote.

#20 — removable EFI fallback. The ESP now contains, in the removable path:

/EFI/boot/bootx64.efi   /EFI/boot/grubx64.efi   /EFI/boot/mmx64.efi
/EFI/boot/BOOTX64.CSV   /EFI/boot/grub.cfg      <-- the file whose absence caused grub rescue>

and that grub.cfg is btrfs-aware, which is the part a careless fix gets wrong:

search.fs_uuid fea54d7d-… root hd0,gpt2
set prefix=($root)'/@/boot/grub'
configfile $prefix/grub.cfg

Note the /@/ prefix. /EFI/SkillFishOS/ has the full set too, so both the NVRAM entry and the removable path work.

#12 — btrfs. Root is btrfs with @ @home @cache @log @swap, mounted compress=zstd:1; grub.cfg regenerated (10 KB) with rootflags=subvol=@; kernel and initrd intact. The installed system boots from disk on its own — no rescue prompt. /var/lib/systemd/random-seed was rewritten after install, which only happens on a real boot.

Snapshots work too, and the log shows the fallback path we wrote doing its job:

creating snapper 'root' config + .snapshots subvolume
create-config failed, creating subvolume manually
done

with @/.snapshots, @/.snapshots/1/snapshot, @/.snapshots/2/snapshot present afterwards.

Two unrelated things your test setup surfaced, both now filed:

• sddm-helper: pam_unix(sddm-autologin): could not identify user (from getpwnam(live)) — the installed system still looks for the live user.
• grub-btrfsd: Error during grub menu creation (grub/ grub-btrfs error) — the snapshot boot menu is not generated by the daemon.

So: your patch protects future builds, which is exactly what it should do, and it is merged. Thanks again for pushing on this — the test only got run because you asked for it.