Cure found for kernel updates

[Lennart Poettering]

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

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

Sure, well, again, I don't see why we need to care about the boot prefs,
if we have te firmware boot menu anyway, and if Windows doesn't care
about the boot menu either...

I just don't think the price you pay for HFS+ ESP madness and
the special-casing for mac there is worth the effort. Without this
everything works pretty fine too, and as good or bad as windows does on
macs. And the panel, well, is not really worth the ugliness of the hack...

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

which is totally OK, and what windows does too, right?

> b) It's not obvious how to set the default from there (ctrl+click, it 
> turns out)

Well, I really don't see why we need to be better than windows for this...

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

The BLS is explicitly not about reinventing grub and all its complexity
when referring to devices. I am sorry, but this really has no place in
the BLS.

I figure we have to leave it at this, we just have to agree to disagree...

Lennart

-- 
Lennart Poettering, Red Hat