Talk:EFI stub kernel

Note
This is a talk page. Please add newer comments below older ones, and sign your comments using four tildes (~~~~). When adding a new section (at the bottom of the page), please mark it as "open for discussion" by using {{talk|open}} so it will show up in the list of open discussions.

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)