RFC: move kernels out of /boot

Duncaen commented 9 months ago

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. (https://github.com/void-linux/void-packages/issues/46006)
Maybe good for raspberrypi kernels too, let install hooks move them to the weird kernel8.img names?

dkwo commented 9 months ago

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

mbsmith commented 8 months ago

I'm all for it.

classabbyamp commented 8 months ago

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.

Jipok commented 8 months ago

I'm glad that at least someone is thinking about solving an important problem(https://github.com/void-linux/void-packages/issues/46006). But getting UKI involved annoying me. Are the goals of this decision even that useful to people? It seemed to me that it was created only to oppress people and the benefits offered are so minimalistic that the quote “Those who are ready to exchange freedom for security are worthy of neither freedom nor security” comes to mind. UKI gives "Providing a fully verified boot process", that is, bad corporations can prohibit the user from changing the kernel (and, accordingly, the system) as is the case now on Android. And other delights in the form of the inability to boot if you live in the “wrong” country. And also contributes to the implementation of DRM. And vendorlock. LinuxD damn.

CtrlC-Root commented 7 months ago

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[bot] commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

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.

dkwo commented 2 months ago

As a good byproduct, it should become not necessary anymore to set preserve=yes in kernel templates.

Duncaen commented 2 months ago

No preserve=yes just makes xbps not remove any files on update, we still need this to not delete modules from the current or old kernels.

void-linux / void-packages

RFC: move kernels out of /boot #48024