Bugs and tasks for 2.02[~rc1]

Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

Hello, all. I went through the list of bugs and created a shortlist of bugs
that need to be looked at for 2.02. I have marked them with plan_release_id
set to 2.02.
Statistics: [1]
Search (with loads of false positives unfortunately): [2]
Not every bug there is a release blocker, for some of them it just would be
nice to know status before releasing. Some of them are probably already
fixed.

Additionally I created a category "Hardware specific" [3]. Bugs there are
not release blockers but fixing them could benefit the release.

I would also appreciate if distros would tell which patches they would
carry if 2.02 was released as it is now. If some patches are in more than 1
distro we probably need to look into including them.

Please bring up any tasks that needs to be done in your opinion for 2.02
and not mentioned as separate thread with [2.02] in subject line.

I would like to come up with a complete list of 2.02 blockers in one week
time, so that we can have a reasonable timeline

[1]
https://savannah.gnu.org/bugs/reporting.php?group_id=68&field=plan_release_id
[2]
https://savannah.gnu.org/search/?type_of_search=bugs&words=plan_release_id+2.02&only_group_id=68&offset=0&max_rows=25#results
[3]
https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=grub&func=browse&set=custom&msort=1&report_id=101&advsrch=1&status_id%5B%5D=1&resolution_id%5B%5D=0&submitted_by%5B%5D=0&assigned_to%5B%5D=0&category_id%5B%5D=0&bug_group_id%5B%5D=105&severity%5B%5D=0&priority%5B%5D=0&summary=&details=&sumORdet=0&history_search=0&history_field=0&history_event=modified&history_date_dayfd=2&history_date_monthfd=3&history_date_yearfd=2016&chunksz=50&spamscore=5&boxoptionwanted=1#options

