Before installing Fedora, I am going to decide the partition layout for my system. I am going to install Windows 11 first, then Fedora alongside it. But I am confused to allocate space for efi and boot. I used to allocate space for /boot (ext4), /boot/efi (fat32). When I installed arch and fedora with their default layouts, /boot was for both /boot and efi. Can I use Windows’ efi for Fedora and not create a partition for /boot? In this case /boot would be mounted to filesystem(btrfs)
You cannot format the ESP with Btrfs. It must be FAT32. That said, it is possible to mount the ESP at /boot (FAT32 format) and use it for all your boot loader and kernel content if it is large enough (1GiB+). But you would probably have to use systemd-boot to do that. I don’t think Grub supports that configuration. Windows does not create a sufficiently large ESP to be shared with other OSs by default. So you will likely have to create a separate partition for /boot. If you use the Grub boot loader, the extra partition has to be formatted with ext4. If you use systemd-boot the extra partition should be formatted with FAT32 (VFAT).
Some documentation about the possible and recommended configurations can be found here: Boot Loader Specification | UAPI Group Specifications
There recently have been discussions on this subject.
It appears quite possible to create the /boot/efi partition for ESP and have the content of /boot reside in the btrfs file system. One caveat there though – In that config it appears that the btrfs file system cannot be encrypted (It prevents booting). Apparently the encryption does not get unlocked until later in the boot process and the first stages of booting with bios are unable to manage that.
The method shown by @glb seems to avoid this blockage.
I did not mean that. I have a couple of options which I cannot choose which to use:
- /boot (ext4), /boot/efi (fat32), / (btrfs with @ and @home subvolumes)
- /boot (fat32) for boot and efi (like archlinux), / (btrfs the same as above)
- /efi (fat32, I found this somewhere), / (btrfs) for the rest
- Using Windows’ efi partition and / for the rest
Grub does, I am using like this in Arch with its defaul layout:
lsblk 0 [21:26:09]
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
zram0 254:0 0 7.1G 0 disk [SWAP]
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 1G 0 part /boot # FAT32, include grub and kernel files
├─nvme0n1p2 259:2 0 120.2G 0 part /var/log
│ /var/cache/pacman/pkg
│ /home
│ /
└─nvme0n1p3 259:3 0 117.2G 0 part
It creates 100mb, which is enough for fedora’s efi entry, however, If it’s filled with other systems’ files, I won’t be able to update my bios (HP)
So it is recommended to create an ext4 partition for /boot, right?
If there is a Windows EFI partition on the disk, you have to use it according to the spec. You are not allowed to have more than one EFI System Partition (ESP).
I think Fedora Linux has some downstream Grub patches that may complicate things. If you want it to work with Fedora’s Grub, you might have to stick with option 1.
2 Likes
Oh I see, okay, I am going to stick with my approach then. Just arch messed everything up. Okay, this is they way I installed Fedora.
1 Like
I’m pretty interested in following up on learning more about this. I’ve read the materials provided by Rod Smith, but I didn’t see where he mentioned this restriction.
Would you mind giving a link to the reference document where I can read up on it?
Thanks!
I just looked this up and it appears that my information may be incorrect (or at least outdated). Here is what I found:
Excerpted from uefi.org – Protocols Media Access – Number and Location of System Partitions:
13.3.3. Number and Location of System Partitions
UEFI does not impose a restriction on the number or location of System Partitions that can exist on a system. System Partitions are discovered when required by UEFI firmware by examining the partition GUID and verifying that the contents of the partition conform to the FAT file system as defined in File System Format. Further, UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes (see 5.3.3) which will exclude the partition as a potential ESP.Software installation may choose to create and locate an ESP on each target OS boot disk, or may choose to create a single ESP independent of the location of OS boot disks and OS partitions. It is outside of the scope of this specification to attempt to coordinate the specification of size and location of an ESP that can be shared by multiple OS or Diagnostics installations, or to manage potential namespace collisions in directory naming in a single (central) ESP.
Edit: Ah, the one ESP requirement is in the BLS spec:
Each partition type mentioned above can be present only once on the same disk.
So I guess it is BLS that further restricts the UEFI requirements.
2 Likes
There can be only one active ESP partition.
There can be many efi partitions as shown by the many users who multiboot with each OS having its own efi partiton, but only one of those may be used for booting. It seems that some simply use the bios boot menu to select which efi partition is used for booting.
As it is not always convenient to increase the size of the ESP after-the-fact, making it big enough in the first place is nice.
Are you using fwupd? It also uses the ESP and fw updates are possibly of good size. My laptop UEFI diagnostics also uses the ESP for saving logs.
My preference is to use the ESP for bootloader (grub, sdboot, uki, fwupd) and all the files the bootloader needs access to (combined /boot /boot/efi). Inside the kernel/initrd is the first place something other than the ESP gets accessed.
2 Likes
This is what I found in Arch linux too. So I can combine /boot (fat32) for both
The primary purpose of the ESP GUID is to find the partition which contains the default loader /BOOT/BOOTX64.EFI. That is how the system can boot from removable devices.
By closely reading the uefi specs it seems like it is up to the implementation to define what works and what doesn’t work. One ESP marked by the ESP GUID always works (supposedly). Loading an .efi file from another vfat file system without the ESP GUID may work, perhaps. Some implementation may also allow loading .efi files from for example ntfs, and with extra UEFI driver modules installed it could also load .efi files from ext4. If you are not confused yet, you should be.
1 Like
You usually don’t select the efi partition to boot, but rather the boot loader, such as the shim+grub for linux boot or the windows boot loader for booting windows. Usually you can also select a disk unit to boot from, in which case it looks for a partition marked with the ESP GUID and loads the file /EFI/BOOT/BOOTX64.EFI in that file system
There is an option to select a partition with the efibootmgr command for creating boot entries in the UEFI native bootloader, so I could see how this might make non-default EFI type GUIDs more accessible?