How big do you make your uEFI and /boot partitions?

uOpt

[H]ard|Gawd
Joined
Mar 29, 2006
Messages
1,964
How big do you make your uEFI and /boot partitions?

And/or how much of your space is in use?

About to set up a long term usage install, don't want to run out of space later.
 
Whatever the defaults are is probably fine. Neither requires much space, really.

This is from my Ubuntu laptop that was first installed ~4.5 years ago. I went over the defaults because I thought I might need the extra space for multi-boot/etc. setups that never materialized:
Code:
$ df -hl -x tmpfs -x efivarfs
Filesystem               Size  Used Avail Use% Mounted on
/dev/nvme0n1p1          1022M   45M  978M   5% /boot/efi
/dev/mapper/boot_crypt   3.9G  267M  3.4G   8% /boot
/dev/mapper/sys_vg-root   98G   30G   63G  33% /
/dev/mapper/sys_vg-home  295G  275G  4.9G  99% /home
(Looks like I really need to clean up my /home.)
 
Yeah, I'll probably go with 200 M EFI and 2 G /boot.

I sometimes run big custom kernels and install multiple native kernels.
 
Best for long term as previously stated is to let windows choose the size of your main OS drive partitions. A fast 1TB drive is more than enough.
Buy separate drives fast as you can afford 2 to 4 TB.
After Windows Install move User, Desktop, Documents, Pictures, Video, and Download folders to a separate drive.
Create Program Files folder on the separate drive and Install all your programs/Games there.
Very easy to do by clicking on the properties of those folders and point to the separate drive and desired folder.
I can think of a few reason this makes good sense.
1) You can format and reload windows as needed when you need a fresh start and loose nothing.
2) Backup of your data files is straight forward without having to pick and choose.
3) Images of your Main OS drive typically are lost or retain the issues you are trying to get rid of when you try to restore them. Especially if you have only one drive to begin with.
4) No need for partitions or to be concerned about them the only separation you need is OS drive and Data Drive you could even add another drive like a external My Book drive to back up your data drive for redundancy.
5) Keeping OS Drive 1/2 full results in best performance for that drive. Cramming it full has the opposite effect
 
I prefer BIOS boot, which means a 512 kb freebsd boot partition (which is where the real boot loader lives), whatever swap (I like to have at least 512 mb of swap on a modern system with memory measured in gigabytes) and then the root partition. For UEFI boot, seems like 200 MB is recommended for the efi partition, but I've got < 1 mb actually used. I've never been a big fan of having a lot of separate partitions, just a root partition is usually simplest; and if your boot loader can't load your kernel off your root partition, maybe get a different boot loader? Or give in and setup a separate boot filesystem, I guess; I was never a fan of initramfs on Linux either... seems a lot more complicated than making a kernel that understands your root filesystem.
 
I prefer BIOS boot, which means a 512 kb freebsd boot partition (which is where the real boot loader lives), whatever swap (I like to have at least 512 mb of swap on a modern system with memory measured in gigabytes) and then the root partition. For UEFI boot, seems like 200 MB is recommended for the efi partition, but I've got < 1 mb actually used. I've never been a big fan of having a lot of separate partitions, just a root partition is usually simplest; and if your boot loader can't load your kernel off your root partition, maybe get a different boot loader? Or give in and setup a separate boot filesystem, I guess; I was never a fan of initramfs on Linux either... seems a lot more complicated than making a kernel that understands your root filesystem.

A separate /boot partition is necessary in certain scenarios, such as the encrypted setup I have and outlined above. Separating out /home makes it much simpler to blow away root and do a fresh install if needed/desired. But yeah, the old guides that recommended partitioning out /var and the like should be discarded for all but the most specific of installs.

And it's 2024. BIOS boot is old and if not already so is on the verge of being deprecated in most distros.


Best for long term as previously stated is to let windows choose the size of your main OS drive partitions. A fast 1TB drive is more than enough.
Buy separate drives fast as you can afford 2 to 4 TB.
After Windows Install move User, Desktop, Documents, Pictures, Video, and Download folders to a separate drive.
Create Program Files folder on the separate drive and Install all your programs/Games there.
Very easy to do by clicking on the properties of those folders and point to the separate drive and desired folder.
I can think of a few reason this makes good sense.
1) You can format and reload windows as needed when you need a fresh start and loose nothing.
2) Backup of your data files is straight forward without having to pick and choose.
3) Images of your Main OS drive typically are lost or retain the issues you are trying to get rid of when you try to restore them. Especially if you have only one drive to begin with.
4) No need for partitions or to be concerned about them the only separation you need is OS drive and Data Drive you could even add another drive like a external My Book drive to back up your data drive for redundancy.
5) Keeping OS Drive 1/2 full results in best performance for that drive. Cramming it full has the opposite effect

Uhhhhhh, sure. Were it not for your post count I'd think this was a bot response. It doesn't really apply here.
 
Has it show in the second post:
/dev/nvme0n1p1 1022M 45M 978M 5% /boot/efi

It is really generous by default expecting a dual boot scenario or something complicated to not create an issue (or update in the futures), if for some reason (like this is some embedded machine with very limited resource) and known in advance exactly what will be installed on it (or will do a fresh setup) you can save good amount of a very small disk space.
 
