EFI-System Partition, GRUB2 Configuration and Software RAID 1
It’s a bit difficult to find an easy to understand explanation of what /boot/ and /boot/efi/ actually are.
I’ve found some possible answers through testing and googling but would be very happy if someone with experience could challenge or confirm my findings / way of thinking.
Context:
- Compatibility Support Module (CSM) in the motherboard is turned OFF
- Fast Boot and Secure Boot in the motherboard are both turned OFF
- Operating System is Ubuntu Server 22.04
- Setup uses two disks with identical capacity (for RAID 1)
- Both disks are in GPT format and on both disks the EFI-System Partition is partition number
1with size512MB(and type1of course). /is a software RAID 1 created withmdadm.- More broadly: I’m doing some testing to better understand how software RAID works and how I can deal with possible RAID "errors" (e.g. swapping a faulty disk, booting from only one of the disks etc.) in the future.
My findings (based on the context above) / Questions
1.) Observation: /boot is not the EFI-System Partition. I.e. it does not contain the bootloader.
However, it contains the GRUB configuration files (/boot/grub/ in my case).
I tested this by installing the bootloader (with the ubuntu server installer) on both disks, then made a change to the grub configuration file (/etc/default/grub, added intel_iommu=on as a "dummy" flag then ran update-grub), shut down the server and physically removed the drive whose EFI partition was mounted when I did the change). Server booted but got stuck in ”emergency” mode because the OS couldn’t find the drive with the EFI-Partition that was specified in /etc/fstab (the ubuntu server installer added the mount point with the UUID of the drive I removed).
However cat /proc/cmdline did show that intel_iommu=on was specified.
This leads me to believe that the grub configuration isn’t stored on the EFI-Partition and is part of the software RAID I created when I installed the system.
2.) Observation: /boot/efi is a mount point of the EFI-System Partition which in turn gives access to the installed bootloader.
At least one of the drives needs to have a bootloader installed (on the EFI-System Partition that is mounted here), otherwise the system will not boot.
Bootloader (GRUB) can be re-installed by running grub-install /dev/sd{x}.
3.) [If 1. and 2. are indeed true], question: Is it necessary for the Ubuntu OS to mount the EFI-System Partition in order to function?
Could I omit the mount instruction inside of /etc/fstab?
This is just a question out of curiosity.
Yes, you could omit mounting /boot/efi, but…
You could comment out the /etc/fstab line for the EFI System Partition, and the system would still boot just fine.
But unless you made other modifications, any updates to the actual bootloader (not just its configuration) would then fail. In other words, apt update grub-* would result in an error as soon as an applicable update is released. Running grub-install to reinstall GRUB would also fail unless extra steps are taken first.
The /boot/efi is not actually mounted for the purpose of booting the operating system: by the time the Linux kernel starts running, the EFI System Partition has already completed its part in the boot process. Instead, the primary purpose of mounting it is to make the bootloader accessible for updates. A secondary purpose might be to make it easily accessible to system administrators, to demystify the ESP, and to allow the ESP to be backed up just like a regular filesystem.
I think some distribution (Gentoo perhaps?) made the choice of only mounting the EFI System Partition only when the bootloader or its configuration is actually being updated, similar to how Microsoft Windows handled it. However, most major distributions chose to mount the ESP just like a regular filesystem.
(Your observations #1 and #2 are entirely correct and contained no apparent questions; only your point #3 contained an actual question, and so that’s what I answered.)
boot partition is for most uses obsolete. It is needed for minimalistic bootloaders like lilo, which don’t know about advanced concepts like crypto, LVM, various file systems and RAIDs. So the solution was to put kernel and initrd to some simple partition which can be understood by lilo, and let the script in the initrd to do complex initialization of the main storage in Linux environment. It is not needed for most current setup with grub, because grub is much smarter, however, the tradition remains.
Then ESP appeared, which basically has the same motivation: to have a simple firmware which doesn’t care about advanced features of different OS and is independent from them. To implement that it requires you to have a simple partition of a standardized structure, which has everything that is needed to boot an OS. ESP can be thought as a modern OS-independent boot partition.
So, for instance, you can have ESP and no dedicated boot. Put the kernel, initramfs and the bootloader to it (so it will be a "combined boot and ESP"), or have a kernel image with built-in EFI stub and initramfs, in which case you only need to put a single file on the ESP (and no dedicated bootloader at all). I have such setup on my laptop for a long time.
There is a caveat: ESP can not be a part of a OS-provided software RAID. UEFI spec has no mentions of software RAID. This can be thought as a consequence of previous paragraph, but lilo, which is even simpler, was able to deal with it; Linux’s RAID1 metadata has a superblock near the end of the device so for lilo a RAID1 boot partition looked like just having a file system slightly smaller that the device, and nothing prevented to require UEFI firmware to behave the same way in the spec. Microsoft failed to create RAID1 with that simple structure (ha, try to create their "software RAID" and you’ll understand what I mean), so more likely they simply omitted the software RAID from the spec entirely.
Common way to have redundant boot with software RAID1 is to have two independent ESPs on two different disks, to sync them manually, and to have two firmware boot records (to be able to boot from each). The example of such setup is Proxmox VE installed onto ZFS software RAID; in that case it uses systemd-boot EFI bootloader (i.e. not grub) and has a hook script which syncs ESPs whenever some boot-related stuff is updated. This is the only automated installer I know of who creates two ESPs and the only distro that takes care of synching; in all other cases you have to do manual partitioning and to do it yourself when you are going to rely on software RAID. Notice that these ESPs better not be images of each other so their FAT UUIDs will differ; I mount them both and copy files. The updates to the ESP are very rare.