Breakage from grub-mkconfig changes for grub-file

Breakage from grub-mkconfig changes for grub-file

[Colin Watson]

ec824e0f2a399ce2ab3a2e3353d372a236595059 introduced extensive changes to
grub-mkconfig, which among other things arranged to run all but a
hardcoded list of grub.d scripts once for each of several platforms with
their output enclosed in an "if" block.  I do not feel that this change
was well-thought-out, and I think it should be rethought or reverted
before 2.02.  I didn't see anything about it here in advance - did I
miss a thread?

The problems I have with it are illustrated by its effects on the Debian
patch.  I must emphasise that I don't think this is unique to the case
of distributions with non-trivial patch sets, and that it's also likely
to affect users who have made reasonable changes to /etc/grub.d/ locally
(as they're entitled to do); distributions are just a useful
early-warning system here.

  1) Awkward hardcoded list; poor configurability

  00_header, 30_os-prober, 40_custom, and 41_custom are run only once.
  The Debian patch set has an additional script which is not
  platform-dependent and should be run only once, namely
  05_debian_theme, so I had to add another case here.  Users will surely
  have other such files; not only do they have to know on upgrade that
  they need to take care of this, but they have no recourse that doesn't
  involve editing $prefix/bin/grub-mkconfig, which is not a file that
  should normally be edited by the system administrator; changes to that
  file will not normally persist on upgrades.

  This should be redesigned so that there is some way to declare in a
  grub.d script that it requires multi-platform support and should be
  run multiple times.  (It *must* be this way round so that upgrades
  work properly.)

  2) Strange ad-hoc platform names

  The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen
  mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the
  platform names used in the GRUB build system, but yet they're exported
  across the interface to /etc/grub.d/ as GRUB_PLATFORM.  This is messy
  and confusing, and it's not clear what promises we make about future
  changes here.

  We should rationalise this before issuing anything as part of a stable
  release, perhaps by adopting the same target_cpu/platform terminology
  used in the build system.  Furthermore, if we made the namespaces
  match up then it would be fairly straightforward to only run grub.d
  scripts for platforms for which we have installed GRUB modules, which
  seems as though it would be sensible.

  3) Breaks function definitions

  In the GRUB script language, "function" is only permitted at the top
  level.  This may be an oversight since bash doesn't share this
  restriction and GRUB script generally tries to look like bash;
  nevertheless it exists today.  Part of the Debian patch set causes
  10_linux to emit a function definition, which now causes a syntax
  error.

  I think my preferred fix here would be to implement functions other
  than at the top level, but it seems a bit rash to try to cram that
  into 2.02.

  4) Smaller bugs

  Aside from the bug fixed in 77ec462a568fc9c89ef45e960bf33b5de73140fb,
  I'm pretty sure that the condition for the "x86" platform is buggy;
  shouldn't it have an extra "-a" in there?  This sort of thing makes me
  worried about the level of testing these changes have had.

The grub-file tool seems reasonable and useful to me, but can we just
revert the grub-mkconfig parts of these changes until after 2.02 so that
the effects of these interface changes can be considered more carefully?
It looks like it was part of a new feature rather than a bug-fix.

I noticed this while testing Debian packages of 2.02~beta1.
Unfortunately, I don't think I can salvage this into something I can
upload without extensive interface changes of the sort that I'm not
comfortable making downstream.

