Wow. Stick to that and your choice will be very limited. And pretty soon none: no Windows, no linux ( maybe some crippled niche on-man-show ), so DOS.
True, Neil. But, I have seen enough situations where that did not result in the same stablity / performance, to always get the base ( the hardware setup and FSes ) in a reliable and maintainable state.
1 Like
Which commonly is not so OK for those, as is OP, who are multibooters. Many threads have reported multibooters having to do a lot of rework to re-enable booting their other installations because of that TW default, when all that work could have been avoided if they bothered to learn of that default and what it implicates, or how easy it is to avoid it happening by following the installation instructions they didn’t read.
You left out the part of the sentence why I wrote it:
1GB is big enough for some .efi binaries and also for a bunch of copies from rootfs to bootfs in case of systemd-boot. I know systemd-boot is not advised for multiboot, I certainly use GRUB as it does all the work putting text in grub.cfg and does not copy kernel+initrd from a native Linux filesystem like Btrfs to a FAT.
I have ESP’s of just 40MiB, smaller than 32 seemed potential problems with FAT type 12 or 16 I forgot.
Another note maybe is that for in-place/live/running conversion from MBR to GPT system, it is OK to have slightly less than 1MiB (sectors 34-2047). I am not sure where the 2MiB size is based upon. Usually alignment is 2048 sectors, so when rootfs partition starts there, changing default alignment to just 1 sector in gdisk, one can create that 0xEF02 type partition.
Might be that last sector of rootfs partition overlaps 2nd/backup GPT space, but if Btrfs as rootfs, one can live shrink it a bit first.
The stories about 40MB EFIs are nice but outdated. The minimum recommendation here in the forum (based on the experience from users and from the actual developement towards systemd-boot [and somewhat grub2-bls]) is at least 1GB. This is also honored by the installer. Experienced users like @malcolmlewis and others recommend 2-4GB.
We have a lot of threads here in the forum which points out the to small ESP/EFI partitions, coming from grown systems. The 100MB times are long, long gone. Do not save on the EFI partition size (makes no sense on TB drives btw) as it is a lot of trouble on many systems to grow the size later on.
Some system manufactures also uses the EFI directory for updating UEFI BIOS and other stuff. This can also take up several space. On one of my HP boxes, alone 60MB of UEFI Bios update stuff is saved there. So please do not only take the required space from the OS into account but also important stuff like space for updating of system firmware and BIOS.
1 Like
Just a quick summary of a few systems I have…
Tumbleweed - HP Z440
grub2-efi
lsblk -f /dev/nvme0n1p1
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1p1 vfat FAT32 ESP 44D1-83D0 4G 0% /boot/efi
du -sh /boot/efi/
7.4M /boot/efi/
Tumbleweed - Dell Precision 5820 Tower
systemd-boot
lsblk -f /dev/sda1
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda1 vfat FAT32 ESP 4FEA-283B 3.3G 16% /boot/efi
du -sh /boot/efi/
659M /boot/efi/
Tumbleweed - Dell OptiPlex 3080 Micro
systemd-boot
lsblk -f /dev/nvme0n1p1
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1p1 vfat FAT32 6767-0208 894.4M 12% /boot/efi
du -sh /boot/efi/
128M /boot/efi/
Leap 16.0 and Windows 11 Pro - Dell OptiPlex XE3
grub2-efi
lsblk -f /dev/nvme0n1p1
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1p1 vfat FAT32 ESP 86C1-B552 3.9G 2% /boot/efi
Tumbleweed and MacOS Monteray - MacBook Pro (Retina, 15-inch, Mid 2012/Early 2013)
systemd-boot and separate OpenCore ESP for MacOS
fdisk -l
Disk /dev/sda: 465.92 GiB, 500277790720 bytes, 977105060 sectors
Disk model: APPLE SSD SM512E
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 000072F2-2709-0000-0D73-0000571D0000
Device Start End Sectors Size Type
/dev/sda1 40 409639 409600 200M EFI System
/dev/sda2 409640 586347135 585937496 279.4G Apple APFS
/dev/sda3 586347136 594735743 8388608 4G EFI System
/dev/sda4 594735744 977105023 382369280 182.3G Linux filesystem
du -sh /boot/efi
337M /boot/efi
As indicated, the Dell and HP systems do use it for firmware updates, likewise BIOS tools etc.
1GB should be enough, 2GB would be my minimum, just to future proof as things change going forward. I just use 4GB these days when preparing a GPT disk (even 128GB ones).
Could you please read https://en.opensuse.org/Code_of_Conduct ?
If I had to use one ESP per PC, I can’t imagine a 4G ESP coming remotely close to adequate to task.
OTOH, of the ESPs here, out of 13 total exclusive of backups, those that both I created and are in routine use as ESPs are 8x320G & 1x368G. Freespace on them is typically at least 85%, even though installed kernel count per installation averages more than 6. The other 4 I created, but are not in use, and are 2x320G, 1x260G and 1x200G. I expect to be dead before any in use are outgrown. I’m not trusting FAT filesystems to host my initrds and kernels as long as I have a choice not to. TBC, all PCs here are multibooters, so hundreds of installed kernels are on each on average.
Not only is FAT generally an issue for/to me, but 98% or more of my boots are via custom stanzas that refer to kernel and initrd symlinks, no dots, occasionally one dash, and not often any numbers. AFAIK, FAT doesn’t support symlinks, and is unlikely ever to.
I’m not sure what you are asking there.
I sometimes use that small space (sectors 34-2047) for a BIOS boot partition, used with legacy MBR booting.