Can someone explain the situation with using /efi as the ESP/EFI system partition

[ghost]

https://wiki.archlinux.org/title/EFI_system_partition

The arch wiki recommends /efi as the EFI system partition because:

- mount the ESP to /efi:
- It ensures a separation of concerns between OS- and EFI-related files, which may include other OSes' files better left alone.
- It avoids increasing the size requirement of the ESP by not placing the files installed to /boot in it: only the EFI binaries (the boot loader (and optionally drivers) and/or the unified kernel image) will be stored on the ESP, which saves storage space.
- It allows to preserve Linux-specific filesystem permissions for files residing in /boot, avoiding FAT limitations.
- It allows to mount separately the ESP according to the need, e.g. only when upgrading the boot loader.
- If using system encryption with the appropriate setup, it allows to leave only a few required files unencrypted while /boot remains protected: this can be useful for unified kernel images or boot loaders that have file system drivers capable of accessing the kernel(s) and files that are stored elsewhere.

But it seems archinstall will fail using anything except /boot , is that correct?

[Torxed]

It should work with EFI being mounted anywhere, but the default should be /efi (or at least I think we changed to that a while back).

I know it sounds weird that the creator say this, but I'd have to double check because we've moved around the partition logic quite a bit the last year or so.

[spsf64]

https://wiki.archlinux.org/title/EFI_system_partition

The arch wiki recommends /efi as the EFI system partition because:

Actually the first suggestion is /boot, you can check just above the quoted text you copied. Also there is a note that says:

Note: If the ESP is not mounted to /boot, make sure to not rely on the [systemd automount mechanism]....

I always use the default /boot from archinstall, it works perfectly.

[ghost]

https://wiki.archlinux.org/title/EFI_system_partition The arch wiki recommends /efi as the EFI system partition because:

Actually the first suggestion is /boot, you can check just above the quoted text you copied. Also there is a note that says:

Note: If the ESP is not mounted to /boot, make sure to not rely on the [systemd automount mechanism]....

I always use the default /boot from archinstall, it works perfectly.

I would assume they would both work though. They're both recommended.

Choosing /boot means the kernel is on a fragile fat32 partition and has no protective permissions something none of the big distributions do. (Fedora, Debian, Ubuntu, Red Hat.)

[ghost]

It should work with EFI being mounted anywhere, but the default should be /efi (or at least I think we changed to that a while back).

I know it sounds weird that the creator say this, but I'd have to double check because we've moved around the partition logic quite a bit the last year or so.

I tried with latest version on the latest iso. It doesn't allowing making any mount points except /boot for any manually created fat32 partition (and uses /boot on the automatic partitioning.) It has a message saing "Not a valid directory."

It used to allow setting anything but the install would eventually fail for me. I assumed it was because I used /efi but I didn't confirm that by posting my log or looking at it properly.

It definitely works with /efi when installing arch manually, the arch wiki listing many of it's advantages.

[ghost]

I tried /efi (with Grub) using the archinstall --config <path to user config file> method as it brings up a "Not a valid directory" prompt normally.

It works fine , one warning in regards to kms, it seems to specify /boot specifically rather than change to what the user selects. I found it in code it's just copying files, I'm away from my computer at the moment tho. Will update this soon.

[ghost]

So the install is working without issues using /efi for ESP and the Grub boot loader.

In regards to the logs generated install.log and cmd_history.txt look normal. cmd_output.txt has warnings about "Possibly missing firmware" and missing font(s) that seem to happen with any install and this:

  -> Running build hook: [kms]
