Secure Boot shenanigans

24th August 2025

Battlefield 6 Beta was a fun time. The series has finally gone "back to basics", recalling moments and atmosphere from Battlefield: Bad Company 2. The weapons feel powerful, the squad-based gameplay is back, and the pseudo-hero characters of Battlefield 2042 are gone. All in all a much better direction for the series than I dared to hope for.

But in order to even start the game, EA's new Javelin anticheat requires that Secure Boot is enabled. Just like with TPM 2.0, this is something I've been vaguely aware of existing ever since I originally built this workstation in late 2019. But Arch Linux didn't support Secure Boot back then, so I left it disabled.

Fast forward a couple of years and the story has changed. Morten Linderud, one of the core Arch Linux developers, decided to improve Secure Boot user experience over the COVID-19 period and created a new tool called sbctl. With that, I was able to set up the Linux side of my dualboot to manage keys and signatures for the files that need to be signed before Secure Boot can be enabled from my UEFI settings. The tool enrolls my own keys alongside Microsoft's, so that I don't need to do anything for Windows ESP files.

This worked for a week, until I ran into a familiar issue once again: my ESP (EFI system partition) was running out of space. This happened very recently, but this time no matter how much compression I enabled I wasn't able to make mkinitcpio -- another tool maintained by Morten Linderud, by the way -- output something that would fit. (I had already removed all the extra early Nvidia modules from the config.)

So, what exactly does mkinitcpio even do? The name of the tool isn't very revealing, but the output files offer a better clue: initramfs-linux.img has the initial RAM filesystem required during booting the kernel and vmlinuz-linux refers to the compressed kernel image itself.

As luck would have it, there are alternatives to mkinitcpio that produce much smaller images by default. Arch Wiki mentions two by name: Dracut and Booster. I gave Booster a go, and was pleasantly surprised: on my machine, the image it creates only takes around 20MB (compared to 70+MB for mkinitcpio before the whole partition runs out of space).

Unfortunately, with the basic setup Booster doesn't work well with Secure Boot, probably because it's still rarely enabled for Arch Linux workstations. I'm glad I found another helper script, booster-um, which combines all of these tools into one and brings one major new one into the mix: systemd-ukify. Armed with this, we can create a single Unified Kernel Image that combines both the kernel and the initramfs into a single PE binary that can be directly executed by the firmware. That single file is then signed with sbctl. booster-um even helpfully cleans up all the now-obsolete leftovers from the /boot partition for you.

The only little snag I hit was that I had created a custom pacman hook for running mkinitcpio -P whenever kernel or Nvidia drivers updated. Of course, I needed to switch that invocation to booster-um -G after removing mkinitcpio entirely.

Again, all of this is necessary only because Windows 10 installation media as of late 2019 created an undersized default partition for EFI -- but I bet there are a ton of dualbooters like me who do not feel like completely reinstalling everything just to accommodate larger and larger kernel + initramfs images. I hope this offers some temporary relief to anyone in the same situation.

This small EFI partition size has repeatedly bitten Microsoft itself in the ass over the years. There was at least one Windows Update that failed to install on my machine due to lack of space on my EFI system partition. Everyone seems to recommend 500MB partition now, but it looks like 100MB might still be the default with Windows 11.