Talk:EFI system partition

From ArchWiki
Jump to navigation Jump to search

You must use the root= kernel parameter in order to boot using this method

The sentence "You must use the root= kernel parameter in order to boot using this method" from EFI system partition#Using bind mount has been bugging me for while now. I traced its origins to Special:Diff/277007.

Are there situations where it's possible to omit the root= parameter (not counting boot loader magic since it also passes the parameter to the kernel)?

-- nl6720 (talk) 08:50, 20 April 2019 (UTC)

Technically its possible if you get systemd-auto-gpt-generator run in initramfs or you hard coded it in a custom kernel or initramfs. Of course this is unsupported.
Marcthe12 (talk) 05:42, 12 November 2019 (UTC)
Although the wiki was updated after systemd-auto-gpt-generator came into existence, I don't think it's referencing that. I have a slight suspicion that it could be about grub-mkconfig not liking a bind mounted /boot. I'll test it when I get the time. -- nl6720 (talk) 15:41, 12 November 2019 (UTC)

Preffered mount point for LVM users

In Typical mount points section it is advised to mount esp at /efi if bootloader has drivers to your root file system. But there is no mentioning of root file systems contained in lvm. I had a problem exactly like in this topic. Seems like rEFInd still cannot boot kernels resided inside LVM. It is said that /boot mount point is preferred when directly booting a EFISTUB kernel from UEFI. Should we expand it with "or if you are using LVM"?

Ashark (talk) 05:27, 24 August 2019 (UTC)

It's not limited to just LVM. The boot loader needs drivers for everything that is below the block devices that UEFI provides, be that LVM, RAID, dm-crypt, LUKS, etc, and ending with the file system. The problem is that boot loader capabilities differ. rEFInd only has file system drivers, so it doesn't support anything more complex than a file system on a partition. GRUB has more drivers, so it can access LVM (but not lvmthin(7)), LUKS1 and RAID.
The current sentence is also not entirely correct about needing a driver for the / file system. What it really needs is a file system driver for the volume where /boot is located, that may not necessary be the / file system in case /boot is a separate volume.
At the moment I can't think what to add to EFI system partition#Typical mount points so that it doesn't lose the boot loader examples. Additionally any changes should also be propagated to Arch boot process#Feature comparison and Partitioning#/boot.
-- nl6720 (talk) 06:43, 24 August 2019 (UTC)
Maybe sentenses like this:
mount ESP to /efi and use a boot loader which has a driver of file system which stores /boot. Also bootloader needs drivers for everything that is below the block devices that UEFI provides, be that LVM, RAID, dm-crypt, LUKS, etc.
mount ESP to /boot. This is the preferred method when directly booting a EFISTUB kernel from UEFI or when your bootloader cannot access file system that stores /boot.
Ashark (talk) 07:04, 24 August 2019 (UTC)
Things are getting more complicated with the mkinitcpio and kernel changes. Storing the kernel and initramfs in /boot is not exactly a requirement anymore, although it is still the default configuration. The only relevant things that strictly remain in /boot/ are the *-ucode.img files. If those get moved away too, then Partitioning#/boot and other pages will need rewriting.
Below are a few drafts that try to address the current situation. Ideally I'd like to merge them (in some form) this year.
I wanted to link from Arch boot process#Boot loader to Partitioning#/boot using a page/section reference, but couldn't find good way to do that.
-- nl6720 (talk) 15:04, 21 December 2019 (UTC)
I'll merge the drafts in their current form if no objection arises until tomorrow. -- nl6720 (talk) 09:11, 4 January 2020 (UTC)
The drafts are merged. Anyone can feel free to improve the wording of those pages. -- nl6720 (talk) 10:01, 5 January 2020 (UTC)

/boot drafts

EFI system partition#Typical mount points

The simplest scenarios for mounting EFI system partition are:

  • mount ESP to /efi and use a boot loader which is capable of accessing the kernel(s) and initramfs image(s) that are stored elsewhere (typically /boot). See Arch boot process#Boot loader for more information on boot loader requirements and capabilities.
  • mount ESP to /boot. This is the preferred method when directly booting a EFISTUB kernel from UEFI.

