/boot or /boot/efi?

halimbo · 2023-11-27 23:47:22

I've always mounted the ESP on /boot and installed GRUB with --efi-directory=/boot.
Installing the linux kernel places it together with the initramfs also on /boot.
This works ofc, but im not sure if its the correct way.
I want to install multiple distros without having conflicting kernels.
The other way would be to mount ESP on /boot/efi (ChatGPT recommended).
However there is this line in the Arch Wiki that says bootloaders cant access all filesystems,
and that its recommended to have a separate FAT32 boot partition.
I see i could either set up a dedicated boot partition for each os,
or i put all the different kernels on one big ESP in different sub folders.
I feel like im missing something that resolves this issue and that would make multi booting much easier.

for now have the kernel on a separate FAT mounted at /boot and ESP mounted in /boot/efi and it works fine.
still, ive looked up some tutorials on YT and most people put everything on the ESP i guess its just preference.

Last edited by halimbo (2023-11-28 01:07:30)

kermit63 · 2023-11-28 01:16:17

halimbo wrote:

However there is this line in the Arch Wiki that says bootloaders cant access all filesystems, and that its recommended to have a separate FAT32 boot partition.

As far as I know, the FAT32 boot partition is a requirement for systemd-boot and efi-stub. GRUB however can access other file system types. If your root partition is ext4, you can just have /boot inside the root partition as long as it is not luks2 argon encrypted. This set-up is particularly helpful if you plan to multi-boot other OSes.

Last edited by kermit63 (2023-11-28 01:18:53)

Head_on_a_Stick · 2023-11-28 05:40:15

halimbo wrote:

(ChatGPT recommended)

Please do not listen to the bullshit generators. See also https://www.aisnakeoil.com/p/chatgpt-is … erator-but

I would not advise using /boot/ for the ESP mountpoint with GRUB. The FAT filesystem breaks too easily.

halimbo · 2023-11-28 12:51:33

The section in the wiki recommending a separate FAT partition for the kernel is misleading then.
It's already flagged as being inaccurate.
I mean GRUB has to have the executable on a FAT partition anyway, but the kernel and the config files don't need to be on FAT.

Anyway i figured it out, there are a few different options to place GRUB and the Kernel but each option requires specific
command line options for grub-install and grub-mkconfig.
i would want to complement the wiki in a way that would be easier to understand but i understand now why it reads itself so confusing. there are too many variables if you start going away from the standard setup.
regarding grub-install...

--boot-directory

feels actually like its kind of a "--config-directory" option, because that's where it will be looking for "[...]/grub/grub.cfg".
and "--bootloader-id" is only really important when you want to run grub-install with

--no-nvram

so you dont mess up the existing "trigger" for UEFI but you can still change the config directory with "--boot-directory". Like for example when grub boots optimally, but it drops you to the shell because it has no config-file (or just the wrong config file).

I don't know if it's just my specific hardware but ESP can be anywhere on the disk it doesn't have to be the first partition (i've read online it has to be in the first 2TB though). leaving the "real" esp on the start of the disk free for other OS (windows) is also useful so you always have your configured GRUB partition somewhere safe.
despite the flagged status in the wiki ("why would you put grub config on the esp") i see value in this option for multi-booting because its packaged together, and not on some "random" linux-distro partition.

the most important thing is:

grub-mkconfig -o /boot/efi/grub/grub.cfg

just looks really wrong somehow.
and yeah it only works when you specify

--boot-directory=/boot/efi

with grub-install.
otherwise grub will look for .../grub/grub.cfg in the place that is /boot in the moment you run the command (whatever partition is mounted there [kernel on arch, or separate kernel partition]).
actually having a separate kernel partition with grub rarely makes sense, since this is the strong point about grub, that it can access every filesystem.

Head_on_a_Stick · 2023-11-28 13:35:19

halimbo wrote:

the most important thing is:
grub-mkconfig -o /boot/efi/grub/grub.cfg
just looks really wrong somehow.
and yeah it only works when you specify
--boot-directory=/boot/efi
with grub-install.

Don't do that. Just use /boot/ for --boot-directory (which is the default) and /boot/grub/grub.cfg for the output of grub-mkconfig. Having grub.cfg on the ESP is pointless.

seth · 2023-11-28 13:39:56

What section in the wiki?

I mean GRUB has to have the executable on a FAT partition anyway, but the kernel and the config files don't need to be on FAT.

With grub, the only thing that has to be fat is the ESP, because the ESP has to be FAT no matter what.

Staying with grub:
kernel and initramfs go into /boot, no matter where you mount the ESP and /boot/efi isn't the preferred location anymore either.
https://wiki.archlinux.org/title/EFI_sy … unt_points

You'd have:
/boot - where your kernel and initramfs and maybe the entire grub stuff goes
/efi where the grubx64.efi goes
The /boot directory doesn't have to he an extra partition but can be part of your root partition or the ESP (though the latter will often be too small, esp. when multi-booting and it was created by windows at like 100MB)

kermit63 · 2023-11-29 10:27:13

halimbo wrote:

