Machine brick & data loss after tring to convert the disk to btrfs and uninstalling from recoveryOS

System info:

Product name: MacBook Pro (13-inch, M1, 2020)
SoC: Apple M1
Device class: je293ap
Product type: MacBookPro17,1
Board ID: 0x24
Chip ID: 0x8103
System firmware: iBoot-7459.101.2
OS version: 12.3 (21E230)
System rOS version: 12.3 (21E230)
No Fallback rOS

Installation type: Asahi Linux Minimal (Arch Linux ARM)

Steps to reproduce:

###### WARNING ######
# Backup your data  #
# before tring      #
# these steps!      #
#####################

1. Install Asahi Linux
2. Boot to USB stick (in GRUB)
3. Verify that Asahi Linux is installed to nvme0n1p5
4. btrfs-convert /dev/nvme0n1p5 -L --uuid copy
5. reboot Now GRUB will fail, and the filesystem is corrupted(I forgot to re-grub-install).
6. Force shutdown
7. Press and hold the power button, then selece Options in the boot picker
8. diskutil list
9. diskutil eraseVolume free free /dev/disk0s5
10. diskutil eraseVolume free free /dev/disk0s4
11. diskutil apfs deleteContainer /dev/disk0s3 free free 0
12. reboot Now the machine is bricked. It’s not possible to get it into macOS or any recoveryOSs. An Apple Configurator revive or idevicerestore -l will complete with no error, but after that it’s still not able to boot it.

An Apple Cofigurator restore or idevicerestore -ley will unbrick it, but user data will lose.

[n8henrie]

Woot!

$ mount | grep btrfs
/dev/nvme0n1p5 on / type btrfs (rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/@)
/dev/nvme0n1p5 on /.snapshots type btrfs (rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,subvolid=262,subvol=/@snapshots)
/dev/nvme0n1p5 on /boot type btrfs (rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,subvolid=258,subvol=/@boot)
/dev/nvme0n1p5 on /gnu type btrfs (rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,subvolid=261,subvol=/@gnu)
/dev/nvme0n1p5 on /home type btrfs (rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,subvolid=263,subvol=/@home)
/dev/nvme0n1p5 on /nix type btrfs (rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,subvolid=260,subvol=/@nix)
/dev/nvme0n1p5 on /var type btrfs (rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,subvolid=259,subvol=/@var)

I used my modified script below, specifying the device: DEVICE=/dev/sda ./make_usb.sh

A few issues along the way:

1. Reboot to asahi, interrupt grub
2. I usually had to usb start then usb reset here before run bootcmd_usb0 would find my USB drive
3. Sometimes I ended up in an emergency shell here, other times it worked fine. If in an emergency shell, mount /dev/sda2 /new_root && exit
4. From here e2fsck and btrfs-convert --copy-label --uuid copy /dev/nvme0n1p5
5. If desired, mount, create subvolumes, migrate files to your subvolume layout and compression options of of choice
6. I chose to defrag and balance (as recommended)
7. Edit /mnt/etc/fstab with your default mount options, subvolumes, and change type to btrfs
8. arch-chroot /mnt, and in the chroot:
9. mount -a to check your fstab and mount options
10. update-grub, make sure it says something about btrfs in its output
11. double check that you have output with grep subvol= /boot/grub/grub.cfg if using a root subvol
12. I had to mkinitcpio -P or I got unknown filesystem when trying to mount root
13. Exit the chroot, reboot, and at this point I had a bootable system!
14. sudo mount /dev/nvme0n1p5 /mnt && sudo btrfs subvol delete /mnt/ext2_saved if desired
15. sudo systemctl enable --now [e-mail], install grub-btrfs, snapper, etc. – off to the races

My version of make_usb.sh:

#!/usr/bin/env bash

set -Eeuf -o pipefail
set -x

main() {
    if [[ "${EUID}" -ne 0 ]]; then 
        sudo --preserve-env=DEVICE "$0" "$@"
        exit $?
    fi

    umount -R /mnt || true

    MODULES="ext2 fat part_gpt search btrfs" update-grub
    pacman -S --noconfirm arch-install-scripts

    sgdisk --clear "${DEVICE}"
    echo -e 'o\ny\nn\n\n\n+1G\nef00\nn\n\n\n+2G\n8300\nw\ny\n' |
        gdisk "${DEVICE}"
    mkfs.vfat -F 32 "${DEVICE}1"
    mkfs.ext4 -F "${DEVICE}2"

    mkdir -p /mnt
    mount "${DEVICE}2" /mnt
    mkdir -p /mnt/boot/{grub,efi}
    mount "${DEVICE}1" /mnt/boot/efi
    cp -a /boot/efi/vendorfw /mnt/boot/efi/venderfw

    pacstrap -c /mnt \
        arch-install-scripts \
        asahi-meta \
        asahi-scripts \
        base \
        btrfs-progs \
        dhcpcd \
        dosfstools \
        e2fsprogs \
        grub \
        iwd \
        linux-asahi \
        neovim \
        reiserfsprogs

    cp -a /etc/pacman.{d,conf} /mnt/etc/
    sed -i 's/^HOOKS=(base udev /&asahi /' /mnt/etc/mkinitcpio.conf

    genfstab -U /mnt >> /mnt/etc/fstab
    arch-chroot /mnt <<EOF
        mkinitcpio -P
        grub-mkconfig -o /boot/grub/grub.cfg
        grub-install --removable
        systemctl enable iwd dhcpcd
        passwd -d root
EOF
    umount -R /mnt
}
main "$@"

[marcan]

“Bricking” means rendering a device inoperable without specialized tools; nobody has ever bricked an Apple Silicon machine here. Screwing up the partitions such that you have to recover using DFU mode is not bricking. Apple gives you instructions on how to recover from that right on their website, and idevicerestore lets you do it from a non-Mac, without any special tools. It isn’t “bricking” any more than wiping the OS on a PC such that you have to plug in a USB drive to reinstall is “bricking”.

Actually, as we are talking about bricking here 😃 How high is the chance that I could completely brick the device without a way to recover? (on a scale 1 to 100 if I do the most stupid sh*t)

We don’t know of any way to do that so far. The most damage we have a strong suspicion you can cause so far is blow the speakers (which is why we aren’t enabling them until we have volume caps in place).

Now the question is what happened to make the machine unable to get into recovery. I have a hard time believing it had anything to do with the btrfs conversion, since Apple’s OS and tooling makes no attempt to parse ext4 or btrfs and couldn’t care less what filesystem exists in the partition. So either this is some freak accident, or a very weird bug, or something unrelated.

Can you reproduce this at will? If so, please provide detailed instructions on how to do so, including exactly what you are booting, with links to any downloads or files or images you used, and clear reproduction steps, one by one, without omission, starting with a cleanly wiped system (DFU erase). If the btrfs conversion really is making the system break after deleting the partitions later then that is way, way down the freak bug scale, and we aren’t going to get anywhere without a very clear reproducer.