Installing Fedora on MacBook Air A1369

November 28, 2022
apple
fedora

Apple is a marketing company. Once the device is not supported anymore, it’s called “vintage”. You should go buy a new one otherwise the experience heavily degrades. But these old laptops are still quite powerful―this MacBook Air 2011 model, for example, has an i7 CPU and an SSD, FFS. Luckily they can be given a new life with Linux.

TL/DR: Installing Fedora 37 on a MacBook Air A1369 (2011) at the end of 2022 is tricky and close to impossible for normal users.

Why Fedora

Myself I use Arch but of course you don’t want the bleeding edge on all the family computers. From the Flatpack bandwagon, Ubuntu’s Snaps look shady and I also remember they wasted energy with Unity. There might be other interesting distros but I try to stay away from them because maintenance takes a lot of time and I can’t tell if they are backed by some lone hacker or a capable entity.

The past years I read some amazing Fedora development blog posts by Christian Schaller and I was looking for an opportunity to try out Fedora.

macOS be gone

Decide whether you still want a separate smaller macOS partition. Having the macOS partition allows you to do firmware upgrades. I wiped mine. In case you still want a macOS partition, shrink it beforehand using some Mac tool, to make space for the Fedora partition.

Fedora on a USB stick

The Fedora download page does not say anything about dd and its weird arguments, but you can cat the downloaded image to /dev/sdX just fine to write the image onto a USB drive.

Press alt on the MacBook while booting to be able to select the USB stick.

Unfortunately you end up in a Grub screen because Grub sets the following variables with incorrect values. For example:

prefix=(hd5)/EFI/BOOT
root=(hd5)

Note the screenshots below show hd1 instead of hd5 because the partition table has been changed in the meanwhile.

Grub looks for the Fedora-WS-Live-37-1-7 partition

