Preparing for a merged /usr in Debian

We can disagree without being insulting or dismissive here, some of the people here actually build distributions and know more about booting than either of us do combined.

> I think that this is the third time that I have explained this is detail for those who ignore how booting sequences work.

I think we are going to disagree about how clear your ideas have been represented by your writing, the evidence is in how few people seem to have understood your intent. Let me see if I understand what you are proposing as another valid way to boot a system.

If I understand correctly you are thinking that we should go back to a simple LILO or uEFI style boot loader that is capable of loading the kernel and passing parameters from the firmware but to disaggregate what is currently in the initramfs into /boot, presuming that the kernel will have built-in drivers equivalent to what the firmware provides to be able to access the block device that /boot lives on, or that the kernel will use the firmware APIs to read the block device. Once you can reliably access the /boot block device you can run your minimal userspace to do hardware setup and pivot into the "real" system.

> is to have a Linux kernel without needing any sorts of drivers compiled statically except those needed to mount the first-stage / filesystem from a local storage area, exactly as GRUB does it for boot,

I may be wrong I don't think GRUB has block device drivers to access /boot, it relies on the firmware built-in services to access the block device, although it does have its own minimal filesystem driver modules (BIOS or uEFI or whatever), which are loaded LILO-style using static block lists, which has the same problems as LILO but GRUB modules are updated more infrequently than the kernel so is less of a problem in practice.

> plus optional kexec

As mjg59 has said elsewhere, and he has more operational experience with this feature than I do, it is a neat feature and great when it works, it's not something that is so reliable that you'd want to depend on it for the common case of everyday booting. In any event, if you are going to boot a Linux kernel, it might as well be the "real" one.