Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Mon, Mar 07, 2016 at 07:57:21PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> > > > Well, I have a bunch of patches that need to be clean up (or even
> > > > re-examined), and I've also got the secure-boot branch here:
> > > >
> > > > https://github.com/vathpela/grub2-fedora/tree/sb
> > > >
> > > > Which is all the patches distros should be carrying to work with Secure
> > > > Boot correctly.  This branch is also recently rebased against master,
> > > > though I'm not sure what the current thinking is regarding their path
> > > > upstream.
> > > >
> > >
> > > Personally I'd rather include support for it. I'm tired of linux vs.
> > > linuxefi nightmare, and patches have been in the wild long enough.
> >
> > So what's the path forward, then?  Just make all efi use linuxefi, like
> > linux vs linux16?  That's pretty close to what I've got already, except
> > on arm where it's just "linux" in EFI mode as well.  But we could make
> > those aliases for the same thing on that platform easily enough.  Or do
> > you have something else in mind?
> 
> RedHat/Fedora config is too platform-dependent and platform is detected at
> mkconfig time rather than at runtime. This is a problem as runtime and
> mkconfig can be different. Case that I see often is coreboot failing due to
> use of Linux16 (which is a valid protocol for coreboot and is used for
> memtest but Linux crashes with it) but other cases exist, like enabling or
> disabling of SCM or moving disk to another computer. Can we fix this by
> introducing some helper to detect it on runtime? It can either be a
> function or a real command

Yeah, we can do something in the config file based on a platform
variable, and then setting the actual commands that way.

I'm curious as to why you think "linux16" doesn't work for Linux,
though.  We use it 100% of the time in Fedora and RHEL, and upstream x86
kernel maintainers have expressed a preference for it.  Using "linux"
instead seems to break much more, for example EDD often does not ever
get exposed to the kernel when it's used.

-- 
  Peter