[SOLVED] Any suggestions to auto-install the kernel into the EFI?

hazel · 05-03-2024, 08:09 AM

I assume that these unexpected reboots are cause by momentary electrical power cuts. Not a serious problem in London but it did happen to me once.

I am beginning to think that it might be worth running elilo and grub in parallel: elilo as my default bootloader and grub for anything that requires multiple different kernels. I could let GRUB boot a symlink; that way I wouldn't have to edit it at all, just reset the link as required.

On Lenovos, you can always access alternative boot options by pressing Enter during boot (or by pressing a special "Menu" key but I can never remember if it's F9 or F12; if you choose the wrong one, it tries to do a wireless boot).

I have been studying the LFS installation of grub. It's very different from the standard version with all those messy scripts. In LFS, you don't use the scripts at all; the book shows you how to write your config file by hand just as you would for reFind or elilo, which removes a large part of my objection to the program.

Didier Spaier · 05-03-2024, 01:57 PM

Quote:

Originally Posted by hazel

I am beginning to think that it might be worth running elilo and grub in parallel: elilo as my default bootloader and grub for anything that requires multiple different kernels.

This is uselessly complicated, Madam.

It would be a lot simpler to have in the ESP a single EFI application, in this case the OS loader installed by grub that you will never need to update (thus zero risk of corrupting the file system) and manage all your systems running grub-mkconfig whenever needed. This way you will never need to use efibootmgr any more.

You will just need to associate to each kernel a dedicated initramfs before running grub-mkconfig. I suggest using dracut for that.

lazardo · 05-06-2024, 05:30 PM

I prefer simiple, discrete steps, eg, none of: initrd, grub, softlinks ala vmlinuz -> $KERNEL. Essentially the same as /etc/lilo.conf minus 'lilo -v'. Does require scripting else you go blind.

Build new $KERNEL, then:
1. mount /boot/efi (unmounted in /etc/rc.local, or not in fstab, or '-o auto' in fstab)
2. copy new $KERNEL to /boot/Slackware
3. append <template> to /boot/Slackware/elilo.conf
4. unmount /boot/efi

<end of scene>

Code:

$ mount -v |grep efi
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

$ ls -l /boot | grep efi
lrwxrwxrwx 1 root root       19 Dec 27  2022 Slackware -> ./efi/EFI/Slackware
drwxr-xr-x 3 root root     1024 Dec 31  1969 efi
-rwxr-xr-x 1 root root   216219 Jun 12  2018 elilo-ia32.efi
-rwxr-xr-x 1 root root   238531 Jun 12  2018 elilo-x86_64.efi

$ ls /boot/Slackware
elilo.conf	     memtest86+-x64-6.10.efi  vmlinuz-6.1.80v1	vmlinuz-6.6.10v1
elilo.conf~	     vmlinuz-5.15.137v0       vmlinuz-6.1.81v1	vmlinuz-6.6.8v1
elilo.efi	     vmlinuz-5.15.137v1       vmlinuz-6.1.82v1	vmlinuz-generic-6.6.8
memtest86+-6.10.bin  vmlinuz-5.15.143v1       vmlinuz-6.1.85v1	vmlinuz-huge-5.15.117

# <template>
image=vmlinuz-$KERNEL
        label=$KERNEL_SUBVER
        read-only
	root=/dev/nvme0n1p3 
	append=" resume=/dev/nvme0n1p2 amd_pstate=passive mitigations=off raid=noautodetect nr_cpus=4 "

SlackCoder · 05-07-2024, 11:20 AM

@lazardo do you keep the old kernel modules installed too?

SlackCoder · 05-07-2024, 11:20 AM

Quote:

Originally Posted by SlackCoder

For those willing to automatic things a bit, I've created a service which installs the kernel on updates. It watches for changes to the kernel, or firmware and modules if mkinitrd.conf is defined. The program then waits for the install programs to finish before updating the EFI.

https://git.server.ky/slackcoder/efi-sync/about/

Slackbuilds here:
https://git.server.ky/slackcoder/sla.../tree/efi-sync

This is now on slackbuilds.org

lazardo · 05-08-2024, 01:30 PM

Quote:

Originally Posted by SlackCoder

@lazardo do you keep the old kernel modules installed too?

Code:

$ ls /lib/modules
5.15.137v1  5.15.143v1	6.1.80v1  6.1.81v1  6.1.82v1  6.1.85v1	6.6.10v1  6.6.8  6.6.8v1

Update: The answer is yes, else booting one of the old kernels would fail, eg, kernel+modules s/b viewed as a single blob stored in multiple pieces.

The context below is still valid but not necessarily relevant to the question.

Larger context:

Keep the original Slackware install huge kernel+modules until the system is known to be stable, like a life jacket.

Phase 1. Customize by reducing components in huge not needed, and architecture+hardware tuning using 'make nconfig', each time bumping CONFIG_LOCALVERSION.

During this phase there may be 6-8 kernel versions and their respective /lib/modules/x.y.z. Note that Phase 1 is not technically necessary, rather it greatly reduces build time+resources, even with ccache+distcc, and I never use initrd.

Phase 2. As soon as the reduce/customize/tune phase is stable, the old kernels+modules are purged: 'removepkg' for Slackware kernel, 'rm /boot/*-x.y.z${LOCALVERSION}*; rm -r /lib/modules/x.y.z${LOCALVERSION}' for custom iterations.

When the LTS kernel branch gets bumped, it is tracked by applying only incremental patches to the now stable+tuned base:

Code:

rsync rsync://rsync.kernel.org/pub/linux/kernel/v6.x/incr/

Phase 3. After each new incremental build is known to be stable, the older iterations are purged, but always keeping a small pool of previous incremental builds as boot failure fallback.

Typically there are two tracked LTS branches, eg, 6.1.x and 6.6.x, with two to three kernel+modules for each track. For major jumps, like 6.1 + 6.6, apply the stable .config to the new release and back to Phase 1.

This workflow helps me stay current with kernel development and still have a stable platform. You can always fetch the Slackware huge kernel+modules in patches/packages when things go completely septic