efi stub record is going out after reboot

[st834]

Hi,

i am try to install kernel as uefi stub. i have read this guide: https://wiki.gentoo.org/wiki/Handbook:A ... :_EFI_Stub. But my settings and new boot record are going out after rebboting my Hewlett Packard Pavilion laptop. I read the article about efibootmgr too. An Internet search indicates errors, but I am booming that this is not so, because the GRUB installation (now I would like to do it without GRUB) works without problems.

I would appreciate advice on how I can get the efi stub right.

Thanks!

[charles17]

for minimalistic setup based on gentoo-sources see https://wiki.gentoo.org/wiki/User:Vaukai/EFI_stub
there replace /boot with /efi

further options in https://wiki.gentoo.org/wiki/EFI_stub

[st834]

Thank you very much for your response. I replaced /boot with /efi, read these articles and checked the kernel settings.

If I try to UEFI file (select the *.efi file) at boot, the kernel behaves as expected.

When adding a boot entry:

Code: Select all

efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Gentoo" --loader "\EFI\Gentoo\kernel-6.6.30-gentoo.efi"

it is added and appears in the list after the efibootmgr -v command is invoked.

With a new start, the boot record is no longer visible in the boot menu. After booting the system from Live USB and calling again the command efibootmgr -v the created boot record is no longer visible.

/sys/firmware/efi/efivars is mounted as rw

Thaks!

[charles17]

can't you use onboard tool to access the bios / efi instead of bothering with efibootmgr?
i don't even have efibootmgr installed.

[st834]

I didn't use it before, but today I'll try it, thanks for the idea. I also found this: https://wiki.archlinux.org/title/Unifie ... boot_order, section 9.8 "Boot entries created with efibootmgr fail to show up in UEFI".

Thanks!

[pietinger]

st834,

I boot my kernel also directly from UEFI and wrote this article:

https://wiki.gentoo.org/wiki/User:Pieti ... l_via_UEFI

If your created UEFI boot entry disappears after system start there exist two reasons:

1. Your UEFI is faulty ... we had in our forum some systems where it was not possible to create a new entry (this is a definite violation of the uefi specification), OR

2. There exist no (valid) bin-file where the entry points to. Most (all?) UEFI systems check at system start EVERY entry it has and if that bin-file EXIST at the defined location; AND IF NOT, UEFI simply deletes this entry (so, yes, you can create every entry you want and you will even see it in "efibootmgr" immdediately after creating ... but if it is not correct it will be deleted after enxt system startup). =>

So, please check again if --loader "\EFI\Gentoo\kernel-6.6.30-gentoo.efi" really point to your EXISTING kernel (maybe a typo somewhere ?).


P.S.: Maybe give us the output of "efibootmgr" and a "ls -lR /efi"

[st834]

Thank you very much for your response. I will check all paths today and will read your article again carefully. I will write the results here. Thanks!

[charles17]

I didn't use it before, but today I'll try it, thanks for the idea. I also found this: https://wiki.archlinux.org/title/Unifie ... boot_order, section 9.8 "Boot entries created with efibootmgr fail to show up in UEFI".

Thanks!

there is some more lyrics on https://wiki.gentoo.org/wiki/EFI_System ... boot_items

[st834]

Hi,

continued to explore the topic.

I installed GRUB earlier with the --removable key. Without this key the bootloader was not visible in UEFI. Here I read https://superuser.com/questions/1756758 ... le-flag-do about with what path and with what name is the *.efi file of the bootloader with the -- removable key installed. Renamed the kernel from /efi/EFI/Gentoo/kernel-6.6.30-gentoo.efi to /efi/EFI/BOOT/bootx64.efi and the process went.

But doesn't Hewlett Packard firmware understand the other way? I bought this computer without pre-installed Windows and there is a version of non-Windows UEFI.

Thanks!

[Nowa]

I installed GRUB earlier with the --removable key. Without this key the bootloader was not visible in UEFI. Here I read https://superuser.com/questions/1756758 ... le-flag-do about with what path and with what name is the *.efi file of the bootloader with the -- removable key installed. Renamed the kernel from /efi/EFI/Gentoo/kernel-6.6.30-gentoo.efi to /efi/EFI/BOOT/bootx64.efi and the process went.

But doesn't Hewlett Packard firmware understand the other way? I bought this computer without pre-installed Windows and there is a version of non-Windows UEFI.

That sounds like buggy UEFI firmware, the only thing you can try here is update the firmware if there is an update available. Otherwise you cannot use EFI stub booting, and I recommend using systemd-boot or refind instead.