Thanks,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Breakage from grub-mkconfig changes for grub-file

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 23.12.2013 23:01, Colin Watson wrote:
> ec824e0f2a399ce2ab3a2e3353d372a236595059 introduced extensive changes to
> grub-mkconfig, which among other things arranged to run all but a
> hardcoded list of grub.d scripts once for each of several platforms with
> their output enclosed in an "if" block.  I do not feel that this change
> was well-thought-out, and I think it should be rethought or reverted
> before 2.02.  I didn't see anything about it here in advance - did I
> miss a thread?
> 
> The problems I have with it are illustrated by its effects on the Debian
> patch.  I must emphasise that I don't think this is unique to the case
> of distributions with non-trivial patch sets, and that it's also likely
> to affect users who have made reasonable changes to /etc/grub.d/ locally
> (as they're entitled to do); distributions are just a useful
> early-warning system here.
> 
>   1) Awkward hardcoded list; poor configurability
> 
>   00_header, 30_os-prober, 40_custom, and 41_custom are run only once.
>   The Debian patch set has an additional script which is not
>   platform-dependent and should be run only once, namely
>   05_debian_theme, so I had to add another case here.  Users will surely
>   have other such files; not only do they have to know on upgrade that
>   they need to take care of this, but they have no recourse that doesn't
>   involve editing $prefix/bin/grub-mkconfig, which is not a file that
>   should normally be edited by the system administrator; changes to that
>   file will not normally persist on upgrades.
> 
>   This should be redesigned so that there is some way to declare in a
>   grub.d script that it requires multi-platform support and should be
>   run multiple times.  (It *must* be this way round so that upgrades
>   work properly.)
> 
The idea was that platform-independent scripts were still runnable,
they'll just produce the same output N times and this list is just an
optimisations, specially to avoid running os-prober N times.
The alternative will be to have something along the lines of different
hashbang or implementing this functionality as sh functions.
>   2) Strange ad-hoc platform names
> 
>   The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen
>   mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the
>   platform names used in the GRUB build system, but yet they're exported
>   across the interface to /etc/grub.d/ as GRUB_PLATFORM.  This is messy
>   and confusing, and it's not clear what promises we make about future
>   changes here.
> 
>   We should rationalise this before issuing anything as part of a stable
>   release, perhaps by adopting the same target_cpu/platform terminology
>   used in the build system.  Furthermore, if we made the namespaces
>   match up then it would be fairly straightforward to only run grub.d
>   scripts for platforms for which we have installed GRUB modules, which
>   seems as though it would be sensible.
> 
GRUB platform names don't match with the OS compatibility. On x86 other
than xen you can use the same kernel on all the platforms. On ARM, for
what is arm-uboot platform for us may require different kernels for
different hardware.
>   3) Breaks function definitions
> 
>   In the GRUB script language, "function" is only permitted at the top
>   level.  This may be an oversight since bash doesn't share this
>   restriction and GRUB script generally tries to look like bash;
>   nevertheless it exists today.  Part of the Debian patch set causes
>   10_linux to emit a function definition, which now causes a syntax
>   error.
> 
>   I think my preferred fix here would be to implement functions other
>   than at the top level, but it seems a bit rash to try to cram that
>   into 2.02.
> 
Ok.
>   4) Smaller bugs
> 
>   Aside from the bug fixed in 77ec462a568fc9c89ef45e960bf33b5de73140fb,
>   I'm pretty sure that the condition for the "x86" platform is buggy;
>   shouldn't it have an extra "-a" in there?  This sort of thing makes me
>   worried about the level of testing these changes have had.
> 
Nice catch.

> The grub-file tool seems reasonable and useful to me, but can we just
> revert the grub-mkconfig parts of these changes until after 2.02 so that
> the effects of these interface changes can be considered more carefully?
I think it's good to move it to "next", together with --root-directory
functionality of grub-mkconfig.
Paulo Flabiano Smorigo wanted this feature badly. Unless he has striking
arguments why 2.02 needs it, I'm ok with moving this to "next".


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: Breakage from grub-mkconfig changes for grub-file

[Colin Watson]

On Mon, Dec 23, 2013 at 11:21:38PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 23.12.2013 23:01, Colin Watson wrote:
> >   This should be redesigned so that there is some way to declare in a
> >   grub.d script that it requires multi-platform support and should be
> >   run multiple times.  (It *must* be this way round so that upgrades
> >   work properly.)
> 
> The idea was that platform-independent scripts were still runnable,
> they'll just produce the same output N times and this list is just an
> optimisations, specially to avoid running os-prober N times.