...

Arch boot process#Boot loader

A boot loader is a piece of software started by the firmware (BIOS or UEFI). It is responsible for loading the kernel with the wanted kernel parameters, and initial RAM disk based on configuration files. In the case of UEFI, the kernel itself can be directly launched by the UEFI using the EFI boot stub. A separate boot loader or boot manager can still be used for the purpose of editing kernel parameters before booting.

Warning: A boot loader must be to be able to access the kernel and initramfs image(s), thus, in a typical setup, it must support accessing /boot. That means it must have support for everything starting from the block devices, stacked block devices (LVM, RAID, dm-crypt, LUKS, etc) and ending with the file system on which the kernel(s) and initramfs image(s) reside. If the boot loader cannot access the kernel and initramfs, then the system will not boot.
Note: Loading Microcode updates requires adjustments in boot loader configuration. [1]
Feature comparison
Note:
  • As GPT is part of the UEFI specification, all UEFI boot loaders support GPT disks. GPT on BIOS systems is possible, using either "hybrid booting" with Hybrid MBR, or the new GPT-only protocol. This protocol may however cause issues with certain BIOS implementations; see rodsbooks for details.
  • Encryption mentioned in file system support is filesystem-level encryption, it has no bearing on block-level encryption.

...

Partitioning#/boot

The /boot directory contains the kernel and ramdisk images as well as the bootloader configuration file and bootloader stages. It also stores data that is used before the kernel begins executing user-space programs. /boot is not required for normal system operation, but only during boot and kernel upgrades (when regenerating the initial ramdisk).

Note:
  • A separate /boot partition is only required if your boot loader is not capable of accessing the /boot directory that resides in /. For example, if the boot loader does not support that file system or if your / is on a stacked block device (e.g. software RAID, a encrypted volume or a LVM volume) and the boot loader does not have drivers for it. See Arch boot process#Boot loader for more information on boot loader requirements and capabilities.
  • If booting using an UEFI boot loader that does not have drivers for other file systems it is recommended to mount the EFI system partition to /boot. See EFI system partition#Mount the partition for more information.

...

Is the main benefit of the alternative is not having to busy wait?

This section is about the accuracy note at EFI system partition#Replacing the above mkinitcpio hook, and https://wiki.archlinux.org/?diff=587697. Since it was already started at https://bbs.archlinux.org/viewtopic.php?id=250466, I think it is best to continue it there. https://bbs.archlinux.org/viewtopic.php?pid=1871849#p1871849 suggested to have the discussion here. Which is why I left this note at the first place. Regid (talk) 19:12, 4 November 2019 (UTC)

https://bbs.archlinux.org/viewtopic.php?id=250466 was transferred to https://bbs.archlinux.org/viewforum.php?id=36, which is the forums dustbin. I don't know for how long they keep the threads there. Among other things, id=250466 does have links to other sites with excellent information on the subject. I don't know if someone would raise such links here. I think this page has much lower traffic then the forums. Which is one more reason to have a discussion there, if possible. Regid (talk) 09:55, 5 November 2019 (UTC)

The entire discussion is meaningless thanks to your subsequent edit, because the rationale was written for the alternative example using mkinitcpio hook and not for mkinitcpio presets. Hence, I removed the entire paragraph. Closing. -- Lahwaacz (talk) 16:48, 5 November 2019 (UTC)

Pacman hook

The pacman hook seems to stop working for kernel upgrades. Looking at /usr/share/libalpm/hooks/90-mkinitcpio-install.hook suggests that Target = boot/vmlinuz* should be replaced with Target = usr/lib/modules/*/vmlinuz. At least, this makes the hook work again on my machine and I can't think of any problem that would be caused by this change (except for kernel images that don't install modules). Entro (talk) 22:40, 10 November 2019 (UTC)

Updated with the new location. Juma93 (talk) 14:36, 13 November 2019 (UTC)