Talk:EFI stub

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 00:16, 2 July 2024 (UTC)
:: Your reply ~~~~

Initramfs

Talk status

This discussion is done as of June 5, 2017.

In fact, this is neither true nor false. UEFI does not support loading an initramfs. But UEFI does not load the kernel, it loads EFISTUB - which happens to be the same binary file as the kernel. EFISTUB takes the argument initrd=\foo\bar\initrd.gz, which should be self-explaining. --Qsuscs (talk) 16:43, 21 October 2013 (UTC)

I agree with the above. I am also wondering if the statement: "This parameter cannot be built into CONFIG_CMDLINE as outlined above." is actually true. I see no reason why this should be so, and I can't find any mention of this in other sources. Will fix once I get around to testing it. --Jepio (talk) 18:54, 7 July 2015 (UTC)

Finally managed to test that claim, and indeed, initrd can not be hardcoded into CONFIG_CMDLINE. By the time the kernel comes around to reading that the variable the EFI stub has already done it's job and can not provide the initrd anymore. However efibootmgr works great, can supply the initrd parameter to the EFI stub and allows the usage of UEFI without an intermediate boot loader for lowest boot delay. Highly recommend it to everyone. --Jepio (talk) 21:39, 6 August 2015 (UTC)

Jepio, I appreciate that you did this research and then took the time to type up your findings here for the benefit of everyone. If there is anything else that does not line up in the main article please make corrections as needed. Thanks again! --Maffblaster (talk) 21:49, 6 August 2015 (UTC)

I think, this needs to be clarified a bit more - the EFI stub can load an initramfs image, but not using the built-in kernel command line - it has to know what to load as a the initramfs before it starts the kernel. I'll try to rephrase the notice you addeed. --Jepio (talk) 11:37, 7 August 2015 (UTC)

Sounds good. Thank you, sir! Closing this discussion. --Maffblaster (talk) 21:00, 5 June 2017 (UTC)

Move "Initramfs" section out to its own article

Talk status

This discussion is done as of August 30, 2017.

Most stuff in the (before I started reworking the other sections) original section Initramfs seems not really specific to this article. It'd better be moved to the Initramfs article only leaving first tree lines of the present version of that section.
Any objections?
--Charles17 (talk) 09:15, 6 June 2017 (UTC)

Meanwhile this section has been almost completely rewritten and duplicate infos removed. So marking this ad "done".--Charles17 (talk) 12:12, 30 August 2017 (UTC)

Replace "make install"?

Talk status

This discussion is done.

I am thinking of replacing

Run the install command:

root #make install

 sh ./arch/x86/boot/install.sh 4.9.16-gentoo arch/x86/boot/bzImage \
         System.map "/boot"
 

with

root #find . -type f -name bzImage -exec cp {} /boot/EFI/Gentoo/ \;

But I am not sure if it doesn't look too complicated esp. for Linux newbies. --Charles17 (talk) 18:36, 19 June 2017 (UTC)

Yeah, go for it! The current installation phase is _really_ not optimal. The resulting kernel binary to be booted should be named simply without version numbering. I use gentoo.efi. This way, efibootmgr doesn't have to be used every time the user updates his kernel to a new version. Fcl (talk) 14:14, 30 August 2017 (UTC)

That's fine with be as well. Don't forget to close the discussion when you make the change. --Maffblaster (talk) 19:38, 10 September 2017 (UTC)

Change done. But without find -exec voodoo.--Charles17 (talk) 07:40, 11 September 2017 (UTC)

efivarfs mounted ro by default in >= sys-apps/openrc-0.28

Talk status

This discussion is done as of September 30, 2017.

Hi, the 'Installation' section talks about using efibootmgr, but efivarfs is now mounted read-only by default on OpenRC (>= 0.28) so this command will fail (unless the filesystem is at least temporarily remounted rw beforehand). Doesn't affect systemd at the moment. Please see my notes here. --Sakaki (talk) 09:56, 30 September 2017 (UTC)

It's described in the efibootmgr article, so needs not be mentioned here again.--Charles17 (talk) 14:42, 30 September 2017 (UTC)

kernel command line need not be built in

Talk status

This discussion is done as of 2024-05-23.

command line can be specified through efibootmgr, eg:

root #efibootmgr -d /dev/nvme0n1 -p 1 -c -b 0000 -L "Gentoo" -l "\gentoo\kernel-4.19.0-gentoo.efi" --unicode "root=ZFS=g-pool/g-root i915.enable_guc=3 psmouse.synaptics_intertouch=1 crashkernel=128M"