Granted, but in some cases those scripts might not be idempotent:
consider a user-written "42_custom" (or whatever) script that adds a
menu entry, for instance.

> The alternative will be to have something along the lines of different
> hashbang or implementing this functionality as sh functions.

How about this simpler option: any script that needs to be run for each
platform could have a magic comment that we grep for in grub-mkconfig.

> >   The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen
> >   mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the
> >   platform names used in the GRUB build system, but yet they're exported
> >   across the interface to /etc/grub.d/ as GRUB_PLATFORM.  This is messy
> >   and confusing, and it's not clear what promises we make about future
> >   changes here.
> > 
> >   We should rationalise this before issuing anything as part of a stable
> >   release, perhaps by adopting the same target_cpu/platform terminology
> >   used in the build system.  Furthermore, if we made the namespaces
> >   match up then it would be fairly straightforward to only run grub.d
> >   scripts for platforms for which we have installed GRUB modules, which
> >   seems as though it would be sensible.
> 
> GRUB platform names don't match with the OS compatibility. On x86 other
> than xen you can use the same kernel on all the platforms. On ARM, for
> what is arm-uboot platform for us may require different kernels for
> different hardware.

OK, but if it is a different concept then it should have a different
name, not "platform" - otherwise it just seems confusing.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Breakage from grub-mkconfig changes for grub-file

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 24.12.2013 01:34, Colin Watson wrote:
> On Mon, Dec 23, 2013 at 11:21:38PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 23.12.2013 23:01, Colin Watson wrote:
>>>   This should be redesigned so that there is some way to declare in a
>>>   grub.d script that it requires multi-platform support and should be
>>>   run multiple times.  (It *must* be this way round so that upgrades
>>>   work properly.)
>>
>> The idea was that platform-independent scripts were still runnable,
>> they'll just produce the same output N times and this list is just an
>> optimisations, specially to avoid running os-prober N times.
> 
> Granted, but in some cases those scripts might not be idempotent:
> consider a user-written "42_custom" (or whatever) script that adds a
> menu entry, for instance.
> 
Only one instance of it will be included on runtime.
>> The alternative will be to have something along the lines of different
>> hashbang or implementing this functionality as sh functions.
> 
> How about this simpler option: any script that needs to be run for each
> platform could have a magic comment that we grep for in grub-mkconfig.
> 
It's certainely a possibility even though I'm not a fan of magic comments.
>>>   The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen
>>>   mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the
>>>   platform names used in the GRUB build system, but yet they're exported
>>>   across the interface to /etc/grub.d/ as GRUB_PLATFORM.  This is messy
>>>   and confusing, and it's not clear what promises we make about future
>>>   changes here.
>>>
>>>   We should rationalise this before issuing anything as part of a stable
>>>   release, perhaps by adopting the same target_cpu/platform terminology
>>>   used in the build system.  Furthermore, if we made the namespaces
>>>   match up then it would be fairly straightforward to only run grub.d
>>>   scripts for platforms for which we have installed GRUB modules, which
>>>   seems as though it would be sensible.
>>
>> GRUB platform names don't match with the OS compatibility. On x86 other
>> than xen you can use the same kernel on all the platforms. On ARM, for
>> what is arm-uboot platform for us may require different kernels for
>> different hardware.
> 
> OK, but if it is a different concept then it should have a different
> name, not "platform" - otherwise it just seems confusing.
> 
Agreed. Do you have an idea for name?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: Breakage from grub-mkconfig changes for grub-file

[Colin Watson]

