[coreboot] Rettungsboot

[Zoran Stojsavljevic]

> Or do you want to do the full EFI "let's waste 128MB of *every** disk* on
> a special FAT32 partition" madness (which still requires bootloaders to
> include one specific FS driver they might otherwise not want)?

YES, you do. Accent on: "every disk" .

Zoran

On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner <jwerner at chromium.org>
wrote:

> > 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.
>
> I don't really see how you could reach this goal with anything that
> requires reading a file from the boot media? There are billions of
> different file systems out there... do you want to require your
> "minimal" bootloader to include drivers for all of them? (There are
> bootloaders that don't contain any file system drivers at all, like
> depthcharge.) Or do you want to do the full EFI "let's waste 128MB of
> every disk on a special FAT32 partition" madness (which still requires
> bootloaders to include one specific FS driver they might otherwise not
> want)?
>
> I think if you want to do anything truly minimal and compatible with
> everything, you can't rely on files (and you should try to rely on
> partitions as little as possible, e.g. no full GPT parsing). Which
> probably means putting it in the first sector. And once you have that,
> you can create some fancy text-based format (or Go source file /
> node.js script / whatever the cool kids use these days) to describe
> the target sector, load address etc. of the fallback kernel... but
> you're really just exemplifying the XKCD Igor mentioned because you've
> just reinvented the MBR. (And let's face it... no coreboot bootloader
> has the pull to sufficiently promote adoption of some completely new
> fallback boot descriptor format right now, even if it doesn't require
> a Go compiler in your bootloader.)
>
> So, really, I think what you want is just the MBR. It is the deadest
> simple design possible (just load a sector and jump), it is as
> infinitely flexible as code itself, and it coexists perfectly with all
> partitioning schemes relevant today (MBR and GPT). Yes, it requires a
> software interrupt BIOS interface, but if the recovery kernel code is
> cleverly written you really only need the disk access part (and you
> know your bootloader already has that driver because that's how it
> loaded the MBR in the first place). And yes, on x86 it requires real
> mode (for non-x86 I'd just make up an as equivalent as possible system
> with your software interrupt solution of choice), but that's a small
> price you pay with a few files worth of shim code in exchange for
> automatic compatibility with 35 years worth of existing BIOSes. I'd
> say that's a better deal than any new dead-on-arrival scheme you could
> make up out of thin air.
>
> (If you really can't stand the idea of BIOS interrupts and real mode,
> I think your next best option would be to try to cram an
> as-small-as-possible binary recovery descriptor and the real mode code
> to parse/load/execute it together into the 446 bytes of MBR space you
> have. This way, your new payloads can just find and parse/load/execute
> the descriptor itself without having to provide any BIOS interface,
> but the thing is still compatible with existing legacy BIOSes as
> well.)
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161130/ee1249fc/attachment.html>