Preparing for a merged /usr in Debian

I apologize for the confusion. I was talking about IBM compatible BIOS. BIOS doesn't have, afaik, filesystem code. It can only read from hard drives (and depending upon age, limited sized drives!). Even Microsoft has a bootloader that loads the windows kernel. Before LILO, Linux must have had a different bootloader. Or it embedded the command line and fit in the first sector of the hard drive. Other Unix either had their own bootloader, or ran on other platforms which I don't know and won't speak for their system setup code.

UEFI, for instances, does contain file system code. And UEFI doesn't require GRUB to boot Linux from a filesystem. I'd bet two pennies that if we had UEFI from the start, GRUB would not be as popular and LILO would not held out so long, assuming all else being equal.

> GRUB (the bootloader) has exactly the same fault! Please read the manual: it can only ever boot one statically configured (with grub-install) GRUB kernel. If you upgrade the GRUB kernel you have to rerun its (static) installation.

A rarer event for me, and a step required as part of my system upgrade. Countless times I'd forget to rerun LILO when testing a kernel, and break the system. GRUB is far more resilient, even when I upgrade it. Anyways, no matter what you do there is always a risk upgrading bootloaders. Many people find GRUB, even with its complexity over LILO, more robust. I also find it much easier to debug failures with GRUB and recover systems.

> <snip> dynamically selected "second stage" Linux kernel to boot with kexec.
Correct me if I'm wrong, but kexec wipes out the previous system state. To build such a system would require extra work to make kexec into a proper bootloader replacement. Considering GRUB has all the drivers I need to just boot my preferred kernel and reliably load an initial /, why would I replace the simpler GRUB with a more complex system?

Also, some hardware is really unhappy about kexec. As a trivial example, my desktop GPU. It does not like being double initialized from the kernel, and I suspect it would take a lot of work to make it so for little gain (this is all on the official open source driver stack).

The boot process is always a pain on a system (my favourite example? The A20 line that needs to be dealt with in real mode). Everything is about trying to make it better. I won't argue the current system is the best thing possible (I know I'll be proven wrong eventually). I do think it's very good as is.

If you want to remove GRUB, UEFI allows that. I do see the value in making cut down systems that match your current system, by initramfs (and I've manually created an initramfs, including initial boot scripts. Interesting, but not unreasonable process. I used it for several years on an encrypted LVM /).

I'm willing to be shown that whole line of thought is wrong. I suggest you try creating your desired system, including all the necessary support structure. If it is better, I'd be happy to push it forward. As of right now, I just don't see how yours is better considering my experience with the Linux boot system.