zstd: error 70 : Write error : cannot write block : Broken pipe 
zstd: /*stdout*\: Broken pipe 

and

  -> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'ast'
zstd: error 70 : Write error : cannot write block : Broken pipe 
zstd: /*stdout*\: Broken pipe 

Is that normal?

[ghost]

I did a totally default install (using /boot as ESP and systemd-boot) and it had the same errors as above.

Default /boot ESP , systemd-boot:

-> Running build hook: [modconf]
-> Running build hook: [kms]
zstd: error 70 : Write error : cannot write block : Broken pipe 
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux.img'
-> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
==> Using default configuration file: '/etc/mkinitcpio.conf'
-> -k /boot/vmlinuz-linux -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: '6.13.3-arch1-1'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [microcode]
-> Running build hook: [modconf]
-> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'ast'
zstd: error 70 : Write error : cannot write block : Broken pipe 
-> Running build hook: [keyboard]

So /efi with Grub does work without any issues from what I can tell (will continue to use it.) Can you consider not blocking /efi with the "Not a valid directory" warning when manually creating partitions?

[ghost]

Log files from a default EFI install , systemd-boot with /boot as ESP.

cmd_output.txt install.log user_configuration.json user_credentials.json cmd_history.txt

[ghost]

Log files from an install with /efi as ESP (so kernel in an EXT4 /boot directory) and Grub.

(Otherwise totally default.)

cmd_output.txt install.log user_configuration.json user_credentials.json cmd_history.txt

[ghost]

Using the efibootstub boot option with /efi as the mounted FAT32 partition with the boot and ESP flags:

It says "Installation completed without any errors. " but doesn't boot as the EFI files are actually in /boot which is EXT4 like the rest of the install.

I assume the archinstall script tells them to be put there every time, instead of changing to what the user selects.

Log files:

user_credentials.json user_configuration.json install.log cmd_output.txt cmd_history.txt

[freyjadomville]

This might be a bit of a crazy thought but could we try a workaround using commands in custom_commands by default?

For example:

mkdir /old-boot 
mv /boot/* /old-boot
mount --bind /efi/<path-to-kernel> /boot
cp /old-boot/* /boot
rm -rf /old-boot
cat "/efi/<path-to-kernel> /boot none defaults,bind 0 1" >> /etc/fstab

Hopefully you get the idea. I have my kernels at /efi/EFI/arch and then bind mounted to /boot.

[Conzpiral]

I confirm /efi does not work on latest archinstall. I need it for my old Opencore Mac Pro to recognize it on boot.

[codefiles]

The hook.preset for mkinitcpio uses /boot as the directory to place kernels and initramfs images.

There are configurations that are valid and archinstall will allow where this may be problematic and will require additional code to handle. For example, using systemd-boot, an ESP of /efi, and a root partition that is anything other than FAT type. In this scenario systemd-boot may not be able to access the /boot directory if the UEFI does not have drivers for the root partition filesystem, which is where /boot will be if the ESP is /efi.

https://wiki.archlinux.org/title/Systemd-boot#Supported_file_systems

[mintsuki]

The hook.preset for mkinitcpio uses /boot as the directory to place kernels and initramfs images.

There are configurations that are valid and archinstall will allow where this may be problematic and will require additional code to handle. For example, using systemd-boot, an ESP of /efi, and a root partition that is anything other than FAT type. In this scenario systemd-boot may not be able to access the /boot directory if the UEFI does not have drivers for the root partition filesystem, which is where /boot will be if the ESP is /efi.

https://wiki.archlinux.org/title/Systemd-boot#Supported_file_systems

i am not sure i am off the mark here, though... like, i am not trying to move /boot elsewhere? i'd like to keep /boot as a FAT boot partition, and have the ESP mounted elsewhere, rather

[codefiles]

@mintsuki

i am not trying to move /boot elsewhere?

I never stated to do this though it could solve the problem. One possible solution would be configuring mkinitcpio to use the ESP in the case it is not /boot.

i'd like to keep /boot as a FAT boot partition, and have the ESP mounted elsewhere, rather

So like using an XBOOTLDR?

Please familiarize yourself with these sections of the ArchWiki concerning the ESP:

• https://wiki.archlinux.org/title/EFI_system_partition#Typical_mount_points
• https://wiki.archlinux.org/title/EFI_system_partition#Alternative_mount_points

[mintsuki]

I am familiar with those terms, the reason i didn't call it "XBOOTLDR" is that it doesn't have to be. The concept of "XBOOTLDR" comes from the Bootloader Specification of systemd-boot, which i am not specifically referring to in this instance.

I made Limine and I am fairly familiar with these terms and the typical mountpoints an ESP may be mounted to.

There is absolutely nothing in the mkinitcpio hook you linked to that has to do with the issue at hand.

[codefiles]

You may be familiar with the terms but if you were familiar with the information the article presents, you would understand the source of the issue.

There is absolutely nothing in the mkinitcpio hook you linked to that has to do with the issue at hand.

When a kernel is installed, that is the template file used to generate a hook for the given kernel. It shows why the kernels and initramfs will be in /boot by default. When using a mount point other than /boot for the ESP these files will be located in /boot without any changes and may then be inaccessible to the boot loader. See how that has everything to do with the issue?

What necessitates creating an ESP and /boot partition?

i'd like to keep /boot as a FAT boot partition, and have the ESP mounted elsewhere, rather

Why?

[mintsuki]

What necessitates creating an ESP and /boot partition?

citing the article you yourself linked:

• It ensures a separation of concerns between OS- and EFI-related files, which may include other OSes' files better left alone.
• It avoids increasing the size requirement of the ESP by not placing the files installed to /boot in it: only the EFI binaries (the boot loader (and optionally drivers) and/or the unified kernel image) will be stored on the ESP, which saves storage space.
• It allows to mount separately the ESP according to the need, e.g. only when upgrading the boot loader.

The reason i say it has nothing to do with the issue is that it does not. The hook will still place the kernel/initramfs in /boot, which is fine. I never said /boot should be non-FAT, i just said that archinstall should support having separate /boot (be it XBOOTLDR or not) and ESP, the latter being able to be mounted to /efi, to /boot/efi, or realistically anywhere else.

The fact of the hook keeping installing the kernel/initramfs to /boot is completely irrelevant; the issue you're concerned with is about the filesystem /boot is formatted with, and whether the bootloader supports it, which is totally valid, but also totally separate from the issue at hand.

[codefiles]

I believe you misunderstand what you quoted. The "Mount the ESP to /efi" bullet expects that the /boot directory will be on the root partition as nowhere in the Wiki does it instruct or advise to create a /boot partition in addition to an ESP other than XBOOTLDR. The bullet after, "Mount the ESP to /efi and additionally mount an "Extended Boot Loader Partition" (XBOOTLDR) to /boot", is about that.

You also convieniently left out these points:

• It allows to preserve Linux-specific filesystem permissions for files residing in /boot, avoiding FAT limitations.
• If using system encryption with the appropriate setup, it allows to leave only a few required files unencrypted while /boot remains protected: this can be useful for unified kernel images or boot loaders that have file system drivers capable of accessing the kernel(s) and files that are stored elsewhere.

As @michaeluk01 commented in this issue:

Choosing /boot means the kernel is on a fragile fat32 partition and has no protective permissions something none of the big distributions do. (Fedora, Debian, Ubuntu, Red Hat.)

[mintsuki]

You also convieniently left out these points:

of course i did, i wasn't trying to hide that i selectively chose bullet points that apply to the situation.

The idea of having a separate FAT /boot partition is not as crazy as you make it sound, plus what @michaeluk01 said doesn't change the fact that these are 2 separate issues. The fact that you don't like the idea of separate FAT /boot partition doesn't mean it is an insane idea or that it shouldn't be supported, as it obviously has its uses, as confirmed by the existence of the concept of XBOOTLDR to begin with.

Now, if we want to talk about having /boot on a non-FAT partition or having it shared with the root partition (also non-FAT), i say that is a different topic that deserves a different issue (perhaps involving support for this being enabled and disabled depending on the various bootloaders).

That all said, please stop being (wrongly may i add) pedantic and let's try to sort these 2 different issues out. I feel like this issue applies to issue number 1; if you want, open another issue for issue number 2, and let's move on. It seems like you're too busy trying to pick a fight over nothing to get stuff done.

[codefiles]

You are taking this personal and it is not.

I never stated or presented anything as crazy or insane nor that I dislike a separate FAT /boot partition. You are acting in bad faith by framing my position that way and from my perspective you are showing ill will towards me.

You should be able to give justification for why an installation should have a partition layout containing an ESP and /boot partition rather than just an ESP if that is what you are proposing. Nothing you quoted as justification does not also apply to /boot being on the root partition so why add a /boot partition?

I am presenting the official documentation for Arch Linux, the ArchWiki. It is my opinion that archinstall should conform to the ArchWiki and I am sure Arch Linux staff would agree.

There is one issue, using an ESP mount point other than /boot can lead to a successful installation that may fail to boot.

[mintsuki]

I can assure you 100% i have no ill will towards you, and i don't care about winning or losing stupid arguments either, i hope i have been as polite as i can possibly be, and if i failed to do that, that is on me.

I gave a justification. I said that this is something you may want to support as it is a valid configuration that has its uses, from wanting to separate OS-level boot files, like the kernel and initramfs, from bootloader-level files like EFI applications and related configuration.

It is also useful to keep OS-level boot files separate from an ESP which is potentially shared with other bootloaders or operating systems.

It is also useful in case the ESP was made too small to accomodate large kernels and initramfses, and so on and so forth.

These reasons are pretty much underlined in the ArchWiki articles you keep mentioning, and i am relatively sure the Arch staff would agree with me here. This is something that should be supported.

[codefiles]

Yes, and as I have stated all of that applies when /boot is on the root partition. What is the benefit of creating an extra partition rather than using the root partition?

[ghost]

I confirm /efi does not work on latest archinstall. I need it for my old Opencore Mac Pro to recognize it on boot.

The tui does block anything except /boot but you can do this.

It seems like an unnecessary work around but you can save the install configuration, edit it with nano so the esp partition is /efi then use archinstall --config <path to user config file or URL> to force it to use /efi. All boot loaders will install without an error but only Grub actually boots this way.

There's must be commands in archinstall that always assume the esp is /boot and doesn't change dynamically to what the user selects.

[codefiles]

@michaeluk01, GRUB has file system drivers so it can access /boot on the root partition, this is why it works.

[mintsuki]

Yes, and as I have stated all of that applies when /boot is on the root partition. What is the benefit of creating an extra partition rather than using the root partition?

Bootloader compatibility.

[ghost]

To developers. Can you remove the TUI blocking /efi as the ESP and just display a message saying the user must use Grub in that situation?

If someone reads the Arch wiki it's totally reasonable for them to want to use /efi , as stated in the intitial post the official Arch wiki recommends /efi for many reasons.

[mintsuki]

And you could check if /boot is a FAT partition and not show said message.

[ghost]

When I used archinstall a few weeks ago the TUI didn't let me mount a FAT partition anywhere other than /boot .

I had to do the archinstall --config work around I mentioned earlier to use /efi with Grub.

[ghost]

And you could check if /boot is a FAT partition and not show said message.

If Grub works with /boot as EXT4 and the Arch wiki says that's beneficial, and all the other major distributions have /boot as EXT4 why would you want to enforce making it FAT when installing Arch with Grub?