What are some good ways on upgrade to automatically install the kernel into the EFI?

The Arch linux wiki describes a number of ways. Bind mounting the EFI onto /boot would be nice, but it would need to use the soft-links created by Slackware's kernel package on install. The EFI's FAT filesystem format does not support soft-links.

Also, soft links only work when the storage spaces for both source and target are mounted which is not the expected situation pre-boot.

Assuming you are using elilo with Slackware, switch over to grub bootlloader after running grub-mkconfig edit /boot/grub/grub.cfg to use vmlinuz-huge symlink and change root=UUID=xxxx-cxxx to root=/dev/xxxxx
If can boot the huge kernel without an initrd this should work

3 members found this post helpful.

I use a 'slackup' post-install script triggered by kernel-modules package updates to copy them over to the efi partition:
https://github.com/glangshaw/slacksc...kernel-modules

1 members found this post helpful.

The simplest without having to install any packages is to add this to your /etc/rc.d/rc.local. It only works if updating only the kernel without the initrd is sufficient. You'll need to replace [EFI kernel location] to the one used by your system.

Note: Edited to remove installpkg patch

Are you using an EFI stub loader to directly boot the kernel? If so, I just copy the new files to the EFI system partition after booting with the old kernel, then reboot. As long as the file names remain the same. Just make a script to do this.

This assumes you don't use ELILO, GRUB, nor any other bootloader.

I have a script to update many things I need to use. One of its functions is upkernel(). It does exactly what you are looking for and many more. It's not pretty but serves me well for many years. If you want to take a look:

https://gitlab.com/-/snippets/2012761#L145

You may safely remove many of its extra features to fit your needs.

I wouldn't feel safe automating such a vital function. I copy my kernel and initrd to the ESP by hand and then edit elilo.conf. It only takes a minute or so.

...

EDIT: I use this script just in case you like something like this https://github.com/rizitis/siab

1 members found this post helpful.

Yes, but that is some minute(s) per machine. If you are responsible for keeping many machines up to date automation like that script is really a must. You will feel safe with automation if you first test the update on some (possible virtual) machine(s) and know that you are comfortable booting from installation media or some other live media to fix anything that has been messed up.

On the other hand, with only a single machine to care about you would spend more time configuring and testing an automated routine than to fix your single machine.

regards Henrik

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

1 members found this post helpful.

Solution: use GRUB and let the kernel and initramfs stay in /boot, where they belong.

5 members found this post helpful.

I'm going to side with colorpurple21859 & Didier on this one - if you want to automate and use current with it's frequent kernel updates: Grub is the way to go. I automate slackpkg with modifications to /usr/libexec/slackpkg/functions.d/post-functions.sh and have multiple kernels.

Current with multiple kernels really hammers the fragile vfat EFI partition and I have corrupted this partition more than once with elilo. Use Grub and it remains untouched.

Can you expand on this, please? In what sense is the ESP "fragile". I am asking because I have a serious problem with current kernels that will require some kind of bisection and that means copying over a lot of kernels. I very much don't want to switch from elilo to GRUB, partly because I dislike its complexities, and partly because my machine's UEFI doesn't respond well to attempts to switch boot order via efibootmgr.

I think it because:
1. ESP partition is FAT32 partition
2. FAT32 does not handle unexpected reboot well
3. linux will mount FAT32 partition with write cache enable
4. If we write the new kernel, while waiting for system to flush the data and we got unexpected reboot, file will get corrupt or sometime, the whole partition get corrupt.

1 members found this post helpful.