Bunder (talk) 11:22, 3 February 2019 (UTC)

Thanks for mentioning this. Will you please integrate your experience into the efibootmgr article. Please bear in mind there are some EFI implementations where it does not work. And also that some users of the EFI stub do not (need to) use efibootmgr.--Charles17 (talk) 06:36, 4 February 2019 (UTC)

The article now covers this.

— Waldo Lemmer 19:57, 23 May 2024 (UTC)

Distribution kernels

Talk status

This discussion is done as of 2024-05-23.

TheFossie Does this actually work with gentoo-kernel and/or gentoo-kernel-bin? Often they need to have loaders reference the post-build initramfs to complete the boot process. What's written here does not look like it will work. Also, not every UEFI will accept parameters like you suggest. --Grknight (talk) 20:06, 4 February 2021 (UTC)

I use gentoo-kernel-bin and have tried these commands. No issue. And, if a user's UEFI doesn't accept parameters and he is using distribution kernels, he might be failed to use EFI Stub as a whole. Maybe, we can mention that in the wiki? Because, if we don't mention the parameter way, the users who have a supported UEFI can't use it. - TheFossie (talk) 05:11, 5 February 2021 (UTC)

TheFossie You say: »And, if a user's UEFI doesn't accept parameters and he is using distribution kernels, he might be failed to use EFI Stub as a whole.«

Is that true? Would it really fail even using Refind as a boot manager?

Would it also fail using suitable settings in savedconfig or /etc/kernel/config.d? If so, IMHO it's worth filing a bug.

You say: »if we don't mention the parameter way, the users who have a supported UEFI can't use it.«

Mentioning the parameter way in the efibootmgr article sound a good idea.

--Charles17 (talk) 11:02, 5 February 2021 (UTC)

Charles17 I put the efibootmgr instructions here for two reasons:

1. There was already an efibootmgr command under Optional: category in this article

2. In order to run these commands, users have to copy vmlinuz/bzimage to appropriate place first. in Efibootmgr article, this context is missing. If I put the exact same writings to Efibootmgr, won't it look irrelevant? - TheFossie (talk) 16:34, 5 February 2021 (UTC)

You could add the missing copy/move commands and possibly another »If this is the folder structure:« box to the Efibootmgr article and give it a general review.

--Charles17 (talk) 16:30, 5 February 2021 (UTC)

Would you please do it on my behalf, as you see fit? And please also mention alternative tools to efibootmgr which users can use to setup their EFI Stub in this article. It would be nice. :D - TheFossie (talk) 16:34, 5 February 2021 (UTC)

No, I will not maintain the efibootmgr article. I don't use efibootmgr at all and my experience with it is too old.

--Charles17 (talk) 16:48, 5 February 2021 (UTC)

I think EFI stub#Creating a boot entry section should also removed. Because, it's partial instruction. The whole Efibootmgr instruction should be moved to that article in this case. - TheFossie (talk) 16:53, 5 February 2021 (UTC)

The efibootmgr instructions are now too intertwined with the rest of the article to be removed, but I think that's fine. This article doesn't duplicate anything that is said at efibootmgr.

— Waldo Lemmer 20:02, 23 May 2024 (UTC)

I just looked at EFI stub#Optional: Kernel with initramfs and the linked forums post Booting UEFI without Grub. And, I think you're wrong. All of you. For example, pietinger in the forums post (btw, shouldn't it be "posting"?) writes at the bottom of his post(ing): "about kernel options: Your kernel must - ALWAYS - be able to access a GPT partition". Why? If I copy the kernel from a live system to the GPT, and boot the kernel from the GPT as a whole (i.e. either without an initrd altogether, or with a unified kernel image), WHY then MUST the kernel be able to access the GPT? It would be already loaded, and there would be no need for the kernel to access the partition anymore...

To be more clear, and that is why I'm even writing this: there are so many different solutions booting and configuring Linux kernels as there are people and systems. There is no "those 10 ways to do it are possible", because you would always miss the 11th and 12th (and so on) way to do it. So, maybe this is all way to much into detail?

Luttztfz (talk) 16:20, 24 May 2024 (UTC)

