Cure found for kernel updates

[Matthew Garrett]

On Fri, May 16, 2014 at 04:23:56PM +0200, Lennart Poettering wrote:
> On Fri, 16.05.14 06:38, Matthew Garrett (mjg59 at srcf.ucam.org) wrote:
> > No, but if we want Thunderbolt then the only way we can integrate with 
> > the OS X boot preferences is with the bootloader on an HFS+
> > partition. 
> 
> I cannot parse this? Can you elaborate what HFS+ has to do with Thunderbolt?

If we want Thunderbolt then we have to perform an EFI boot rather than 
using the BIOS compatibility layer. The only way to perform an EFI boot 
and integrate with the OS X boot preferences is to have the bootloader 
on an HFS+ partition.

> > It's also the only way we get a reasonable recovery experience if the 
> > user ever clears the PRAM, which is still a recommended diagnostic 
> > procedure on Apple hardware.
> 
> You can always get into the firmware boot menu, can't you?

Yes, but

a) You need an HFS+ partition unless you want a generic "EFI Boot" 
option
b) It's not obvious how to set the default from there (ctrl+click, it 
turns out)

> > There clearly is a need for it, otherwise we wouldn't be talking about 
> > it.
> 
> I don't see any need for it in the BLS. It's legacy stuff, doesn't have
> to be covered by a new spec, if the old way to handle it with bootloader
> specific syntaxes is fine...

We obviously disagree on this point, but I don't see any strong 
incentive to work on implementing this if we still end up with 
configuration in two different locations.

> > I appreciate the design goal. I just don't think it results in a broadly 
> > useful specification.
> 
> Well, the specification is not supposed to cover everything, and I
> really don't see what your problem is to defer to grub's own stuff for
> MBR chainloading, doing that once, and leaving it in place statically,
> and just doing BLS for linux kernels and stuff.

Because, as I said before, it's not necessarily static and it's 
confusing to have two different configuration formats for handling the 
same data. All that's needed is an addition something like:

chain-drive: A drive number in firmware-specific order. If the firmware 
supports bootloader embedding then the bootloader interpreting this 
stanza will jump to the bootloader embedded on this drive. Not available 
on EFI systems.
chain-partition: If chain-drive is set, indicates that the bootloader 
will jump to an embedded bootloader at this (1-indexed) partition. If 
absent or 0, the bootloader will jump to the drive's boot sector. Not 
available on EFI systems.

On BIOS, just add the chain-drive number to 0x80 and make the 
appropriate BIOS call. The implementation at the bootloader level is 
trivial. Figuring out how to map the drive to the BIOS number is 
obviously a pain, but you don't have to care - that's left up to the 
installer, and we already have the code to do that. It requires no 
changes to gummiboot and only a small patch to grub.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org