RFC: move kernels out of /boot

[Duncaen]

Some distributions have started to move the kernels out of the boot directory by default and let the install hooks etc handle copying them over.

The kernel hooks would then copy the kernels into /boot, users could then change the hooks to i.e. allow to create unified kernel image (UKI) executable without the extra duplication between the UKI file and the package dropped kernel binary.

Seems like the "standard" location for kernel files would be /usr/lib/modules/${VERSION}/vmlinuz.

Advantages:

• kernels can be copied to /boot and modified for i.e. signing.
• kernels don't have to be copied to /boot for UKIs.
• kernel.d post install moves kernels after the initramfs hook, the stupid grub mkconfig wouldn't pick up kernels for which initramfs generation failed. ("linux6.5: configured successfully" without initramfs #46006)
• Maybe good for raspberrypi kernels too, let install hooks move them to the weird kernel8.img names?

[dkwo]

Good idea. This is also useful on apple silicon, where you concatenate a payload for m1n1.

[mbsmith]

I'm all for it.

[classabbyamp]

no it doesn't. this is only for how they are packaged:

The kernel hooks would then copy the kernels into /boot, users could then change the hooks to i.e. allow to create unified kernel image (UKI) executable without the extra duplication between the UKI file and the package dropped kernel binary.

[CtrlC-Root]

I think this would be valuable especially if there is an easy way to make local changes to or extend the hooks in order to implement custom behavior.

Background context:

I have been attempting to use Void Linux on embedded systems with fairly limited disk space. These systems typically have a separate /boot partition and one challenge I've run into has been sizing it appropriately; if it's too large you end up wasting precious space but if it's too small you risk breaking system updates (or requiring manual intervention). This is made more complicated by the fact that it's difficult to predict the size of generated initramfs images ahead of time (since they occasionally increase). Right now I have solved this with a script that wraps xbps-install and makes sure you end up with the right things in /boot (it's not 100% full and it has files necessary to boot) after it's done running. I have seen the warnings printed during xbps-install that mention the system may not be bootable due to low disk space in /boot but (1) assuming I've sized it appropriately it should be mostly full all of the time and (2) I know what the right thing to do is in my situation and I'd like to have it done automatically so I can run xbps-install unattended.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[CtrlC-Root]

I think this is still valuable. I have several systems where I regularly have to make sure to never have more than two kernels (i.e. upgrade, reboot, and then vkpurge) in order to make sure I don't exceed the space allocated to the boot partition.

[dkwo]

Quick question: what is the consensus about a place for config and sysmap, currently also in boot

vinstall .config 644 boot config-${_kernver}
vinstall System.map 644 boot System.map-${_kernver}

as well as device trees (for the archs that have them), e.g. INSTALL_DTBS_PATH=${DESTDIR}/boot/dtbs/dtbs-${_kernver}?
This just is in case I want to start experimenting with the asahi linux kernel.