4.1.1 — lib-restore.sh carries the needs-bash guard every library has

4.1.1 — lib-restore.sh carries the needs-bash guard every library has

4.1.0's commit failed CI on one check: tests/cli-test.sh requires every tracked script to guard for bash before its first set -, and the new lib-restore.sh — untracked when 4.1.0 was tested locally — had no library guard. The guard is added; nothing else changes.

Everything in the 4.1.0 release notes stands: the M2 Max restore (PASS-VM), one restore pipeline (lib-restore.sh), the test bed without a spare drive, the setup-fingerprint report.

4.1.0 — Apple Silicon first: the M2 Max restore, one restore pipeline, a test bed that needs no spare drive

4.1.0 — Apple Silicon first: the M2 Max restore, one restore pipeline, a test bed that needs no spare drive

Found on the M2 Max, fixed

• Fedora Asahi Remix: shim on the removable path had no GRUB beside it.
  restore-rebuild-boot.sh took os-release's ID for the ESP's vendor
  directory. Asahi has ID=fedora-asahi-remix and ships its loaders in
  EFI/fedora, so the Fedora-shim branch was never taken, grub2-install
  was tried (and refused, on an EFI Secure Boot build), and EFI/BOOT/BOOTAA64.EFI
  (shim) was left with no grubaa64.efi to load: the restored system stopped
  at Failed to open \EFI\BOOT\grubaa64.efi. Caught by the test bed's VM boot
  before any reboot. The rebuild now finds the directory that actually holds
  this arch's shim or GRUB (ID, each ID_LIKE token, then whichever
  directory has a shim, then one with a GRUB image; never EFI/BOOT), and
  testbed.sh finish checks the removable path's shim has its GRUB beside it
  before it lets anyone boot. Seven x86 bare-metal restores had passed without
  exercising this.
• The VM boot on aarch64 had no display: -vga std is not an option of
  the virt machine. It gets a virtio-gpu-pci there.

The restore test bed without a spare drive

