0.3.5.1 → 0.4.0 update: Raspberry Pi path (deferred from #3399)

[helix-nine]

Follow-up to #3399 (0.3.5.1 → 0.4.0 in-place update). The Raspberry Pi arch was deferred because it's a different boot problem, not just another target:

• 0.3.5.1 Pi boots firmware-direct (config.txt / cmdline.txt, root=PARTUUID=cb15ae4d-02 boot=embassy) — no grub.
• 0.4.0 Pi boots via arm64-efi grub (grub-install --target=arm64-efi in the image build).
• do_update skips the chroot on raspberrypi (if PLATFORM != raspberrypi in sync_boot), so — unlike x86 — we can't run anything (no grub-install, no update-grub2) at apply time. The only lever is the payload's boot/ contents, which sync_boot rsyncs onto the Pi boot partition.

Proposed approach

Ship a firmware-direct config.txt + cmdline.txt in the payload's boot/ that loads the 0.4.0 kernel + initramfs directly (bypassing grub), with cmdline.txt = root=PARTUUID=cb15ae4d-02 boot=startos <pi params>. The cb15ae4d disk id is fixed across 0.3.5.1 and 0.4.0 Pi images, so the root PARTUUID is deterministic. sync_boot overwrites the box's config.txt/cmdline.txt with ours → the Pi firmware boots the 0.4.0 kernel → boot=startos runs the 0.4.0 initramfs migration.

Remaining work

• Extract the 0.3.5.1 Pi base rootfs from the published .img.gz (not an ISO) — inspect the img's partition layout for the rootfs/squashfs.
• Build the firmware-direct config.txt/cmdline.txt for the 0.4.0 Pi kernel (this is net-new; the 0.4.0 Pi build is grub-based).
• Wire assemble-migration-payload.sh (.img.gz case) + the start-os-migration-squashfs make target + CI to include raspberrypi.
• Validate on real Pi hardware — a wrong config.txt bricks the boot.

Also gated on 0.4.0 Pi being release-ready.

[helix-nine]

Decision (from #3399 review): Raspberry Pi will not get an in-place 0.3.5.1 → 0.4.0 migration — Pi users reflash (USB/SD) instead.

Rationale: unlike x86/aarch64, a fresh 0.4.0 Pi boots firmware → U-Boot → GRUB(arm64-efi) across a 4-partition GPT, while a migrated 0.3.5.1 Pi keeps its 2-partition MBR SD (256 MB FAT boot + ext4 root, no gap before root). Reconstructing the 0.4.0 boot chain in place requires repartitioning the just-booted SD (or a permanent dual-mount workaround) — partition-table surgery whose risk isn't justified when reflashing is a clean, well-supported path for Pi. Closing as won't-do.