Re: btrfs subvolumes [was Re: Bugs and tasks for 2.02[~rc1] ]

[Michael Chang]

On Mon, Apr 18, 2016 at 06:22:10AM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, April 13, 2016, Olaf Hering  wrote:
> 
> > On Fri, Mar 11, Vladimir 'phcoder' Serbinenko wrote:
> >
> > > On Wednesday, March 9, 2016, 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)?
> > > 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.
> >
> > Why does it break pvgrub? Both grub on BIOS and xen use the same
> convention

It won't. But we have been using relative patch schemes to support booting
subvolumes via btrfs set-default to rollback changes.

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

Because there's could only be one path scheme at a time and upstream has
decided to settle on absolute path. I think unless in config level could
provide means to deal with subvolumes and its mount point information there
couldn't be a clean solution for that.

Thanks,
Michael

> >
> > Olaf
> >
> > ___
> > Grub-devel mailing list
> > Grub-devel@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> 
> 
> -- 
> Regards
> Vladimir 'phcoder' Serbinenko

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


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

btrfs subvolumes [was Re: Bugs and tasks for 2.02[~rc1] ]

[Vladimir 'phcoder' Serbinenko]

On Wednesday, April 13, 2016, Olaf Hering  wrote:

> On Fri, Mar 11, Vladimir 'phcoder' Serbinenko wrote:
>
> > On Wednesday, March 9, 2016, 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)?
> > 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.
>
> Why does it break pvgrub? Both grub on BIOS and xen use the same
convention

> The changes made by SUSE tweak grub2 enough to take subvolumes into
> account. Not sure why these changes are missing upstream.
>
> Olaf
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org 
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

On Wednesday, April 13, 2016, Bruce Dubbs  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
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

 Le mar. 22 mars 2016 20:51, Andrei Borzenkov <arvidj...@gmail.com
<javascript:_e(%7B%7D,'cvml','arvidj...@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
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

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

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



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

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

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

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​

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

Re: Bugs and tasks for 2.02[~rc1]

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

Le Wed, Mar 2, 2016 à 7:01 AM, Vladimir 'phcoder' Serbinenko <
phco...@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=plan_release_id
> [2]
> https://savannah.gnu.org/search/?type_of_search=bugs=plan_release_id+2.02_group_id=68=0_rows=25#results
> [3]
> https://savannah.gnu.org/bugs/index.php?go_report=Apply=grub=browse=custom=1_id=101=1_id%5B%5D=1_id%5B%5D=0_by%5B%5D=0_to%5B%5D=0_id%5B%5D=0_group_id%5B%5D=105%5B%5D=0%5B%5D=0===0_search=0_field=0_event=modified_date_dayfd=2_date_monthfd=3_date_yearfd=2016=50=5=1#options
>
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

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

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

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

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.

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

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?

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

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.

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

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

Fedora patches [was Re: Bugs and tasks for 2.02[~rc1]]

[Vladimir 'phcoder' Serbinenko]

On Friday, March 4, 2016, Peter Jones  wrote:

> On Wed, Mar 02, 2016 at 03:01:03PM +, 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)
>
Cherry-picked this one

>
> Then these are just generic network handling patches:
>
> 836b528 DHCP client ID and UUID options added.
>
I didn't see it in for-upstream

> eb1adf5 trim arp packets with abnormal size
>
 Didn't see it either but the last version I've seen just trims it at
arbitrary size rather than checking size fields for sanity then, cutting at
min (old_size, sum_of_all_size_fields) which is a proper solution. Can we
get it cleaned up?

>
> 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
>
This patch is bad. See how it reallocates script in cas_reboot but never
modifies caller variable. Caller may acccess freed space. More high-level
problem: can machine get stuck in CAS reboot cycle? How would user request
GRUB not to respect the settings and go to console or menu instead?

> 297d32d for ppc, reset console display attr when clear screen
>
 Why is this hardware-specific? Sounds like we miss setting of terminal
mode to non-highlighted somewhere. On no other terminal cls resets
highlight status. This changes user-visible behaviour.

> 0ca5375 Disable GRUB video support for IBM power machines
>
> Are there IBM machines with display output or are they all servers? Can we
be more fine-grained on disabling video?

