Add a blog post about decluttering NixOS EFI system partition.

posts/2025/11/08/declutter-nixos-efi-system-partition/index.org

@@ -0,0 +1,94 @@
+#+OPTIONS: html-postamble:nil
+#+title: Declutter NixOS EFI System Partition
+#+date: <2025-11-08 Sat>
+#+author: Tom Alexander
+#+email:
+#+language: en
+#+select_tags: export
+#+exclude_tags: noexport
+
+What does the EFI system partition look like on a NixOS system look like?
+
+#+begin_src text
+  /boot
+  ├── EFI
+  │   ├── BOOT
+  │   │   └── BOOTX64.EFI
+  │   ├── memtest86
+  │   │   └── memtest.efi
+  │   ├── nixos
+  │   │   ├── 0p4jsn66rw6gm6rc2wnzpmzhd5aldpab-initrd-linux-6.16.12-initrd.efi
+  │   │   └── 7zhgbsmhsch25y51ry39di8s7d5aa3b1-linux-6.16.12-bzImage.efi
+  │   └── systemd
+  │       └── systemd-bootx64.efi
+  └── loader
+      ├── entries
+      │   ├── memtest86.conf
+      │   ├── nixos-generation-1.conf
+      │   └── nixos-generation-2.conf
+      ├── entries.srel
+      ├── keys
+      ├── loader.conf
+      └── random-seed
+#+end_src
+
+Or maybe [[https://github.com/nix-community/lanzaboote][you care about security]], in which case your EFI system partition might look like:
+
+#+begin_src text
+  /boot
+  └── EFI
+      ├── BOOT
+      │   └── BOOTX64.EFI
+      ├── Linux
+      │   ├── nixos-generation-819-4rahvvcu2fvsjfwgnfzu4hp5sm6pjir7ivy65unygrzlmnt2wmfa.efi
+      │   ├── nixos-generation-820-hfu7owhqplrumyvkudyxuiem6ocrgb5z7ujqncl6aoemj4ekktkq.efi
+      │   └── nixos-generation-821-g2l3xmw6w5c26n3ixl53jejzslttdmvs3wajnb7aittwsfttwypq.efi
+      └── systemd
+          └── systemd-bootx64.efi
+#+end_src
+
+Regardless, they both have the same problem: they are storing information that is specific to my system and necessary for booting in the EFI system partition.
+
+What does *my* NixOS EFI system partition look like?
+
+#+begin_src text
+  /efi
+  └── EFI
+      └── BOOT
+          └── BOOTX64.EFI
+#+end_src
+
+That src_text[:exports code]{BOOTX64.EFI} contains no information specific to my system. It does not change when I make new generations of my system config. If I ever lost it, I could copy it off another one of my machines or build it again from publicly-available sources.
+
+* Why
+
+** Backups
+
+One of the best features of ZFS is [[https://klarasystems.com/articles/introduction-to-zfs-replication/][ZFS send/recv]]. But with the old way of booting, I couldn't simply use ZFS send/recv to make a functional backup of my system: I also needed the information in the EFI system partition. Now, all of the information about my system is stored on ZFS, so I can use ZFS send/recv to make full, functional backups.
+
+** Dual Booting
+
+I like to boot multiple different systems off the same ZFS pool. For example, you might want to have a NixOS system for productive work encrypted with one password, and another NixOS system encrypted with a different password for running video games to keep your data safe from the closed-source +spyware+ anti-cheat bundled in games. I wouldn't want the two NixOS systems overwriting each other's entries in the shared EFI system partition. Since 100% of the data about my system is stored on ZFS, I can have as many separate NixOS systems as I want, all on the same ZFS pool, without fighting each other. On top of that, I can also seamless boot other Linux distros, also sharing the same pool.
+
+** Not filling up the EFI system partition
+
+This is an issue many new NixOS users encounter. They get their system configuration written, and start happily using their system, until [[https://discourse.nixos.org/t/what-to-do-with-a-full-boot-partition/2049][one day it suddenly breaks]]. Avoiding the problem is easy (if you know to do it) through limiting the number of generations that are kept, but recovering from it after it breaks is less fun.
+
+With my system, I can store as many generations as I want, since all of my kernels and ramdisks are stored on my main ZFS partition instead of my EFI system partition.
+
+* What this is not
+
+** More secure
+
+If you set up your NixOS system with [[https://github.com/nix-community/lanzaboote][Lanzaboote]], your EFI system partition files are cryptographically signed so they cannot be modified without your consent. While your kernel and init ramdisk won't be encrypted (and therefore won't be private), those two files seldom contain any private information. I do not think my new method of booting NixOS is any more private or secure than Lanzaboote.
+
+* How
+
+* Why aren't you upstreaming this?
+
+I would love for this functionality to make it into upstream ZFSBootMenu. The reasons I am not sending this patch upstream are:
+
+1. I am not confident in the quality of my changes. ZFSBootMenu is implemented in bash. Bash doesn't have data structures, so structured data is passed around by writing tabular data to files in the tmpfs filesystem. Bash likes to keep running, even after encountering errors, unless you use [[http://redsymbol.net/articles/unofficial-bash-strict-mode/][Unofficial Bash Strict Mode]] (which ZFSBootMenu did not). Returning data from functions is handled by writing to stdout. Variables are global by default. Some impressive scripters have demonstrably been able to create large complex projects with shell scripting (for example, ZFSBootMenu or poudriere) but my bash skills are not at their level, and I have no interest in reaching that level in bash.
+2. My extlinux.conf parsing code is incredibly crude, largely because I am parsing it in bash.
+3. I haven't tested my changes on the vast combinations of ZFSBootMenu environments. ZFSBootMenu can be run via bios or UEFI. It can be run as a kernel+ramdisk or as an EFI executable. It can be built with mkinitcpio or dracut. It can boot a multitude of Linux distros. All I know is this works on my system.
+4. I don't know if the ZFSBootMenu maintainers are interested in maintaining this code. They already have so many environments to test, I can see them not wanting to add another to the pile, especially for something less mainstream like NixOS. My boot code currently only has 1 user, so it is hard to make an argument for the value of this code.