UEFI kernel Stub without copying or renaming the kernel

iTanguy · 2014-09-07 09:11:32

Hi,
I am discovering UEFI to prepare my new PC setup, which will only run ArchLinux, as my other personal & professional PCs.

As the Linux Jernel offers a UEFI stub, I am considering avoiding using a "external" boot loader : I don't really see the point in my use case (no double boot).
Reading carefuly the Wiki pages, it seems that it is required to either copy the kernel (and eventually the initramfs images)

mv /boot/vmlinuz /boot/eif/EFI/archlinux/vmlinuz.efi

or at least rename it, either manually or via a systemd/mkinitcipo script.
I may have misinderstood, as I find the information and instructions quite confusing on the Wiki (but I need to better understand before suggestin any improvement).

I don't like much the idea of coyping the kernel, I 'd like to have system configuration as little modified as possible, as it's the easiest way to make it last and benefits from ArchLinux's evolutions in the coming years (and that's what can be expected from a Linux distribution, by the way : avoid writing plenty of administration scripts for basic stuff).

Hence, a few questions :
- is it required to have an file named with a .efi extension ?
- will it work with a gzip-compressed image vmlinuz (which is ArchLinux's default) ? I am abit surprised that it could work
-a symlink would do the copy/rename trick... but we're stuck with FAT32, which does not offer symlinks... or did I miss something ?

My impression so far is that Linux UEF stub (or ArchLinux) is not really ready yet. If you confirm that, I will give up and use what should be useless know, a boot loader.

Thanks

Last edited by iTanguy (2014-09-08 19:34:08)

Head_on_a_Stick · 2014-09-07 10:52:09

I'm confused: why do you think you have to move the kernel?
The simplest solution is to mount /boot on the EFI system patition (rather than /boot/efi or whatever), and the use efibootmgr...
https://wiki.archlinux.org/index.php/EF … ot_manager
EFISTUB is ready (I have used it myself with no problems), however the firmware programmers cannot code for s**t and my motherboard will only retain the first two NVRAM entries & will overwrite any subsequent entries if the "Legacy" mode is engaged...
In short, I would recommend gummiboot as a more reliable method (this is also a boot manager, rather than a bootloader).

Last edited by Head_on_a_Stick (2014-09-07 10:52:37)

jasonwryan · 2014-09-07 17:15:10

See: https://www.happyassassin.net/2014/01/2 … work-then/

teateawhy · 2014-09-07 19:00:46

iTanguy wrote:

As the Linux Jernel offers a UEFI stub, I am considering avoiding using a "external" boot loader : I don't really see the point in my use case (no double boot).

There are good reasons to make use of a boot loader, even without dual boot. For example a boot loader allows you to edit the kernel parameters easily without changing the EFI firmware entry.

- will it work with a gzip-compressed image vmlinuz (which is ArchLinux's default) ? I am abit surprised that it could work

EDIT: Yes that works and here is how:
"vmlinuz is not merely a compressed image. It also has gzip decompressor code built into it"

-a symlink would do the copy/rename trick... but we're stuck with FAT32, which does offers symlinks... or did I miss something ?

The kernel (or bootloader) has to be located on the FAT32 EFI System Partition, so that the UEFI firmware can read it. Even if FAT32 had symlinks: Symlinks are not understood by the UEFI firmware, let alone a symlink to a filesystem that is not FAT32.

My impression so far is that Linux UEF stub (or ArchLinux) is not really ready yet. If you confirm that, I will give up and use what should be useless know, a boot loader.

It is ready now. But using the stub is not as convenient as booting with a boot loader.

Last edited by teateawhy (2014-09-07 19:04:05)

WonderWoofy · 2014-09-08 00:05:14

You should know that there exist things called boot managers in addition to boot loaders. These are useful, fast, and additionally rEFInd also allows you to load a filesystem driver that allows it to read kernels (and initramfs') off of a number of filesystems.

When I first started using UEFI, I too wanted to try to avoid using any kind of middle-man in the process. But the advantages of a boot manager far outweigh the "light weight" of having none. Simply the ability to adjust the kernel command line on the fly is reason enough in my opinion.

iTanguy · 2014-09-08 20:09:49

Thank you all, it really helps !

I am back from weekend (I was away from my new PC, so I could hardly answer before) and could do a few tests this evening (before I had to leave the screen for a live TV program that could not be missed by my roomate).

So
- still did not manage to make the Linux Efistub boot directly, using efibootmgr, nor from the efi shell v1 included on the archlinux installl image
- gave a try to gummiboot which indeed worked, it booted on disk to Arch at least once \o/ (then it was time for the Live TV program...)
By the way, it means that booting to the eifstub indirectly works, as gummiboot apparenlty requires a EFI-stub linux image.

teateawhy wrote:

There are good reasons to make use of a boot loader, even without dual boot. For example a boot loader allows you to edit the kernel parameters easily without changing the EFI firmware entry.

Agree, though I don't modify the boot options often (much less often than the kernel updates on ArchLinux).
I am not against the idea of a boot manager, I have been using lilo & grub for years.
And maybe I will also install linux-lts as a fallback kernel as well, so that could be another reason.

But I still want to give the direct-to-EFISTUB way a try.
You may see it as curiosity. But if (for simple use case, with limitations) it works, I will at last consider UEFI as a real improvement over BIOS (for my simple use cases).

teateawhy wrote:

- will it work with a gzip-compressed image vmlinuz (which is ArchLinux's default) ? I am abit surprised that it could work
EDIT: Yes that works and here is how:
"vmlinuz is not merely a compressed image. It also has gzip decompressor code built into it"

Thanks, this is very interesting. I like to know how, why things work, or eventually don't. (in fact, I am stupid, I should have guessed: how could it work elseways ?)

teateawhy wrote:

My impression so far is that Linux UEF stub (or ArchLinux) is not really ready yet. If you confirm that, I will give up and use what should be useless know, a boot loader.
It is ready now. But using the stub is not as convenient as booting with a boot loader.

Hum re-reading myself, my words are far more agressive and definitive than what I meant. Especially considering that I had only spent 2 hours to read and try booting. But today, I am still disappointed not to have managed yet to boot to the EFI Stub directly (after more reading, these questions and answer and 2 hours of tests tonight).

Hopefuly, the problem is "only" my poor quality EFI firmware ? (I have an Intel NUC D54250WYK, by the way)
Tests to be continued tomorow (no Live TV program scheduled ).

iTanguy · 2014-09-13 14:16:43

The UEFI Stub works nice after a BIOS update.

Fixed

Thanks everyone

Arch Linux

#1 2014-09-07 09:11:32

UEFI kernel Stub without copying or renaming the kernel

#2 2014-09-07 10:52:09

Re: UEFI kernel Stub without copying or renaming the kernel

#3 2014-09-07 17:15:10

Re: UEFI kernel Stub without copying or renaming the kernel

#4 2014-09-07 19:00:46

Re: UEFI kernel Stub without copying or renaming the kernel

#5 2014-09-08 00:05:14

Re: UEFI kernel Stub without copying or renaming the kernel

#6 2014-09-08 20:09:49

Re: UEFI kernel Stub without copying or renaming the kernel

#7 2014-09-13 14:16:43

Re: UEFI kernel Stub without copying or renaming the kernel

Board footer