Bastian, thanks for pinging me about your message that I missed in November. On Thu, 2021-11-11 at 11:47 +0100, Bastian Blank wrote: > Hi folks > > I'd like to propose some pretty drastic reshaping of the way kernels, > initrd and bootloaders interact with each other and with dpkg. > > Traditionaly we install kernel images and configs into /boot. During > installation we generate files in /boot (and housekeeping in /var/lib). > Setup symlinks, sometimes in /boot, sometimes in /. This is then used > by bootloader scripts to generate something bootable. > > This poses several problems: > - We still have bootloaders without config generation, aka it relys on > symlinks and may even break on runtime if they are changed. But > symlinks and bootloader setup are not handled by the same package. > - A lot of bootloaders require special filesystems or other settings. > Now this more and more clashs with dpkg, as dpkg can't write data on > those filesystems (FAT for EFI is a common example). I'm not sure how common it is to make the EFI boot partition be /boot. I do know Raspberry Pi users expect /boot to be the FAT partition that its boot ROM uses, and it is a common complaint that our linux-image packages are not upgradable in such a configuration. > - You need to know what you want to boot and need to install your system > accordingly. > - It does not fit anywhere in the regime of /usr-merge. > > So my rough ideas would be: > - Everything from kernel packages is installed somewhere in /usr/lib. I had been thinking the same thing myself for a while, but didn't get round to working out any details. So, you can count me as cautiously positive toward this. One objection would be that this may (depending on the boot loader and storage configuration) require even more storage for the kernel, which may matter for some smaller systems. > Aka the images itself and, if we got to it, pre-built initramfs and > even unified images (initramfs integrated). > - Everything generated on installation by e.g. initramfs generators is > put somewhere into /var/lib/. > - The bootloader stuff is responsible to put everything where they want > to have it. So those can tightly control what they need setup in what > way. I think we would need to have some kind of compatibility fallback behaviour for a while, but it does make sense to delegate this to the boot loader. > How it could like like: > - /usr/lib/kernel/linux_5.14.0-1-amd64 > - kernel (linux can boot efi, bios and xen) > - (initramfs.$package) > - (kernel.efiunified) > - /usr/lib/kernel/xen_4.14 > - kernel.pcbios > - kernel.efi > - /var/lib/kernel/linux_5.14.0-1-amd64 > - initramfs.$package (you could have multiple initramfs generators > installed) > - data.$package This might be a bit too flexible. How do we avoid having huge numbers of boot menu entries? How is the default option decided? > The interfaces: > - kernel tells installed initramfs generators to do their magic on a > single kernel > - kernel tells installed bootloaders to do their magic on a single > kernel > - initramfs on installation wants to build all initramfs > - bootloaders on installation want to do their magic > > All the tracking and signaling should be in one package. > > What are your thoughts about that? So this would involve quite a lot of packages: - linux (Debian) - linux (Ubuntu) - linux (upstream deb-pkg) - xen - kfreebsd-N - grub - flash-kernel - all those obscure boot loaders we hoped were gone It's going to take some time and effort to change all of those, so we would need good arguments for why all the other maintainers should bother with it, and we would need to plan for a gradual transition. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are.
Attachment:
signature.asc
Description: This is a digitally signed message part