linux-backup-system › Restore Asahi Linux

How to restore Asahi Linux from a backup on an Apple Silicon Mac

Your Fedora Asahi Remix install is gone — a dead disk, a wiped Linux partition, an upgrade that will not boot — and you have a backup of its files. On a PC you would partition a new disk, put the files back and reinstall the bootloader. On an Apple Silicon Mac that cannot work; this page explains why, the route that does work, what to protect now, and exactly how much of that route has been tested.

Why a Mac running Linux cannot be restored the x86 way

On an x86 PC the firmware boots a file from a FAT partition, the EFI System Partition (ESP). Everything between the firmware and the kernel is files, so a file-level backup plus a bootloader reinstall can rebuild the machine on a blank disk.

A Mac running Linux starts a chain that Linux did not make and cannot make:

• A stub macOS. The Asahi installer creates a small APFS container per install — Asahi's partitioning notes put it at 2.5 GB, holding the parts of iBoot and macOS needed to boot the machine, including a copy of recoveryOS. Its boot policy is signed by the machine's own Secure Enclave when the installer sets it, and m1n1 sits in its kernel slot.
• m1n1 and U-Boot on the ESP. m1n1 loads its second stage and U-Boot from the ESP that belongs to that stub; each Asahi install gets its own ESP, logically tied to its stub.
• shim, then GRUB. U-Boot's UEFI implementation loads shim, which loads GRUB on arm64-efi, which boots a 16k-page kernel.
• Boot entries in a file. U-Boot keeps its EFI variables in ubootefi.var on the ESP the stub names. Entries shim's fallback writes at boot time persist there; entries efibootmgr writes from Linux do not survive a reboot.
• A 4Kn disk. Apple's NVMe uses 4096-byte logical sectors, and the first partitions on it can never be recreated from Linux.

The first link — the stub and its signed boot policy — is not a file, so no backup can hold it and no restore can write it. On this hardware, “bare metal” means “after the installer”: you get a fresh boot chain from Apple's side first, then put your system back over it.

The path that works: reinstall from macOS, then restore over it

The order is fixed: a fresh Fedora Asahi Remix booting, then your backup restored over that install, then the restored system pointed at the new partitions and its boot files rebuilt from inside it.

1. Get a fresh Fedora Asahi Remix booting from macOS

In macOS, open Terminal and run the installer command that Asahi Linux publishes:

curl https://alx.sh | sh

The installer runs from a macOS that still boots and finishes with one step in recoveryOS. It downloads the stub macOS image for your model from Apple's servers to build the boot chain — Asahi's own notes say the Apple components come from Apple's publicly available restore images, and that even a local install still reaches Apple's CDN for them. Boot the new install once, so you know the chain from the stub to GRUB works before you put anything over it.

2. Restore your files over the fresh install

The files go onto the new install's root (and /home), mounted at a target path the way the backed-up fstab mounts them. On Fedora Asahi Remix that is typically a btrfs root with root and home subvolumes, an ext4 /boot and the ESP at /boot/efi.

Never restore over the root filesystem you are running from. The restore has to run from another system: a live USB, if your Mac's U-Boot boots one, or another Linux system that can see the disk. This is the weakest step on a Mac — see what is verified below.

From a Borg repository, the extraction looks like this. borg extract always writes into the current directory, so change into the target first; --dry-run runs every step except writing:

cd /mnt/target
borg list /mnt/backup/borg-backup
borg extract --dry-run --list /mnt/backup/borg-backup::ARCHIVE
borg extract --list --numeric-ids /mnt/backup/borg-backup::ARCHIVE

--numeric-ids restores owners by number, not by name through the rescue system's own user database, which numbers system accounts differently from yours.

3. Point fstab, crypttab and the kernel command lines at the new partitions

The installer made new partitions with new ids. Your restored /etc/fstab, /etc/crypttab and kernel command lines still name the old ones. Read the new ids with lsblk -f, then rewrite each entry in the form it already uses (UUID=, PARTUUID=, LABEL=), leaving device-mapper names alone.

On Fedora Asahi Remix the command lines live in the BLS entries under /boot/loader/entries/ and in GRUB's defaults, /etc/default/grub and its drop-ins. An encrypted root adds rd.luks.uuid=; a stale one gives you a machine that stops in the initramfs with every file present.