Addition: I apologize for the "you're all wrong" part... I don't really mean it as it may sound. I'm wrong too, if you get my meaning ;-) (And, in my defense and as my excuse: I'm a non-native speaker, so my English is always "wrong"...) Luttztfz (talk) 16:28, 24 May 2024 (UTC)

Please don't confuse a GPT partition, which is ANY partition on a disk partitioned with GPT, with the ESP, which is the EfiSystemPartition. For the kernel to be able to access any partition on a GPT disk (including its root partition), every kernel MUST have this enabled:

CONFIG_EFI_PARTITION=y

<=>

-*- Enable the block layer --->

  Partition Types --->
     [*] Advanced partition selection
     [*] EFI GUID Partition support

You missed the link to -> "This is explained in: EFI_System_Partition"

GPT means: GUID Partition Table https://en.wikipedia.org/wiki/GUID_Partition_Table

ESP is the "special partition" for booting with UEFI

For example it is possible to have a GPT formatted disk and do an old MBR(CSM)boot instead an UEFI boot ... and so you dont need an ESP ... but the kernel needs ALWAYS EFI GUID Partition support to access this disk.

(So, yes, you MUST have this always enabled as soon as you use a disk which is GPT formated; and for using an ESP you need additionally <*> VFAT (Windows-95) fs support)

Pietinger 18:05, 24 May 2024 (UTC)

Thanks for your answer. And you're absolutely right, I'm confusing GPT with ESP. My bad.

I used a hybrid partitioning on one of my PCs, for the use with an older OS that did not support GPT. Theoretically, once a kernel is booted, it can also rely solely on any other available partitioning scheme that may be present. For example, I could use the GPT part only for the ESP, and load a kernel from it that only supports MBR. I could set up extended partitions (anything past partition 4, i.e. /dev/sda5 on SATA for the first extended partition), and Linux would pick it up and could use it as root partition, or as LVM, or as encrypted LUKS partition, whatever. For this to work, the kernel doesn't have to support GPT. The only thing that would NOT work, clearly, is being able to install new kernels to the ESP, i.e. if you compile a new kernel, it would have to be done from another system (like from a Live system). This COULD be a safety thing, since a running system would not be able to modify the kernel(s) at all. It would, however, make kernel updates much more complicated...

Just saying. But, my apology for getting GPT/ESP wrong. Sorry for that.

As a sidenote: On one of my systems I once used a USB stick for booting, back then (BIOS) with an MBR bootloader (GRUB) and a /boot partition (ext2). The main system (root, /home, /local and so forth) was on a APM partitioned disk. APM, the Apple Partition Map, is normally not supported on PC, but since Linux supports it, it was no problem.

That was my point. But of course, those are all very special cases.

Luttztfz (talk) 19:31, 24 May 2024 (UTC)

Addition: What I forgot: I once also used an LVM on an unpartitioned disk. I.e. I had two HDDs in the PC, the first had the bootloader and the /boot partition on it, while the second held the LVM without any partition map. The first HDD also had another OS installed (Windows), which of course then saw the second disk as "empty" and "unformatted". So you'd really have to know what you're doing. In such a scenario it is the same thing: once the kernel is loaded, it doesn't necessarly need support for the MBR, if -- and only if -- you can manage to work without access to the /boot partition (holding the kernels + initrds, if any). It greatly depends how the bootloader handles this, but since GRUB loads both the kernel and the initrd into memory, the kernel does not need to support the device where it was loaded from in order to be able to boot successfully... Again, for kernel updates this would add an additional level of complexity.

Luttztfz (talk) 19:40, 24 May 2024 (UTC)

In summary: yes, you are absolutely right, the kernel needs support for the disk partition schema (MBR, GPT, or even APM ;-), for the disk(s) it needs to access = minimum: disk with root partition (+ of course anything the admin wants to mount via fstab). If the root partition is on a GPT disk, CONFIG_EFI_PARTITION must therefore always be activated. Pietinger 20:39, 24 May 2024 (UTC)

EFI/Gentoo vs. EFI/example

Talk status

This discussion is done as of April 9, 2024.

What was so bad about calling it EFI/Gentoo/ as we did until https://wiki.gentoo.org/index.php?title=EFI_stub&oldid=1240620? Presently it looks like only installkernel used that path while the traditional manual installation goes into EFI/example. --Vaukai (talk) 13:06, 9 April 2024 (UTC)

When I edited the wiki article, I wanted to make sure that I didn't get in the way of any automated routines (e.g. grub -> \EFI\gentoo\), and I also wanted to deliberately point out that the name can be chosen arbitrarily; it just has to match the UEFI entry. But it can of course be changed again at any time if it makes more sense. -- Pietinger 14:30, 9 April 2024 (UTC)

Closing this, since Vaukai seems to have moved on.

— Waldo Lemmer 20:06, 16 May 2024 (UTC)