genkernel, new kernel, efi entries... can I use a symlink?

[sixtysixtysix]

I hope I manage to explain the following clearly. What I'm trying to do is implement something I see by default in my Arch installation and which I have found massively useful.

I use GPT partitioning for all disks - NO need at all to go anywhere near Windows/MBR or, in fact, grub.

I am set up to boot via efi stub. I presently use efibootmgr to write/replace the entries in NVRAM. Since there's no option to edit an entry (that I'm aware of) it requires me to delete and re-write that entry every time the kernel version changes, or I've done something else to my boot parameters (e.g. load a module). Since I use PARTUUID entries with hibernate that's quite a lot of typing.

It's clunky to keep deleting/re-writing those entries, and even the tiniest syntax error will cause a panic or boot failure.

The way that Arch handles kernel upgrades is that it has a hook which automatically regenerates an Initramfs while the entry in the bootloader points at a file which ... is symlinked? (is that right?) to the new kernel. Thus whichever specific version number is built, the bootloader entry itself never needs editing.

Is it possible to do what I'd like i.e. create an entry in efi that points to a label such as "Gentoo" and which will never need replacing despite the actual version number of the kernel? I realise that Arch is systemd, and I'm using openrc.

Subsidiary question: would it make any difference if I overcame my dislike of MBR and actually installed grub on the disk? Since grub has a simple way to update itself, anything that saves the faff of keep messing about inside efibootmgr is a good idea.

[grknight]

[pietinger]

I have all my systems installed with grub2 as described in our AMD64 handbook. After the main installation I made the kernel bootable from UEFI (=efistub-kernel) and copied it WITHOUT version information into \EFI\...[mysys]...\bzImage.efi

so I have two boot-entries in my UEFI-BIOS. One pointing to grub2 and the other pointing to my efistub-kernel.

After (successfull) booting my new kernel from UEFI I do simply:

[pietinger]

[Leonardo.b]

Write a script to handle your kernel upgrades.
It is more convenient.

[sixtysixtysix]

woah! Thanks... you made me look - I had no idea grub2 in Gentoo could be installed directly onto GPT! That'll teach me to keep referring to the Arch wiki at times!

So, a couple of other questions then, because for sure I'm going down this road. Anything that stops me ever having to manually edit those efi entries is fine by me

the process described by pietinger:

I sort of follow but not entirely clear. why do you duplicate? Or is that simply the default outcome of the method you use?

I followed the Gentoo wiki and have a /boot/efi/boot/bootx64.efi which is a copy of "vmlinuz-<version>.img". Is there any reason to use bzImage instead? Very happy for you to point me at some docs or a wiki page.

You allude to what I'm trying to achieve i.e. booting a particular file by name, and it's the name that I want fixed. So copying something into the new file achieves this, but then if I go with grub, then surely by updating grub I'm letting it do the exact same thing really?



Guess I'll find out more once I install and configure grub, but tbh I'm very happy it will just run without me adding any disk partitions.

One other question: the wiki page says to add "pc" USE flag for installation on bios. I don't need this, yet the USE flags suggested by emerge include "pc". I can disable it, but what's the outcome? Should I install the whole shebang for use with EFI?

[pietinger]

First of all you have to know about UEFI-BIOS:

UEFI searches in all partitions marked as ESP (efi system partition) for bootable binaries. There is ONE name - "bootx64.efi" - which is a default and will be found ALWAYS (when it is in \EFI\boot) - even without a boot-entry. This is the reason why on a USB-stick (where there is no boot-entry) the name must be "bootx64.efi". If you want to boot another entry you HAVE to make an entry (with "efibootmgr") in UEFI-table.

Second: I am using grub2 not as primary backup (it is only my second backup) because I have another bootable (efi-stub-) kernel. This is because I am using IMA. Look to my table:

[sixtysixtysix]

thanks again, pietinger for taking the time to explain carefully.

All sorted now, after a confusing couple of hours with Grub2. I'll explain because a) grateful to you for taking the time, thus not ignoring b) in case it's at all helpful elsewhere.

What it took me quite a while to figure out, after many unsuccessful attempts at booting (!!) was

that the Gentoo wiki on grub installation and config differs from the AMD64 wiki in a vital respect: they use slightly different paths for the EFI! To explain - I have simple /dev/sda1, /dev/sda2, dev/sda3 all properly formatted. /dev/sda1 is a VFAT partition, mounted (in fstab) at /boot

