v4.0.3: linux-backup-system 4.0.3 — proof of concept confirmed

linux-backup-system 4.0.3 — proof of concept confirmed

This release carries the 4.0 milestone forward: the suite is proven to work end
to end — back up a real machine, restore it onto a different, blank disk with
the suite's own restore scripts, and boot the restored disk into a working
system — verified on bare metal, with the original disks proven untouched.

A fifth bare-metal restore has passed on real hardware, on the hardest boot
chain so far:

• Fedora 44 Workstation on a 2014 MacBook Pro 15" (i7-4870HQ, NVIDIA 470xx,
  AX210) — btrfs root and home subvolumes on LUKS2 argon2id unlocked by
  dracut with a keyfile, an encrypted LUKS2 argon2id /boot opened by GRUB
  2.14 built from source into /usr/local and chained from Fedora's shim,
  SELinux enforcing. Fedora's own GRUB is 2.12, which has no argon2 support
  at all: only the from-source 2.14 can open this /boot. Booted first in a
  VM (testbed.sh vmboot: PASS), then on the machine from the Mac firmware
  menu. testbed.sh collect: VERDICT: PASS, 99.99% of 447,938 files restored
  with the archived size, Wi-Fi, DNS and Bluetooth up, the original disk
  identical before and after.

The first restore of this machine would not have booted — and every check
passed. The restore took the from-source GRUB core on the ESP for a distro's
signed image and kept it: its built-in config still unlocked the ORIGINAL
disk's /boot. It never rewrote /boot/grub/grub.cfg, the config GRUB 2.14 reads
(Fedora's generator writes /boot/grub2/), nor the ESP stub, which finds /boot
by cryptomount and a cryptouuid/ prefix instead of a search. Its GRUB checks
passed on the original disk's ids because that disk was still installed, the
argon2 check compared version numbers against 2.12, and the restore exited 0
after verification failures. 4.0.3:

• rebuilds a GRUB core built on the source machine with the grub-install
  whose modules can open the /boot container (argon2 needs GRUB 2.14 —
  backup-verify.sh and the restore now say so, and report the newest GRUB
  installed, not the first one found);
• rewrites the ids in every GRUB configuration and in a cryptomount-only
  ESP stub, and reads search lines with hint options;
• fails verification for any GRUB configuration or loader image that still
  names the source disk, even when that disk is present;
• puts the GRUB core beside shim on the removable-media path, which an
  installed-system restore (no firmware entry) boots through;
• exits non-zero when the restore's own checks fail.

The test bed learned from its own first boots. On a Mac the restored ESP made
the firmware menu show the test drive exactly like the internal disk: the test
drive is now labelled TEST. A status line in the test loader's built-in config
used if … fi, which GRUB's rescue parser cannot run, and the test boot stopped
at grub>: the config is plain commands again, and a test holds it there. And
no test drive should reach a real reboot untested any more: finish checks that
GRUB's own code unlocks the drive with the test passphrase, then boots the
drive in QEMU — snapshot, no network — with a report disk for its boot logger,
and only says the drive is ready when that VM boot passes. The troubleshooting
report carries the VM boot's verdict for setup reports.

What 4.0 does not claim: a setup whose rows are still ⚠️ or ❌ has not been
restored and booted yet. Following 4.x releases will fill those rows in and
each turning green only when its own test-bed run passes, together with
ongoing code improvements found along the way. Next are shim Secure Boot and
restore from a live USB, and additional tested systems. The distros and setups
the package map does not know wait on contributions, i.e. openSUSE, Limine,
rEFInd, Raspberry Pi, GRUB legacy BIOS and any other distro.
Until every row describing your machine is ✅, use the suite for testing only.