On Tue, Dec 24, 2013 at 01:38:18AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 24.12.2013 01:34, Colin Watson wrote:
> > On Mon, Dec 23, 2013 at 11:21:38PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> >> The idea was that platform-independent scripts were still runnable,
> >> they'll just produce the same output N times and this list is just an
> >> optimisations, specially to avoid running os-prober N times.
> > 
> > Granted, but in some cases those scripts might not be idempotent:
> > consider a user-written "42_custom" (or whatever) script that adds a
> > menu entry, for instance.
> 
> Only one instance of it will be included on runtime.

Well, OK, but is there really no possible grub.cfg code that would be
non-idempotent?  Besides, people already complain about generated
grub.cfg files being noisy. :-)

> >> The alternative will be to have something along the lines of different
> >> hashbang or implementing this functionality as sh functions.
> > 
> > How about this simpler option: any script that needs to be run for each
> > platform could have a magic comment that we grep for in grub-mkconfig.
> 
> It's certainely a possibility even though I'm not a fan of magic comments.

Nor I, normally, but they seem like a reasonable option here.

> >>>   We should rationalise this before issuing anything as part of a stable
> >>>   release, perhaps by adopting the same target_cpu/platform terminology
> >>>   used in the build system.  Furthermore, if we made the namespaces
> >>>   match up then it would be fairly straightforward to only run grub.d
> >>>   scripts for platforms for which we have installed GRUB modules, which
> >>>   seems as though it would be sensible.
> >>
> >> GRUB platform names don't match with the OS compatibility. On x86 other
> >> than xen you can use the same kernel on all the platforms. On ARM, for
> >> what is arm-uboot platform for us may require different kernels for
> >> different hardware.
> > 
> > OK, but if it is a different concept then it should have a different
> > name, not "platform" - otherwise it just seems confusing.
> 
> Agreed. Do you have an idea for name?

Hmm.  Maybe GRUB_OS_KERNEL_TYPE or GRUB_EXPECTED_KERNEL or something?
(We would also want to avoid confusion with the GRUB kernel.)

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Breakage from grub-mkconfig changes for grub-file

[Andrey Borzenkov]

В Вт, 24/12/2013 в 00:34 +0000, Colin Watson пишет:
> On Mon, Dec 23, 2013 at 11:21:38PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > On 23.12.2013 23:01, Colin Watson wrote:
> > >   This should be redesigned so that there is some way to declare in a
> > >   grub.d script that it requires multi-platform support and should be
> > >   run multiple times.  (It *must* be this way round so that upgrades
> > >   work properly.)
> > 
> > The idea was that platform-independent scripts were still runnable,
> > they'll just produce the same output N times and this list is just an
> > optimisations, specially to avoid running os-prober N times.
> 
> Granted, but in some cases those scripts might not be idempotent:
> consider a user-written "42_custom" (or whatever) script that adds a
> menu entry, for instance.
> 
> > The alternative will be to have something along the lines of different
> > hashbang or implementing this functionality as sh functions.
> 
> How about this simpler option: any script that needs to be run for each
> platform could have a magic comment that we grep for in grub-mkconfig.
> 

I have a feeling that we are doing it backwards. What we actually want
is to know file type. So what about making grub-file print it instead of
having ever growing list of conditions? I.e.

grub-file --print {cpu|os|bits|...} 

and simply using it in every script to generate run-time condition like
in (simplified)

cpu=$(grub-file --print cpu)

cat << EOF
if [ \$grub_platform = $cpu ] ;  then
menuentry ...
EOF

And this could be wrapped in grub_mkconfig_platform_condition function.


> > >   The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen
> > >   mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the
> > >   platform names used in the GRUB build system, but yet they're exported
> > >   across the interface to /etc/grub.d/ as GRUB_PLATFORM.  This is messy
> > >   and confusing, and it's not clear what promises we make about future
> > >   changes here.
> > > 
> > >   We should rationalise this before issuing anything as part of a stable
> > >   release, perhaps by adopting the same target_cpu/platform terminology
> > >   used in the build system.  Furthermore, if we made the namespaces
> > >   match up then it would be fairly straightforward to only run grub.d
> > >   scripts for platforms for which we have installed GRUB modules, which
> > >   seems as though it would be sensible.
> > 
> > GRUB platform names don't match with the OS compatibility. On x86 other
> > than xen you can use the same kernel on all the platforms. On ARM, for
> > what is arm-uboot platform for us may require different kernels for
> > different hardware.
> 
> OK, but if it is a different concept then it should have a different
> name, not "platform" - otherwise it just seems confusing.
> 

