Hey coreboot folks,
here's something that's bugging me for a long time: Our lack of an out- of-the-box booting experience.
All our payloads that don't implement legacy boot facilities (i.e. BIOS, UEFI), only work in the usual case, to boot an installed OS that's con- figured to work with that payload. But they stink at booting in the un- usual case, e.g. from installation, rescue or live boot media.
One could now point a finger at the developers of those media and say, they only have an MBR / UEFI boot partition, no GRUB / FILO / whatever configuration file. So it's their fault? Well, I say, it's our fault! We never specified how a civilized, general booting process shall look like.
My proposal: Let's specify a fallback boot mechanism for bootloaders for the case they feel lost. This would include
o a configuration file format (to specify a binary to load along with its parameters),
o a search scheme for the configuration file (e.g. search the first partition of each disk for `/boot/rettungsboot`),
o a set of supported partition table formats,
o a set of supported file systems,
o a set of binary formats that one can expect the payload to support (e.g. multiboot2, multiboot, bzImage).
The configuration file format should be most lean and simple. We might want support for multiple options (i.e. a simple menu) though. Some- thing like the legacy GRUB format maybe?
What do you think?
Best regards, Nico
PS. Yes, it's too late to change the name (see subject). For the curi- ous, who didn't look it up yet: "Rettungsboot" is the German phrase for "life boat".
Hello Nico,
Saturday, November 26, 2016, 6:42:40 PM, you wrote:
NH> Hey coreboot folks, NH> here's something that's bugging me for a long time: Our lack of an out- NH> of-the-box booting experience.
NH> All our payloads that don't implement legacy boot facilities (i.e. BIOS, NH> UEFI), only work in the usual case, to boot an installed OS that's con- NH> figured to work with that payload. But they stink at booting in the un- NH> usual case, e.g. from installation, rescue or live boot media.
NH> One could now point a finger at the developers of those media and say, NH> they only have an MBR / UEFI boot partition, no GRUB / FILO / whatever NH> configuration file. So it's their fault? Well, I say, it's our fault! NH> We never specified how a civilized, general booting process shall look NH> like.
NH> My proposal: Let's specify a fallback boot mechanism for bootloaders for NH> the case they feel lost. This would include
NH> o a configuration file format (to specify a binary to load along NH> with its parameters),
NH> o a search scheme for the configuration file (e.g. search the first NH> partition of each disk for `/boot/rettungsboot`),
NH> o a set of supported partition table formats,
NH> o a set of supported file systems,
NH> o a set of binary formats that one can expect the payload to support NH> (e.g. multiboot2, multiboot, bzImage).
NH> The configuration file format should be most lean and simple. We might NH> want support for multiple options (i.e. a simple menu) though. Some- NH> thing like the legacy GRUB format maybe? NH> What do you think?
https://xkcd.com/927/ comes to mind immediately.
What would be the incentive for the boot media creators to support yet another booting format, supported by a tiny amount of systems? Why not instead consider including a minimal subset of SeaBIOS or Tianocore (enough for booting), or maybe do a survey and try to support the most common variations of grub/isolinux etc used on such CDs?
On 26.11.2016 19:18, Igor Skochinsky wrote:
Hello Nico,
Saturday, November 26, 2016, 6:42:40 PM, you wrote:
NH> Hey coreboot folks, NH> here's something that's bugging me for a long time: Our lack of an out- NH> of-the-box booting experience.
NH> All our payloads that don't implement legacy boot facilities (i.e. BIOS, NH> UEFI), only work in the usual case, to boot an installed OS that's con- NH> figured to work with that payload. But they stink at booting in the un- NH> usual case, e.g. from installation, rescue or live boot media.
NH> One could now point a finger at the developers of those media and say, NH> they only have an MBR / UEFI boot partition, no GRUB / FILO / whatever NH> configuration file. So it's their fault? Well, I say, it's our fault! NH> We never specified how a civilized, general booting process shall look NH> like.
NH> My proposal: Let's specify a fallback boot mechanism for bootloaders for NH> the case they feel lost. This would include
NH> o a configuration file format (to specify a binary to load along NH> with its parameters),
NH> o a search scheme for the configuration file (e.g. search the first NH> partition of each disk for `/boot/rettungsboot`),
NH> o a set of supported partition table formats,
NH> o a set of supported file systems,
NH> o a set of binary formats that one can expect the payload to support NH> (e.g. multiboot2, multiboot, bzImage).
NH> The configuration file format should be most lean and simple. We might NH> want support for multiple options (i.e. a simple menu) though. Some- NH> thing like the legacy GRUB format maybe? NH> What do you think?
https://xkcd.com/927/ comes to mind immediately.
Of course, it does ;)
What would be the incentive for the boot media creators to support yet another booting format, supported by a tiny amount of systems?
I have to admit that my view on boot media is very limited. I have al- most exclusively free software developers in mind and I hope they would be responsive to a non-proprietary alternative or at least accept pat- ches.
Why not instead consider including a minimal subset of SeaBIOS or Tianocore (enough for booting),
This could bloat a bootloader by a huge factor just for compatibility. It would be hard to implement, even harder to maintain.
It's also about the impression someone gets after installing coreboot. Legacy boot just doesn't fit in there: We have this nice, fast boot but to actually use it you have to load a ton of extra software between coreboot and your OS?
or maybe do a survey and try to support the most common variations of grub/isolinux etc used on such CDs?
I had that in mind too, for some time. It would be less bloating than legacy boot support but still leave a lot to implement and maintain. As you mentioned GRUB, have you looked at it's file format lately? It's more a shell scripting language than configuration.
Being a workaround hidden from the media creators, it's also unlikely that it wouldn't break right in the moment you need it most.
To sum it up, I want something that is lean and clean enough so it could be added to any bootloader. Even if that boot loader is not of the let's build a tiny OS type. When I boot a machine the first time with coreboot I want it to come up and be able to install an OS, without any workaround.
Nico
coreboot today is linuxbios minus the linux. The original intent was always that linux be our lifeboat. The current set of (as you point out) not terrific options is a result of linux growing too big for flash, and flash growing too big for linux, ca. 2002, when we adopted the payload model. The original keyword in the config file was 'linux', not 'payload'. The bootloaders we adopted (etherboot, filo, ...) were never (to me) a very satisfactory replacement for linux. They always came with lots of limitations.
But why linux? Why a full OS? Simple observation, here in my 35th year of working with firmware and bootloaders.
Every bootloader starts simple, and becomes an OS. Every single one starts with the intent of being small and compact and only supporting some needed subset of file systems/devices/protocols and ends up implementing everything. Because there was an attempt to start out simple, no matter how good the intial design is, that design is overwhelmed by the continuous addition of features, the result being a badly bloated, huge system with no apparent design.
The exception, it has been argued, is EFI, which had some sort of design in 1999. From my point of view, it skipped right past all the initial stages and entered the world bloated and with no apparent design, or at least not a very good one.
So you need to think, not in terms of lean and clean, but in terms of what it looks like after a few years when everyone has attached their favorite features to your lifeboat. I think it's a mistake to ever think you are going to implement some limited-function, limited-footprint bootloader, because people will jump on it and just add code. Just look at what's happened with systemd.
Also worth considering is that the tinykernel configs have got linux down to 400K. You can trim it down to that, and carefully add features back. This comes with huge benefits I think. You get drivers that work, protocols that work, all the file systems you want, and you can put nice interactive boot UIs in user mode. Today's flash parts are more than large enough to do a good environment -- tinycore linux could be used, for example, once it was trimmed a bit. It's only about 12M today with a full X environment.
Power8 and Power9 systems use linux in flash as their bootloader. This example has not been lost on other systems being developed today.
I think it's worth considering a tinykernel linux as bootloader before you start with a new thing.
ron
-
Igor Skochinsky -
Nico Huber -
ron minnich