> 2f3c666 Add support for UEFI operating systems returned by os-prober
>
I'm interested in this one but it's not in for-upstream.

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



> 1f1a695 Make "exit" take a return code.
>
I think that making exit behave differently on EFI is a bad thing. Look at
how ridicoulous code for single-casing halt has got. No other platform uses
exit with code either.

>
>
> cb62c40 Mark po/exclude.pot as binary so git won't try to diff
> nonprintables.
>
I don't see it in for-upstream

> e0bb91a Fix bzr's ignore artificats in .gitignore
>
This one looks generally good. I think Andrei's suggestion for split is
reasonable but not absolutely required. Just tell me which way to commit
it.

> ecaecc9 Add some __unused__ where gcc 5.x is more picky about it.
>
don't see it

> e704140 Move bash completion script (#922997)
>
Can we keep old directory in case of missing pkg-config?

> bc5d351 Allow "fallback" to include entries by title, not just number.
>
I share Andrei's concerns

> 7401bf6 Honor a symlink when generating configuration by grub2-mkconfig
>
Cherry-picked it.

> 5212412 Fix bad test on GRUB_DISABLE_SUBMENU.
>
Don't see it.

> 73545c7 Add GRUB_DISABLE_UUID.
>
Don't see it


-- 
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

On Wednesday, March 9, 2016, 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)?
>
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 
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

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

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

On Monday, March 7, 2016, Matt Fleming  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
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

On Wednesday, March 9, 2016, Daniel Kiper  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
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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.

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

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?

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

Re: Bugs and tasks for 2.02[~rc1]

[Daniel Kiper]

On Wed, Mar 09, 2016 at 02:51:42PM +, 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

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

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.

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

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

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  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 +, 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?
>
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

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

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

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

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

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

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

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

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

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

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.

___
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 +, Vladimir 'phcoder' Serbinenko wrote:
> Le lun. 7 mars 2016 23:01, Peter Jones  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


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

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

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.

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

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

Le lun. 7 mars 2016 23:01, Peter Jones  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
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

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

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

Le lun. 7 mars 2016 22:14, Peter Jones  a écrit :

> On Mon, Mar 07, 2016 at 08:40:58PM +, Vladimir 'phcoder' Serbinenko
> wrote:
> > Le lun. 7 mars 2016 21:33, Andrei Borzenkov  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
>
___
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 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?

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

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

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

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

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

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Mon, Mar 07, 2016 at 08:40:58PM +, Vladimir 'phcoder' Serbinenko wrote:
> Le lun. 7 mars 2016 21:33, Andrei Borzenkov  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

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

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

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

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

Le lun. 7 mars 2016 22:03, Peter Jones  a écrit :

> On Mon, Mar 07, 2016 at 07:57:21PM +, 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
>
___
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 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?

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

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Mon, Mar 07, 2016 at 07:57:21PM +, 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

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

07.03.2016 23:40, Vladimir 'phcoder' Serbinenko пишет:
> Le lun. 7 mars 2016 21:33, Andrei Borzenkov  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
> 
>>
>>
>>
>>
> 


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

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

Le lun. 7 mars 2016 21:33, Andrei Borzenkov  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

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

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.



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

Re: Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

Le lun. 7 mars 2016 20:00, Peter Jones  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 +, 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.
> > >

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

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 +, 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 (_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 

Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones]

On Wed, Mar 02, 2016 at 03:01:03PM +, 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

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

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

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

Re: Bugs and tasks for 2.02[~rc1]

[Daniel Kiper]

Hey,

On Wed, Mar 02, 2016 at 03:01:03PM +, 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

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

Bugs and tasks for 2.02[~rc1]

[Vladimir 'phcoder' Serbinenko]

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=plan_release_id
[2]
https://savannah.gnu.org/search/?type_of_search=bugs=plan_release_id+2.02_group_id=68=0_rows=25#results
[3]
https://savannah.gnu.org/bugs/index.php?go_report=Apply=grub=browse=custom=1_id=101=1_id%5B%5D=1_id%5B%5D=0_by%5B%5D=0_to%5B%5D=0_id%5B%5D=0_group_id%5B%5D=105%5B%5D=0%5B%5D=0===0_search=0_field=0_event=modified_date_dayfd=2_date_monthfd=3_date_yearfd=2016=50=5=1#options
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel