Strange default boot.loader.efi.efiSysMountPoint = "/boot"

Help
1

Hello,

I noticed that the default value for boot.loader.efi.efiSysMountPoint is /boot and not /boot/efi as I would assume as sensible default. Is there a reason for that? Am I missing something?

I recently started using NixOS on a physical machine (so far I tested only on a VM) and I set the following config to make it to boot:

boot.loader.grub.enable = true;
boot.loader.grub.device = "nodev";
boot.loader.grub.efiSupport = true;
boot.loader.grub.efiInstallAsRemovable = false;
boot.loader.efi.efiSysMountPoint = "/boot/efi";
boot.loader.efi.canTouchEfiVariables = true;

Thank you.

Mark

2 Likes
2

/boot is a sensible default, as then your EFI stuff lives in /boot/EFI, if though you change it to /boot/efi, it gets moved to /boot/efi/EFI.

And for some reason, the Calamares based installation indeed uses /boot/efi IIRC.

1 Like
3

/boot/efi is a common choice for the vfat ESP filesystem, when /boot is some other filesystem — typically ext4 or zfs. This was perhaps more common when BIOS or hybrid bootloaders were still a consideration, either as a fallback or because the partitioning was already set up.

I’ve only just started moving my systems from a zfs bpool and tiny ESP, to all of that space as ESP on /boot, as a first step toward using secure boot at last!

1 Like
4

This might be an interesting related read:

5

Thank you folks! I’m definitely missing something since this doesn’t make sense to me ;-).

EFI partition has to be vfat (aka FAT32). My understanding is that all UEFI firmwares expect FAT formatted partition with *.efi files since they can’t read ext4 / btrfs / zfs …

Good point but I can’t mount both vfat and (in my case) btrfs to a single path and expect to access files from both mountpoints. My setup is vfat (esp) btrfs (/boot) and LUKS with btrfs inside (root).

I’ll check that. Thank you.

6

except if you have a filesystem driver for it, which do exist and systemd-boot supports them.

7

Ouuhhh! That’s awesome. I had no idea. That probably also means you can give it LUKS+btrfs or ZFS+encryption driver.

Really compelling reason to use systemd-boot. Now it all make sense. Thank you.

8

That’s what I was going to link :stuck_out_tongue: TL;DR: It’s weird that people separate /boot and /boot/efi into different partitions. Just having /boot is not only acceptable, it’s preferable since it’s just as good and it reduces the problem space. The main reason to separate /boot and /boot/efi would be because your ESP is tiny, like the one Windows creates by default.

9

See efifs: GitHub - pbatard/efifs: EFI FileSystem drivers

It takes the file system code from Grub and transforms it into EFI drivers, so you could in theory convince UEFI to boot off something as exotic as ZFS using that. LUKS would probably be a major challenge since it requires user input to unlock, but I suppose the tools are there to make it possible.

10

Though I don’t advise using ZFS with systemd-boot because ZFS does not implement certain ioctl to get parts of the filesystem, which BTRFS implements for similar style FS.

11

I’m not sure this really changes the situation? The EFI firmware would still need a place to load this driver from, presumably?

So you’d still wind up with a small FAT ESP, and a separate other-fs boot, just like with grub. In the cases of NTFS or ext4 that might be the same fs as root, in zfs that would be desirable too but the grub driver has limited support for advanced pool features, so a separate boot pool is still typical.

12

That’s a good point. Can somebody please explain how does firmware load btrfs (or other) driver from btrfs formatted /boot partition?

13

I have not read the spec myself, though from prior discussion I am remembering that the spec itself doesn’t mandate a specific filesystem support, but FAT basically became kind of industry standard because of how simple it is to implement and probably some “sponsoring” by microsoft, or them mandating it or another MS-FS. Especially the latter is just a wild guess though.

In theory any firmware implementor could support other or additional filesystems to discover the EFI-executables/bootloader from.

Though:

  1. Implemnting any FS in addition to FAT would require them to have a “bigger” chip to burn the firmware on, which would increase cost, for no to little use targetting a very small group of powerusers.
  2. Implementing other FS, without FAT would limit the market reach to that small group of power users.

Both options are probably not sustainable outside of niche-markets we do not have regular access to.

14

Could you plz provide more details?

15
1 Like