Re: Breakage from grub-mkconfig changes for grub-file

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 24.12.2013 03:56, Andrey Borzenkov wrote:
> В Вт, 24/12/2013 в 00:34 +0000, Colin Watson пишет:
>> On Mon, Dec 23, 2013 at 11:21:38PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> On 23.12.2013 23:01, Colin Watson wrote:
>>>>   This should be redesigned so that there is some way to declare in a
>>>>   grub.d script that it requires multi-platform support and should be
>>>>   run multiple times.  (It *must* be this way round so that upgrades
>>>>   work properly.)
>>>
>>> The idea was that platform-independent scripts were still runnable,
>>> they'll just produce the same output N times and this list is just an
>>> optimisations, specially to avoid running os-prober N times.
>>
>> Granted, but in some cases those scripts might not be idempotent:
>> consider a user-written "42_custom" (or whatever) script that adds a
>> menu entry, for instance.
>>
>>> The alternative will be to have something along the lines of different
>>> hashbang or implementing this functionality as sh functions.
>>
>> How about this simpler option: any script that needs to be run for each
>> platform could have a magic comment that we grep for in grub-mkconfig.
>>
> 
> I have a feeling that we are doing it backwards. What we actually want
> is to know file type. So what about making grub-file print it instead of
> having ever growing list of conditions? I.e.
> 
> grub-file --print {cpu|os|bits|...} 
> 
> and simply using it in every script to generate run-time condition like
> in (simplified)
> 
> cpu=$(grub-file --print cpu)
> 
> cat << EOF
> if [ \$grub_platform = $cpu ] ;  then
> menuentry ...
> EOF
> 
> And this could be wrapped in grub_mkconfig_platform_condition function.
> 
The same file can have several formats and it's actually pretty common
to squeeze several formats in the same image. Like EFI image and bzImage
in the same file.
> 
>>>>   The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen
>>>>   mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the
>>>>   platform names used in the GRUB build system, but yet they're exported
>>>>   across the interface to /etc/grub.d/ as GRUB_PLATFORM.  This is messy
>>>>   and confusing, and it's not clear what promises we make about future
>>>>   changes here.
>>>>
>>>>   We should rationalise this before issuing anything as part of a stable
>>>>   release, perhaps by adopting the same target_cpu/platform terminology
>>>>   used in the build system.  Furthermore, if we made the namespaces
>>>>   match up then it would be fairly straightforward to only run grub.d
>>>>   scripts for platforms for which we have installed GRUB modules, which
>>>>   seems as though it would be sensible.
>>>
>>> GRUB platform names don't match with the OS compatibility. On x86 other
>>> than xen you can use the same kernel on all the platforms. On ARM, for
>>> what is arm-uboot platform for us may require different kernels for
>>> different hardware.
>>
>> OK, but if it is a different concept then it should have a different
>> name, not "platform" - otherwise it just seems confusing.
>>
> 
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: Breakage from grub-mkconfig changes for grub-file

[pfsmorigo]

