I’m about to install Manjaro and i want to ask if 512MB for Boot/EFI is that’s enough or if i should go for a bigger partition when it comes to UEFI Boot?
Only Nvidia GPU’s required bigger Boot partition like 2gbyte or has this something to do with MBR? At least on my old PC (with a nvidia gpu) i have above 2Gbyte /boot, because i ran into issue in the past.
I have no interest to share my Linux Bootdrives with Windows or to encrypt my boot or my system root/home and i only want to use 2 Kernels.
@pwx @linux-aarhus
Ohh so you have to create for UEFI a partition for /boot/efi and a additional partition for /boot that is required to store this Kernels then?
And when i have only /boot/efi, my kernels will be stored only under root, with a boot folder?
Extra boot partition is an option in case of encryption. But i think you are not going to encrypt root, do you?
Extra large esp (efi partition) may come in handy if you decide to boot without grub, with universal images, and you get those bloated with nvidia or other drivers.
But in all standart usual setups a esp partition sized 300-500 is more than enough, because the kernels are not stored there at all.
Im not a fan from boot encryption, but on my PC (with MBR) and Laptop (also with MBR), i had /boot (partition ext3) mounted with bootflag for both of my system.
But since im a UEFI/EFI Virgin
that is a little new side quest for me.
On an EFI based system only the efi stubs is stored on the EFI partition.
The /boot is part of the root file system.
The common location for mounting the EFI partition is usually in a root folder /efi.
Due to various compatibility issues with grub the Linux world mounted the EFI partition as an extension the /boot folder.
And to further confuse the topic - using systemd-boot requires the EFI partition to be mounted at /boot which could possibly create issues when Nvidia modules is combined into the kernel by mkinitcpio. In such case it is important to not make the EFI partition too small.
But in the case of a default Manjaro Calamares installation you get no issues at all - you don’t need any customised partitioning - unless of course you want the /homeon a separate partition
A default Manjaro /boot folder is only limited in size by the size of installation disk.
Yeah that was always the reason for me to create even with my first Manjaro install 6 years ago, a manual partition way.
I guess this is true, but only for the automatic install i guess.
I was forced 3 year’s ago, to extend my /boot partition with my nvidia PC, because 300MB was not enough.
From my experience at this time, because i couldn’t resize that partition (since it was created near the start sectors), i had to refresh all boot files to the new partition.
And it was very confusing with root/boot and the identical looking /boot (since the / is included in this path) which looked like a symlink to me and somehow it was not, because i had to replace the boot files in both area’s.
Some stuff i probably will never understand, but hey, im happy i could at least fix that big problem at this time.
512 MB is more than sufficient for an EFI System Partition (ESP) – by default, the Manjaro installer (Calamares) creates a 300 MB $ESP, and this is already large enough for the purpose.
The $ESP typically only needs to hold files and directories such as the efi boot stubs – examples: grubx64.efi, bootx64.efi and refindx64.efi (if one happens to use the rEFInd boot manager).
Themes and resources might also be stored on the $ESP, depending on individual preference – even with theming files and/or efi boot stubs for several OS (in a multi-boot scenario), 512 MB should still be adequate.
Technically, there is no size limit for the $ESP – other than limitations imposed by any given filesystem – but the general rule-of-thumb recommendation is to choose a size that suits only what you need, or might need in the future.
The $ESP is not designed for housing kernels. Perhaps there was some confusion, as @linux-aarhus suggests.
Exactly. The only case one can eventually house kernels there is if one ditches grub and decides to use UKIs to boot. But that’s not the default config.
Me personally, i like the idea, but i do not want to house kernels on the super unreliable fat filesystem, so i will not use UKIs. Which means i only have the grub loader which is about 5 mb. My ESP is 300mb and i still find it pretty future proof. 1 GB for me is a space reserved for nothing and just wasted.
One has to also keep in mind - the more customization, the less support from the forum in the future. Because we assume some sane defaults as a starting point for troubleshooting. So as a rule of a thumb - never customize something you do not fully understand and cannot troubleshoot by yourself.
P.s. i think i hit the wrong reply arrow…my post is more at Kobold.
The EFi directory, whether in / or in /boot must be a separate partition in FAT32 file format. And FAT32 filesystem is an extremely inefficient format. The inefficiency grows exponentially with size.
350MB is probably ideal, definitely 512MB is the max. I say 350MB, because really 300MB is what it should be, but there used to be an issue with the Manjaro installer, that if it formatted the EFI partition and it was set to 300MB, the install would fail, so going to 350MB would fix that.
Generally FAT32 runs into “issues” at anything nearing 32GB, or any file approaching 4GB. But seriously, unless you are doing something non-standard it is only holding stubs and never needs to be more than 512MB. Although I have seen 1GB used for safety by some “just in case” experimenters. Personally I had a problem with the choice of FAT32 as the EFI file system from the beginning, but not because of the size limits.
The efi fs is fat because Microslop actively participated in this standart development. So you see remnants of micro-thinking everywhere. For example ia an efi shell the partitions are called FS0: and FS1: (case insensitive of course), there is ls command but it also works with dir…etc.
And thus, most firmwares cannot read anything but fat on a disk. So the very boot loader has to be on that.
Just pitching in — and some of the stuff I might be posting here may already have been said by others — the EFI system partition needs not be very big at all, because it’s only meant to contain EFI stubs. EFI stubs are EFI/UEFI-compatible boot loaders, such as (the EFI version of) grub or refind.
That said, the reason why Microsoft recommends 512 MiB is that if you install (or dual-boot with) Microsoft Windows, there will be a whole load of additional Microsoft-specific junk in there as well. But I have known people — even here on the forum — with an EFI system partition of only 16 MiB, and formatted in FAT16 instead of vfat.
The recommended size is 300 MiB, and I think it’s more than enough.
Notes:
Do not get the EFI system partition mixed up with /boot. /boot is where the kernels, the initramfs and the grub configuration live. In theory, it could be of any filesystem type regarded as writable by the kernel, so that it can be written to, for instance when updating your kernels. However, at boot time, before the kernel is even loaded, it must be read from and written to by the boot loader, but grub itself cannot write to btrfs, and its support for xfs is a hit-and miss — some grub versions cannot read it at all. If you’re going to have /boot as a separate partition, then best is to choose ext4 as its filesystem.
The EFI system partition is mounted at /boot/efi in Manjaro, or at /efi in some other distributions, and must be formatted with a filesystem supported by the firmware. In practice, this will usually be vfat (FAT32).
No, a separate /boot is not required. However, there may be circumstances where it is recommended to have a separate partition for /boot.
The fact that grub cannot write to btrfs and thus cannot save your last booted entry while you would still like to use btrfs for your root filesystem could be such a reason, although in this case, it should be noted that if you want to make bootable btrfs snapshots, then that will no longer be possible. The whole “bootable snapshot” strategy depends on the root filesystem being btrfs with /boot being part of the root subvolume “@”.
The kernels will always be stored under /boot, regardless of whether /boot is a separate partition or not.
Remember, UNIX does not think in terms of drives and partitions; it only thinks in terms of a unified directory structure.
Yes, but this has nothing to do with whether /boot is the mountpoint for a separate partition or just a directory on the root filesystem.
It’s because grub cannot write to btrfs, and in addition to that, it also has a problem with sparse files.
On a GPT-partitioned drive with UEFI boot, the EFI system partition is the one that should be marked with the esp and boot flags.
You can optionally also add a root flag on the root filesystem, but this is not required — it’s only needed on systems with systemd that do not have an /etc/fstab file, so as to allow systemd to automatically detect the root filesystem.
If you don’t understand, then just ask. That’s what this forum is all about.
Well, if you use unified kernels, then it would be best to put them in the EFI system partition, since they will be directly booted from within the EFI. In that case, the EFI stub is actually in the compressed kernel binary, and such systems can boot without needing grub or refind.
That issue did indeed exist for quite a while, but was eventually solved in a later version of calamares.
Absolutely. M$ like to stick their fingers into many pies, and whenever they get the chance to infer they made the recipe, they do.
The $ESP can actually be formatted with a variety of file systems; the only proviso being that an efi filesystem driver must exist for it.
They do exist, but the fat32 variant of vfat is indeed the de facto standard, and logistically speaking, it would be an up-hill battle to encourage the industry to change.
