From: Peter Jones <pjones@redhat.com>
To: "Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com>
Cc: Andrei Borzenkov <arvidjaar@gmail.com>,
The development of GRUB 2 <grub-devel@gnu.org>,
Colin Watson <cjwatson@debian.org>
Subject: Re: Bugs and tasks for 2.02[~rc1]
Date: Mon, 7 Mar 2016 16:03:32 -0500 [thread overview]
Message-ID: <20160307210331.GC13163@redhat.com> (raw)
In-Reply-To: <CAEaD8JOWrxf3pytScdZdzcrF1sLR4Fu1VVKgJd5ct3zDg3V4fw@mail.gmail.com>
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
next prev parent reply other threads:[~2016-03-07 21:03 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 15:01 Bugs and tasks for 2.02[~rc1] Vladimir 'phcoder' Serbinenko
2016-03-02 22:24 ` Daniel Kiper
2016-03-09 10:49 ` Daniel Kiper
[not found] ` <20160309144557.GA19753@char.us.oracle.com>
2016-03-09 14:51 ` Vladimir 'phcoder' Serbinenko
2016-03-09 20:05 ` Daniel Kiper
2016-03-04 20:06 ` Peter Jones
2016-03-05 8:38 ` Andrei Borzenkov
2016-03-07 19:00 ` Peter Jones
2016-03-07 19:57 ` Vladimir 'phcoder' Serbinenko
2016-03-07 20:33 ` Andrei Borzenkov
2016-03-07 20:40 ` Vladimir 'phcoder' Serbinenko
2016-03-07 20:57 ` Andrei Borzenkov
2016-03-07 21:03 ` Vladimir 'phcoder' Serbinenko
2016-03-07 21:20 ` Peter Jones
2016-03-07 21:29 ` Andrei Borzenkov
2016-03-07 22:01 ` Peter Jones
2016-03-07 22:07 ` Vladimir 'phcoder' Serbinenko
2016-03-08 4:16 ` Michael Chang
2016-03-08 3:40 ` Michael Chang
2016-03-08 4:57 ` Andrei Borzenkov
2016-03-09 15:18 ` Matt Fleming
2016-03-09 20:15 ` Linux loader EFI handover (was: Bugs and tasks for 2.02[~rc1]) Andrei Borzenkov
2016-03-10 14:21 ` Matt Fleming
2016-03-11 17:46 ` Linux loader EFI handover Andrei Borzenkov
2016-03-07 21:42 ` Bugs and tasks for 2.02[~rc1] Matt Fleming
2016-03-11 15:51 ` Vladimir 'phcoder' Serbinenko
2016-03-14 15:17 ` Matt Fleming
2016-03-15 17:38 ` Vladimir 'phcoder' Serbinenko
2016-03-22 17:54 ` Peter Jones
2016-03-07 21:14 ` Peter Jones
2016-03-07 21:50 ` Vladimir 'phcoder' Serbinenko
2016-03-07 21:10 ` Peter Jones
2016-03-11 18:01 ` Andrei Borzenkov
2016-03-07 21:03 ` Peter Jones [this message]
2016-03-07 21:08 ` Andrei Borzenkov
2016-03-07 21:26 ` Peter Jones
2016-03-07 21:08 ` Vladimir 'phcoder' Serbinenko
2016-03-08 17:57 ` Andrei Borzenkov
2016-03-08 21:47 ` Peter Jones
2016-03-11 18:38 ` Andrei Borzenkov
2016-03-09 6:38 ` Olaf Hering
2016-03-09 7:54 ` Michael Chang
2016-03-09 8:13 ` Andrei Borzenkov
2016-03-11 16:04 ` Vladimir 'phcoder' Serbinenko
2016-04-13 8:49 ` Olaf Hering
2016-03-13 6:30 ` Andrei Borzenkov
2016-03-22 18:48 ` Vladimir 'phcoder' Serbinenko
2016-03-22 19:51 ` Andrei Borzenkov
2016-04-18 4:18 ` Vladimir 'phcoder' Serbinenko
[not found] ` <20160328145903.GF17944@char.us.oracle.com>
2016-04-12 16:44 ` Konrad Rzeszutek Wilk
2016-04-18 4:20 ` Vladimir 'phcoder' Serbinenko
2016-04-12 17:53 ` Bruce Dubbs
2016-04-18 4:20 ` Vladimir 'phcoder' Serbinenko
-- strict thread matches above, loose matches on Subject: below --
2016-03-03 14:47 Juergen Gross
2016-03-09 10:52 ` Daniel Kiper
2016-03-11 15:47 ` Vladimir 'phcoder' Serbinenko
2016-03-11 15:57 ` Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160307210331.GC13163@redhat.com \
--to=pjones@redhat.com \
--cc=arvidjaar@gmail.com \
--cc=cjwatson@debian.org \
--cc=grub-devel@gnu.org \
--cc=phcoder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).