Mon, Dec 23, 2013 at 11:21:38PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 23.12.2013 23:01, Colin Watson wrote:
> > ec824e0f2a399ce2ab3a2e3353d372a236595059 introduced extensive changes to
> > grub-mkconfig, which among other things arranged to run all but a
> > hardcoded list of grub.d scripts once for each of several platforms with
> > their output enclosed in an "if" block.  I do not feel that this change
> > was well-thought-out, and I think it should be rethought or reverted
> > before 2.02.  I didn't see anything about it here in advance - did I
> > miss a thread?
> > 
> > The problems I have with it are illustrated by its effects on the Debian
> > patch.  I must emphasise that I don't think this is unique to the case
> > of distributions with non-trivial patch sets, and that it's also likely
> > to affect users who have made reasonable changes to /etc/grub.d/ locally
> > (as they're entitled to do); distributions are just a useful
> > early-warning system here.
> > 
> >   1) Awkward hardcoded list; poor configurability
> > 
> >   00_header, 30_os-prober, 40_custom, and 41_custom are run only once.
> >   The Debian patch set has an additional script which is not
> >   platform-dependent and should be run only once, namely
> >   05_debian_theme, so I had to add another case here.  Users will surely
> >   have other such files; not only do they have to know on upgrade that
> >   they need to take care of this, but they have no recourse that doesn't
> >   involve editing $prefix/bin/grub-mkconfig, which is not a file that
> >   should normally be edited by the system administrator; changes to that
> >   file will not normally persist on upgrades.
> > 
> >   This should be redesigned so that there is some way to declare in a
> >   grub.d script that it requires multi-platform support and should be
> >   run multiple times.  (It *must* be this way round so that upgrades
> >   work properly.)
> > 
> The idea was that platform-independent scripts were still runnable,
> they'll just produce the same output N times and this list is just an
> optimisations, specially to avoid running os-prober N times.
> The alternative will be to have something along the lines of different
> hashbang or implementing this functionality as sh functions.
> >   2) Strange ad-hoc platform names
> > 
> >   The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen
> >   mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the
> >   platform names used in the GRUB build system, but yet they're exported
> >   across the interface to /etc/grub.d/ as GRUB_PLATFORM.  This is messy
> >   and confusing, and it's not clear what promises we make about future
> >   changes here.
> > 
> >   We should rationalise this before issuing anything as part of a stable
> >   release, perhaps by adopting the same target_cpu/platform terminology
> >   used in the build system.  Furthermore, if we made the namespaces
> >   match up then it would be fairly straightforward to only run grub.d
> >   scripts for platforms for which we have installed GRUB modules, which
> >   seems as though it would be sensible.
> > 
> GRUB platform names don't match with the OS compatibility. On x86 other
> than xen you can use the same kernel on all the platforms. On ARM, for
> what is arm-uboot platform for us may require different kernels for
> different hardware.
> >   3) Breaks function definitions
> > 
> >   In the GRUB script language, "function" is only permitted at the top
> >   level.  This may be an oversight since bash doesn't share this
> >   restriction and GRUB script generally tries to look like bash;
> >   nevertheless it exists today.  Part of the Debian patch set causes
> >   10_linux to emit a function definition, which now causes a syntax
> >   error.
> > 
> >   I think my preferred fix here would be to implement functions other
> >   than at the top level, but it seems a bit rash to try to cram that
> >   into 2.02.
> > 
> Ok.
> >   4) Smaller bugs
> > 
> >   Aside from the bug fixed in 77ec462a568fc9c89ef45e960bf33b5de73140fb,
> >   I'm pretty sure that the condition for the "x86" platform is buggy;
> >   shouldn't it have an extra "-a" in there?  This sort of thing makes me
> >   worried about the level of testing these changes have had.
> > 
> Nice catch.
> 
> > The grub-file tool seems reasonable and useful to me, but can we just
> > revert the grub-mkconfig parts of these changes until after 2.02 so that
> > the effects of these interface changes can be considered more carefully?
> I think it's good to move it to "next", together with --root-directory
> functionality of grub-mkconfig.
> Paulo Flabiano Smorigo wanted this feature badly. Unless he has striking
> arguments why 2.02 needs it, I'm ok with moving this to "next".
> 

We can move this to next. The --root-directory is not high priority
and can delay it without problems.

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