I prefer BIOS boot, which means a 512 kb freebsd boot partition (which is where the real boot loader lives), whatever swap (I like to have at least 512 mb of swap on a modern system with memory measured in gigabytes) and then the root partition. For UEFI boot, seems like 200 MB is recommended for the efi partition, but I've got < 1 mb actually used. I've never been a big fan of having a lot of separate partitions, just a root partition is usually simplest; and if your boot loader can't load your kernel off your root partition, maybe get a different boot loader? Or give in and setup a separate boot filesystem, I guess; I was never a fan of initramfs on Linux either... seems a lot more complicated than making a kernel that understands your root filesystem.

The target machine is a laptop that doesn't do BIOS boot, unfortunately.

As for partitions, yes I need a separate /boot because of encryption. And more partitions come in because of FreeBSD, although this particular laptop is intended mainly for Linux. There will be a big ZFS partition that carries bulk data for both Linux and FreeBSD.

I also need a swap partition >= RAM for Linux kernel-bases suspend-to-disk.

I think that's about it for partitions :)
 
I use a 4GB FAT32 partition for EFI. That's because I use systemd-boot for my boot manager which requires boot files on that partition. I'm currently at 1.01GB used. You don't want to run out of space on the EFI partition though because it's a pain to fix later. If you're not running multiple distros then you don't need much space at all.
 
I use a 4GB FAT32 partition for EFI. That's because I use systemd-boot for my boot manager which requires boot files on that partition. I'm currently at 1.01GB used. You don't want to run out of space on the EFI partition though because it's a pain to fix later. If you're not running multiple distros then you don't need much space at all.

How does systemd-boot help with running multiples distros? Can it boot FreeBSD?
 
How does systemd-boot help with running multiples distros? Can it boot FreeBSD?
I haven't tried. It can boot Windows or any Linux distro. I suspect there will be an issue with a ZFS partition for boot so you'd have to chainload whatever FreeBSD sets up.

For multiple distros, systemd-boot works with loader entry files which are very simple text files. This is an example of one that I had for LMDE using BTRFS subvolumes.
title LMDE-TEST
sort-key LMDE-TEST
options root=UUID=aedb0fc0-bd70-471a-82f5-f7c9a498592b rootflags=subvol=@LMDE rw
linux /LMDE/vmlinuz
initrd /LMDE/initrd.img

The LMDE directory would be on your EFI partition for the two boot files. Each distro has it's own entry file which gets compiled into a menu of options on boot.
 
  • Like
Reactions: uOpt
like this
Uhhhhhh, sure. Were it not for your post count I'd think this was a bot response. It doesn't really apply here.
I do not disagree with what you and others have recommended here. My point is no matter the current or future best practices be prepared to make changes minimizing consequences. I guess it depends on what your definition of "long term usage install" means. Certainly my response speaks to that. In regards to my post count I tend to refrain from the superfluous. If things don't need to be said....
 
Aren't all EFI partitions FAT32?

It's not strictly required. Apple has efi (not uefi, last I checked) partitions, I think... What do they use? But everybody else probably uses fat, because it's universal.
 
It's not strictly required. Apple has efi (not uefi, last I checked) partitions, I think... What do they use? But everybody else probably uses fat, because it's universal.

With the exception of Apple (who are always the exception), UEFI requires the EFI partition to be FAT32.
 
With the exception of Apple (who are always the exception), UEFI requires the EFI partition to be FAT32.

Eh, the spec requires the firmware to work with fat32 (and maybe fat 12 and 16), but an in-spec firmware could read another filesystem if it really wanted to.
 
Eh, the spec requires the firmware to work with fat32 (and maybe fat 12 and 16), but an in-spec firmware could read another filesystem if it really wanted to.

Except there would be little to no point in doing so. FAT32 is the standard for EFI partitions under UEFI, and it works. Changing file systems won't make it work any better.
 
Except there would be little to no point in doing so. FAT32 is the standard for EFI partitions under UEFI, and it works. Changing file systems won't make it work any better.

Once kernel bloat gets the size above 2 GB the systemd-boot people will need that :)
 
I generally go with 1GB for each due to the size of multiple kernels with systemd-boot.
 
I'm trying to decide on a Fedora/Arch dual boot (Windows won't be on this SSD - it's on another nvme ssd) system but still not sure how to partition.
Both file systems will be btrfs but not sure how else to do it.
This is so confusing. There's good arguments for a separate home - but, not sure if there is reason for more partitions - I like the idea of less - to keep it simple.
However, there's a case for various boot loaders - Grub, systemd-boot and rEFInd are the main ones today? I think Grub is the default boot loader for both operating systems?
 
Arch defaults to systemd-boot. Fedora I'm not sure about.

Personally, I prefer systemd-boot with dracut. For multiple partitions, I generally aim for btrfs with system & home partitions, which helps if you need to reinstall Linux & use the old data from /home for your user account.
 
I found a reason to have a larger /boot.

When you build your own kernel using the .config from the distribution's kernel you get huge initrds (around 1 GB).

While I think it would be better to fix that a larger /boot will also do.
 
I found a reason to have a larger /boot.

When you build your own kernel using the .config from the distribution's kernel you get huge initrds (around 1 GB).

While I think it would be better to fix that a larger /boot will also do.
That depends on the distro. With Arch, you can build out a kernel but dracut or mkinitramfs will still utilize the default or preferred archiving program to compress the kernel & intitramfs files.
 
Back
Top