<--

Gentoo Linux on Macbook Air

This page covers various features, nuances, notes, etc. of my Gentoo system running on a 2012 Macbook Air. This laptop was initially bought as a tinkering project for 150USD. While this is not the most powerful device, it is suitable for just about anything I encounter on a daily basis and is used as my primary system. My intentions for this system are reliability and speed most importantly. Follows is a tidy system with minimal kernel parameters set, fine-tuned USE flags, and a system I'm rather familiar with. Much of my configuration can be found here.

laptop image laptop open image

Overview

hardware features
kernel
bootloader
system bits
applications
miscellaneous
screenshots

Hardware Features

This is a Macbook Air 5,2 (EMC 2559) fit with the following (see lspci, lsusb)

Modifications

Since 2010, Apple Macbooks have used their proprietary SSDs with non-standard connectors. When I bought this machine, it came with a 128 GB Samgsung "blade" SSD which I was not very keen on keeping. Luckily, there exists adapters which simply act as a bridge between a standard M.2 SSD and Apple's connector. Installation was quite easy and the adapter has been reliable since. This laptop also came with what I presume was the original battery, as it lasted about 15 minutes after being charged and would lose power randomly. A suitable replacement can be found roughly 50USD. With this, I get about 5 hours on a full charge, mostly thanks to TLP and thermald. Now, if only the memory wasn't soldered directly to the motherboard, or I could find the courage to replace it.

Kernel

After spending quite some time narrowing down kernel parameters enabled, I have a 7.8MB kernel image with ~4000 parameters set. Note, this configuration is very hardware and user specific. I opted for zero modules since I don't need any out-of-tree hardware support. I also did not configure anything very drastically in either direction, like extreme security, sacraficing usability, etc. I chose to use gentoo-sources to provide kernel source as it contains some handy patches and is easy to obtain via emerge. A base 6.10 kernel builds locally (with 4 cores!) in approximately 17 minutes, which is not too troublesome when working on bare metal. I also chose to omit an initramfs, which means CPU microcode can/should be built directly into the kernel. This can be achieved by first installing sys-firmware/intel-microcode. This is also a good time to add microcode signature to /etc/portage/make.conf:
$ iucode_tool -S -l /lib/firmware/intel-ucode/*
        iucode_tool: system has processor(s) with signature 0x000306a9
microcode bundle 1: /lib/firmware/intel-ucode/06-3a-09
selected microcodes:
  001/001: sig 0x000306a9, pf_mask 0x12, 2019-02-13, rev 0x0021, size 14336
# echo 'MICROCODE_SIGNATURES="-s 0x000306a9"' >> /etc/portage/make.conf
      
CPU's signature is found in bundle 1, so the filename to use is /lib/firmware/intel-ucode/06-3a-09. Ensure the following kernel options are set appropriately, where the argument passed to CONFIG_EXTRA_FIRMWARE is the filename of our microcode
CONFIG_MICROCODE=y
CONFIG_FW_LOADER=y
CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
      
Check dmesg for microcode output to ensure all was successful. Specific configuration for this machine can be found at 6.10.0 .config. For some more kernel related stuff, see here.

Bootloader

Spoiler: there is none. For the duration of my time using Linux, I have used GRUB across various systems. In my experience, it's been ok, it does what it needs to, allows for ample configuration like theming and security. However, some time ago it went kaput on this machine and despite manually setting the root partition in /boot/grub/grub.cfg, it seems the incorrect value was passed to the kernel at boot and the partition could not be found. Every time I would reboot I would have to manually set it from GRUB command line (which is a handy trick to know nonetheless):
grub> ls
(hd0) (hd0,gpt0) (hd0,gpt1) (hd0,gpt2)
grub> ls (hd0,gpt1)/
vmlinuz vmlinuz.old
grub> root=(hd0,gpt1)
grub> linux /boot/vmlinuz root=/dev/sda3
grub> boot
      
Since this isn't a multiboot machine, GRUB can simply be omitted and expose the kernel image as an EFI stub. First, the following kernel options must be set
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="root=PARTUUID=<uuid> ro"
      
Where root is set to the PARTUUID value of the root partition. Use blkid to obtain this. Once kernel has been recompiled, copy the image to the EFI partition and create a new boot entry with below command(s). It is also wise to remove unneeded entries to conserve limited space. (below command selects the first entry with -b and deletes it with -B)
# efibootmgr -b 1 -B
# cp arch/x86/boot/bzImage /boot/efi/gentoo/bzImage-x.y.z.efi
# efibootmgr -c -d /dev/sda -L "gentoo efi stub" -l "\efi\gentoo\bzImage-x.y.z.efi"
      
Reboot and the bootable system should be shown in Mac's EFI program.

Other System Bits

C Library

I opted to use musl on this system, over the traditionally used glibc. While there are never-ending debates over which library is better, using musl has some clear benefits on this machine. Namely, shorter compile times -- musl compiles in roughly 2 minutes, versus glibc's 2 hours. Omitting glibc also removes the dependency for GCC, another hefty package. As for the reduced "compatibility" when using musl, in terms of non-POSIX compliant code, Flatpak is an adequate solution. I currently use Flatpak packages for proprietary applications whose binaries are linked against glibc, and Firefox, as NodeJS has a strict runtime dependency of GCC.

Compiler

As you may have guessed, this system's default compiler infrastructure is provided by LLVM. Clang and its counterparts have become much more widely used and are compatible with just about all code I encounter on this machine. Some advantages of this are of course the reduced system overhead of not depending on GNU's compiler collection, slightly faster compilation times and reduced memory usage, and potentially overall safer binaries.

Profile

Subsequently, this system uses a somewhat custom Portage profile, or at least a combination of existing ones. A musl/llvm profile exists, but I also wanted to omit multilib support from this system, as I do not need to run or build any 32-bit applications. With the way that cascading profiles work in Portage, this was quite easy to combine with the no-multilib profile. For reference, some primary features (USE flags) used on this system are Wayland, Pipewire, elogind, and OpenRC. Since no-multilib already has very few things enabled, not many things need to be explicitly disabled. Although, I have quite a few package-specific USE flags disabling unneeded features to help remove dependencies that may only be required for one or two packages.

Applications

Packages in my world file can be found in package list, and list of all system packages in full package list. Some notable utilities I use are below.

Miscellaneous

Another QOL modification for me was disabling the rather obnoxious startup sound present on all Macbooks. To do this, kernel must be built with efivarfs support (CONFIG_EFIVAR_FS) and the partition must be mounted at /sys/firmware/efi/efivars/. Next, the following commands must be run as proper root, not just with elevated permissions. Begin by removing the immutable flag from the appropriate file. Mac's EFI terminal uses the bell code (0x07) to audibly play system messages/warnings. It can be set to null character to silence it. Lastly, replace the immutable flag.
chattr -i /sys/firmware/efi/efivars/SystemAudioVolume-7c436110-ab2a-4bbb-a880-fe41995c9f82
printf "\x07\x00\x00\x00\x00" > /sys/firmware/efi/efivars/SystemAudioVolume-7c436110-ab2a-4bbb-a880-fe41995c9f82
chattr +i /sys/firmware/efi/efivars/SystemAudioVolume-7c436110-ab2a-4bbb-a880-fe41995c9f82
      

Screenshots

fetch image neovim image gotop image wofi image zathura image gtklock image