efibootmgr: change kernel hook logic

[jastintime]

creating new firmware entries with every kernel configuration is dangerous. This will instead create an 'A' and 'B' kernel and initramfs. This does not modify any firmware entries but instead puts a kernel and initramfs in fixed locations to allow the user to manually create an EFI entry for their current kernel and previous one.

The post-remove hook didn't seem to have a use anymore so I removed it.

The script does NOT deal properly with the efi partition being anywhere but /efi/boot, I'm not sure of a good way of finding it and guidance would be appreciated.

Users will need to create their own entry with efibootmgr, I can add this to the void documentation.

Discussed in #58384

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture, x64 glibc

[jastintime]

@ahesford I implemented the logic as you described alongside with a backup kernel, I'd appreciate if you could give me some feedback on this PR.

Thank you

[jastintime]

the names should also probably be changed, I did "A" and "B" but maybe "current" and "previous" are better.

I only tested this with the "linux" package kernel, which is currently 6.12, testing the other provided kernels would be a good idea.

[hippi777]

is there a way to retrieve the verisons of those A/B files? i would store it somewhere if it can't be obtained after this change... otherwise i like the idea, but atmega showed me that it is hard to kill such with many writing cycles

[jastintime]

is there a way to retrieve the verisons of those A/B files?

you could store it, it can also be retrieved straight from the efi files with file as following
file vmlinuz-A.efi | awk '{print $9}'

[ahesford]

I'm not sure this belongs in the efibootmgr package, because it really has nothing to do with efibootmgr. It is better to just drop the hooks from efibootmgr altogether. Something like this hook, if it is sufficiently general, belongs somewhere like linux-base. That said, this probably needs a lot more sophistication to be included as a general-purpose hook:

1. Names like "current" and "previous" are definitely more descriptive than "A" and "B", although specifics can be bikeshedded.
2. The path to the EFI directory must be configurable, and should default to an appropriate subdirectory of the EFI system partition, for example, /boot/efi/EFI/void.
3. The target name should probably be configurable, for example, to allow the kernel to be copied to the fallback location at, e.g., /boot/efi/EFI/boot/bootx64.efi.
4. There should be some logic in place to avoid thrashing between kernel series. Most users probably do not want an update of linux6.6 to replace their linux6.18 kernel just because the package was updated.

[jastintime]

I'm not sure this belongs in the efibootmgr package, because it really has nothing to do with efibootmgr. It is better to just drop the hooks from efibootmgr altogether. Something like this hook, if it is sufficiently general, belongs somewhere like linux-base. That said, this probably needs a lot more sophistication to be included as a general-purpose hook:

Sure I'd be fine if this were moved elsewhere.

Names like "current" and "previous" are definitely more descriptive than "A" and "B", although specifics can be bikeshedded.

I agree, I can change them. A and B are just what came to mind first, I can change it to whatever people prefer.

The path to the EFI directory must be configurable, and should default to an appropriate subdirectory of the EFI system partition, for example, /boot/efi/EFI/void.

Sure.

The target name should probably be configurable, for example, to allow the kernel to be copied to the fallback location at, e.g., /boot/efi/EFI/boot/bootx64.efi.

Sure. For both of these configurations would that just be a variable in efiootmgr-kernel-hook(or wherever this gets moved to)?

There should be some logic in place to avoid thrashing between kernel series. Most users probably do not want an update of linux6.6 to replace their linux6.18 kernel just because the package was updated.

This one is hard to do and I'm not sure of a way to do so that isn't complicated. There are plenty of cases where a user does want linux6.6 to replace their linux6.18 such as in the case of a kernel regression. Since this should not be the default I found the simple logic to be sufficient but if anyone has any ideas here I'm open to them.

[ahesford]

There should be some logic in place to avoid thrashing between kernel series. Most users probably do not want an update of linux6.6 to replace their linux6.18 kernel just because the package was updated.

This one is hard to do and I'm not sure of a way to do so that isn't complicated. There are plenty of cases where a user does want linux6.6 to replace their linux6.18 such as in the case of a kernel regression. Since this should not be the default I found the simple logic to be sufficient but if anyone has any ideas here I'm open to them.

I think you've misinterpreted the behavior. Your hook will fire with every kernel update, which means that a linux6.6 update that comes after the user installs linux6.18 will cycle the kernels and replace the "A" version with linux6.6. Most users probably do not want this.

The existing hook avoids this problem by preserving existing boot order and creating a new entry for every minor kernel series. The user decides independently which entry should boot, and this will not change unless a kernel series is removed entirely and the corresponding entry is removed. Your proposal requires more sophistication to allow users to prevent updates of one kernel series from stomping on another.