Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

Le lun. 7 mars 2016 22:03, Peter Jones <address@hidden> a écrit :

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.

I'm not against using it for i386-pc but it's broken on every other platform, including i386-coreboot. Ideally we should be able to pass this info on i386-pc as well when using 32-bit protocol but unfortunately there are no fields for this

--
  Peter