• TB_TARGET_IMAGE=<file> — a sparse disk image on the backup drive (no
  CoW, never on one of this machine's own disks), attached as a loop device
  and used exactly like a test drive: partitioned like the host, LUKS with the
  host's KDF, restored, fingerprinted, booted in a VM. A file is nothing the
  firmware can boot, so its verdict is PASS-VM from testbed.sh collect --vm: proof of the restore, not of the Bare-metal restore column, which
  stays ⚠️ until a drive has really booted.
• TB_TARGET_ESP=<PARTUUID> — the same-disk mode for machines whose
  firmware boots nothing external (Apple Silicon): a spare ESP on the running
  disk plus the free space after it — on a Mac, the ESP of a second "UEFI
  environment only" Asahi install. The test bed adds its partitions there
  (explicit numbers and sectors, one sgdisk call each, the free region
  re-verified at write time, partx -a because a disk in use cannot re-read
  its table, never a zap), keeps the ESP and its stub files (only EFI/ is
  cleared), and the restored system is picked at power-on. The boot logger
  then goes by partition PARTUUID, not disk serial; U-Boot's ubootefi.var
  (this machine's boot order, restored onto the spare ESP) is parked so the
  stub boots its own ESP; the restored boot chain is checked to name test
  partitions only; the VM boot gets a read-only device-mapper disk made of the
  test partitions alone under a GPT with their real PARTUUIDs and the disk's
  sector size; TB_DELETE_TARGET=1 testbed.sh revert removes the partitions
  (never the ESP). Written and unit-tested; not yet run on metal — it needs
  the second stub installed from macOS.
• TB_BACKUP_MOUNT=<mount> — the test archive goes to another mounted
  drive (another machine's production backup drive plugged in for the test);
  the suite's wrong-drive guard is told that drive's UUID for the test only.
• 4096-byte-sector targets: the VM's virtual disk now carries the
  target's logical sector size (Apple NVMe is 4Kn; at 512 the GPT is read at
  the wrong offsets).
• The USB transfer-size workaround (TB_SECTORS_KB) applies to USB drives
  only — no longer to NVMe, SATA or loop devices.

One restore pipeline: lib-restore.sh

borg-restore.sh and backintime-restore.sh carried 1,100 identical lines
each, and they had drifted: Back In Time's copy lacked the volume-group name
bridge, the tolerance for an ESP GRUB stub with no grub.cfg, and the check
that a Debian initramfs carries the root container's crypttab entry. The shared
pipeline — target checks, the new disk's ids, fstab / crypttab / command-line
rewrite, swapfiles and the SELinux relabel, the chroot boot rebuild, the
verification — is now lib-restore.sh, eleven stages both front ends run in
order. The front ends keep what differs: archive or snapshot selection and
the extraction. Installed to /usr/local/sbin and copied to the backup
drive's recovery-scripts/ with the rest. Proven by the M2 Max restore, which
ran the refactored pipeline.

The README, split

The README is 200 lines: what it is, the quick start, Apple Silicon, the
status summary, restore, the documentation table. Everything else moved
verbatim into docs/: STATUS.md (the tested / untested tables, the test
bed, what is not yet universal), INSTALL.md (deploy, drive set-up and
sizing, dependencies, scheduling, retention, the tray, every file),
RESTORE.md, TROUBLESHOOTING.md (logs, the report, USB bridge drops,
hand-rolling a fix), LAYERS.md, FAQ.md. Every cross-reference in
CONTRIBUTING, SECURITY, the issue templates and the scripts' own hints was
repointed. deploy.sh copies RESTORE.md and TROUBLESHOOTING.md to the
backup drive's recovery-scripts/ too.

The report a new setup is added from

backup-diag.sh opens with a setup fingerprint: one screen of the facts
every decision is made from, gathered without assuming any of them —
ID/ID_LIKE, which package managers exist (apt, dnf, zypper, pacman, apk,
xbps, emerge, slackpkg, nix, eopkg, rpm-ostree, …), the root filesystem and
the whole device stack under it, every real filesystem mounted (the fixed
type list that filtered an unknown root filesystem out of its own report is
gone), what the kernel supports, page and sector sizes, encryption and
volume management, the ESP's vendor directories and U-Boot's variable file
where there is one, every loader config found, the initramfs tools, what
could take snapshots — then the mkfs/fsck/tooling each filesystem has. That
section plus What the suite's own detection reports is what a distro,
filesystem or boot layout the suite has never met is added from, with nothing
else needed from the machine. "Universal" is the goal; this is how a report
from a setup nobody here owns turns into a fix.

Apple Silicon, said plainly

The FAQ now says what "run the Asahi installer from macOS" depends on — Apple
still serving the stub macOS image for that model — and what to protect on a
Mac that will outlive its macOS support: never delete the stub container,
keep macOS bootable (the installer runs from it and finishes in
recoveryOS), count on a restore over the existing
boot chain, and consider a second stub while Apple still serves the image.

v4.0.5

4.0.5: bare-metal restore verified on a seventh system — Linux Mint 22.3 on the Acer Predator Triton 500, UKI-only systemd-boot built by the host's own hooks, LVM on LUKS

Restored from the installed system onto a blank 2 TB USB SATA SSD with
testbed/testbed.sh, booted first in a VM (testbed.sh vmboot: PASS, the
passphrase typed at the initramfs prompt), then on the machine from the
firmware menu with Secure Boot on: Wi-Fi, DNS, Bluetooth up, 99.99% of
686,667 files restored with the archived size, testbed.sh collect →
VERDICT: PASS, this machine's disks identical before and after.

The first restore of this machine would not have booted.

Restore:

• restore-rebuild-boot.sh: on a UEFI host with systemd-boot, a grub.cfg counts
  as GRUB only when the ESP holds a GRUB image ("GNU GRUB", or a bare core's
  "grub rescue> "/grub_mod_init). A Mint host with the grub packages installed
  got grub-install and update-grub: shim → GRUB on the fallback path, and a menu
  with no Linux entry (only os-prober's find on this machine's Windows disk).
• restore-rebuild-boot.sh: UKIs built by a Debian host's own kernel postinst /
  initramfs post-update hook (ukify) are rebuilt through update-initramfs
  (UKI_TOOL=update-initramfs), one kernel at a time; a kernel is installed when
  dpkg says so (a UKI-only host keeps no /boot/vmlinuz-*), and every UKI must
  have changed afterwards. kernel-install with layout=none had done nothing:
  every UKI kept an initramfs that unlocks the source disk. The update-initramfs
  loop is one function for both paths.
• restore-rebuild-boot.sh: sbctl sign-all failing only on database entries for
  files that are gone is named as such, not reported as a signing failure.
• borg-restore.sh: the crypttab entry of an LVM root is also found by the
  volume group its container holds on this system, when the restored LVM
  metadata backup names another device.
• backintime-restore.sh: the installed-system crypttab pairing of
  borg-restore.sh (containers open under another name, the old disk still
  installed) and the rebuild-only 'initramfs' option, the same code.

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.

linux-backup-system 4.0.2 — proof of concept confirmed

linux-backup-system 4.0.2 — 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 fully working
system — verified on bare metal, with the original disks proven untouched.

Four bare-metal restores have now passed on real hardware, on four different
distros and four very different layouts:

• Manjaro — btrfs root on LUKS2 (sd-encrypt), systemd-boot + UKIs,
  Secure Boot with sbctl keys (2019 ASUS ZenBook UX534FTC).
• Linux Mint 22.3 — ext4 on LVM-on-LUKS2 with a keyfile, encrypted LUKS2
  argon2id /boot opened by GRUB 2.14 (EFI), SELinux relabel boot; on a
  2014 ASUS X750JN, a 3-SSD triple boot with Linux Mint, Fedora and
  EndeavourOS. testbed.sh collect: VERDICT: PASS.
• Fedora 44 Workstation — btrfs root and home subvolumes on LUKS2 argon2id
  unlocked by dracut, vfat XBOOTLDR /boot + ESP at /efi, systemd-boot +
  kernel-install UKIs, SELinux enforcing; the same X750JN, its Fedora SSD
  restored. testbed.sh collect: VERDICT: PASS, 99.99% of 587,637 files
  restored with the archived size, system state running.
• EndeavourOS — ext4 root on LUKS2 argon2id unlocked by dracut, vfat
  XBOOTLDR /boot + ESP at /efi, systemd-boot Type #1 entries for linux and
  linux-lts, KDE Plasma 6.7 on Wayland; the same X750JN, its EndeavourOS SSD
  restored. testbed.sh collect: VERDICT: PASS, 99.96% of 583,535 files
  restored with the archived size, system state running.

None of these machines is "factory standard": custom GRUB builds, unusual
encryption layouts, multi-boot disks and years of leftovers. That is exactly
what the suite has to survive, and it is why every result is proven per setup
and recorded in the README's Tested / untested tables — every successful test
on real hardware is recorded and documented there.

A passing verdict is not the end of a test. Forensic inspection of the first
restored Fedora drive found two directory-ownership faults every automated
check had passed: ~/.local and ~/.local/share restored with the wrong
ownership and permissions (root:root 700), because a folder kept inside an
excluded tree was archived without its parent directories; and the cache
directories packages create under /var/cache (lightdm, akmods) missing or
root-owned. 4.0.2 archives the parents of every kept folder and the first
level of /var/cache, the restore repairs directories older archives left
root-owned, and the test bed's boot report now flags root-owned directories in
a home. A second restore re-verified the ownership fix.

The EndeavourOS run tested the test bed itself. Its first test boot logged in to
a desktop with no panel, no launcher and no terminal: the functional test
archive kept ~/.config but not ~/.local/share, where Plasma keeps its panel
theme, plasmoids, color schemes and icons. The same boot unlocked the host's SD
card, because the restored crypttab and its keyfile came back with the restore.
Neither was a fault in the restore scripts: the test archive now keeps a home's
desktop state, and the test drive no longer unlocks or mounts the host's other
disks. A second restore booted into the full desktop and passed.

The same run fixed the leftovers a long-lived system carries (4.0.1): unified
kernel images of removed kernels, a rescue image no generator rebuilds, a dead
ESP GRUB stub, a GRUB font that made grub-mkconfig abort, and files labelled
with an SELinux type whose policy module was gone — named on the live system by
backup-verify.sh section 7 and repaired by --fix.

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 —
shim Secure Boot, Limine, rEFInd, restore
from a live USB, Raspberry Pi, GRUB legacy BIOS — each turning green only when
its own test-bed run passes, together with ongoing code improvements found
along the way. openSUSE and the distros the package map does not know wait on
contributions.

Until every row describing your machine is ✅, use the suite for testing only.

linux-backup-system 4.0.1 — proof of concept confirmed

linux-backup-system 4.0.1 — 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 fully working
system — verified on bare metal, with the original disks proven untouched.

Three bare-metal restores have now passed on real hardware, on three different
distros and three very different layouts:

• Manjaro — btrfs root on LUKS2 (sd-encrypt), systemd-boot + UKIs,
  Secure Boot with sbctl keys (2019 ASUS ZenBook UX534FTC).
• Linux Mint 22.3 — ext4 on LVM-on-LUKS2 with a keyfile, encrypted LUKS2
  argon2id /boot opened by GRUB 2.14 (EFI), SELinux relabel boot; on a
  2014 ASUS X750JN, a 3-SSD triple boot with Linux Mint, Fedora and
  EndeavourOS. testbed.sh collect: VERDICT: PASS.
• Fedora 44 Workstation — btrfs root and home subvolumes on LUKS2 argon2id
  unlocked by dracut, vfat XBOOTLDR /boot + ESP at /efi, systemd-boot +
  kernel-install UKIs, SELinux enforcing; the same X750JN, its Fedora SSD
  restored. testbed.sh collect: VERDICT: PASS, 99.99% of 587,461 files
  restored with the archived size.

None of these machines is "factory standard": custom GRUB builds, unusual
encryption layouts, multi-boot disks and years of leftovers. That is exactly
what the suite has to survive, and it is why every result is proven per setup
and recorded in the README's Tested / untested tables — every successful test
on real hardware is recorded and documented there.

Getting Fedora through a real restore found and fixed the leftovers a
long-lived system carries: unified kernel images of kernels removed months
ago (still in the boot menu, embedding the old disk's command line), a rescue
image no generator rebuilds, an ESP GRUB stub that was already dead, a GRUB
font that made grub-mkconfig abort, and files labelled with an SELinux type
whose policy module was gone — which silently broke the btrfs replica. The
restore now handles each on the new disk, and backup-verify.sh names them on
the live system (section 7) and repairs them with --fix. It also fixed an
installer that could start a backup mid-deploy from an old timer, a drive
unlock unit that marked every boot degraded without a keyfile, and a
troubleshooting report that now shows disk serial mismatches, firmware boot
entries, what shim really chains to, SELinux mode and test bed verdicts. The
restore test bed identifies USB drives whose bridges hide their serial, never
writes or prunes replicas on a backup drive another machine uses, keeps its
config for collect, and compares every subvolume.

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 —
EndeavourOS, Arch, systemd-boot Type #1, shim Secure Boot, Limine, rEFInd,
restore from a live USB, Raspberry Pi, GRUB legacy BIOS — each turning green
only when its own test-bed run passes, together with ongoing code improvements
found along the way. openSUSE and the distros the package map does not know
wait on contributions.

Until every row describing your machine is ✅, use the suite for testing only.

linux-backup-system 4.0.0 — proof of concept confirmed

linux-backup-system 4.0.0 — proof of concept confirmed

This major release marks the point where 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 fully working
system — verified on bare metal, with the original disks proven untouched.

Two bare-metal restores have now passed on real hardware, on two different
distros and two very different layouts:

• Manjaro — btrfs root on LUKS2 (sd-encrypt), systemd-boot + UKIs,
  Secure Boot with sbctl keys (2019 ASUS ZenBook UX534FTC).
• Linux Mint 22.3 — ext4 on LVM-on-LUKS2 with a keyfile, encrypted LUKS2
  argon2id /boot opened by GRUB 2.14 (EFI), SELinux relabel boot; on a
  2014 ASUS X750JN, a 3-SSD triple boot with Linux Mint, Fedora and
  EndeavourOS. testbed.sh collect: VERDICT: PASS.

None of these machines is "factory standard": custom GRUB builds, unusual
encryption layouts, multi-boot disks and years of leftovers. That is exactly
what the suite has to survive, and it is why every result is proven per setup
and recorded in the README's Tested / untested tables — every successful test
on real hardware is recorded and documented there.

Getting Mint through a real restore found and fixed the class of bugs only a
restore from an installed system exposes: crypttab still unlocking the
original disk, a Debian initramfs that could not unlock its root, a GRUB stub
naming the old /boot container, a /boot too small for a blanket initramfs
rebuild, and a verification pass that never read /etc/crypttab. The restore
test bed (testbed/testbed.sh) now mirrors LVM-on-LUKS and encrypted /boot
layouts, uses a 100 GiB slice of the test drive, and boots it unattended.

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 —
Fedora (SELinux enforcing next), EndeavourOS, Arch, systemd-boot Type #1 and
dracut/kernel-install UKIs, shim Secure Boot, Limine, rEFInd, restore from a
live USB, Raspberry Pi, GRUB legacy BIOS, openSUSE — each turning green only
when its own test-bed run passes, together with ongoing code improvements
found along the way.

Until every row describing your machine is ✅, use the suite for testing only.

v3.8.0 — Limine and rEFInd restore, SELinux relabel, a tray that sees only real runs

Restore:

• Limine (CachyOS's default) and rEFInd are reinstalled by restore-rebuild-boot.sh, and a firmware boot entry is created with efibootmgr (NVRAM entries are in no backup). Written and fixture-tested only, so both rows are ❌.
• On a restored system with SELinux enforcing or permissive, the restore creates /.autorelabel. The Back In Time layer does not carry SELinux labels, and an enforcing Fedora/RHEL system with unlabeled files refuses logins. ❌ until a Fedora restore confirms it.

Verify: archives booted by Limine, rEFInd or syslinux/extlinux no longer FAIL with "no bootloader config". With the backup drive unplugged, check 1 no longer tests the root disk's keyslots and reports a false FAIL.

Tray: "backup running" is shown only when a backup actually runs, not when a shell, editor or grep command line mentions a script name. With the drive unplugged, the drive label says not connected instead of showing the root filesystem's size.

Which systems can be restored bare-metal: CONTRIBUTING.md now lists the setups that are possible but not handled yet, each with what a patch needs: ostree/transactional distros, NixOS, ZFS/bcachefs roots, mdadm RAID, syslinux/LILO, TPM2/FIDO2 LUKS, sbctl Secure Boot, non-systemd distros. It also has a Not possible section, so nobody spends time on those: Apple Silicon, ARM boards with U-Boot at raw offsets, Chromebooks, A/B image systems. For them, reinstall first, then restore over the install.

v3.7.0 — restore finds the ESP at /efi; fstab/crypttab ids rewritten by field; verified on EndeavourOS

Verified on EndeavourOS: a 2014 ASUS X750JN, ext4 root on LUKS2, plain vfat /boot (XBOOTLDR) + ESP at /efi, systemd-boot, dracut. deploy.sh set up the USB NVMe backup drive, then real borg, Back In Time, Timeshift and LUKS header backups ran and backup-verify.sh reported 0 FAIL. The Arch / Manjaro / EndeavourOS and plain /boot rows are ✅.

Restore fixes — each would have left a restored machine unbootable or misreported:

• Both restore scripts looked for the ESP only at /boot/efi. With the ESP at /efi, its fstab UUID was never rewritten and the restored system hung at boot.
• fstab/crypttab IDs were matched on the substring UUID=, which also matched inside PARTUUID=. They are now parsed by field and rewritten in the form each entry already uses (UUID=, PARTUUID=, LABEL=, PARTLABEL=).
• The post-restore check stopped at its first count (((X++)) under set -e), and it knew only /boot/vmlinuz-*. It now also counts kernel-install entries and UKIs.
• An ESP mounted directly at /boot is recognised. The new disk's partition types (ESP = EFI System, a separate vfat /boot = XBOOTLDR) are checked before anything is rewritten, and each warning prints the sgdisk fix.

deploy.sh fixes found on Arch: an unbound variable made the capacity check count only /; deploying with no drive connected aborted on every non-btrfs host; a non-blank SD card listed last aborted the deploy; a disk with only a partition table was described as having a filesystem.

v3.6.4 — Apple Silicon restore (Asahi installer, then restore over it) verified on an M1 Pro

An Apple Silicon restore is never bare metal: m1n1, U-Boot and the partitions the Mac's firmware boots from are Apple-managed and cannot be backed up or recreated from Linux. The order is: Asahi installer from macOS to get a fresh Fedora Asahi Remix booting, then this backup restored over it. The README status table, the Restore section, the Apple Silicon FAQ, ABOUT and backup-verify.sh section 6 all say so.

That row is ✅: in September 2026 a MacBook Pro (M1 Pro) was reinstalled with the Asahi installer and this suite's backup restored over the fresh install, and it boots — done with an earlier 3.x release; the restore path has not changed since in a way that affects it. A report from an M2 or later, or with the current release, is still welcome.