This is precisely the reason why this feature is only available in testing, and not stable. I wrote a bit more about this here: https://bugs.gentoo.org/932842#c3

[pietinger]

[...] Otherwise you cannot use EFI stub booting, and I recommend using systemd-boot or refind instead. [...]

I'm sorry if I have a different opinion here: Of course you can also boot a stub kernel directly with such a buggy UEFI by copying this stub kernel to the ESP in \EFI\BOOT\bootx64.efi, which @st834 has also done. The only disadvantage with this UEFI is that you can only boot this one kernel and cannot select others in the UEFI(-BIOS) (this means: if a kernel is not bootable, you have to boot from a boot CD and chroot into the gentoo system).

@st834

since you have overwritten the grub by copying your stub kernel (and because you probably don't want to have a boot manager) you can of course stay on this path. If you do want a boot manager, there is no reason to go to systemd-boot or refind ... your old grub will do just as well ... and you can reactivate it at any time by installing it (again) with paramter --removable.

[Nowa]

I'm sorry if I have a different opinion here: Of course you can also boot a stub kernel directly with such a buggy UEFI by copying this stub kernel to the ESP in \EFI\BOOT\bootx64.efi, which @st834 has also done. The only disadvantage with this UEFI is that you can only boot this one kernel and cannot select others in the UEFI(-BIOS) (this means: if a kernel is not bootable, you have to boot from a boot CD and chroot into the gentoo system).

Yes you are right, what I meant to say was not that it is not possible at all, but that it is not supported by sys-kernel/installkernel[efistub]. And that you'll therefore have to do the copying manually, or make your own custom kernel installation hook to do it for you.

I still highly recommend using systemd-boot or refind instead, or have a system recovery usb close by at all times

[pietinger]

[...] I still highly recommend using systemd-boot or refind instead, or have a system recovery usb close by at all times

What speaks against grub ?

It is even the default in our AMD64 Handbook:
https://wiki.gentoo.org/wiki/Handbook:A ... ault:_GRUB
Even I recommend systemd-boot only for systemd installations and for OpenRC also the grub:
https://wiki.gentoo.org/wiki/User:Pieti ... _at_Gentoo

[Nowa]

What speaks against grub ?

Nothing, it's just that users who try efistub booting usually do so because it is "simple" (as in less components, more direct, etc). If that fails, as it unfortunately does on many buggy UEFIs, then I'd recommend a light-weight chain-loading solution such as systemd-boot or refind, since those are relatively more simple and direct compared to GRUB. GRUB on the other hand is more of a "real bootloader", and less of a "chain loader" for EFI executables. But that's just my opinion.

[pietinger]

What speaks against grub ?

Nothing, it's just that users who try efistub booting usually do so because it is "simple" (as in less components, more direct, etc). If that fails, as it unfortunately does on many buggy UEFIs, then I'd recommend a light-weight chain-loading solution such as systemd-boot or refind, since those are relatively more simple and direct compared to GRUB. GRUB on the other hand is more of a "real bootloader", and less of a "chain loader" for EFI executables. But that's just my opinion.

Thank you very much for this explanation !

(Yes, grub is a bootloader and bootmanger in one; as a moderator I am of course bound to the specifications of our developers (AMD64 Handbook) ... I was already afraid that I had recommended systemd-boot for systemd systems ... and your recommendation here takes away some of that worry )

[st834]

Thakns a lot for all answers!

I'm sorry if I have a different opinion here: Of course you can also boot a stub kernel directly with such a buggy UEFI by copying this stub kernel to the ESP in \EFI\BOOT\bootx64.efi, which @st834 has also done. The only disadvantage with this UEFI is that you can only boot this one kernel and cannot select others in the UEFI(-BIOS) (this means: if a kernel is not bootable, you have to boot from a boot CD and chroot into the gentoo system).

I thought about it too, thank you. The technical solution may be to choose an alternative * .efi file manually in UEFI file expolrer, but this is possible if the computer is used by one person who installed the system.

Thanks!

[logrusx]

The boot entry may disappear if the files it points to disappear as well.

Also search the internet for similar problems with your particular hardware.

Best Regards,
Georgi

[st834]

Thank you very much for the answers and attention in this post!


Georgi: I looked, but unfortunately did not find much information about UEFI Hewlett-Packard like mine. I think the reason for this limited functional UEFI and the lack of information about it is that, I ordered a laptop without pre-installed Windows, which an exception for HP is.

I'll probably put an intermediate bootloader systemd-boot

Thank you very much !