[-- Attachment #2: Type: text/html, Size: 2905 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Daniel Kiper]

Hey,

On Wed, Mar 02, 2016 at 03:01:03PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> Hello, all. I went through the list of bugs and created a shortlist of bugs
> that need to be looked at for 2.02. I have marked them with plan_release_id
> set to 2.02.
> Statistics: [1]
> Search (with loads of false positives unfortunately): [2]
> Not every bug there is a release blocker, for some of them it just would be
> nice to know status before releasing. Some of them are probably already
> fixed.
>
> Additionally I created a category "Hardware specific" [3]. Bugs there are
> not release blockers but fixing them could benefit the release.
>
> I would also appreciate if distros would tell which patches they would
> carry if 2.02 was released as it is now. If some patches are in more than 1
> distro we probably need to look into including them.
>
> Please bring up any tasks that needs to be done in your opinion for 2.02
> and not mentioned as separate thread with [2.02] in subject line.

Is it possible to get "multiboot2: Add two extensions"
(https://lists.gnu.org/archive/html/grub-devel/2016-03/msg00053.html)
patch series into 2.02 train?

Daniel

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Wed, Mar 02, 2016 at 03:01:03PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> Hello, all. I went through the list of bugs and created a shortlist of bugs
> that need to be looked at for 2.02. I have marked them with plan_release_id
> set to 2.02.
> Statistics: [1]
> Search (with loads of false positives unfortunately): [2]
> Not every bug there is a release blocker, for some of them it just would be
> nice to know status before releasing. Some of them are probably already
> fixed.
> 
> Additionally I created a category "Hardware specific" [3]. Bugs there are
> not release blockers but fixing them could benefit the release.

In the interest of fixing them up eventually, here's a chunk
of ones that look reasonably well-suited for upstream without much work
on them, which I've rebased against your master branch today.

https://github.com/vathpela/grub2-fedora/tree/for-upstream

Most of these are not critical for this release - really only 3 of them.
Here are some notes on each; I can send them individually to the list if
you think it's worthwhile.

There are only a couple that are "critical", and we really want in this
release:

bf4d216 Fix crash on http
78b3509 Update to minilzo-2.08
eaa05aa Failed config now returns exit code (#1252311)

Then these are just generic network handling patches:

836b528 DHCP client ID and UUID options added.
eb1adf5 trim arp packets with abnormal size

And these are hardware specific.  They're not critical, in the sense
that I can keep carrying them if you have any problems and we can work
it out for the /next/ release.

beee9fc Add vlan-tag support on IBM PPC machines
93a6fae IBM client architecture (CAS) reboot support
297d32d for ppc, reset console display attr when clear screen
0ca5375 Disable GRUB video support for IBM power machines

2f3c666 Add support for UEFI operating systems returned by os-prober
05f2dc3 Make efi machines load an env block from a variable
1f1a695 Make "exit" take a return code.

The rest are all about the git repo and compilers and similar.  These
are well into "nice to have" for 2.02.  I can re-send them after the
release, they're just what's left on my list that's pretty close to
ready for upstream.

cb62c40 Mark po/exclude.pot as binary so git won't try to diff nonprintables.
e0bb91a Fix bzr's ignore artificats in .gitignore
ecaecc9 Add some __unused__ where gcc 5.x is more picky about it.
e704140 Move bash completion script (#922997)
bc5d351 Allow "fallback" to include entries by title, not just number.
7401bf6 Honor a symlink when generating configuration by grub2-mkconfig
5212412 Fix bad test on GRUB_DISABLE_SUBMENU.
73545c7 Add GRUB_DISABLE_UUID.

> I would also appreciate if distros would tell which patches they would
> carry if 2.02 was released as it is now. If some patches are in more than 1
> distro we probably need to look into including them.

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.

-- 
        Peter

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

04.03.2016 23:06, Peter Jones пишет:
> On Wed, Mar 02, 2016 at 03:01:03PM +0000, Vladimir 'phcoder' Serbinenko wrote:
>> Hello, all. I went through the list of bugs and created a shortlist of bugs
>> that need to be looked at for 2.02. I have marked them with plan_release_id
>> set to 2.02.
>> Statistics: [1]
>> Search (with loads of false positives unfortunately): [2]
>> Not every bug there is a release blocker, for some of them it just would be
>> nice to know status before releasing. Some of them are probably already
>> fixed.
>>
>> Additionally I created a category "Hardware specific" [3]. Bugs there are
>> not release blockers but fixing them could benefit the release.
> 
> In the interest of fixing them up eventually, here's a chunk
> of ones that look reasonably well-suited for upstream without much work
> on them, which I've rebased against your master branch today.
> 
> https://github.com/vathpela/grub2-fedora/tree/for-upstream
> 
> Most of these are not critical for this release - really only 3 of them.
> Here are some notes on each; I can send them individually to the list if
> you think it's worthwhile.
> 
> There are only a couple that are "critical", and we really want in this
> release:
> 
> bf4d216 Fix crash on http

Fixed differently in 92c8f58d973a621890e302cba3d80fe0bbc208d7

> 78b3509 Update to minilzo-2.08

I know. But the sheer size of update makes me afraid of doing it now.

> eaa05aa Failed config now returns exit code (#1252311)
> 

I think it makes sense.

> Then these are just generic network handling patches:
> 
> 836b528 DHCP client ID and UUID options added.

Use case would be interesting. You can query arbitrary option already.

> eb1adf5 trim arp packets with abnormal size
> 

nb is not used anywhere in this branch, so I do not understand what this
code does at all.

> And these are hardware specific.  They're not critical, in the sense
> that I can keep carrying them if you have any problems and we can work
> it out for the /next/ release.
> 
> beee9fc Add vlan-tag support on IBM PPC machines

Yes, openSUSE (and I think SUSE) also carries variant of this patch. We
probably need to revisit it.

> 93a6fae IBM client architecture (CAS) reboot support

Is in (open)SUSE as well

> 297d32d for ppc, reset console display attr when clear screen

Does not apply cleanly to upstream (is on top of some other patch?)

> 0ca5375 Disable GRUB video support for IBM power machines
> 

Is in (open)SUSE as well

> 2f3c666 Add support for UEFI operating systems returned by os-prober

We already support it for quite some time, although differently (based
on os-prober support).

> 05f2dc3 Make efi machines load an env block from a variable

This needs discussion. As well, as openSUSE "store environment block in
btrfs reserved area" patch. And there was intention to use PV reserved
areas for it as well.

> 1f1a695 Make "exit" take a return code.
> 

What about
https://lists.gnu.org/archive/html/grub-devel/2016-01/msg00049.html and
followup?

> The rest are all about the git repo and compilers and similar.  These
> are well into "nice to have" for 2.02.  I can re-send them after the
> release, they're just what's left on my list that's pretty close to
> ready for upstream.
> 
> cb62c40 Mark po/exclude.pot as binary so git won't try to diff nonprintables.

Does it cause a problem? It does not look like there are many of them.

> e0bb91a Fix bzr's ignore artificats in .gitignore
> ecaecc9 Add some __unused__ where gcc 5.x is more picky about it.

How this can become unused?

>  grub_gettext_env_write_lang (struct grub_env_var *var
>   			     __attribute__ ((unused)), const char *val)
>   {
>  -  grub_err_t err;
>  +  grub_err_t __attribute__((__unused__)) err;
>     err = grub_gettext_init_ext (&main_context, val, grub_env_get ("locale_dir"),
>   			       grub_env_get ("prefix"));
>     if (err)

And in normal, entry is used. So more detailed explanation how either of
them become unused is needed (and BTW it is compiled with gcc 5.x on
openSUSE and apparently without errors).


> e704140 Move bash completion script (#922997)

Well, this is obvious compatibility question. Is there any way to detect
it at configure time? Does bash have pkg-config or similar?

> bc5d351 Allow "fallback" to include entries by title, not just number.

What about multiple entries? fallback allows them.

> 7401bf6 Honor a symlink when generating configuration by grub2-mkconfig

Makes sense

> 5212412 Fix bad test on GRUB_DISABLE_SUBMENU.

What is bad here? The documented valued is "y".

> 73545c7 Add GRUB_DISABLE_UUID.
> 

If name as detected by GRUB is correct, there will be no search because
hints will be correct (just direct verification that device is indeed
correct). If name is wrong you need search, otherwise you fail to boot
or boot wrong binary. I do not see what we gain here.

>> I would also appreciate if distros would tell which patches they would
>> carry if 2.02 was released as it is now. If some patches are in more than 1
>> distro we probably need to look into including them.
> 
> 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.

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Sat, Mar 05, 2016 at 11:38:00AM +0300, Andrei Borzenkov wrote:
> 04.03.2016 23:06, Peter Jones пишет:
> > On Wed, Mar 02, 2016 at 03:01:03PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> >> Hello, all. I went through the list of bugs and created a shortlist of bugs
> >> that need to be looked at for 2.02. I have marked them with plan_release_id
> >> set to 2.02.
> >> Statistics: [1]
> >> Search (with loads of false positives unfortunately): [2]
> >> Not every bug there is a release blocker, for some of them it just would be
> >> nice to know status before releasing. Some of them are probably already
> >> fixed.
> >>
> >> Additionally I created a category "Hardware specific" [3]. Bugs there are
> >> not release blockers but fixing them could benefit the release.
> > 
> > In the interest of fixing them up eventually, here's a chunk
> > of ones that look reasonably well-suited for upstream without much work
> > on them, which I've rebased against your master branch today.
> > 
> > https://github.com/vathpela/grub2-fedora/tree/for-upstream
> > 
> > Most of these are not critical for this release - really only 3 of them.
> > Here are some notes on each; I can send them individually to the list if
> > you think it's worthwhile.
> > 
> > There are only a couple that are "critical", and we really want in this
> > release:
> > 
> > bf4d216 Fix crash on http
> 
> Fixed differently in 92c8f58d973a621890e302cba3d80fe0bbc208d7

Oh, thanks, I missed that.

> > 78b3509 Update to minilzo-2.08
> 
> I know. But the sheer size of update makes me afraid of doing it now.

Yeah, I see that concern, I'm just worried there's a CVE here we're
missing.  FWIW we've been carrying that patch for 15 months or so
without seeing any issue whatsoever, but then we're not building for
more extravagant platforms - it's really just the x86, arm, and ppc
families.

> > eaa05aa Failed config now returns exit code (#1252311)
> 
> I think it makes sense.
> 
> > Then these are just generic network handling patches:
> > 
> > 836b528 DHCP client ID and UUID options added.
> 
> Use case would be interesting. You can query arbitrary option already.
> 
> > eb1adf5 trim arp packets with abnormal size
> > 
> 
> nb is not used anywhere in this branch, so I do not understand what this
> code does at all.

Fair enough; I'll move these two for later and try to figure them out.
I think I do have another patch that uses the DHCP one that I didn't put on
this list, but it's completely likely that I'm just carrying an old
patch that's been supplanted by something else.

> > And these are hardware specific.  They're not critical, in the sense
> > that I can keep carrying them if you have any problems and we can work
> > it out for the /next/ release.
> > 
> > beee9fc Add vlan-tag support on IBM PPC machines
> 
> Yes, openSUSE (and I think SUSE) also carries variant of this patch. We
> probably need to revisit it.
> 
> > 93a6fae IBM client architecture (CAS) reboot support
> 
> Is in (open)SUSE as well
> 
> > 297d32d for ppc, reset console display attr when clear screen
> 
> Does not apply cleanly to upstream (is on top of some other patch?)

I'm not seeing any reason this should not apply.  I think probably the
literal nonprintable ^L in the string breaks "git am" (or "git apply"),
and if you "git fetch" + "git cherry-pick" it works?  Or add the file to
.gitattributes as:

grub-core/term/terminfo.c binary

And then do "git format-patch $commitid" and apply that result.  But
that's a blunt enough hammer that it's not something we really want to
/commit/ for a .c file, I would think, since it makes reading the
patches difficult.  Also you have to fetch the remote anyway, so
cherry-pick makes more sense.

At the same time, we probably ought to change it to \x0c instead of the
^L.  So I've done that in my current version of the patch, but it won't
help this time.

> > 0ca5375 Disable GRUB video support for IBM power machines
> 
> Is in (open)SUSE as well
> 
> > 2f3c666 Add support for UEFI operating systems returned by os-prober
> 
> We already support it for quite some time, although differently (based
> on os-prober support).

Ah, yeah, looks like f25870887b7.  Thanks.

> > 05f2dc3 Make efi machines load an env block from a variable
> 
> This needs discussion. As well, as openSUSE "store environment block in
> btrfs reserved area" patch. And there was intention to use PV reserved
> areas for it as well.

Completely fair.  I picked an EFI variable because I was using this to
control some debugging code that's still in progress, and it's nice that
you can set it before the bootloader starts (or restore it using
dmpstore, etc.)

> > 1f1a695 Make "exit" take a return code.
> > 
> 
> What about
> https://lists.gnu.org/archive/html/grub-devel/2016-01/msg00049.html and
> followup?

Well, that's a good question.  The code in this patch is sort of a
middle ground there - it makes GRUB_EFI_LOAD_ERROR the default, and
makes "exit" and "exit N" both work.  So if you do "exit 0", you get no
fallback to the next item, but "exit" alone, "exit N" for any N but 0,
and all the failure paths in the C code all wind up showing the next
menu item.

I can make it another command if you like, but it seems like a pretty
natural semantic for exit to have.  So the issue is that it won't do
anything on a bunch of platforms other than what they're already doing.
Is that a big deal?  We have plenty of commands that perform a level of
functionality based on the underlying support.

> > The rest are all about the git repo and compilers and similar.  These
> > are well into "nice to have" for 2.02.  I can re-send them after the
> > release, they're just what's left on my list that's pretty close to
> > ready for upstream.
> > 
> > cb62c40 Mark po/exclude.pot as binary so git won't try to diff nonprintables.
> 
> Does it cause a problem? It does not look like there are many of them.

Well, in the glorious world where we have a tarball newer than
0d6498a67d4 it should cause a lot fewer problems :)  But if your
build does:

tar xf grub-2.02~beta2.tar.xz
cd grub-2.02~beta2
git init
git add .
git commit -a -m grub-2.02-beta2
git am <all the patches we want since then>

Then that last step fails because nonprintables in diff really do not
work well.  This patch makes "git format-patch" output that file's diff
as a binary diff instead, and so it works.

I wouldn't want to do this for a C file, but exclude.pot doesn't see a
lot of changes.  And it has a lot of junk in it to begin with - that's
what it exists for.  

Still, if we have actual regular releases, this isn't particularly
important.  It's just if distros (or users) wind up applying a pile of
patches from the repo to make their packages that it becomes an issue.

> > e0bb91a Fix bzr's ignore artificats in .gitignore

Did you accidentally skip this one?

> > ecaecc9 Add some __unused__ where gcc 5.x is more picky about it.
> 
> How this can become unused?
>
> >  grub_gettext_env_write_lang (struct grub_env_var *var
> >   			     __attribute__ ((unused)), const char *val)
> >   {
> >  -  grub_err_t err;
> >  +  grub_err_t __attribute__((__unused__)) err;
> >     err = grub_gettext_init_ext (&main_context, val, grub_env_get ("locale_dir"),
> >   			       grub_env_get ("prefix"));
> >     if (err)
> 
> And in normal, entry is used. So more detailed explanation how either of
> them become unused is needed (and BTW it is compiled with gcc 5.x on
> openSUSE and apparently without errors).

Yep, you're right - sorry about that, the last one should have been
stripped out - it's the artifact of another patch that's not really
upstreamable in its current form.  The whole first file looks valid to
me, though?  I'll rebase it as two patches and leave one of them in
for-upstream.

> > e704140 Move bash completion script (#922997)
> 
> Well, this is obvious compatibility question. Is there any way to detect
> it at configure time? Does bash have pkg-config or similar?

I don't see anything obviously like that, unfortunately, and I'm not
really sure in what version they switched it.

> > bc5d351 Allow "fallback" to include entries by title, not just number.
> 
> What about multiple entries? fallback allows them.

I'm not sure I understand your question.  This still allows that if you
treat them numerically or by id.  I suppose it's possible to break the
value up as a list of quoted strings to test by title, but it gets messy
with corner cases pretty quickly.  FWIW the documentation *doesn't* say
that it allows multiple entries, but *does* say, more or less by
accident, that you can use titles:
-------------------------------------------------
@node fallback
@subsection fallback

If this variable is set, it identifies a menu entry that should be
selected if the default menu entry fails to boot.  Entries are
identified in the same way as for @samp{default} (@pxref{default}).
-------------------------------------------------
and then:
-------------------------------------------------
@node default
@subsection default

If this variable is set, it identifies a menu entry that should be
selected by default, possibly after a timeout (@pxref{timeout}).  The
entry may be identified by number or by id.

For example, if you have:

@verbatim
menuentry 'Example GNU/Linux distribution' --class gnu-linux --id example-gnu-linux {
        ...
}
@end verbatim

then you can make this the default using:

@example
default=example-gnu-linux
@end example

If the entry is in a submenu, then it must be identified using the
titles of each of the submenus starting from the top level followed by
the number or title of the menu entry itself, separated by @samp{>}.
For example, take the following menu structure:

@example
Submenu 1
  Menu Entry 1
  Menu Entry 2
Submenu 2
  Submenu 3
    Menu Entry 3
    Menu Entry 4
  Menu Entry 5
@end example

``Menu Entry 3'' would then be identified as
@samp{Submenu 2>Submenu 3>Menu Entry 3}.
...
-------------------------------------------------
(mildly reformatted for mail purposes.)

So this patch actually brings it closer into conformance with the
documentation, but still allows multiple fallbacks by index or id to
work as they currently do.

> > 7401bf6 Honor a symlink when generating configuration by grub2-mkconfig
> 
> Makes sense
> 
> > 5212412 Fix bad test on GRUB_DISABLE_SUBMENU.
> 
> What is bad here? The documented valued is "y".

Actually the real issue is that we're inconsistent among many variables,
where we use (and document) "yes", "y", and "true".  So we discovered a
tendency to put the wrong thing in, and I got tired of it and made this
one take either of those.  Maybe this should be addressed more
systemically with a function to judge true or false that recognizes
1/true/y/yes as true?

> > 73545c7 Add GRUB_DISABLE_UUID.
> 
> If name as detected by GRUB is correct, there will be no search because
> hints will be correct (just direct verification that device is indeed
> correct). If name is wrong you need search, otherwise you fail to boot
> or boot wrong binary. I do not see what we gain here.

So, the bug report from our QA dept believed
GRUB_DISABLE_LINUX_UUID=true should accomplish this, and that it's
pointless without it.  And I think they've kind of got a point, since if
the user has the problem GRUB_DISABLE_LINUX_UUID was meant to solve,
there's no reason to believe they can't have the same problem with the
other filesystem.  We made them separate settings because one is about
/boot and one is about / , but fundamentally they're both doing parts of
the same thing.

I'm not really disagreeing with your logic here - but if we have it
avoiding UUIDs for one of those, it would seem like the other would also
be something we can avoid.

> >> I would also appreciate if distros would tell which patches they would
> >> carry if 2.02 was released as it is now. If some patches are in more than 1
> >> distro we probably need to look into including them.
> > 
> > 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?

Anyway, I've moved the patches that clearly need some more work to a
branch called "for-upstream-wip", and fixed up the ones still in
"for-upstream" as I've mentioned above.

Thanks!

-- 
  Peter

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 14683 bytes --]

Le lun. 7 mars 2016 20:00, Peter Jones <pjones@redhat.com> a écrit :

> On Sat, Mar 05, 2016 at 11:38:00AM +0300, Andrei Borzenkov wrote:
> > 04.03.2016 23:06, Peter Jones пишет:
> > > On Wed, Mar 02, 2016 at 03:01:03PM +0000, Vladimir 'phcoder'
> Serbinenko wrote:
> > >> Hello, all. I went through the list of bugs and created a shortlist
> of bugs
> > >> that need to be looked at for 2.02. I have marked them with
> plan_release_id
> > >> set to 2.02.
> > >> Statistics: [1]
> > >> Search (with loads of false positives unfortunately): [2]
> > >> Not every bug there is a release blocker, for some of them it just
> would be
> > >> nice to know status before releasing. Some of them are probably
> already
> > >> fixed.
> > >>
> > >> Additionally I created a category "Hardware specific" [3]. Bugs there
> are
> > >> not release blockers but fixing them could benefit the release.
> > >
> > > In the interest of fixing them up eventually, here's a chunk
> > > of ones that look reasonably well-suited for upstream without much work
> > > on them, which I've rebased against your master branch today.
> > >
> > > https://github.com/vathpela/grub2-fedora/tree/for-upstream
> > >
> > > Most of these are not critical for this release - really only 3 of
> them.
> > > Here are some notes on each; I can send them individually to the list
> if
> > > you think it's worthwhile.
> > >
> > > There are only a couple that are "critical", and we really want in this
> > > release:
> > >
> > > bf4d216 Fix crash on http
> >
> > Fixed differently in 92c8f58d973a621890e302cba3d80fe0bbc208d7
>
> Oh, thanks, I missed that.
>
> > > 78b3509 Update to minilzo-2.08
> >
> > I know. But the sheer size of update makes me afraid of doing it now.
>
> Yeah, I see that concern, I'm just worried there's a CVE here we're
> missing.  FWIW we've been carrying that patch for 15 months or so
> without seeing any issue whatsoever, but then we're not building for
> more extravagant platforms - it's really just the x86, arm, and ppc
> families.
>
> > > eaa05aa Failed config now returns exit code (#1252311)
> >
> > I think it makes sense.
> >
> > > Then these are just generic network handling patches:
> > >
> > > 836b528 DHCP client ID and UUID options added.
> >
> > Use case would be interesting. You can query arbitrary option already.
> >
> > > eb1adf5 trim arp packets with abnormal size
> > >
> >
> > nb is not used anywhere in this branch, so I do not understand what this
> > code does at all.
>
> Fair enough; I'll move these two for later and try to figure them out.
> I think I do have another patch that uses the DHCP one that I didn't put on
> this list, but it's completely likely that I'm just carrying an old
> patch that's been supplanted by something else.
>
> > > And these are hardware specific.  They're not critical, in the sense
> > > that I can keep carrying them if you have any problems and we can work
> > > it out for the /next/ release.
> > >
> > > beee9fc Add vlan-tag support on IBM PPC machines
> >
> > Yes, openSUSE (and I think SUSE) also carries variant of this patch. We
> > probably need to revisit it.
> >
> > > 93a6fae IBM client architecture (CAS) reboot support
> >
> > Is in (open)SUSE as well
> >
> > > 297d32d for ppc, reset console display attr when clear screen
> >
> > Does not apply cleanly to upstream (is on top of some other patch?)
>
> I'm not seeing any reason this should not apply.  I think probably the
> literal nonprintable ^L in the string breaks "git am" (or "git apply"),
> and if you "git fetch" + "git cherry-pick" it works?  Or add the file to
> .gitattributes as:
>
> grub-core/term/terminfo.c binary
>
> And then do "git format-patch $commitid" and apply that result.  But
> that's a blunt enough hammer that it's not something we really want to
> /commit/ for a .c file, I would think, since it makes reading the
> patches difficult.  Also you have to fetch the remote anyway, so
> cherry-pick makes more sense.
>
> At the same time, we probably ought to change it to \x0c instead of the
> ^L.  So I've done that in my current version of the patch, but it won't
> help this time.
>
> > > 0ca5375 Disable GRUB video support for IBM power machines
> >
> > Is in (open)SUSE as well
> >
> > > 2f3c666 Add support for UEFI operating systems returned by os-prober
> >
> > We already support it for quite some time, although differently (based
> > on os-prober support).
>
> Ah, yeah, looks like f25870887b7.  Thanks.
>
> > > 05f2dc3 Make efi machines load an env block from a variable
> >
> > This needs discussion. As well, as openSUSE "store environment block in
> > btrfs reserved area" patch. And there was intention to use PV reserved
> > areas for it as well.
>
> Completely fair.  I picked an EFI variable because I was using this to
> control some debugging code that's still in progress, and it's nice that
> you can set it before the bootloader starts (or restore it using
> dmpstore, etc.)
>
> > > 1f1a695 Make "exit" take a return code.
> > >
> >
> > What about
> > https://lists.gnu.org/archive/html/grub-devel/2016-01/msg00049.html and
> > followup?
>
> Well, that's a good question.  The code in this patch is sort of a
> middle ground there - it makes GRUB_EFI_LOAD_ERROR the default, and
> makes "exit" and "exit N" both work.  So if you do "exit 0", you get no
> fallback to the next item, but "exit" alone, "exit N" for any N but 0,
> and all the failure paths in the C code all wind up showing the next
> menu item.
>
> I can make it another command if you like, but it seems like a pretty
> natural semantic for exit to have.  So the issue is that it won't do
> anything on a bunch of platforms other than what they're already doing.
> Is that a big deal?  We have plenty of commands that perform a level of
> functionality based on the underlying support.
>
> > > The rest are all about the git repo and compilers and similar.  These
> > > are well into "nice to have" for 2.02.  I can re-send them after the
> > > release, they're just what's left on my list that's pretty close to
> > > ready for upstream.
> > >
> > > cb62c40 Mark po/exclude.pot as binary so git won't try to diff
> nonprintables.
> >
> > Does it cause a problem? It does not look like there are many of them.
>
> Well, in the glorious world where we have a tarball newer than
> 0d6498a67d4 it should cause a lot fewer problems :)  But if your
> build does:
>
> tar xf grub-2.02~beta2.tar.xz
> cd grub-2.02~beta2
> git init
> git add .
> git commit -a -m grub-2.02-beta2
> git am <all the patches we want since then>
>
> Then that last step fails because nonprintables in diff really do not
> work well.  This patch makes "git format-patch" output that file's diff
> as a binary diff instead, and so it works.
>
> I wouldn't want to do this for a C file, but exclude.pot doesn't see a
> lot of changes.  And it has a lot of junk in it to begin with - that's
> what it exists for.
>
> Still, if we have actual regular releases, this isn't particularly
> important.  It's just if distros (or users) wind up applying a pile of
> patches from the repo to make their packages that it becomes an issue.
>
> > > e0bb91a Fix bzr's ignore artificats in .gitignore
>
> Did you accidentally skip this one?
>
> > > ecaecc9 Add some __unused__ where gcc 5.x is more picky about it.
> >
> > How this can become unused?
> >
> > >  grub_gettext_env_write_lang (struct grub_env_var *var
> > >                          __attribute__ ((unused)), const char *val)
> > >   {
> > >  -  grub_err_t err;
> > >  +  grub_err_t __attribute__((__unused__)) err;
> > >     err = grub_gettext_init_ext (&main_context, val, grub_env_get
> ("locale_dir"),
> > >                            grub_env_get ("prefix"));
> > >     if (err)
> >
> > And in normal, entry is used. So more detailed explanation how either of
> > them become unused is needed (and BTW it is compiled with gcc 5.x on
> > openSUSE and apparently without errors).
>
> Yep, you're right - sorry about that, the last one should have been
> stripped out - it's the artifact of another patch that's not really
> upstreamable in its current form.  The whole first file looks valid to
> me, though?  I'll rebase it as two patches and leave one of them in
> for-upstream.
>
> > > e704140 Move bash completion script (#922997)
> >
> > Well, this is obvious compatibility question. Is there any way to detect
> > it at configure time? Does bash have pkg-config or similar?
>
> I don't see anything obviously like that, unfortunately, and I'm not
> really sure in what version they switched it.
>
> > > bc5d351 Allow "fallback" to include entries by title, not just number.
> >
> > What about multiple entries? fallback allows them.
>
> I'm not sure I understand your question.  This still allows that if you
> treat them numerically or by id.  I suppose it's possible to break the
> value up as a list of quoted strings to test by title, but it gets messy
> with corner cases pretty quickly.  FWIW the documentation *doesn't* say
> that it allows multiple entries, but *does* say, more or less by
> accident, that you can use titles:
> -------------------------------------------------
> @node fallback
> @subsection fallback
>
> If this variable is set, it identifies a menu entry that should be
> selected if the default menu entry fails to boot.  Entries are
> identified in the same way as for @samp{default} (@pxref{default}).
> -------------------------------------------------
> and then:
> -------------------------------------------------
> @node default
> @subsection default
>
> If this variable is set, it identifies a menu entry that should be
> selected by default, possibly after a timeout (@pxref{timeout}).  The
> entry may be identified by number or by id.
>
> For example, if you have:
>
> @verbatim
> menuentry 'Example GNU/Linux distribution' --class gnu-linux --id
> example-gnu-linux {
>         ...
> }
> @end verbatim
>
> then you can make this the default using:
>
> @example
> default=example-gnu-linux
> @end example
>
> If the entry is in a submenu, then it must be identified using the
> titles of each of the submenus starting from the top level followed by
> the number or title of the menu entry itself, separated by @samp{>}.
> For example, take the following menu structure:
>
> @example
> Submenu 1
>   Menu Entry 1
>   Menu Entry 2
> Submenu 2
>   Submenu 3
>     Menu Entry 3
>     Menu Entry 4
>   Menu Entry 5
> @end example
>
> ``Menu Entry 3'' would then be identified as
> @samp{Submenu 2>Submenu 3>Menu Entry 3}.
> ...
> -------------------------------------------------
> (mildly reformatted for mail purposes.)
>
> So this patch actually brings it closer into conformance with the
> documentation, but still allows multiple fallbacks by index or id to
> work as they currently do.
>
> > > 7401bf6 Honor a symlink when generating configuration by grub2-mkconfig
> >
> > Makes sense
> >
> > > 5212412 Fix bad test on GRUB_DISABLE_SUBMENU.
> >
> > What is bad here? The documented valued is "y".
>
> Actually the real issue is that we're inconsistent among many variables,
> where we use (and document) "yes", "y", and "true".  So we discovered a
> tendency to put the wrong thing in, and I got tired of it and made this
> one take either of those.  Maybe this should be addressed more
> systemically with a function to judge true or false that recognizes
> 1/true/y/yes as true?
>
> > > 73545c7 Add GRUB_DISABLE_UUID.
> >
> > If name as detected by GRUB is correct, there will be no search because
> > hints will be correct (just direct verification that device is indeed
> > correct). If name is wrong you need search, otherwise you fail to boot
> > or boot wrong binary. I do not see what we gain here.
>
> So, the bug report from our QA dept believed
> GRUB_DISABLE_LINUX_UUID=true should accomplish this, and that it's
> pointless without it.  And I think they've kind of got a point, since if
> the user has the problem GRUB_DISABLE_LINUX_UUID was meant to solve,
> there's no reason to believe they can't have the same problem with the
> other filesystem.  We made them separate settings because one is about
> /boot and one is about / , but fundamentally they're both doing parts of
> the same thing.
>
> I'm not really disagreeing with your logic here - but if we have it
> avoiding UUIDs for one of those, it would seem like the other would also
> be something we can avoid.
>
> > >> I would also appreciate if distros would tell which patches they would
> > >> carry if 2.02 was released as it is now. If some patches are in more
> than 1
> > >> distro we probably need to look into including them.
> > >
> > > 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

>
> Anyway, I've moved the patches that clearly need some more work to a
> branch called "for-upstream-wip", and fixed up the ones still in
> "for-upstream" as I've mentioned above.
>
> Thanks!
>
> --
>   Peter
>

[-- Attachment #2: Type: text/html, Size: 17447 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

07.03.2016 22:57, Vladimir 'phcoder' Serbinenko пишет:
>>
>>>>> I would also appreciate if distros would tell which patches they would
>>>>> carry if 2.02 was released as it is now. If some patches are in more
>> than 1
>>>>> distro we probably need to look into including them.
>>>>
>>>> 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
> 

Yes, of course, that was what I actually mean - get rid of special
linuxefi and just fold processing into standard linux command. We can
simply always call shim protocol if available on EFI; it should return
success if secure boot is disabled so should be transparent.

What is really a problem (or at least rather more involved) is
chainloader. If secure boot is enabled, we effectively need to implement
complete relocation of PE binary, bypassing EFI. I remember several
interesting bugs in this code in openSUSE :)

One more thing is module load. Currently patches disable it and use only
modules included in core.img. I think we could relax it and allow module
loading from internal memory disk. This will allow distribute signed
image as grub-mkstanalone, making available full GRUB functionality.

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3341 bytes --]

Le lun. 7 mars 2016 21:33, Andrei Borzenkov <arvidjaar@gmail.com> a écrit :

> 07.03.2016 22:57, Vladimir 'phcoder' Serbinenko пишет:
> >>
> >>>>> I would also appreciate if distros would tell which patches they
> would
> >>>>> carry if 2.02 was released as it is now. If some patches are in more
> >> than 1
> >>>>> distro we probably need to look into including them.
> >>>>
> >>>> 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
> >
>
> Yes, of course, that was what I actually mean - get rid of special
> linuxefi and just fold processing into standard linux command. We can
> simply always call shim protocol if available on EFI; it should return
> success if secure boot is disabled so should be transparent.
>
Can you point to some patch to estimate code size of this change? What if
shim is not available? How big part of it is related to secure boot? Just
changing Linux boot protocol doesn't need FSF involvement. Accepting secure
boot might. I'd rather make verification framework and make secure boot
just one client, so module for it can be easily carried by whoever chooses
to implement it. But this is probably 2.03 material

>
> What is really a problem (or at least rather more involved) is
> chainloader. If secure boot is enabled, we effectively need to implement
> complete relocation of PE binary, bypassing EFI. I remember several
> interesting bugs in this code in openSUSE :)
>
> One more thing is module load. Currently patches disable it and use only
> modules included in core.img. I think we could relax it and allow module
> loading from internal memory disk. This will allow distribute signed
> image as grub-mkstanalone, making available full GRUB functionality.
>
Again, I feel like it's something for verification framework

>
>
>
>

[-- Attachment #2: Type: text/html, Size: 4400 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

07.03.2016 23:40, Vladimir 'phcoder' Serbinenko пишет:
> Le lun. 7 mars 2016 21:33, Andrei Borzenkov <arvidjaar@gmail.com> a écrit :
> 
>> 07.03.2016 22:57, Vladimir 'phcoder' Serbinenko пишет:
>>>>
>>>>>>> I would also appreciate if distros would tell which patches they
>> would
>>>>>>> carry if 2.02 was released as it is now. If some patches are in more
>>>> than 1
>>>>>>> distro we probably need to look into including them.
>>>>>>
>>>>>> 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
>>>
>>
>> Yes, of course, that was what I actually mean - get rid of special
>> linuxefi and just fold processing into standard linux command. We can
>> simply always call shim protocol if available on EFI; it should return
>> success if secure boot is disabled so should be transparent.
>>
> Can you point to some patch to estimate code size of this change? What if

Here are patches from SUSE tree.

https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-add-linuxefi.patch?expand=1

Note that it duplicates quite a bit of standard linux code. What we
mostly are interested in is grub_linuxefi_secure_validate(). Also it
reloads kernel after verification, which feels wrong, it should keep
verified image in memory.

https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-chainloader.patch?expand=1

This one is likely needed in full.

https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-no-insmod-on-sb.patch?expand=1

Variant of it is needed - we cannot allow arbitrary module loading from
untrusted location.

> shim is not available? 

I suppose we need to check whether secure boot is enabled. If yes, we
should fail boot because we cannot verify signature.

> How big part of it is related to secure boot? Just
> changing Linux boot protocol doesn't need FSF involvement. Accepting secure

Patches currently use EFI stub to launch kernel but I think this is done
simply to make code easier. We can continue to use the same load
protocol as before, just add image verification.

> boot might. I'd rather make verification framework and make secure boot
> just one client, so module for it can be easily carried by whoever chooses
> to implement it.

How do you decide what verification method to use?

> But this is probably 2.03 material
> 
>>
>> What is really a problem (or at least rather more involved) is
>> chainloader. If secure boot is enabled, we effectively need to implement
>> complete relocation of PE binary, bypassing EFI. I remember several
>> interesting bugs in this code in openSUSE :)
>>
>> One more thing is module load. Currently patches disable it and use only
>> modules included in core.img. I think we could relax it and allow module
>> loading from internal memory disk. This will allow distribute signed
>> image as grub-mkstanalone, making available full GRUB functionality.
>>
> Again, I feel like it's something for verification framework
> 
>>
>>
>>
>>
> 

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 5145 bytes --]

Le lun. 7 mars 2016 21:57, Andrei Borzenkov <arvidjaar@gmail.com> a écrit :

> 07.03.2016 23:40, Vladimir 'phcoder' Serbinenko пишет:
> > Le lun. 7 mars 2016 21:33, Andrei Borzenkov <arvidjaar@gmail.com> a
> écrit :
> >
> >> 07.03.2016 22:57, Vladimir 'phcoder' Serbinenko пишет:
> >>>>
> >>>>>>> I would also appreciate if distros would tell which patches they
> >> would
> >>>>>>> carry if 2.02 was released as it is now. If some patches are in
> more
> >>>> than 1
> >>>>>>> distro we probably need to look into including them.
> >>>>>>
> >>>>>> 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
> >>>
> >>
> >> Yes, of course, that was what I actually mean - get rid of special
> >> linuxefi and just fold processing into standard linux command. We can
> >> simply always call shim protocol if available on EFI; it should return
> >> success if secure boot is disabled so should be transparent.
> >>
> > Can you point to some patch to estimate code size of this change? What if
>
> Here are patches from SUSE tree.
>
>
> https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-add-linuxefi.patch?expand=1
>
> Note that it duplicates quite a bit of standard linux code. What we
> mostly are interested in is grub_linuxefi_secure_validate(). Also it
> reloads kernel after verification, which feels wrong, it should keep
> verified image in memory.
>
>
> https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-chainloader.patch?expand=1
>
> This one is likely needed in full.
>
>
> https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-no-insmod-on-sb.patch?expand=1
>
> Variant of it is needed - we cannot allow arbitrary module loading from
> untrusted location.
>
> > shim is not available?
>
> I suppose we need to check whether secure boot is enabled. If yes, we
> should fail boot because we cannot verify signature.
>
> > How big part of it is related to secure boot? Just
> > changing Linux boot protocol doesn't need FSF involvement. Accepting
> secure
>
> Patches currently use EFI stub to launch kernel but I think this is done
> simply to make code easier. We can continue to use the same load
> protocol as before, just add image verification.
>
> > boot might. I'd rather make verification framework and make secure boot
> > just one client, so module for it can be easily carried by whoever
> chooses
> > to implement it.
>
> How do you decide what verification method to use?
>
By embedding the right parameters in the image, probably by embedding the
right module, same as we do now for verify module for gnupg signatures.
I'll try to get another stab at verification framework to see how much code
it is

>
> > But this is probably 2.03 material
> >
> >>
> >> What is really a problem (or at least rather more involved) is
> >> chainloader. If secure boot is enabled, we effectively need to implement
> >> complete relocation of PE binary, bypassing EFI. I remember several
> >> interesting bugs in this code in openSUSE :)
> >>
> >> One more thing is module load. Currently patches disable it and use only
> >> modules included in core.img. I think we could relax it and allow module
> >> loading from internal memory disk. This will allow distribute signed
> >> image as grub-mkstanalone, making available full GRUB functionality.
> >>
> > Again, I feel like it's something for verification framework
> >
> >>
> >>
> >>
> >>
> >
>
>

[-- Attachment #2: Type: text/html, Size: 7109 bytes --]

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

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

08.03.2016 00:03, Peter Jones пишет:

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

Every now and then I thought about adding EDD to linux loader but as
nobody actually complained I never felt like doing it. Not sure what it
is used for as well. How knowing BIOS disk order is useful on Linux?

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

Le lun. 7 mars 2016 22:03, Peter Jones <pjones@redhat.com> 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
>

[-- Attachment #2: Type: text/html, Size: 3366 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Mon, Mar 07, 2016 at 11:33:52PM +0300, Andrei Borzenkov wrote:
> 07.03.2016 22:57, Vladimir 'phcoder' Serbinenko пишет:
> >>
> >>>>> I would also appreciate if distros would tell which patches they would
> >>>>> carry if 2.02 was released as it is now. If some patches are in more
> >> than 1
> >>>>> distro we probably need to look into including them.
> >>>>
> >>>> 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
> > 
> 
> Yes, of course, that was what I actually mean - get rid of special
> linuxefi and just fold processing into standard linux command. We can
> simply always call shim protocol if available on EFI; it should return
> success if secure boot is disabled so should be transparent.
> 
> What is really a problem (or at least rather more involved) is
> chainloader. If secure boot is enabled, we effectively need to implement
> complete relocation of PE binary, bypassing EFI. I remember several
> interesting bugs in this code in openSUSE :)

We've already got something like that (I think derived from the SuSE
patch) here:
https://github.com/vathpela/grub2-fedora/commit/4ea532fc9f8af1b1b23f424e3205c5eebfa8f877

I think at this point it seems to generally work.  Note that we're
bypassing EFI for loading, but we're still calling into shim for the
verification, so there's not a validation loophole here.

> One more thing is module load. Currently patches disable it and use only
> modules included in core.img. I think we could relax it and allow module
> loading from internal memory disk. This will allow distribute signed
> image as grub-mkstanalone, making available full GRUB functionality.

I'm not seeing what this accomplishes.  We don't have major limitations
on e.g. bootloader size on these platforms, so linking in the modules
we're comfortable supporting the first time is not a big deal.  Maybe
I'm just missing your point though?

-- 
  Peter

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Mon, Mar 07, 2016 at 08:40:58PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> Le lun. 7 mars 2016 21:33, Andrei Borzenkov <arvidjaar@gmail.com> a écrit :
> 
> > 07.03.2016 22:57, Vladimir 'phcoder' Serbinenko пишет:
> > >>
> > >>>>> I would also appreciate if distros would tell which patches they
> > would
> > >>>>> carry if 2.02 was released as it is now. If some patches are in more
> > >> than 1
> > >>>>> distro we probably need to look into including them.
> > >>>>
> > >>>> 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
> > >
> >
> > Yes, of course, that was what I actually mean - get rid of special
> > linuxefi and just fold processing into standard linux command. We can
> > simply always call shim protocol if available on EFI; it should return
> > success if secure boot is disabled so should be transparent.
> >
> Can you point to some patch to estimate code size of this change? What if
> shim is not available? How big part of it is related to secure boot? Just
> changing Linux boot protocol doesn't need FSF involvement. Accepting secure
> boot might. I'd rather make verification framework and make secure boot
> just one client, so module for it can be easily carried by whoever chooses
> to implement it. But this is probably 2.03 material

John Sullivan has, in the past, expressed that grub calling out to shim
for secure boot validation is a reasonable method; I'm not sure why we'd
need more involvement, but if you feel we must, okay.  I'd rather see
support for the only strong validation system we have in the real world,
than arbitrary frameworks.  But I agree, we're probably talking about
something after 2.02.

-- 
  Peter

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Mon, Mar 07, 2016 at 11:57:33PM +0300, Andrei Borzenkov wrote:
> 
> > How big part of it is related to secure boot? Just
> > changing Linux boot protocol doesn't need FSF involvement. Accepting secure
> 
> Patches currently use EFI stub to launch kernel but I think this is done
> simply to make code easier. We can continue to use the same load
> protocol as before, just add image verification.

No, they're doing it because that is the supported entry point for EFI
in Linux.  We do not want EFI machines using other entry points.  It
worked out terribly when we used to do this, and we don't want to start
again.  I've Cc'd Matt Fleming, the upstream kernel EFI maintainer,
because I'm sure he's going to agree with me.

-- 
  Peter

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Tue, Mar 08, 2016 at 12:08:22AM +0300, Andrei Borzenkov wrote:
> 08.03.2016 00:03, Peter Jones пишет:
> 
> > 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.
> > 
> 
> Every now and then I thought about adding EDD to linux loader but as
> nobody actually complained I never felt like doing it. Not sure what it
> is used for as well. How knowing BIOS disk order is useful on Linux?

It's the only way to figure out which disks are okay candidates for
installing the boot loader.  Otherwise you're just rolling the dice.
(Not that EDD is that great, mind you...)

But this speaks to the wider issue of both this and the efi stub: in the
kernel, we're better off getting it directly from the firmware when
possible, rather than have it proxied through grub and a boot params
structure.  That's why the kernel has code to do this in the first
place.

The only thing marshaling it through a pile of structures in memory does
is introduce errors or missing data.  And it adds work coordinating what
goes in those structures.  It's not helpful unless there's a specific
reason to do it.

-- 
  Peter

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

08.03.2016 00:20, Peter Jones пишет:
> On Mon, Mar 07, 2016 at 11:57:33PM +0300, Andrei Borzenkov wrote:
>>
>>> How big part of it is related to secure boot? Just
>>> changing Linux boot protocol doesn't need FSF involvement. Accepting secure
>>
>> Patches currently use EFI stub to launch kernel but I think this is done
>> simply to make code easier. We can continue to use the same load
>> protocol as before, just add image verification.
> 
> No, they're doing it because that is the supported entry point for EFI
> in Linux.  We do not want EFI machines using other entry points.  It
> worked out terribly when we used to do this, and we don't want to start
> again.  I've Cc'd Matt Fleming, the upstream kernel EFI maintainer,
> because I'm sure he's going to agree with me.
> 

So you mean that linux loader is currently broken on EFI?

Re: Bugs and tasks for 2.02[~rc1]

[Matt Fleming]

On Mon, 07 Mar, at 04:20:00PM, Peter Jones wrote:
> On Mon, Mar 07, 2016 at 11:57:33PM +0300, Andrei Borzenkov wrote:
> > 
> > > How big part of it is related to secure boot? Just
> > > changing Linux boot protocol doesn't need FSF involvement. Accepting secure
> > 
> > Patches currently use EFI stub to launch kernel but I think this is done
> > simply to make code easier. We can continue to use the same load
> > protocol as before, just add image verification.
> 
> No, they're doing it because that is the supported entry point for EFI
> in Linux.  We do not want EFI machines using other entry points.  It
> worked out terribly when we used to do this, and we don't want to start
> again.  I've Cc'd Matt Fleming, the upstream kernel EFI maintainer,
> because I'm sure he's going to agree with me.

Yeah, I agree with you.

Having multiple entry points works out badly for everyone, since they
tend to bit rot, and few people test all of them equally. While we
continue to support legacy boot entry points upstream, we're not
actively adding support for new features to them for EFI.

For boot loaders, the EFI handover protocol is definitely the
preferred method of booting Linux on EFI.

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3791 bytes --]

Le lun. 7 mars 2016 22:14, Peter Jones <pjones@redhat.com> a écrit :

> On Mon, Mar 07, 2016 at 08:40:58PM +0000, Vladimir 'phcoder' Serbinenko
> wrote:
> > Le lun. 7 mars 2016 21:33, Andrei Borzenkov <arvidjaar@gmail.com> a
> écrit :
> >
> > > 07.03.2016 22:57, Vladimir 'phcoder' Serbinenko пишет:
> > > >>
> > > >>>>> I would also appreciate if distros would tell which patches they
> > > would
> > > >>>>> carry if 2.02 was released as it is now. If some patches are in
> more
> > > >> than 1
> > > >>>>> distro we probably need to look into including them.
> > > >>>>
> > > >>>> 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
> > > >
> > >
> > > Yes, of course, that was what I actually mean - get rid of special
> > > linuxefi and just fold processing into standard linux command. We can
> > > simply always call shim protocol if available on EFI; it should return
> > > success if secure boot is disabled so should be transparent.
> > >
> > Can you point to some patch to estimate code size of this change? What if
> > shim is not available? How big part of it is related to secure boot? Just
> > changing Linux boot protocol doesn't need FSF involvement. Accepting
> secure
> > boot might. I'd rather make verification framework and make secure boot
> > just one client, so module for it can be easily carried by whoever
> chooses
> > to implement it. But this is probably 2.03 material
>
> John Sullivan has, in the past, expressed that grub calling out to shim
> for secure boot validation is a reasonable method; I'm not sure why we'd
> need more involvement, but if you feel we must, okay.  I'd rather see
> support for the only strong validation system we have in the real world,
> than arbitrary frameworks.  But I agree, we're probably talking about
> something after 2.02.
>
Framework is just an elaborate word for separating verification code from
support around it like retention of the file in memory or determining files
to check. I know of several users for this and would like to avoid code
duplication

>
> --
>   Peter
>

[-- Attachment #2: Type: text/html, Size: 5076 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Tue, Mar 08, 2016 at 12:29:14AM +0300, Andrei Borzenkov wrote:
> 08.03.2016 00:20, Peter Jones пишет:
> > On Mon, Mar 07, 2016 at 11:57:33PM +0300, Andrei Borzenkov wrote:
> >>
> >>> How big part of it is related to secure boot? Just
> >>> changing Linux boot protocol doesn't need FSF involvement. Accepting secure
> >>
> >> Patches currently use EFI stub to launch kernel but I think this is done
> >> simply to make code easier. We can continue to use the same load
> >> protocol as before, just add image verification.
> > 
> > No, they're doing it because that is the supported entry point for EFI
> > in Linux.  We do not want EFI machines using other entry points.  It
> > worked out terribly when we used to do this, and we don't want to start
> > again.  I've Cc'd Matt Fleming, the upstream kernel EFI maintainer,
> > because I'm sure he's going to agree with me.
> 
> So you mean that linux loader is currently broken on EFI?

None of the 3 OSes we produce ever uses it.  I don't know about what
other distros ship, but a lot of them are using the secure boot code by
default in all cases, so they're also going through the EFI stub.

My expectation is that on many systems it does work, but there are a lot
of corner cases where things are not quite right.  In those cases you'll
see problems like:

- less total memory available than expected due to e820 vs efi memory
  map issues
- the very real issue recently where grub set the type incorrectly on
  some memory map entries, resulting in NVDIMMs winding up being marked
  as normal allocatable memory.
- 64-bit kernel on 32-bit platform like Baytrail can't work
- some machines we won't get the virtual address map right and e.g. UEFI
  variables just won't work

It goes on like this.

-- 
  Peter

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2230 bytes --]

Le lun. 7 mars 2016 23:01, Peter Jones <pjones@redhat.com> a écrit :

> On Tue, Mar 08, 2016 at 12:29:14AM +0300, Andrei Borzenkov wrote:
> > 08.03.2016 00:20, Peter Jones пишет:
> > > On Mon, Mar 07, 2016 at 11:57:33PM +0300, Andrei Borzenkov wrote:
> > >>
> > >>> How big part of it is related to secure boot? Just
> > >>> changing Linux boot protocol doesn't need FSF involvement. Accepting
> secure
> > >>
> > >> Patches currently use EFI stub to launch kernel but I think this is
> done
> > >> simply to make code easier. We can continue to use the same load
> > >> protocol as before, just add image verification.
> > >
> > > No, they're doing it because that is the supported entry point for EFI
> > > in Linux.  We do not want EFI machines using other entry points.  It
> > > worked out terribly when we used to do this, and we don't want to start
> > > again.  I've Cc'd Matt Fleming, the upstream kernel EFI maintainer,
> > > because I'm sure he's going to agree with me.
> >
> > So you mean that linux loader is currently broken on EFI?
>
> None of the 3 OSes we produce ever uses it.  I don't know about what
> other distros ship, but a lot of them are using the secure boot code by
> default in all cases, so they're also going through the EFI stub.
>
> My expectation is that on many systems it does work, but there are a lot
> of corner cases where things are not quite right.  In those cases you'll
> see problems like:
>
> - less total memory available than expected due to e820 vs efi memory
>   map issues
> - the very real issue recently where grub set the type incorrectly on
>   some memory map entries, resulting in NVDIMMs winding up being marked
>   as normal allocatable memory.
> - 64-bit kernel on 32-bit platform like Baytrail can't work
> - some machines we won't get the virtual address map right and e.g. UEFI
>   variables just won't work
>
Most of it sounds like just moving code around and not fixing the real
issues. E.g. nvdimm issue can bite on a different way if GRUB itself
mistreated nvdimm or passes bad info to another OS. Switching to linuxefi
is not a reason not to fix real issues

>
> It goes on like this.
>
> --
>   Peter
>

[-- Attachment #2: Type: text/html, Size: 2858 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Michael Chang]

On Mon, Mar 07, 2016 at 05:01:33PM -0500, Peter Jones wrote:
> On Tue, Mar 08, 2016 at 12:29:14AM +0300, Andrei Borzenkov wrote:
> > 08.03.2016 00:20, Peter Jones пишет:
> > > On Mon, Mar 07, 2016 at 11:57:33PM +0300, Andrei Borzenkov wrote:
> > >>
> > >>> How big part of it is related to secure boot? Just
> > >>> changing Linux boot protocol doesn't need FSF involvement. Accepting secure
> > >>
> > >> Patches currently use EFI stub to launch kernel but I think this is done
> > >> simply to make code easier. We can continue to use the same load
> > >> protocol as before, just add image verification.
> > > 
> > > No, they're doing it because that is the supported entry point for EFI
> > > in Linux.  We do not want EFI machines using other entry points.  It
> > > worked out terribly when we used to do this, and we don't want to start
> > > again.  I've Cc'd Matt Fleming, the upstream kernel EFI maintainer,
> > > because I'm sure he's going to agree with me.
> > 
> > So you mean that linux loader is currently broken on EFI?
> 
> None of the 3 OSes we produce ever uses it.  I don't know about what
> other distros ship, but a lot of them are using the secure boot code by
> default in all cases, so they're also going through the EFI stub.
> 
> My expectation is that on many systems it does work, but there are a lot
> of corner cases where things are not quite right.  In those cases you'll
> see problems like:
> 
> - less total memory available than expected due to e820 vs efi memory
>   map issues
> - the very real issue recently where grub set the type incorrectly on
>   some memory map entries, resulting in NVDIMMs winding up being marked
>   as normal allocatable memory.
> - 64-bit kernel on 32-bit platform like Baytrail can't work
> - some machines we won't get the virtual address map right and e.g. UEFI
>   variables just won't work
> 
> It goes on like this.

On the other hand, other grub2 functions like gfxpayload is broken with
linuxefi, as efi stub would set screen_info from scratch by gop protocol
and also linuxefi doesn't initialize it at all (as it seems not relevant
for the efi stub).

I think the switch to efi stub has to consider the existing grub.cfg
could still service without changes and function regression, or we will
end up in trouble of maintaining the config that is in continously
running, espeically for those not created by grub-mkconfig. 

Thanks,
Michael

> 
> -- 
>   Peter
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bugs and tasks for 2.02[~rc1]

[Michael Chang]

On Mon, Mar 07, 2016 at 10:07:58PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> Le lun. 7 mars 2016 23:01, Peter Jones <pjones@redhat.com> a écrit :
> 
> > On Tue, Mar 08, 2016 at 12:29:14AM +0300, Andrei Borzenkov wrote:
> > > 08.03.2016 00:20, Peter Jones пишет:
> > > > On Mon, Mar 07, 2016 at 11:57:33PM +0300, Andrei Borzenkov wrote:
> > > >>
> > > >>> How big part of it is related to secure boot? Just
> > > >>> changing Linux boot protocol doesn't need FSF involvement. Accepting
> > secure
> > > >>
> > > >> Patches currently use EFI stub to launch kernel but I think this is
> > done
> > > >> simply to make code easier. We can continue to use the same load
> > > >> protocol as before, just add image verification.
> > > >
> > > > No, they're doing it because that is the supported entry point for EFI
> > > > in Linux.  We do not want EFI machines using other entry points.  It
> > > > worked out terribly when we used to do this, and we don't want to start
> > > > again.  I've Cc'd Matt Fleming, the upstream kernel EFI maintainer,
> > > > because I'm sure he's going to agree with me.
> > >
> > > So you mean that linux loader is currently broken on EFI?
> >
> > None of the 3 OSes we produce ever uses it.  I don't know about what
> > other distros ship, but a lot of them are using the secure boot code by
> > default in all cases, so they're also going through the EFI stub.
> >
> > My expectation is that on many systems it does work, but there are a lot
> > of corner cases where things are not quite right.  In those cases you'll
> > see problems like:
> >
> > - less total memory available than expected due to e820 vs efi memory
> >   map issues
> > - the very real issue recently where grub set the type incorrectly on
> >   some memory map entries, resulting in NVDIMMs winding up being marked
> >   as normal allocatable memory.
> > - 64-bit kernel on 32-bit platform like Baytrail can't work
> > - some machines we won't get the virtual address map right and e.g. UEFI
> >   variables just won't work
> >
> Most of it sounds like just moving code around and not fixing the real
> issues. E.g. nvdimm issue can bite on a different way if GRUB itself
> mistreated nvdimm or passes bad info to another OS. Switching to linuxefi
> is not a reason not to fix real issues

I think some issues like the scarcity of e820 entry can only be fixed
cleanly in uefi stub. And also, the uefi stub is required for some magic
to happen, like verification.of signed kernel module.

Last but not least, it helps in eliminating duplicated bugs, as what we
are all familiar the ExitBootService() issue and it's stunt in elilo,
grub2 and uefi stub. Why not jumping to the same ship and have it fixed
once and for all.

Thanks,
Michael

> 
> >
> > It goes on like this.
> >
> > --
> >   Peter
> >

> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

08.03.2016 06:40, Michael Chang пишет:
> On Mon, Mar 07, 2016 at 05:01:33PM -0500, Peter Jones wrote:
>> On Tue, Mar 08, 2016 at 12:29:14AM +0300, Andrei Borzenkov wrote:
>>> 08.03.2016 00:20, Peter Jones пишет:
>>>> On Mon, Mar 07, 2016 at 11:57:33PM +0300, Andrei Borzenkov wrote:
>>>>>
>>>>>> How big part of it is related to secure boot? Just
>>>>>> changing Linux boot protocol doesn't need FSF involvement. Accepting secure
>>>>>
>>>>> Patches currently use EFI stub to launch kernel but I think this is done
>>>>> simply to make code easier. We can continue to use the same load
>>>>> protocol as before, just add image verification.
>>>>
>>>> No, they're doing it because that is the supported entry point for EFI
>>>> in Linux.  We do not want EFI machines using other entry points.  It
>>>> worked out terribly when we used to do this, and we don't want to start
>>>> again.  I've Cc'd Matt Fleming, the upstream kernel EFI maintainer,
>>>> because I'm sure he's going to agree with me.
>>>
>>> So you mean that linux loader is currently broken on EFI?
>>
>> None of the 3 OSes we produce ever uses it.  I don't know about what
>> other distros ship, but a lot of them are using the secure boot code by
>> default in all cases, so they're also going through the EFI stub.
>>

SUSE allows switching off secure boot in YaST, this is relatively
popular advice to users to work around some problems and quite a lot of
users simply do not want to use SB at all (judging by forum posts). So
it gets at least some use in the wild.

>> My expectation is that on many systems it does work, but there are a lot
>> of corner cases where things are not quite right.  In those cases you'll
>> see problems like:
>>
>> - less total memory available than expected due to e820 vs efi memory
>>   map issues

Do you have pointers to real-life examples?

>> - the very real issue recently where grub set the type incorrectly on
>>   some memory map entries, resulting in NVDIMMs winding up being marked
>>   as normal allocatable memory.

Fixed in beta3.

>> - 64-bit kernel on 32-bit platform like Baytrail can't work

Do you mean "32 bit EFI"? If yes, why is it a problem?

>> - some machines we won't get the virtual address map right and e.g. UEFI
>>   variables just won't work
>>

This sounds like bug in GRUB that needs fixing anyway.

>> It goes on like this.
> 
> On the other hand, other grub2 functions like gfxpayload is broken with
> linuxefi, as efi stub would set screen_info from scratch by gop protocol
> and also linuxefi doesn't initialize it at all (as it seems not relevant
> for the efi stub).
> 
> I think the switch to efi stub has to consider the existing grub.cfg
> could still service without changes and function regression, or we will
> end up in trouble of maintaining the config that is in continously
> running, espeically for those not created by grub-mkconfig. 
> 

Yes, any implementation should reuse as much of existing loader code as
possible and only change handover method.

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

07.03.2016 22:00, Peter Jones пишет:
...
> 
>>> And these are hardware specific.  They're not critical, in the sense
>>> that I can keep carrying them if you have any problems and we can work
>>> it out for the /next/ release.
>>>
>>> beee9fc Add vlan-tag support on IBM PPC machines
>>
>> Yes, openSUSE (and I think SUSE) also carries variant of this patch. We
>> probably need to revisit it.
>>

It looks like there are quite a lot of different patches floating
around. We have one in next branch; I just sent some cleanup against
this code and would be interested in review. I would also appreciate if
we all could settle on a single version, hopefully what we (will) have
in next.

...
>>
>>> 297d32d for ppc, reset console display attr when clear screen
>>
>> Does not apply cleanly to upstream (is on top of some other patch?)
> 
> I'm not seeing any reason this should not apply.  I think probably the

I screwed something up, sorry. Looks sane.

...
> 
>>> 1f1a695 Make "exit" take a return code.
>>>
>>
>> What about
>> https://lists.gnu.org/archive/html/grub-devel/2016-01/msg00049.html and
>> followup?
> 
> Well, that's a good question.  The code in this patch is sort of a
> middle ground there - it makes GRUB_EFI_LOAD_ERROR the default, and
> makes "exit" and "exit N" both work.  So if you do "exit 0", you get no
> fallback to the next item, but "exit" alone, "exit N" for any N but 0,
> and all the failure paths in the C code all wind up showing the next
> menu item.
> 
> I can make it another command if you like, but it seems like a pretty
> natural semantic for exit to have.  So the issue is that it won't do
> anything on a bunch of platforms other than what they're already doing.
> Is that a big deal?  We have plenty of commands that perform a level of
> functionality based on the underlying support.
> 

As long as EFI is the only platform that has notion of "returning to
menu" what is the value of code bloat for other platforms? We'd need
then invent exit codes or options etc and it really is not worth it, at
least now.

...

> 
>>> e0bb91a Fix bzr's ignore artificats in .gitignore
> 
> Did you accidentally skip this one?
>

Not really but it is a lot of churn in something I do not really care
about :) Could you split it in two - alpha sorting and actual changes,
this makes it easier to see what is changed.


>>> ecaecc9 Add some __unused__ where gcc 5.x is more picky about it.
>>
>> How this can become unused?
>>
>>>  grub_gettext_env_write_lang (struct grub_env_var *var
>>>   			     __attribute__ ((unused)), const char *val)
>>>   {
>>>  -  grub_err_t err;
>>>  +  grub_err_t __attribute__((__unused__)) err;
>>>     err = grub_gettext_init_ext (&main_context, val, grub_env_get ("locale_dir"),
>>>   			       grub_env_get ("prefix"));
>>>     if (err)
>>
>> And in normal, entry is used. So more detailed explanation how either of
>> them become unused is needed (and BTW it is compiled with gcc 5.x on
>> openSUSE and apparently without errors).
> 
> Yep, you're right - sorry about that, the last one should have been
> stripped out - it's the artifact of another patch that's not really
> upstreamable in its current form.  The whole first file looks valid to
> me, though? 

Huh? The about quote is from the first file. How can "err" be unused if
it is assigned and checked on the next line?

> I'll rebase it as two patches and leave one of them in
> for-upstream.
> 
>>> e704140 Move bash completion script (#922997)
>>
>> Well, this is obvious compatibility question. Is there any way to detect
>> it at configure time? Does bash have pkg-config or similar?
> 
> I don't see anything obviously like that, unfortunately, and I'm not
> really sure in what version they switched it.
> 

There is.

bor@bor-Latitude-E5450:~/src/systemd$ pkg-config --variable
completionsdir bash-completion
/usr/share/bash-completion/completions

Could you add configure.ac option that checks for it and defaults to
current value?

>>> bc5d351 Allow "fallback" to include entries by title, not just number.
>>
>> What about multiple entries? fallback allows them.
> 
> I'm not sure I understand your question.  This still allows that if you

Currently you can have

fallback="1 2 3 4"

Your patch treats full value of "fallback" as a single title.

> treat them numerically or by id.  I suppose it's possible to break the
> value up as a list of quoted strings to test by title, but it gets messy
> with corner cases pretty quickly.

We usually accept ids everywhere numbers or titles are accepted; and ids
can quite sensibly be split in multiple entries.

>  FWIW the documentation *doesn't* say
> that it allows multiple entries, but *does* say, more or less by
> accident, that you can use titles:

We can also fix documentation :)

We usually favor ids over names or titles. But that also can become
pretty much hairy with submenus. So I think this needs some discussion
about design.
...
>>
>>> 5212412 Fix bad test on GRUB_DISABLE_SUBMENU.
>>
>> What is bad here? The documented valued is "y".
> 
> Actually the real issue is that we're inconsistent among many variables,
> where we use (and document) "yes", "y", and "true".  So we discovered a
> tendency to put the wrong thing in, and I got tired of it and made this
> one take either of those.  Maybe this should be addressed more
> systemically with a function to judge true or false that recognizes
> 1/true/y/yes as true?

This came up before and I personally am fine with generic function that
checks boolean value (C version is needed as well). Something for post-2.02.

> 
>>> 73545c7 Add GRUB_DISABLE_UUID.
>>
>> If name as detected by GRUB is correct, there will be no search because
>> hints will be correct (just direct verification that device is indeed
>> correct). If name is wrong you need search, otherwise you fail to boot
>> or boot wrong binary. I do not see what we gain here.
> 
> So, the bug report from our QA dept believed
> GRUB_DISABLE_LINUX_UUID=true should accomplish this, and that it's
> pointless without it.  And I think they've kind of got a point, since if
> the user has the problem GRUB_DISABLE_LINUX_UUID was meant to solve,
> there's no reason to believe they can't have the same problem with the
> other filesystem.  We made them separate settings because one is about
> /boot and one is about / , but fundamentally they're both doing parts of
> the same thing.
> 

Not really. Linux UUIDs cannot be used without initrd, so if you have
monolithic kernel without initrd you cannot really use UUIDs for root.
So you can disable them in this case.

It really needs some more details about problem it was intended to solve.

> I'm not really disagreeing with your logic here - but if we have it
> avoiding UUIDs for one of those, it would seem like the other would also
> be something we can avoid.
> 
...

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Tue, Mar 08, 2016 at 08:57:16PM +0300, Andrei Borzenkov wrote:
> 07.03.2016 22:00, Peter Jones пишет:
> ...
> > 
> >>> And these are hardware specific.  They're not critical, in the sense
> >>> that I can keep carrying them if you have any problems and we can work
> >>> it out for the /next/ release.
> >>>
> >>> beee9fc Add vlan-tag support on IBM PPC machines
> >>
> >> Yes, openSUSE (and I think SUSE) also carries variant of this patch. We
> >> probably need to revisit it.
> >>
> 
> It looks like there are quite a lot of different patches floating
> around. We have one in next branch; I just sent some cleanup against
> this code and would be interested in review. I would also appreciate if
> we all could settle on a single version, hopefully what we (will) have
> in next.

Okay.

>> >>> 1f1a695 Make "exit" take a return code.
> >>>
> >>
> >> What about
> >> https://lists.gnu.org/archive/html/grub-devel/2016-01/msg00049.html and
> >> followup?
> > 
> > Well, that's a good question.  The code in this patch is sort of a
> > middle ground there - it makes GRUB_EFI_LOAD_ERROR the default, and
> > makes "exit" and "exit N" both work.  So if you do "exit 0", you get no
> > fallback to the next item, but "exit" alone, "exit N" for any N but 0,
> > and all the failure paths in the C code all wind up showing the next
> > menu item.
> > 
> > I can make it another command if you like, but it seems like a pretty
> > natural semantic for exit to have.  So the issue is that it won't do
> > anything on a bunch of platforms other than what they're already doing.
> > Is that a big deal?  We have plenty of commands that perform a level of
> > functionality based on the underlying support.
> > 
> 
> As long as EFI is the only platform that has notion of "returning to
> menu" what is the value of code bloat for other platforms? We'd need
> then invent exit codes or options etc and it really is not worth it, at
> least now.

I guess that's a fair point, but I still think the semantics of "the
command to exit with an exit code isn't exit" is pretty weird.  Would
you have an objection to two implementations with some #ifdef things
going on to determine which you get at build time, to avoid the bloat on
other platforms?

> >>> e0bb91a Fix bzr's ignore artificats in .gitignore
> > 
> > Did you accidentally skip this one?
> >
> 
> Not really but it is a lot of churn in something I do not really care
> about :) Could you split it in two - alpha sorting and actual changes,
> this makes it easier to see what is changed.

Okay, will do.

> >>> ecaecc9 Add some __unused__ where gcc 5.x is more picky about it.
> >>
> >> How this can become unused?
> >>
> >>>  grub_gettext_env_write_lang (struct grub_env_var *var
> >>>   			     __attribute__ ((unused)), const char *val)
> >>>   {
> >>>  -  grub_err_t err;
> >>>  +  grub_err_t __attribute__((__unused__)) err;
> >>>     err = grub_gettext_init_ext (&main_context, val, grub_env_get ("locale_dir"),
> >>>   			       grub_env_get ("prefix"));
> >>>     if (err)
> >>
> >> And in normal, entry is used. So more detailed explanation how either of
> >> them become unused is needed (and BTW it is compiled with gcc 5.x on
> >> openSUSE and apparently without errors).
> > 
> > Yep, you're right - sorry about that, the last one should have been
> > stripped out - it's the artifact of another patch that's not really
> > upstreamable in its current form.  The whole first file looks valid to
> > me, though? 
> 
> Huh? The about quote is from the first file. How can "err" be unused if
> it is assigned and checked on the next line?

Okay, clearly I got confused there because the other file /was/ the
problem I described.  But the same actually applies to this one as well,
so I'm going to move it out of this branch as well.  Basically I've got
some UI patches I'm carrying from our desktop team that accomplish what
they wanted to visually, but they're not really very good patches, which
is why I didn't push those.  One of them removes the error printing
between initializing locale_dir and secondary_locale_dir.  But that
patch isn't something I think is suitable for upstream as it is written,
and I didn't realize this patch depended on that one.

Sorry about that.  I've folded them together in my tree now, so that
I'll remember to fix that when I'm cleaning those up.

> > I'll rebase it as two patches and leave one of them in
> > for-upstream.
> > 
> >>> e704140 Move bash completion script (#922997)
> >>
> >> Well, this is obvious compatibility question. Is there any way to detect
> >> it at configure time? Does bash have pkg-config or similar?
> > 
> > I don't see anything obviously like that, unfortunately, and I'm not
> > really sure in what version they switched it.
> > 
> 
> There is.
> 
> bor@bor-Latitude-E5450:~/src/systemd$ pkg-config --variable
> completionsdir bash-completion
> /usr/share/bash-completion/completions
> 
> Could you add configure.ac option that checks for it and defaults to
> current value?

Gah, it's in bash-completion not in bash.  Well, anyway: sure thing,
I'll fix up configure.ac, though I'm not that well versed in autoconf.
Currently what I have is here, and I welcome any feedback:
https://github.com/vathpela/grub2-fedora/commit/04844de3eb04f

Note that I've built that version but not actually tested it yet.

> >>> bc5d351 Allow "fallback" to include entries by title, not just number.
> >>
> >> What about multiple entries? fallback allows them.
> > 
> > I'm not sure I understand your question.  This still allows that if you
> 
> Currently you can have
> 
> fallback="1 2 3 4"
> 
> Your patch treats full value of "fallback" as a single title.
> 
> > treat them numerically or by id.  I suppose it's possible to break the
> > value up as a list of quoted strings to test by title, but it gets messy
> > with corner cases pretty quickly.
> 
> We usually accept ids everywhere numbers or titles are accepted; and ids
> can quite sensibly be split in multiple entries.
> 
> >  FWIW the documentation *doesn't* say
> > that it allows multiple entries, but *does* say, more or less by
> > accident, that you can use titles:
> 
> We can also fix documentation :)
> 
> We usually favor ids over names or titles. But that also can become
> pretty much hairy with submenus. So I think this needs some discussion
> about design.

Alright; I've moved it to my -wip branch.  At the same time I've updated
it to address your concern, I think, so if you want to have a look:
https://github.com/vathpela/grub2-fedora/commit/8c93aae4e

> >>> 5212412 Fix bad test on GRUB_DISABLE_SUBMENU.
> >>
> >> What is bad here? The documented valued is "y".
> > 
> > Actually the real issue is that we're inconsistent among many variables,
> > where we use (and document) "yes", "y", and "true".  So we discovered a
> > tendency to put the wrong thing in, and I got tired of it and made this
> > one take either of those.  Maybe this should be addressed more
> > systemically with a function to judge true or false that recognizes
> > 1/true/y/yes as true?
> 
> This came up before and I personally am fine with generic function that
> checks boolean value (C version is needed as well). Something for post-2.02.

Agreed.

> >>> 73545c7 Add GRUB_DISABLE_UUID.
> >>
> >> If name as detected by GRUB is correct, there will be no search because
> >> hints will be correct (just direct verification that device is indeed
> >> correct). If name is wrong you need search, otherwise you fail to boot
> >> or boot wrong binary. I do not see what we gain here.
> > 
> > So, the bug report from our QA dept believed
> > GRUB_DISABLE_LINUX_UUID=true should accomplish this, and that it's
> > pointless without it.  And I think they've kind of got a point, since if
> > the user has the problem GRUB_DISABLE_LINUX_UUID was meant to solve,
> > there's no reason to believe they can't have the same problem with the
> > other filesystem.  We made them separate settings because one is about
> > /boot and one is about / , but fundamentally they're both doing parts of
> > the same thing.
> > 
> 
> Not really. Linux UUIDs cannot be used without initrd, so if you have
> monolithic kernel without initrd you cannot really use UUIDs for root.
> So you can disable them in this case.
> 
> It really needs some more details about problem it was intended to solve.

Original bug is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1027833 .  I'm not
personally very invested in this one, except inasmuch as it's in my
tree and I'd like that diff to get smaller over time... :)

-- 
  Peter

Re: Bugs and tasks for 2.02[~rc1]

[Olaf Hering]

On Wed, Mar 02, Vladimir 'phcoder' Serbinenko wrote:

> I would like to come up with a complete list of 2.02 blockers in one week time,
> so that we can have a reasonable timeline

Did anyone took the time to fix btrfs support (convert it from handling
btrfs as filesystem into that what it really is: a container of subvolumes)?


Olaf

Re: Bugs and tasks for 2.02[~rc1]

[Michael Chang]

On Wed, Mar 09, 2016 at 07:38:45AM +0100, Olaf Hering wrote:
> On Wed, Mar 02, Vladimir 'phcoder' Serbinenko wrote:
> 
> > I would like to come up with a complete list of 2.02 blockers in one week time,
> > so that we can have a reasonable timeline
> 
> Did anyone took the time to fix btrfs support (convert it from handling
> btrfs as filesystem into that what it really is: a container of subvolumes)?

I think the first thing to decide is the path scheme on a subvolume to
be used in grub config. Currently it's treated as if no subvolume and
use path from topmost tree. It's good to get btrfs handled consistently
as other file systems but sacrificing the abilty to be always boot from
default subvolume.

Thanks,
Michael

> 
> 
> Olaf
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

On Wed, Mar 9, 2016 at 10:54 AM, Michael Chang <mchang@suse.com> wrote:
> On Wed, Mar 09, 2016 at 07:38:45AM +0100, Olaf Hering wrote:
>> On Wed, Mar 02, Vladimir 'phcoder' Serbinenko wrote:
>>
>> > I would like to come up with a complete list of 2.02 blockers in one week time,
>> > so that we can have a reasonable timeline
>>
>> Did anyone took the time to fix btrfs support (convert it from handling
>> btrfs as filesystem into that what it really is: a container of subvolumes)?
>
> I think the first thing to decide is the path scheme on a subvolume to
> be used in grub config. Currently it's treated as if no subvolume and
> use path from topmost tree. It's good to get btrfs handled consistently
> as other file systems but sacrificing the abilty to be always boot from
> default subvolume.
>

It is hardly 2.02 material, so should be discussed separately.

Re: Bugs and tasks for 2.02[~rc1]

[Daniel Kiper]

On Wed, Mar 02, 2016 at 11:24:49PM +0100, Daniel Kiper wrote:
> Hey,
>
> On Wed, Mar 02, 2016 at 03:01:03PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> > Hello, all. I went through the list of bugs and created a shortlist of bugs
> > that need to be looked at for 2.02. I have marked them with plan_release_id
> > set to 2.02.
> > Statistics: [1]
> > Search (with loads of false positives unfortunately): [2]
> > Not every bug there is a release blocker, for some of them it just would be
> > nice to know status before releasing. Some of them are probably already
> > fixed.
> >
> > Additionally I created a category "Hardware specific" [3]. Bugs there are
> > not release blockers but fixing them could benefit the release.
> >
> > I would also appreciate if distros would tell which patches they would
> > carry if 2.02 was released as it is now. If some patches are in more than 1
> > distro we probably need to look into including them.
> >
> > Please bring up any tasks that needs to be done in your opinion for 2.02
> > and not mentioned as separate thread with [2.02] in subject line.
>
> Is it possible to get "multiboot2: Add two extensions"
> (https://lists.gnu.org/archive/html/grub-devel/2016-03/msg00053.html)
> patch series into 2.02 train?

Is there anybody out there?

Daniel

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]

I will go through most of my mails tomorrow. I'm inclined to include
multiboot2 extensions but had few comments about patch style

Le mer. 9 mars 2016 15:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> a
écrit :

> On Wed, Mar 09, 2016 at 11:49:40AM +0100, Daniel Kiper wrote:
> > On Wed, Mar 02, 2016 at 11:24:49PM +0100, Daniel Kiper wrote:
> > > Hey,
> > >
> > > On Wed, Mar 02, 2016 at 03:01:03PM +0000, Vladimir 'phcoder'
> Serbinenko wrote:
> > > > Hello, all. I went through the list of bugs and created a shortlist
> of bugs
> > > > that need to be looked at for 2.02. I have marked them with
> plan_release_id
> > > > set to 2.02.
> > > > Statistics: [1]
> > > > Search (with loads of false positives unfortunately): [2]
> > > > Not every bug there is a release blocker, for some of them it just
> would be
> > > > nice to know status before releasing. Some of them are probably
> already
> > > > fixed.
> > > >
> > > > Additionally I created a category "Hardware specific" [3]. Bugs
> there are
> > > > not release blockers but fixing them could benefit the release.
> > > >
> > > > I would also appreciate if distros would tell which patches they
> would
> > > > carry if 2.02 was released as it is now. If some patches are in more
> than 1
> > > > distro we probably need to look into including them.
> > > >
> > > > Please bring up any tasks that needs to be done in your opinion for
> 2.02
> > > > and not mentioned as separate thread with [2.02] in subject line.
> > >
> > > Is it possible to get "multiboot2: Add two extensions"
> > > (https://lists.gnu.org/archive/html/grub-devel/2016-03/msg00053.html)
> > > patch series into 2.02 train?
> >
> > Is there anybody out there?
>
> In case somebody wants a link to the consumer of this, see please
> https://github.com/xenserver/xen-4.6.pg (see master directory - and
> there are the multiboot patches).
>
> Thought I believe Daniel also has a link to the actual posting of the
> patches
> on xen-devel somewhere?
>
>

[-- Attachment #2: Type: text/html, Size: 2769 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Matt Fleming]

On Tue, 08 Mar, at 07:57:35AM, Andrei Borzenkov wrote:
> >> - 64-bit kernel on 32-bit platform like Baytrail can't work
> 
> Do you mean "32 bit EFI"? If yes, why is it a problem?

The biggest issue is that there's no way right now for a boot loader
to tell the kernel that it needs to use a translation layer when
calling EFI services (we refer to this as the "thunk" layer in the
kernel) without going via the EFI handover protocol.

Obviously this could be achieved by writing the required code for GRUB
but it would be largely duplicated from the existing code EFI boot
stub code in the kernel. I don't think it's worth the effort.

The kernel figures out when to use the thunk layer by taking note of
which EFI handover offset entry point the boot loader entered from, we
include both a 32-bit and 64-bit entry point when CONFIG_EFI_MIXED is
enabled.

Re: Bugs and tasks for 2.02[~rc1]

[Daniel Kiper]

On Wed, Mar 09, 2016 at 02:51:42PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> I will go through most of my mails tomorrow. I'm inclined to include
> multiboot2 extensions but had few comments about patch style

No problem. Thanks a lot!

Daniel

Linux loader EFI handover (was: Bugs and tasks for 2.02[~rc1])

[Andrei Borzenkov]

09.03.2016 18:18, Matt Fleming пишет:
> On Tue, 08 Mar, at 07:57:35AM, Andrei Borzenkov wrote:
>>>> - 64-bit kernel on 32-bit platform like Baytrail can't work
>>
>> Do you mean "32 bit EFI"? If yes, why is it a problem?
> 
> The biggest issue is that there's no way right now for a boot loader
> to tell the kernel that it needs to use a translation layer when
> calling EFI services (we refer to this as the "thunk" layer in the
> kernel) without going via the EFI handover protocol.
> 
> Obviously this could be achieved by writing the required code for GRUB
> but it would be largely duplicated from the existing code EFI boot
> stub code in the kernel. I don't think it's worth the effort.
> 

That sounds like this should be supported irrespectively of secure boot
then.

> The kernel figures out when to use the thunk layer by taking note of
> which EFI handover offset entry point the boot loader entered from, we
> include both a 32-bit and 64-bit entry point when CONFIG_EFI_MIXED is
> enabled.
> 

OK, looking at linuxefi patch, the only real difference from normal
linux loader is that it restricts memory allocations to below 1G. Is it
kernel requirement?

What to do if kernel is compiled without CONFIG_EFI_MIXED support?
Should we fall back to traditional handover without calling into EFI
stub or fail load completely?

Re: Linux loader EFI handover (was: Bugs and tasks for 2.02[~rc1])

[Matt Fleming]

On Wed, 09 Mar, at 11:15:16PM, Andrei Borzenkov wrote:
> 09.03.2016 18:18, Matt Fleming пишет:
> > On Tue, 08 Mar, at 07:57:35AM, Andrei Borzenkov wrote:
> >>>> - 64-bit kernel on 32-bit platform like Baytrail can't work
> >>
> >> Do you mean "32 bit EFI"? If yes, why is it a problem?
> > 
> > The biggest issue is that there's no way right now for a boot loader
> > to tell the kernel that it needs to use a translation layer when
> > calling EFI services (we refer to this as the "thunk" layer in the
> > kernel) without going via the EFI handover protocol.
> > 
> > Obviously this could be achieved by writing the required code for GRUB
> > but it would be largely duplicated from the existing code EFI boot
> > stub code in the kernel. I don't think it's worth the effort.
> > 
> 
> That sounds like this should be supported irrespectively of secure boot
> then.
 
I'm not sure what you mean here. Are you suggesting to add support for
the EFI handover protocol to the regular linux loader?

> > The kernel figures out when to use the thunk layer by taking note of
> > which EFI handover offset entry point the boot loader entered from, we
> > include both a 32-bit and 64-bit entry point when CONFIG_EFI_MIXED is
> > enabled.
> > 
> 
> OK, looking at linuxefi patch, the only real difference from normal
> linux loader is that it restricts memory allocations to below 1G. Is it
> kernel requirement?
 
No, I'm not aware of such a requirement for modern kernels, though
it's possible there was a historical restriction.

> What to do if kernel is compiled without CONFIG_EFI_MIXED support?
> Should we fall back to traditional handover without calling into EFI
> stub or fail load completely?

Falling back to the traditional handover and disabling EFI runtime
services would be the best way to go. You can see whether mixed mode
is enabled by inspecting the ->xloadflags in the bzImage header.

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]

On Monday, March 7, 2016, Matt Fleming <matt@codeblueprint.co.uk> wrote:

> On Mon, 07 Mar, at 04:20:00PM, Peter Jones wrote:
> > On Mon, Mar 07, 2016 at 11:57:33PM +0300, Andrei Borzenkov wrote:
> > >
> > > > How big part of it is related to secure boot? Just
> > > > changing Linux boot protocol doesn't need FSF involvement. Accepting
> secure
> > >
> > > Patches currently use EFI stub to launch kernel but I think this is
> done
> > > simply to make code easier. We can continue to use the same load
> > > protocol as before, just add image verification.
> >
> > No, they're doing it because that is the supported entry point for EFI
> > in Linux.  We do not want EFI machines using other entry points.  It
> > worked out terribly when we used to do this, and we don't want to start
> > again.  I've Cc'd Matt Fleming, the upstream kernel EFI maintainer,
> > because I'm sure he's going to agree with me.
>
> Yeah, I agree with you.
>
> Having multiple entry points works out badly for everyone, since they
> tend to bit rot, and few people test all of them equally. While we
> continue to support legacy boot entry points upstream, we're not
> actively adding support for new features to them for EFI.
>
> For boot loaders, the EFI handover protocol is definitely the
> preferred method of booting Linux on EFI.
>
I'm ok with switching to EFI entry point for EFI platforms if plain 32-bit
entry point stays available for platforms like coreboot. Can we agree on
this?


-- 
Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: Type: text/html, Size: 1914 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Wednesday, March 9, 2016, Olaf Hering <olaf@aepfle.de> wrote:

> On Wed, Mar 02, Vladimir 'phcoder' Serbinenko wrote:
>
> > I would like to come up with a complete list of 2.02 blockers in one
> week time,
> > so that we can have a reasonable timeline
>
> Did anyone took the time to fix btrfs support (convert it from handling
> btrfs as filesystem into that what it really is: a container of
> subvolumes)?
>
What is the problem with current approach? subvolume is little more than a
directory from a point of view of read-only implementation

>
>
> Olaf
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org <javascript:;>
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: Type: text/html, Size: 1308 bytes --]

Re: Linux loader EFI handover

[Andrei Borzenkov]

10.03.2016 17:21, Matt Fleming пишет:
> On Wed, 09 Mar, at 11:15:16PM, Andrei Borzenkov wrote:
>> 09.03.2016 18:18, Matt Fleming пишет:
>>> On Tue, 08 Mar, at 07:57:35AM, Andrei Borzenkov wrote:
>>>>>> - 64-bit kernel on 32-bit platform like Baytrail can't work
>>>>
>>>> Do you mean "32 bit EFI"? If yes, why is it a problem?
>>>
>>> The biggest issue is that there's no way right now for a boot loader
>>> to tell the kernel that it needs to use a translation layer when
>>> calling EFI services (we refer to this as the "thunk" layer in the
>>> kernel) without going via the EFI handover protocol.
>>>
>>> Obviously this could be achieved by writing the required code for GRUB
>>> but it would be largely duplicated from the existing code EFI boot
>>> stub code in the kernel. I don't think it's worth the effort.
>>>
>>
>> That sounds like this should be supported irrespectively of secure boot
>> then.
>  
> I'm not sure what you mean here. Are you suggesting to add support for
> the EFI handover protocol to the regular linux loader?
> 

Yes.

>>> The kernel figures out when to use the thunk layer by taking note of
>>> which EFI handover offset entry point the boot loader entered from, we
>>> include both a 32-bit and 64-bit entry point when CONFIG_EFI_MIXED is
>>> enabled.
>>>
>>
>> OK, looking at linuxefi patch, the only real difference from normal
>> linux loader is that it restricts memory allocations to below 1G. Is it
>> kernel requirement?
>  
> No, I'm not aware of such a requirement for modern kernels, though
> it's possible there was a historical restriction.
> 
>> What to do if kernel is compiled without CONFIG_EFI_MIXED support?
>> Should we fall back to traditional handover without calling into EFI
>> stub or fail load completely?
> 
> Falling back to the traditional handover and disabling EFI runtime
> services would be the best way to go. You can see whether mixed mode
> is enabled by inspecting the ->xloadflags in the bzImage header.
> 

OK, even more reason to support EFI handover as part of normal linux loader.

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

08.03.2016 00:10, Peter Jones пишет:
> On Mon, Mar 07, 2016 at 11:33:52PM +0300, Andrei Borzenkov wrote:
>> 07.03.2016 22:57, Vladimir 'phcoder' Serbinenko пишет:
>>>>
>>>>>>> I would also appreciate if distros would tell which patches they would
>>>>>>> carry if 2.02 was released as it is now. If some patches are in more
>>>> than 1
>>>>>>> distro we probably need to look into including them.
>>>>>>
>>>>>> 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
>>>
>>
>> Yes, of course, that was what I actually mean - get rid of special
>> linuxefi and just fold processing into standard linux command. We can
>> simply always call shim protocol if available on EFI; it should return
>> success if secure boot is disabled so should be transparent.
>>
>> What is really a problem (or at least rather more involved) is
>> chainloader. If secure boot is enabled, we effectively need to implement
>> complete relocation of PE binary, bypassing EFI. I remember several
>> interesting bugs in this code in openSUSE :)
> 
> We've already got something like that (I think derived from the SuSE
> patch) here:
> https://github.com/vathpela/grub2-fedora/commit/4ea532fc9f8af1b1b23f424e3205c5eebfa8f877
> 
> I think at this point it seems to generally work.  Note that we're
> bypassing EFI for loading, but we're still calling into shim for the
> verification, so there's not a validation loophole here.
> 
>> One more thing is module load. Currently patches disable it and use only
>> modules included in core.img. I think we could relax it and allow module
>> loading from internal memory disk. This will allow distribute signed
>> image as grub-mkstanalone, making available full GRUB functionality.
> 
> I'm not seeing what this accomplishes.  We don't have major limitations
> on e.g. bootloader size on these platforms, so linking in the modules
> we're comfortable supporting the first time is not a big deal.  Maybe
> I'm just missing your point though?
> 

Modules included in image are loaded and initialized when GRUB starts;
we may not want to do it for every module (in some cases modules are
mutually exclusive). Including only selected module almost sure means
you will miss some command when you need it (I remember attempts to
debug problems on EFI and finding that none of usual lsefi & co are
present). Having them in memory disk makes full functionality available
without any unintended side effect (except slightly increased size).

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

09.03.2016 00:47, Peter Jones пишет:
>>>
>>>>> e704140 Move bash completion script (#922997)
>>>>
>>>> Well, this is obvious compatibility question. Is there any way to detect
>>>> it at configure time? Does bash have pkg-config or similar?
>>>
>>> I don't see anything obviously like that, unfortunately, and I'm not
>>> really sure in what version they switched it.
>>>
>>
>> There is.
>>
>> bor@bor-Latitude-E5450:~/src/systemd$ pkg-config --variable
>> completionsdir bash-completion
>> /usr/share/bash-completion/completions
>>
>> Could you add configure.ac option that checks for it and defaults to
>> current value?
> 
> Gah, it's in bash-completion not in bash.  Well, anyway: sure thing,
> I'll fix up configure.ac, though I'm not that well versed in autoconf.
> Currently what I have is here, and I welcome any feedback:
> https://github.com/vathpela/grub2-fedora/commit/04844de3eb04f
> 

Default should be current value.

This should use PKG_CHECK_EXISTS which also correctly handles missing
pkg-config at configure time. It is OK to require pkg-config for
building from GIT though.

We may want to make it into --with-bashcompletiondir so users can set it
also if pkg-config and/or bash-completion are not available.

Also please print bashcompletiondir value in final summary.

> Note that I've built that version but not actually tested it yet.
> 
...

> 
>>>>> 73545c7 Add GRUB_DISABLE_UUID.
>>>>
>>>> If name as detected by GRUB is correct, there will be no search because
>>>> hints will be correct (just direct verification that device is indeed
>>>> correct). If name is wrong you need search, otherwise you fail to boot
>>>> or boot wrong binary. I do not see what we gain here.
>>>
>>> So, the bug report from our QA dept believed
>>> GRUB_DISABLE_LINUX_UUID=true should accomplish this, and that it's
>>> pointless without it.  And I think they've kind of got a point, since if
>>> the user has the problem GRUB_DISABLE_LINUX_UUID was meant to solve,
>>> there's no reason to believe they can't have the same problem with the
>>> other filesystem.  We made them separate settings because one is about
>>> /boot and one is about / , but fundamentally they're both doing parts of
>>> the same thing.
>>>
>>
>> Not really. Linux UUIDs cannot be used without initrd, so if you have
>> monolithic kernel without initrd you cannot really use UUIDs for root.
>> So you can disable them in this case.
>>
>> It really needs some more details about problem it was intended to solve.
> 
> Original bug is here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1027833 .  I'm not
> personally very invested in this one, except inasmuch as it's in my
> tree and I'd like that diff to get smaller over time... :)
> 

So user has /boot UUID changing all the time? Unfortunately this bug
does not really explain why it happens. I mean, normally UUID of /boot
changes when you re-create filesystem, but then your /boot/grub is lost
as well together with grub.cfg and you need to create it again at which
point you get new UUID.

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

02.03.2016 18:01, Vladimir 'phcoder' Serbinenko пишет:
> 
> Please bring up any tasks that needs to be done in your opinion for 2.02
> and not mentioned as separate thread with [2.02] in subject line.
> 

There were several coverity defects that had been marked as "Fix
submitted" by you quite some time ago but apparently fixes were never
pushed. Could you check if you still have them and submit?

Re: Bugs and tasks for 2.02[~rc1]

[Matt Fleming]

On Fri, 11 Mar, at 04:51:52PM, Vladimir 'phcoder' Serbinenko wrote:
> 
> I'm ok with switching to EFI entry point for EFI platforms if plain 32-bit
> entry point stays available for platforms like coreboot. Can we agree on
> this?

Yes, the legacy 32-bit entry points won't be going anywhere. They will
still be available.

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

Can somebody prepare a patch for this minimally changing current linux.c?

On Mon, Mar 14, 2016 at 8:17 AM, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Fri, 11 Mar, at 04:51:52PM, Vladimir 'phcoder' Serbinenko wrote:
>>
>> I'm ok with switching to EFI entry point for EFI platforms if plain 32-bit
>> entry point stays available for platforms like coreboot. Can we agree on
>> this?
>
> Yes, the legacy 32-bit entry points won't be going anywhere. They will
> still be available.



-- 
Regards
Vladimir 'phcoder' Serbinenko

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Tue, Mar 15, 2016 at 10:38:32AM -0700, Vladimir 'phcoder' Serbinenko wrote:
> Can somebody prepare a patch for this minimally changing current linux.c?

Sure, I can do that - sorry for the delay here, I had some family things
come up and had to spend last week away.  So it'll still be a bit
longer, because I'm still catching up with stuff.

-- 
  Peter

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]

Sorry, for delay. We have a busy period at work but it should end soon.
I've put up the list of tasks for 2.02 in a doc:
https://docs.google.com/document/d/1O6wveo1_WsAyEHMD041xMYvhDTDp3jQYzmqkgBx57HM/edit?usp=sharing
.
If some of them turn out too much work or too tricky, they can still be
removed. If your task is not in the list, you have asked for 2.02 and I
haven't specifically replied to you that it's not ok for 2.02, then I've
forgotten it. In this case please email me privately.

Le Wed, Mar 2, 2016 à 7:01 AM, Vladimir 'phcoder' Serbinenko <
phcoder@gmail.com> a écrit :

> Hello, all. I went through the list of bugs and created a shortlist of
> bugs that need to be looked at for 2.02. I have marked them with
> plan_release_id set to 2.02.
> Statistics: [1]
> Search (with loads of false positives unfortunately): [2]
> Not every bug there is a release blocker, for some of them it just would
> be nice to know status before releasing. Some of them are probably already
> fixed.
>
> Additionally I created a category "Hardware specific" [3]. Bugs there are
> not release blockers but fixing them could benefit the release.
>
> I would also appreciate if distros would tell which patches they would
> carry if 2.02 was released as it is now. If some patches are in more than 1
> distro we probably need to look into including them.
>
> Please bring up any tasks that needs to be done in your opinion for 2.02
> and not mentioned as separate thread with [2.02] in subject line.
>
> I would like to come up with a complete list of 2.02 blockers in one week
> time, so that we can have a reasonable timeline
>
> [1]
> https://savannah.gnu.org/bugs/reporting.php?group_id=68&field=plan_release_id
> [2]
> https://savannah.gnu.org/search/?type_of_search=bugs&words=plan_release_id+2.02&only_group_id=68&offset=0&max_rows=25#results
> [3]
> https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=grub&func=browse&set=custom&msort=1&report_id=101&advsrch=1&status_id%5B%5D=1&resolution_id%5B%5D=0&submitted_by%5B%5D=0&assigned_to%5B%5D=0&category_id%5B%5D=0&bug_group_id%5B%5D=105&severity%5B%5D=0&priority%5B%5D=0&summary=&details=&sumORdet=0&history_search=0&history_field=0&history_event=modified&history_date_dayfd=2&history_date_monthfd=3&history_date_yearfd=2016&chunksz=50&spamscore=5&boxoptionwanted=1#options
>
>

[-- Attachment #2: Type: text/html, Size: 3920 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov]

22.03.2016 21:48, Vladimir 'phcoder' Serbinenko пишет:
> Sorry, for delay. We have a busy period at work but it should end soon.
> I've put up the list of tasks for 2.02 in a doc:
> https://docs.google.com/document/d/1O6wveo1_WsAyEHMD041xMYvhDTDp3jQYzmqkgBx57HM/edit?usp=sharing
> .
> If some of them turn out too much work or too tricky, they can still be
> removed. If your task is not in the list, you have asked for 2.02 and I
> haven't specifically replied to you that it's not ok for 2.02, then I've
> forgotten it. In this case please email me privately.
> 

> Coverity fixes
> Bug reports marked with targhet release 2.02
> [not a blocker] Hardware-specific bugs
> multiboot2+EFI
> EFI linux protocol
> multiboot2 relocatable
> Huge PV domains
> [openbsd] 2.02-beta3: build fails - getroot.c:(.text+0x2b): undefined reference to `getrawpartition'

Two build fixes are committed. autogen.sh is nice to have but not urgent
for 2.02

> 2.02-beta3 remove attempt to free stack space and initialize variable before possible use

iso9660 part committed. zfs not sure, it is triggered by non-standard
build options; it needs some discussion how to solve it generically -
there are many places where static analyzer is confused by checking for
grub_errno.

> [PATCH 2/2] arm efi: Use fdt from firmware when available
> [PATCH 1/3] push/pop errno in initrd read file path
> [PATCH 3/3] pxenet: process transmit interrupts when out of resources
> Fedora patches [was Re: Bugs and tasks for 2.02[~rc1]]
> verifier framework

That's too late for 2.02, really.

> [PATCH] efidisk: prevent errors from diskfilter scan of removable drives

Is applied.

> linux16/linux/linuxefi mess

Support for EFI handover will make linuxefi redundant. But I'm not sure
how you suggest eliminating linux16 vs. linux.

> [2.02][PATCH] bootp: export server IP as environment variable

Should I commit it?


What about

- disk IO buffer alignment for small read (I personally prefer the first
version of Leif's patch that exposes alignment in core, it also allows
us to print it in ls output)

- F2FS support

- SMBIOS patches

- getroot: Correctly handle missing btrfs device identifiers.​

- arm64,xen: add xen_boot support into grup-mkconfig

- [RFC] Add exitcode support​ (or, better, suggestion in this thread to
change default exit code on EFI)

- something also needs to be done about
[PATCH] broken ESC navigation if authentication is used​

Re: Bugs and tasks for 2.02[~rc1]

[Konrad Rzeszutek Wilk]

On Mon, Mar 28, 2016 at 10:59:03AM -0400, Konrad Rzeszutek Wilk wrote:
> ..snip..
> > What about
> > 
> > - disk IO buffer alignment for small read (I personally prefer the first
> > version of Leif's patch that exposes alignment in core, it also allows
> > us to print it in ls output)
> > 
> > - F2FS support
> > 
> > - SMBIOS patches
> > 
> > - getroot: Correctly handle missing btrfs device identifiers.​
> > 
> > - arm64,xen: add xen_boot support into grup-mkconfig
> 
> So .. what is involved in this? Xen is in its feature freeze window so I am not
> exactly sure if the corresponding Xen patches have been posted?
> 
> Who is the author of these? (Not seeing it on the CC-list).

And I believe the underlaying Xen pieces are in? (On Xen side it is
"xen/arm64: check XSM Magic from the second unknown module." I believe).

> > 
> > - [RFC] Add exitcode support​ (or, better, suggestion in this thread to
> > change default exit code on EFI)
> > 
> > - something also needs to be done about
> > [PATCH] broken ESC navigation if authentication is used​
> 
> I would also add the multiboot2 from Daniel. I recall even seeing an email
> from Vladimir saying 'One more day and I will commit them' but I don't see
> them in the git tree?

ping? They have been reviewed..

Re: Bugs and tasks for 2.02[~rc1]

[Bruce Dubbs]

Vladimir 'phcoder' Serbinenko wrote:
> Hello, all. I went through the list of bugs and created a shortlist of bugs
> that need to be looked at for 2.02. I have marked them with plan_release_id
> set to 2.02.

[snip]

> I would like to come up with a complete list of 2.02 blockers in one week
> time, so that we can have a reasonable timeline

Is there an updated list of blockers?  Is there a time estimate for the 
2.02 release?

   -- Bruce

Re: Bugs and tasks for 2.02[~rc1]

[Olaf Hering]

On Fri, Mar 11, Vladimir 'phcoder' Serbinenko wrote:

> On Wednesday, March 9, 2016, Olaf Hering <olaf@aepfle.de> wrote:
>     On Wed, Mar 02, Vladimir 'phcoder' Serbinenko wrote:
>     > I would like to come up with a complete list of 2.02 blockers in one week
>     > time, so that we can have a reasonable timeline
>     Did anyone took the time to fix btrfs support (convert it from handling
>     btrfs as filesystem into that what it really is: a container of
>     subvolumes)?
> What is the problem with current approach? subvolume is little more than a
> directory from a point of view of read-only implementation 

A root filesystem in a subvolume is kind of a chroot. For example
grub.cfg within that subvolume references /boot/initrd. But upstream
grub can not use such grub.cfg via 'configfile ($root)$subvol/grub.cfg'
because the referenced path '/boot/initrd' does not take the subvolume
path into account.  This breaks at least in pvgrub, and makes testing
upstream grub with SLE12 or Leap impossible.

The changes made by SUSE tweak grub2 enough to take subvolumes into
account. Not sure why these changes are missing upstream.

Olaf

Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3243 bytes --]

 Le mar. 22 mars 2016 20:51, Andrei Borzenkov <arvidjaar@gmail.com
<javascript:_e(%7B%7D,'cvml','arvidjaar@gmail.com');>> a écrit :

> 22.03.2016 21:48, Vladimir 'phcoder' Serbinenko пишет:
> > Sorry, for delay. We have a busy period at work but it should end soon.
> > I've put up the list of tasks for 2.02 in a doc:
> >
> https://docs.google.com/document/d/1O6wveo1_WsAyEHMD041xMYvhDTDp3jQYzmqkgBx57HM/edit?usp=sharing
> > .
> > If some of them turn out too much work or too tricky, they can still be
> > removed. If your task is not in the list, you have asked for 2.02 and I
> > haven't specifically replied to you that it's not ok for 2.02, then I've
> > forgotten it. In this case please email me privately.
> >
>
> > Coverity fixes
> > Bug reports marked with targhet release 2.02
> > [not a blocker] Hardware-specific bugs
> > multiboot2+EFI
> > EFI linux protocol
> > multiboot2 relocatable
> > Huge PV domains
> > [openbsd] 2.02-beta3: build fails - getroot.c:(.text+0x2b): undefined
> reference to `getrawpartition'
>
> Two build fixes are committed. autogen.sh is nice to have but not urgent
> for 2.02
>
> > 2.02-beta3 remove attempt to free stack space and initialize variable
> before possible use
>
> iso9660 part committed. zfs not sure, it is triggered by non-standard
> build options; it needs some discussion how to solve it generically -
> there are many places where static analyzer is confused by checking for
> grub_errno.
>
> > [PATCH 2/2] arm efi: Use fdt from firmware when available
> > [PATCH 1/3] push/pop errno in initrd read file path
> > [PATCH 3/3] pxenet: process transmit interrupts when out of resources
> > Fedora patches [was Re: Bugs and tasks for 2.02[~rc1]]
> > verifier framework
>
> That's too late for 2.02, really.
>
> Agreed, let's move it to 2.03

> > [PATCH] efidisk: prevent errors from diskfilter scan of removable drives
>
> Is applied.
>
> > linux16/linux/linuxefi mess
>
> Support for EFI handover will make linuxefi redundant. But I'm not sure
> how you suggest eliminating linux16 vs. linux.
>
I'm not sure but we have a problem with RH on coreboot because of it.

>
> > [2.02][PATCH] bootp: export server IP as environment variable
>
> Should I commit it?
>
Please do

>
>
> What about
>
> - disk IO buffer alignment for small read (I personally prefer the first
> version of Leif's patch that exposes alignment in core, it also allows
> us to print it in ls output)
>
a version which just makes a small optimization out of it is fine. Full
revamp if this code is a big no.

>
> - F2FS support
>
> A feature. Can wait 2.03.

> - SMBIOS patches
>
> A feature. Can wait 2.03.

> - getroot: Correctly handle missing btrfs device identifiers.​
>
> this is a bug fix, 2.02

> - arm64,xen: add xen_boot support into grup-mkconfig
>
 2.02

>
> - [RFC] Add exitcode support​ (or, better, suggestion in this thread to
> change default exit code on EFI)
>
> Changing default is good. It's a bug really. 2.02

> - something also needs to be done about
> [PATCH] broken ESC navigation if authentication is used​
>
 Adding to the list


-- 
Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: Type: text/html, Size: 5020 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

On Tuesday, March 29, 2016, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
wrote:

> .snip..
> > What about
> >
> > - disk IO buffer alignment for small read (I personally prefer the first
> > version of Leif's patch that exposes alignment in core, it also allows
> > us to print it in ls output)
> >
> > - F2FS support
> >
> > - SMBIOS patches
> >
> > - getroot: Correctly handle missing btrfs device identifiers.​
> >
> > - arm64,xen: add xen_boot support into grup-mkconfig
>
> So .. what is involved in this? Xen is in its feature freeze window so I
> am not
> exactly sure if the corresponding Xen patches have been posted?
>
> Who is the author of these? (Not seeing it on the CC-list).
> >
> > - [RFC] Add exitcode support​ (or, better, suggestion in this thread to
> > change default exit code on EFI)
> >
> > - something also needs to be done about
> > [PATCH] broken ESC navigation if authentication is used​
>
> I would also add the multiboot2 from Daniel. I recall even seeing an email
> from Vladimir saying 'One more day and I will commit them' but I don't see
> them in the git tree?
>

This is the multiboot2+EFI entry. I have broken linux install right now.
I'll commit it when I fix the install unless someone else with commit
privileges does it first.



-- 
Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: Type: text/html, Size: 1723 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Wednesday, April 13, 2016, Bruce Dubbs <bruce.dubbs@gmail.com> wrote:

> Vladimir 'phcoder' Serbinenko wrote:
>
>> Hello, all. I went through the list of bugs and created a shortlist of
>> bugs
>> that need to be looked at for 2.02. I have marked them with
>> plan_release_id
>> set to 2.02.
>>
>
> [snip]
>
> I would like to come up with a complete list of 2.02 blockers in one week
>> time, so that we can have a reasonable timeline
>>
>
> Is there an updated list of blockers?  Is there a time estimate for the
> 2.02 release?
>
> I update google doc as I go

>   -- Bruce
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: Type: text/html, Size: 1487 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Juergen Gross]

On 11/03/16 16:47, Vladimir 'phcoder' Serbinenko wrote:
> 
> 
> On Wednesday, March 9, 2016, Daniel Kiper <daniel.kiper@oracle.com
> <mailto:daniel.kiper@oracle.com>> wrote:
> 
>     On Thu, Mar 03, 2016 at 03:47:17PM +0100, Juergen Gross wrote:
>     > Hi Vladimir,
>     >
>     > would it be possible to get "grub-xen: support booting huge
>     pv-domains"
>     > (http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00071.html)
>     > patch series into grub2 2.02?
> 
>     Andrei, Vladimir, what do you think about that?
> 
> Can you help us estimate the impact of those changes? What is the
> current limit and what is the new limit? How common are the
> configurations between old and new limit? 

The old limit was 512GB memory size for a pv-domain.

The new limit is, hmm, much much larger. Don't know. More than any
hardware today is capable to handle.

We at SUSE already have customers asking for domains in the TB range.


Juergen

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

On Wednesday, March 9, 2016, Daniel Kiper <daniel.kiper@oracle.com> wrote:

> On Thu, Mar 03, 2016 at 03:47:17PM +0100, Juergen Gross wrote:
> > Hi Vladimir,
> >
> > would it be possible to get "grub-xen: support booting huge pv-domains"
> > (http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00071.html)
> > patch series into grub2 2.02?
>
> Andrei, Vladimir, what do you think about that?
>
Can you help us estimate the impact of those changes? What is the current
limit and what is the new limit? How common are the configurations between
old and new limit?

>
> Daniel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: Type: text/html, Size: 1106 bytes --]

Re: Bugs and tasks for 2.02[~rc1]

[Daniel Kiper]

On Thu, Mar 03, 2016 at 03:47:17PM +0100, Juergen Gross wrote:
> Hi Vladimir,
>
> would it be possible to get "grub-xen: support booting huge pv-domains"
> (http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00071.html)
> patch series into grub2 2.02?

Andrei, Vladimir, what do you think about that?

Daniel

Bugs and tasks for 2.02[~rc1]

[Juergen Gross]

Hi Vladimir,

would it be possible to get "grub-xen: support booting huge pv-domains"
(http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00071.html)
patch series into grub2 2.02?

Juergen