The small grub.cfg on the ESP, in EFI/fedora/, finds /boot with search --fs-uuid. Point it at the filesystem that now holds /boot/grub2/.

4. Rebuild the initramfs and GRUB from inside the restored system

Bind the running system's kernel interfaces into the target and chroot into it:

mount --bind /dev /mnt/target/dev
mount --bind /dev/pts /mnt/target/dev/pts
mount -t proc proc /mnt/target/proc
mount -t sysfs sys /mnt/target/sys
mount --bind /run /mnt/target/run
chroot /mnt/target /bin/bash

Inside, regenerate every initramfs and the GRUB configuration:

dracut --regenerate-all --force
grub2-mkconfig -o /boot/grub2/grub.cfg

Do not reinstall the loaders themselves. With shim on the ESP, the signed GRUB image stays where it is; grub2-install would replace it with an unsigned one. And do not trust os-release for the ESP's directory: Fedora Asahi Remix reports ID=fedora-asahi-remix but keeps its loaders in EFI/fedora. A rebuild keyed to the ID takes the wrong branch and can leave shim on the removable path with no grubaa64.efi beside it — which is exactly what testing on an M2 Max found.

5. Relabel for SELinux, check, then reboot

Fedora Asahi Remix uses SELinux (the M2 Max tested here runs it enforcing), and an enforcing system with unlabeled files refuses logins. Have the first boot relabel everything (still inside the chroot):

touch /.autorelabel

The first boot relabels every file and reboots once. Before that reboot, search the restored /etc, /boot and ESP for every old id you replaced. Anything that still names one will boot, unlock or mount the wrong disk, or nothing.

What to back up, and what to protect now

A file-level backup of an Asahi Mac should hold /, a separate /home, the separate /boot and the ESP at /boot/efi, plus a LUKS header backup of every encrypted device. That is what you can restore.

The rest only the Asahi installer can make, and the installer depends on Apple still serving the stub image for your model. That matters most on the Macs Asahi is for — the ones that outlive their macOS support. So, while everything still works:

• Never delete the stub container (the 2–3 GB APFS partition beside your Linux partitions) to reclaim its space, and keep macOS bootable: the installer runs from it, and recoveryOS finishes it.
• Plan on restoring over the existing boot chain. Keep the stub, the ESP and /boot where they are, reformat or replace only the root, and restore over it. That route needs nothing from Apple.
• Consider a second stub. The installer's “UEFI environment only” install (about 3 GB, alongside the first) is cheap insurance while Apple still serves the image: a spare, machine-signed boot chain a restore can be pointed at.

What has been verified, exactly

Two Macs, two different levels of proof. Read the result column literally.

A PASS-VM is evidence for the restore, not for the Mac's own firmware booting it, and it is never counted as a real boot. The M2 Max went to a disk image because its U-Boot enumerated none of the USB drives tried, so “restore onto a spare drive and boot it” was impossible there. A real boot on that Mac needs test partitions in free space behind a second Asahi stub, and that ✅ is still to earn.

The M2 Max run found two faults that only an Apple Silicon machine would show: the EFI/fedora directory problem above (the first VM boot stopped at Failed to open \EFI\BOOT\grubaa64.efi), and the 4Kn disk — a VM that presents the same drive with 512-byte sectors reads its partition table at the wrong offsets. Both are handled now: the rebuild finds the directory that actually holds the loaders, and the VM boot passes the disk's logical sector size through. Restore from a live USB, on any machine, is still ⚠️ under test.

Frequently asked questions

Sources

• Fedora Asahi Remix — Asahi Linux (the install command from macOS)
• Partitioning cheatsheet — Asahi Linux docs (the 2.5 GB stub container, one ESP per install)
• Das U-Boot — Asahi Linux docs (U-Boot as m1n1's payload, USB boot)
• Open OS Platform Interoperability — Asahi Linux docs (Apple components from restore images and Apple's CDN)
• borg extract — Borg documentation and borg list
• Manual pages: lsblk(8), dracut(8)
• Project docs on GitHub: STATUS.md, TESTED-SYSTEMS.md, RESTORE.md, FAQ.md