This is a more generic Linux question. As I have an EFI motherboard with Secure Boot I need an ESP partition: I have one mounted as /boot/efi and it works fine on this installation. But I was wondering; Is there any disadvantage to making the entirety of /boot my ESP? That way I can make better use of the 4GB I assign to it, having it store grub and the kernel images too… they’re all loaded temporarily as part of the boot process so it makes sense to use this one little partition for everything! As long as it’s fat32 there shouldn’t be anything breaking the configuration right? Especially on a machine where I don’t plan to dual-boot, only one OS installed on the main drive so there would be no kernel image conflicts.
Just in case though I wanted to ask for opinions: Does anyone else place the entirety of /boot on the EFI partition instead of just /boot/efi? Does it work well for you, do you find it more optimal this way? As a bonus question; Is exfat (fat64) a newer and better partition format to use, or is it still a good idea to stick to fat32 exclusively for the ESP else the BIOS might complain?
This thread on the Arch forum seems so suggest it works both ways: There should be no clear breakage so it’s a matter of preference. I think I’ll test this partitioning setup in VirtualBox, the latest version lets me emulate an EFI system where the ESP is used so I can simulate how the configuration behaves.
To be on the safe side, I try to follow the EFI specification as closely as possible:
One EFI System Partition (“esp”) per GPT drive (labeled as “esp” using parted, GParted, KDE Partition Manager, etc)
This “esp” formatted as FAT32 for internal drive or FAT12/16/32 for external media
Keeping the “esp” separate from invidual OS system/boot/root partitions
I avoid going outside of that scope, and it has worked consisently for me on multiple computers, regardless of dual-booting. I tend to err towards 512MB for this partition, though honestly even 256MB is plenty of room. (Plenty of room since I don’t install my /boot files within, but rather use a separate partition for /boot.) You can even get by with 128MB, even when dual-booting with Windows.
‘*’ The unique GUID for the “esp” on a GPT formatted disk is always: C12A7328-F81F-11D2-BA4B-00A0C93EC93B
Thanks. I plan to stick within those specifications… less for keeping the esp separate from /boot if I were to go this route: Formatting as FAT32, only having one such partition per drive, even placing it at the beginning (sda1). From what I understand, as long as the contents of /boot/efi are accessible to the firmware after powering on, it doesn’t care if you also store grub and your kernels there.
The only notable issue someone brought up is that the FAT filesystem doesn’t allow symlinks; On openSUSE this may be a problem as the latest kernel is symlinked. Manjaro doesn’t appear to do this by comparison: I didn’t find any symbolic links within /boot so it should be good.
I would reconsider this approach, only because FAT32 does not use a journal nor have robust resiliency as do other file-systems such as XFS, EXT4, or BTRFS. If something were to happen during a system update (such as loss of power), you risk breaking your entire Linux system due to corrupted files in your boot directory. Consider that many updates to Manjaro regularly involve kernel, initram, and grub updates. Unlike changes to the EFI system partition, changes to your boot directory happen on a routine basis.
Take this warning for what it’s worth. It’s your system at the end of the day, but I feel better sharing caveats.
That’s a good observation, however I would add to it: If loss of power occurs while a kernel is being installed and grub is getting rebuilt, you’re in trouble regardless and will have to fix your boot loader via rescue session from the installation medium.
I already experienced write errors during power failure or hard lockup with ext4: While an affected file doesn’t become corrupted, it does end up erased and turned into a 0 byte entry. I believe you need to use the command “sync” after writing a change to your drive, otherwise if the machine shuts down without warning any file updated during the last few seconds may end up gone.
I assume with FAT the file may get saved as corrupted; Between a corrupt file and a 0 byte one, there isn’t much improvement in my opinion. I wonder if BTRFS / XFS / ZFS handle this better.
BTRFS and ZFS are both “Copy-on-Write” (CoW) file-systems, so it’s nearly impossible to leave it in a corrupted state. In fact, ZFS has no true file-system checker, since it’s not needed (nor would make any sense. The closest thing being a routine “scrub” that can mitigate and repair corruption from a failing drive by comparing it to a healthy drive within the same vdev / pool. Scrubs cannot repair corruption on a single-drive or striped vdev.)
But that’s outside the scope of EFI and bootloaders, as you noted the real concern is the existence of the files within the boot directory. Even if your file-system is “clean”, having only a half of the files present will break the bootup process.
Out of curiosity, how come you want a large 4GB FAT32 partition for the esp? Why not a smaller esp (around 128MB), where the remainder of the 4GB can be used towards your root file-system?
Since you asked for feedback and experiences, I will share this:
I’ve had the best results and performances using XFS. Better than EXT4 and BTRFS. From now on (until ZFS becomes a safe and feasible default in future distros and editions) I’m using XFS for my boot, root, and home partitions (or all of them together in a single partition), whether or not I’m using LUKS.
I just find XFS to be better overall in nearly every aspect compared to the other common file-systems used on Linux desktops. XFS seems to work the best with SSD + weekly trims. The only benefit I found from BTRFS was it’s snapshotting feature. However, I use ZFS (and snapshots) on a NAS server, so I needn’t any of BTRFS’s features, personally.
xfs and ext4 seem to be on par, both are said to be very good: With ext4 being the most common and tested, I’m fine sticking to it for all my partitions. I tried btrfs for my openSUSE install at some point and it ended up in disaster, had to do a full reinstall because the system ended up corrupted after reboot.
Speaking of the EFI partition there’s something else I must ask, in case I choose to keep it separate still: What must I do to hide it from the OS? At least in VirtualBox the /boot/efi partition is still mounted and shows up in Dolphin, it’s an annoyance I’d like to get rid of. I assume I need to enable another flag (alongside boot) when creating the ESP in the installer? I remember trying the hidden flag with no result.
For SSD / NVMe? Not quite. XFS easily outperforms all the others. (I don’t consider F2FS since it’s not officially supported nor feasible on desktop Linux.)
XFS is also very mature and stable, and it is now the default file-system for RedHat Enterprise Linux.
My real-world experiences with SSD reflect those benchmarks and results. Just thought I would share.
You can comment out the entry in your /etc/fstab and then reboot. Most Linux distros add an entry to the fstab to mount your esp under /boot/efi.
UPDATE: If you try to do anything EFI-related on your live system, it’s going to abort with errors since your esp is unavailable. Remember to mount it to /boot/efi or /efi before you proceed to run any commands that require access to the esp.
You don’t need to touch or change any flags, since the installer will take care of that for you. The only flag that needs to be explicitly set is the “esp” flag for your EFI System Partition, if your distro’s installer doesn’t do it automatically. Normally, an installer asks you “Which partition is your EFI System Partition?” Different distros and systems might use a fancier name to indicate this flag, but “esp” is the clearest and easiest one to use in casual speech.
UPDATE: Upon re-reading your post, it just goes to show you how loosely these technical terms are used between communities, OSes, and even desktop environments. In your case, when you say “boot” flag, you may in fact be referring to the same thing when I say “esp” flag. I just realized KDE Partition Manager also refers to it as “boot”.
Just thought I would share.
In your case, when you say “boot” flag, you may in fact be referring to the same thing when I say “esp” flag. I just realized KDE Partition Manager also refers to it as “boot”.