Type ls to see what disks exist and then ls (hd1 and press TAB to see the partitions names:

To get past the Grub screen, correct the prefix and root variables:

grub> set prefix=(hd5,msdos1,gpt1)/boot/grub2/
grub> set root=(hd5,msdos1,gpt1)
grub> normal

Fedora on an SSD

Anaconda is the software which installs Fedora. The classic “wizard” design can be confusing when you have an already partitioned disk and partitions need to be deleted to make space for Fedora.

Enable the disk encryption, then at the end of some automatic partitioning the disk will end up with three partitions:

efi
boot
luks

The installation takes some time and it will show errors. When an error dialog shows up, open Terminal and check out the *.log files in /tmp to see what exactly happened.

“(FSError(‘format failed: 1’), ‘/dev/sda1’)”

Anaconda’s /tmp/storage.log shows:

INFO:program:Running... mkfs.hfsplus -v Linux HFS+ ESP /dev/sda1
INFO:program:stderr:
INFO:program:b'mkfs.hfsplus: write (sector 2880): Input/output error'
DEBUG:program:Return code: 1
ERROR:anaconda.modules.storage.installation:Failed to create storage layout: (FSError('format failed: 1'), '/dev/sda1')

This can be fixed by writing /dev/zero to /dev/sda.

“Failed to set new efi boot target”

Anaconda’s /tmp/storage.log shows:

INFO:program: Running in chroot '/mnt/sysroot'... efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -1 \EFI\fedora\shimx64.efi
INFO:program: Could not prepare Boot variable: Invalid argument
DEBUG: program: Return code: 5
[...]
ERROR:anaconda.modules.storage.bootloader.installation: Bootloader installation has failed: Failed to set new efi boot target. This is most likely a kernel or firmware bug.

You would never guess but Invalid argument means the /dev/sda1 partition is not writable. Make sure it’s writable and run the command manually, for example:

$ sudo chroot /mnt/sysroot
# touch /boot/efi/EFI/test && rm /boot/efi/test
# efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -1 \EFI\fedora\shimx64.efi

Convincing the system to boot

By now there should be a fedora folder on your EFI partition, representing a new boot option at the EFI level:

$ sudo chroot /mnt/sysroot
# ls /boot/efi/EFI
BOOT fedora

The Apple thing needs the folder to contain a BOOTX64.EFI file otherwise it is ignored, but Anaconda creates instead a BOOTX64.CSV:

$ sudo chroot /mnt/sysroot
# cat /boot/efi/EFI/fedora/BOOTX64.CSV
??shimx64.efi,Fedora,,This is the boot entry for Fedora

Shove the partition in Apple’s EFI loader with:

$ sudo cp /mnt/sysroot/boot/efi/EFI/fedora/shimx64.efi /mnt/sysroot/boot/efi/EFI/fedora/BOOTX64.EFI

Grub does not know what to do

By now the system should be able to start Grub, which displays a boot menu with a single useless entry. But don’t reboot the system just yet.

The generated grub.cfg creates the boot menu entries using blscfg which follows the Boot Loader Specification:

$ cat /mnt/sysroot/boot/grub2/grub.cfg
[...]
# The blscfg command parses the BootLoaderSpec files stored in /boot/loader/entries and
# populates the boot menu. Please refer to the Boot Loader Specification documentation
# for the files format: https://systemd.io/BOOT_LOADER_SPECIFICATION/.
[...]
insmod blscfg
blscfg
[...]

The BLS entries are defined in /boot/loader/entries/, but there is no such folder. It seems the failure to “set new efi boot target” during the installation prevented the proper “Fedora” BLS entry to be created.

Anaconda’s pyanaconda/modules/storage/bootloader/bootloader.py also shows InstallBootloaderTask just before CreateBLSEntriesTask:

InstallBootloaderTask.run() is the one printing the “Bootloader installation has failed:” error we can see above.
CreateBLSEntriesTask.run() calls create_bls_entries() which recreates the BLS entries.

To create them manually, run kernel-install:

$ sudo chroot /mnt/sysroot

# ls /lib/modules
6.0.7-301.fc37.x86_64

# kernel-install --verbose add 6.0.7-301.fc37.x86_64 /lib/modules/6.0.7-301.fc37.x86_64/vmlinuz
[...]
+/usr/lib/kernel/install.d/20-grub.install add 6.0.7-301.fc37.x86_64 /boot/f2190fde193f427a9ab189554835efa7/6.0.7-301.fc37.x86_64 /lib/modules/6.0.7-301.fc37.x86_64/vmlinuz
grub2-probe: error: cannot find a device for / (is /dev mounted?).
No path or device is specified.
Usage: grub2-probe [OPTION...] [OPTION]... [PATH|DEVICE]
[...]

# grub2-mkconfig -o /etc/grub2.cfg

It seems the grub2-probe error did not cause any issues. Fingers crossed.

Check that the entries have been defined:

# ls -l /boot/loader/entries/
f2190fde193f427a9ab189554835efa7-0-rescue.conf
f2190fde193f427a9ab189554835efa7-6.0.7-301.fc37.x86_64.conf

Reboot

By now the system is able to show the Grub menu with a “Fedora” and a “Fedora Rescue” entry. In my case selecting the “Fedora” option was failing to show the password prompt for decrypting the root partition. Pressing ESC to switch from the graphical screen to the boot log revealed no errors:

Luckily a good soul from the Fedora Matrix room suggested to select the Fedora Rescue option in the Grub boot menu, which started the system! Surprisingly the Fedora Rescue showed the “Welcome to Fedora” wizard and the thing was looking all normal.

Then running sudo dnf update upgraded the kernel, which seems to have fixed the “Fedora” menu entry, as it boots fine now. Wi-fi works, the three-finger gestures work amazing, the function keys work, camera works, Firefox can play DRM after installing something, all good.

Too bad now I need to keep an eye on /boot/efi/EFI/fedora/shimx64.efi and copy it as /boot/efi/EFI/fedora/BOOTX64.EFI whenever it changes. I’ll probably completely forget about it.