Cure found for kernel updates

[Lennart Poettering]

On Fri, 16.05.14 06:38, Matthew Garrett (mjg59 at srcf.ucam.org) wrote:

> On Thu, May 15, 2014 at 11:30:47PM +0200, Lennart Poettering wrote:
> > On Thu, 15.05.14 19:37, Matthew Garrett (mjg59 at srcf.ucam.org) wrote:
> > > Windows ends up with reduced access to the hardware. We do what OS X 
> > > does, not what Windows does, because that's the only way to get (for 
> > > example) working Thunderbolt.
> > 
> > You are not really suggesting that having a second HFS+ ESP in place is
> > what turns on Thunderbolt, are you?
> 
> 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?

> 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?

> > > What's the objection to specifying a mechanism for chainloading?
> > 
> > Chainloading for MBR? Well, for starters, that there is no need for it,
> > and clearly legacy.
> 
> 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...

> > checking the device path is so error prone and broken. And then trying
> > to come up with a scheme that works on both EFI and on MBR is just
> > intensly complex. Hence: we would rather not reference anything outside
> > of the immedaiety boot partition.
> 
> 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.

> > I really don't see why grub's native old config wasn't good enough for
> > that. THe BLS module I wrote for grub was supposed to be used in
> > combination with a fixed config file for any other windowses you might
> > have installed.
> 
> Like I said, if we're changing our configuration format then there's a 
> strong incentive not to split boot configuration between two different 
> formats. Given the choice between adding complexity to tooling and 
> complexity to users, it seems like we should be the ones doing the hard 
> work.

Well, the BLS is supposed to not standardize old cruft. MBR is on its
way out. I am not going to standardize some ARM-specific or
S390-specific or whatever-else-specific chainloading schemes in the BLS
either. It has no place there. Leave the arch-specific/legacy hacks in
the arch-specific boot loaders. And do BLS for all the new, native,
linux kernels, and UEFI.

I really don't see what the problem is to continue to use grub's MBR
chainloading where necessary.

Lennart

-- 
Lennart Poettering, Red Hat