having previously followed the wiki for efibootmgr, I have

/boot/efi/boot/

in which is

bootx64.efi

Trouble was, that by following the paths listed in the grub wiki, after I ran

[pietinger]

[Goverp]

As what's now an aside, the reason you can't use a symlink is that the EFI partition is FAT32, and that doesn't support symlinks.
If you were to revert to using the kernel EFI stub loader, you'd probably want to install your new kernels as "vmlinuz" rather than "vmlinuz-5.16.97" or whatever, which requires changes to whatever procedure you use to install kernels. But then you get the problem of recovery when it breaks. At a minimum, you'd want to copy vmlinuz as vmlinuz.old, and perhaps have an EFI entry to boot that. Ideally, you'd install the new kernel as vmlinuz.new first, test it, and once successful, copy vmlinuz->vmlinuz.old and copy vmlinuz.new as vmlinuz. (Use copy rather than rename so as not to leave missing files to stop the EFI boot process deleting the boot command entries.)
_________________
Greybeard

[sixtysixtysix]

Thanks, Goverp. Makes perfect sense now - I'd been wondering.

Recovery when it breaks? Yes, I can see that. To date all I've been doing (since I have two disks with working OSes) is that if my latest Gentoo kernel fails, I simply boot up in the other OS and either rewrite the NVRAM entry (this is the most common cause of failure) or failing that, boot with the live install USB.

I can see that, with Gentoo long since the daily driver, it's probably wise to have something a bit quicker/more convenient for correcting failures.

I suppose this simply leads me back to an aspect of the original post... I installed grub. Sure, it works. But unless I have an older kernel installed AND any real need to then boot to that one instead, it just felt like unnecessary overhead. The one important thing it did do was make a better job of writing the entry into the efi partition.

I see that it's possible to create a boot text menu (if I'm understanding Syslinux wiki correctly) so perhaps my answer would be to create a config file for Syslinux, register that as the loader, and then select older/previous kernel from there.

It's completely true that in all my previous uses of Linux (Manjaro, Fedora, Ubuntu) I allowed the full distro to set me up, which tended to always use Grub and a selection menu. But since I switched to running only Linux, and furthermore that I only ever need(ed) one single, solid OS, I don't really see the point in fancy boot loaders. If I think of all the time I wasted over the years by obsessing over the eye candy.... installing Plymouth in Arch even - JUST so that I could stare at something pretty for a few seconds. Even mroe so now that I try hard as I can to make the machine boot as fast as possible... WHY would I want to stop and stare at a boot screen? Each to their own etc.

I now see that by auto logging direct into xfce4 session via X, my longest delay is waiting for the blank screen to acquire wallpaper and icons. Now... if only I knew how to speed that up!!?

[Hu]

As an incidental recovery tip, some UEFI firmware offers a modestly capable shell, along the lines of the old MS-DOS COMMAND.COM shell. In such firmware, you can drop to that shell, then run a UEFI application of your choice (including a Linux kernel with EFI stub) directly from the shell. This may be more convenient for a one-off repair when you built a bad kernel or bad default EFI entry, since it can let you boot the good kernel directly from the firmware. I wouldn't recommend this as a standard bootloader, but it can get you back into your normal system to let you do the repairs using Linux tools, and might be more convenient than needing an alternate working OS.

[sixtysixtysix]

Thanks, Hu

Very good idea! In fact I'm still learning... and now that I have a stable installation, and which I understand reasonably well, I can get to doing some nice extras like scripts and helpers. In fact the .iso I use for Arch installation has a nice little UEFI shell that makes editing the boot entries supremely easy. Even better, it can be installed in an efi partition somewhere on the boot mount... So I'm going to look into doing that for exactly the reasons you mention i.e. make it easy to get in and edit an entry without the hassle of rebooting and remounting disks just to get at an entry.

I'm also about to look at writing/copying parts of the install scripts and place them on the live sticks as well, to save all the typing

[dcrook]

You might want to look at using rEFIned for managing your boot process since it can just can for kernels installed in /boot and automatically boot the newest one.
https://wiki.gentoo.org/wiki/Refind

[sixtysixtysix]

thanks for the tip dcrook, but I want as little as possible in between pushing the power button and having a working desktop.

I ended up using Grub for Gentoo because the alternative was just not worth the pain. Even now I'd like things to take less time hahaha. Oh dear, I should probably get out more!