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).
- 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.
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.

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

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?

Regards,
Bastian

--
Schshschshchsch.
-- The Gorn, "Arena", stardate 3046.2

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmH4cMQACgkQ57/I7JWG EQlagBAAl2Wr7tDKz44GNVnROWaXC4QkMlLYC+TcEa1SkquUr9Eql4aytswFfv+T nP6FzDPfKAfi3Kn5T1+e+n5R/H6AkXwTW5OJQItPghqSVoGa4E2CN1eLae/fb4h4 6fYcjXWl7rcksNSkwZHNhUj3trsa2YLRyec3EOACw/lTq1c/xCdK0cSYgezKZVUX I80pPpMh5SLp0rj4WVGmY2QSUPsWj5AfxD2UK+FNLfs3Xe2uDFprNHX4tO/IpVMA lRLeptCRsKdljLaDndvExIY4ngAzw1kqxrXrq3C6NBd8FvAP+Ivo3MODc76o9v5Z wSb25WjxTFWnCRN9AahUBPwFnokARm15Rbaz8pxlXjvH0T9Ryi4eKfcwSVRXsI6o /HRyoz85RnFKA4BZcUeiH5lbOHXLFqD9yUxEjwzPMCiL7cabmEoX44KkZPh6A8BT 9Ot9gp35w7m5qs4PxNezOq+kNUBevlddCciCXHta6EGufXf8KQftj7mvir3iJmwM hNRzNk9yz5kAp8e77HBZ7MnWcOq4yhfj18t9/5a4cmnpkA3gOcEUQRaprdjBXIV9 XUF/IPZXvvUP4emwbzzrWLJsXYTPLpmydNf/mBxEGaH8DnrX/XkgCK/xzxRomaU2 JcQOnKM+rDbFBskSlUBpYxDoWJJ8F1HiY63e4Qjsg7IzZ4kRlTQ=
=j7Nj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Likely not important for the broader discussion, but a small note which may help with the solution space.

On Tuesday, 1 February 2022 00:29:08 CET Ben Hutchings wrote:

I'm not sure how common it is to make the EFI boot partition be /boot.

I make images for my Pine64 Rock64 which has its EFI partition mounted on /boot/efi (and I set the 'esp' and 'boot' flags on that partition).
This should work on all rockchip based SoC's, but only verified it on Rock64.
I use the grub-efi-arm64 package.

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.

That's an unfortunate *choice* by the Raspberry Pi foundation, but there is no need for that. The RPi (initial) boot loader looks for the first FAT partition to find the files needed for the later stage of the boot process.
It does not care where that is mounted (or whether it is mounted at all).
On the RPi images on raspi.debian.net the FAT partition is mounted on /boot/firmware (and raspi-firmware package expects them there).

HTH,
Diederik
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYfh6TwAKCRDXblvOeH7b bu35AP9cyQ22hc+dDb9AJr18Me/rcxJ2qPj9wwAQepuS0GwIkQEAv4jOihrANZSU lQxlOuVM1SVegutcwAziLMi/EvipvQ0=
=lQhG
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ben

On Tue, Feb 01, 2022 at 12:29:08AM +0100, Ben Hutchings wrote:

On Thu, 2021-11-11 at 11:47 +0100, Bastian Blank wrote:

- 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.

EFI is one example. Some deprecated boot loaders do the same, like the
one for hppa I think by requiring old ext2 variants.

However "other" people have decided to create discoverable partitions by
using pre-defined UUID. https://systemd.io/DISCOVERABLE_PARTITIONS/
There an EFI partition is either stuck at /efi or /boot (if empty).

So my rough ideas would be:
- Everything from kernel packages is installed somewhere in /usr/lib.

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.

Yeah, that might happen. Reflink copies or hardlinks can help, if /boot
is the same filesystem.

If we allow initramfs creators to write directly to the final resting
place, it'll somewhat reduce the space requirements, as the initramfs
tends to be the largest part. But it reduces the flexibility as lot.

- 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.

Yes, that we'll need. I assume this compatibility fallback would be the
first implementation of the new protocol anyway.

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.

What to you mean with "too flexible"?

How do we avoid having huge numbers
of boot menu entries?

What do you mean with that? The number of boot entries does not go up
to the status quo.

How is the default option decided?

That's an unsolved problem, yes. We could prefer the one pulled in by
the meta package as default.

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.

Yep.

Bastian

--
The sight of death frightens them [Earthers].
-- Kras the Klingon, "Friday's Child", stardate 3497.2

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)