despite the flagged status in the wiki ("why would you put grub config on the esp") i see value in this option for multi-booting because its packaged together, and not on some "random" linux-distro partition.

This would only work if:
1. Your EFI parition is big enough to accommodate all the kernel files, but more importantly:
2. The distro you're multi-booting does not use the same kernel-naming convention as arch. If you try an arch-based distro like endeavourOS for example with arch, you will end up sharing the same kernel files for both OS, which could lead to some nasty complications. Once you update the kernel files from arch, you will not be able to boot into your still unupdated arch-based distro since it is still expecting the old kernel. You can escape this if you bind mount /boot to another folder in the esp partition, but that will add another layer of complication to your grub set-up.

halimbo · 2023-11-30 21:16:43

Right at the top of "wiki.archlinux.org/title/GRUB"

Warning: File systems can get new features not yet supported by GRUB, making them unsuitable for /boot unless disabling incompatible features. This can be typically worked around by using a separate /boot partition with a universally supported file system such as FAT32.

This led me to the idea of kernel and grub-config on FAT...

seth wrote:

/efi where the grubx64.efi goes

This seems reasonable, would be nice if this got adopted in the wiki. And then you still go

grub-mkconfig -o /boot/grub/grub.cfg

because you "linked" it beforehand with

grub-install --boot-directory=/boot --efi-directory=/efi

Considering /dev/sda and --target=x86_64-efi and --bootloader-id=arch (i believe it's "arch" and not "GRUB") are
the default options, these two (boot- and efi-directory ) would be the only options you need in a lot of cases (idk 80%?)
I think the GRUB wiki is (bonkers) too complicated in the fact that it "hides" the simple solution which is seth's recommendation.
I should not complain sorry. rather make a post in the wiki:talk.
it wasnt really a problem so i guess i don't have to mark this as solved or something do i?

halimbo · 2023-11-30 21:26:35

kermit63 wrote:

halimbo wrote:
despite the flagged status in the wiki ("why would you put grub config on the esp") i see value in this option for multi-booting because its packaged together, and not on some "random" linux-distro partition.
This would only work if:
1. Your EFI parition is big enough to accommodate all the kernel files, but more importantly:
2. The distro you're multi-booting does not use the same kernel-naming convention as arch. If you try an arch-based distro like endeavourOS for example with arch, you will end up sharing the same kernel files for both OS, which could lead to some nasty complications. Once you update the kernel files from arch, you will not be able to boot into your still unupdated arch-based distro since it is still expecting the old kernel. You can escape this if you bind mount /boot to another folder in the esp partition, but that will add another layer of complication to your grub set-up.

Sorry if my post was confusing, what i really meant with this section was putting only the GRUB config files on the ESP, so grub does not need to source them from another partition (where your linux os is installed). This has somewhat better flexibility for multibooting since you can format any distro-partition but still have GRUB functioning for the other ones. In this case the kernel files would be somewhere else. and grub config files dont take any space really.
On another note, iin the past i really DID put the kernel on the ESP, because i didnt knew better. I recognize its horrible for multi booting because of the conflicts etc. I only ever had single arch install so i didnt feel the impact.

Head_on_a_Stick · 2023-12-01 06:16:05

halimbo wrote:

Right at the top of "wiki.archlinux.org/title/GRUB"
Warning: File systems can get new features not yet supported by GRUB, making them unsuitable for /boot unless disabling incompatible features. This can be typically worked around by using a separate /boot partition with a universally supported file system such as FAT32.

The /boot/ filesystem would only gain those new features if it was reformatted every time the fileystem tools package was updated, which seems highly unlikely.

nl6720 · 2023-12-01 06:50:00

While existing file systems do not gain these new features unless you manually enable them (might not be true for f2fs), the mkfs utilities do gain them.
For example, xfsprogs 6.5.0-1, which is in the repos since 2023-10-21 and thus in the 2023-11-01 ISO, enables nrext64 on new file systems, but GRUB only gained support for it in git nine days ago.

This means that if you're installing Arch right now, you cannot use XFS for /boot if you plan to use GRUB, unless you manually pass -i nrext64=0 to mkfs.xfs.

Both https://wiki.archlinux.org/title/Arch_b … oot_loader and https://wiki.archlinux.org/title/Partitioning#/boot list more examples of things like these happening in the past.

Arch Linux

#1 2023-11-27 23:47:22

/boot or /boot/efi?

#2 2023-11-28 01:16:17

Re: /boot or /boot/efi?

#3 2023-11-28 05:40:15

Re: /boot or /boot/efi?

#4 2023-11-28 12:51:33

Re: /boot or /boot/efi?

#5 2023-11-28 13:35:19

Re: /boot or /boot/efi?

#6 2023-11-28 13:39:56

Re: /boot or /boot/efi?

#7 2023-11-29 10:27:13

Re: /boot or /boot/efi?

#8 2023-11-30 21:16:43

Re: /boot or /boot/efi?

#9 2023-11-30 21:26:35

Re: /boot or /boot/efi?

#10 2023-12-01 06:16:05

Re: /boot or /boot/efi?

#11 2023-12-01 06:50:00

Re: /boot or /boot/efi?

Board footer