passing options to grub in xen,openfirmware and efi

passing options to grub in xen,openfirmware and efi

[Olaf Hering]

Is there a way to pass options to grub in a Xen PV domU, in openfirmware
and in EFI environment?

In a PV domU arguments can be passed to the specified
kernel="/path/file" with the extra="what ever" option.
In openfirmware the arguments may come from the /boot/chosen node.
In EFI it may be possible as well, not my area of expertise.
In the wellknown dumb i386 BIOS no such way exist.

In case grub has code to evalute these things, how can such arguements
be used within grub.cfg? Where is that documented?

Thanks,

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Andrei Borzenkov]

On Thu, Apr 23, 2015 at 11:03 AM, Olaf Hering <olaf@aepfle.de> wrote:
>
> Is there a way to pass options to grub in a Xen PV domU, in openfirmware
> and in EFI environment?
>
> In a PV domU arguments can be passed to the specified
> kernel="/path/file" with the extra="what ever" option.
> In openfirmware the arguments may come from the /boot/chosen node.
> In EFI it may be possible as well, not my area of expertise.
> In the wellknown dumb i386 BIOS no such way exist.
>
> In case grub has code to evalute these things, how can such arguements
> be used within grub.cfg? Where is that documented?
>

I believe the question briefly came up already but without any
followup. IIRC it was in relation to how to pass real kernel name to
grub in Xen.

For OFW grub will parse bootargs property, interpret it as series of
variable assignments separated by ";" and set these variables. There
is nothing similar for Xen or EFI cases currently. For EFI we could
fetch arguments using Loaded Image Protocol (LoadOptions). Another
option (in addition, not either/or) is to define GUID for grub and set
them in NVRAM.

What I do not like is the possibility to blindly set any internal
variable (consider overriding of $prefix). I'd prefer to set variables
in separate namespace, like grub.arg.XXX=YYY for XXX=YYY argument and
let user figure out what to do with them.

As long as variables are defined you of course can do whatever you
like with them, including referencing them in grub.cfg. How you can
use them in grub.cfg is limited only by your imagination then :)

I do not think it is documented anywhere mostly because feature does
not really exist; I suppose OFW was added mostly as prerequisite for
something else. git blame may answer it.

And of course patches are welcome :)

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Thu, Apr 23, Andrei Borzenkov wrote:

> What I do not like is the possibility to blindly set any internal
> variable (consider overriding of $prefix). I'd prefer to set variables
> in separate namespace, like grub.arg.XXX=YYY for XXX=YYY argument and
> let user figure out what to do with them.

You mean if booted with 'boot hd:,grub foo=bar' a 'grub.arg.foo=bar'
should be available? That sounds like a plan.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Andrei Borzenkov]

On Thu, Apr 23, 2015 at 12:43 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Thu, Apr 23, Andrei Borzenkov wrote:
>
>> What I do not like is the possibility to blindly set any internal
>> variable (consider overriding of $prefix). I'd prefer to set variables
>> in separate namespace, like grub.arg.XXX=YYY for XXX=YYY argument and
>> let user figure out what to do with them.
>
> You mean if booted with 'boot hd:,grub foo=bar' a 'grub.arg.foo=bar'
> should be available?

yes.

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Thu, Apr 23, Andrei Borzenkov wrote:

> On Thu, Apr 23, 2015 at 12:43 PM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Thu, Apr 23, Andrei Borzenkov wrote:
> >
> >> What I do not like is the possibility to blindly set any internal
> >> variable (consider overriding of $prefix). I'd prefer to set variables
> >> in separate namespace, like grub.arg.XXX=YYY for XXX=YYY argument and
> >> let user figure out what to do with them.
> >
> > You mean if booted with 'boot hd:,grub foo=bar' a 'grub.arg.foo=bar'
> > should be available?
> 
> yes.

Current grub_parse_cmdline seems to set foo=bar instead.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Andrei Borzenkov]

On Thu, Apr 23, 2015 at 2:25 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Thu, Apr 23, Andrei Borzenkov wrote:
>
>> On Thu, Apr 23, 2015 at 12:43 PM, Olaf Hering <olaf@aepfle.de> wrote:
>> > On Thu, Apr 23, Andrei Borzenkov wrote:
>> >
>> >> What I do not like is the possibility to blindly set any internal
>> >> variable (consider overriding of $prefix). I'd prefer to set variables
>> >> in separate namespace, like grub.arg.XXX=YYY for XXX=YYY argument and
>> >> let user figure out what to do with them.
>> >
>> > You mean if booted with 'boot hd:,grub foo=bar' a 'grub.arg.foo=bar'
>> > should be available?
>>
>> yes.
>
> Current grub_parse_cmdline seems to set foo=bar instead.
>

I know. as I said, IIRC it was added to support specific requirement,
not as part of generic framework. Of course, now that it is there
nobody knows who depends on it.

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Thu, Apr 23, Andrei Borzenkov wrote:

> I know. as I said, IIRC it was added to support specific requirement,
> not as part of generic framework. Of course, now that it is there
> nobody knows who depends on it.

What is wrong with it anyway? Both grub and the optional commands passed
to it are one unit.

Looks like your concern is that the defaults used during mkimage time
can be changed at runtime. Thats common practice I think.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 23.04.2015 11:35, Andrei Borzenkov wrote:
> On Thu, Apr 23, 2015 at 11:03 AM, Olaf Hering <olaf@aepfle.de> wrote:
>>
>> Is there a way to pass options to grub in a Xen PV domU, in openfirmware
>> and in EFI environment?
>>
>> In a PV domU arguments can be passed to the specified
>> kernel="/path/file" with the extra="what ever" option.
>> In openfirmware the arguments may come from the /boot/chosen node.
>> In EFI it may be possible as well, not my area of expertise.
>> In the wellknown dumb i386 BIOS no such way exist.
>>
>> In case grub has code to evalute these things, how can such arguements
>> be used within grub.cfg? Where is that documented?
>>
> 
> I believe the question briefly came up already but without any
> followup. IIRC it was in relation to how to pass real kernel name to
> grub in Xen.
> 
> For OFW grub will parse bootargs property, interpret it as series of
> variable assignments separated by ";" and set these variables. There
> is nothing similar for Xen or EFI cases currently. For EFI we could
> fetch arguments using Loaded Image Protocol (LoadOptions). Another
> option (in addition, not either/or) is to define GUID for grub and set
> them in NVRAM.
> 
> What I do not like is the possibility to blindly set any internal
> variable (consider overriding of $prefix). I'd prefer to set variables
> in separate namespace, like grub.arg.XXX=YYY for XXX=YYY argument and
> let user figure out what to do with them.
I'm aware of the problem and I fully agree with you. Automatic install
doesn't use those and I think the reason for it was to specify root in
early days of porting. I don't think it's used for anything nowadays.

Also unless there is a good usecase for having command line parsing, I'm
all for killing existing ieee1275 parsing altogether and not introducing
any parsing in the future.
> 
> As long as variables are defined you of course can do whatever you
> like with them, including referencing them in grub.cfg. How you can
> use them in grub.cfg is limited only by your imagination then :)
> 
> I do not think it is documented anywhere mostly because feature does
> not really exist; I suppose OFW was added mostly as prerequisite for
> something else. git blame may answer it.
> 
> And of course patches are welcome :)
> 
> _______________________________________________
> 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: 213 bytes --]

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Wed, Apr 29, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> I'm aware of the problem and I fully agree with you. Automatic install
> doesn't use those and I think the reason for it was to specify root in
> early days of porting. I don't think it's used for anything nowadays.

For PV guests the use case is simple: provide a generic grub binary,
which recognizes optional knobs from the domU.cfg. This will be used to
select one of the configured devices as root.
I can imagine that this can be used for OF or EFI as well.

> Also unless there is a good usecase for having command line parsing, I'm
> all for killing existing ieee1275 parsing altogether and not introducing
> any parsing in the future.

So you want to dumb it down to the 80s PC level, even if some firmware
implementations can set knobs?!

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'phcoder' Serbinenko]

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

On Apr 29, 2015 5:10 PM, "Olaf Hering" <olaf@aepfle.de> wrote:
>
> On Wed, Apr 29, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
> > I'm aware of the problem and I fully agree with you. Automatic install
> > doesn't use those and I think the reason for it was to specify root in
> > early days of porting. I don't think it's used for anything nowadays.
>
> For PV guests the use case is simple: provide a generic grub binary,
> which recognizes optional knobs from the domU.cfg. This will be used to
> select one of the configured devices as root.
More details on this one please. Both command line and grub binary are on
host. How is managing changing one is different from the other?
> I can imagine that this can be used for OF or EFI as well.
>
> > Also unless there is a good usecase for having command line parsing, I'm
> > all for killing existing ieee1275 parsing altogether and not introducing
> > any parsing in the future.
>
> So you want to dumb it down to the 80s PC level, even if some firmware
> implementations can set knobs?!
>
"It's shiny and new" or "this is from 80s" are fallacies and not arguments.
> Olaf
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Wed, Apr 29, Vladimir 'phcoder' Serbinenko wrote:

> 
> On Apr 29, 2015 5:10 PM, "Olaf Hering" <olaf@aepfle.de> wrote:
> >
> > On Wed, Apr 29, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> >
> > > I'm aware of the problem and I fully agree with you. Automatic install
> > > doesn't use those and I think the reason for it was to specify root in
> > > early days of porting. I don't think it's used for anything nowadays.
> >
> > For PV guests the use case is simple: provide a generic grub binary,
> > which recognizes optional knobs from the domU.cfg. This will be used to
> > select one of the configured devices as root.
> More details on this one please. Both command line and grub binary are on host.
> How is managing changing one is different from the other?

Not sure what you are asking, but:
The distro provides a static binary, which has a certain level of
features. And some of the features can be controlled from the outside by
some knobs. The feature is to select a certain drive without user
interaction, and the knob is a string in the cmdline in the PV domU
case.

> > > Also unless there is a good usecase for having command line parsing, I'm
> > > all for killing existing ieee1275 parsing altogether and not introducing
> > > any parsing in the future.
> > So you want to dumb it down to the 80s PC level, even if some firmware
> > implementations can set knobs?!
> "It's shiny and new" or "this is from 80s" are fallacies and not arguments.

Its not new that a firmware provides an interface to query its
properties AND that a firmware provides an interface the adjust
properties. OF does that. EFI maybe, no idea. And in some sense a PV
guest via its cmdline does that as well. I have however not looked how
the cmdline is passed to the PV kernel and how its retrieved in the PV
kernel.

My laptop with its BIOS provides nothing like that because the concept
is based on the PC from the 80s. Or whatever.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'phcoder' Serbinenko]

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

On Apr 29, 2015 5:35 PM, "Olaf Hering" <olaf@aepfle.de> wrote:
>
> On Wed, Apr 29, Vladimir 'phcoder' Serbinenko wrote:
>
> >
> > On Apr 29, 2015 5:10 PM, "Olaf Hering" <olaf@aepfle.de> wrote:
> > >
> > > On Wed, Apr 29, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > >
> > > > I'm aware of the problem and I fully agree with you. Automatic
install
> > > > doesn't use those and I think the reason for it was to specify root
in
> > > > early days of porting. I don't think it's used for anything
nowadays.
> > >
> > > For PV guests the use case is simple: provide a generic grub binary,
> > > which recognizes optional knobs from the domU.cfg. This will be used
to
> > > select one of the configured devices as root.
> > More details on this one please. Both command line and grub binary are
on host.
> > How is managing changing one is different from the other?
>
> Not sure what you are asking, but:
> The distro provides a static binary, which has a certain level of
> features. And some of the features can be controlled from the outside by
> some knobs. The feature is to select a certain drive without user
> interaction,
This info is already in grub.cfg. Why does grub.cfg need help to find disk
with distro if it already contains a refence to it?

>and the knob is a string in the cmdline in the PV domU
> case.
>
> > > > Also unless there is a good usecase for having command line
parsing, I'm
> > > > all for killing existing ieee1275 parsing altogether and not
introducing
> > > > any parsing in the future.
> > > So you want to dumb it down to the 80s PC level, even if some firmware
> > > implementations can set knobs?!
> > "It's shiny and new" or "this is from 80s" are fallacies and not
arguments.
>
> Its not new that a firmware provides an interface to query its
> properties AND that a firmware provides an interface the adjust
> properties. OF does that. EFI maybe, no idea. And in some sense a PV
> guest via its cmdline does that as well. I have however not looked how
> the cmdline is passed to the PV kernel and how its retrieved in the PV
> kernel.
>
And your point is? Just that something is available doesn't mean it's useful
> My laptop with its BIOS provides nothing like that because the concept
> is based on the PC from the 80s. Or whatever.
>
> Olaf
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Wed, Apr 29, Vladimir 'phcoder' Serbinenko wrote:

> This info is already in grub.cfg. Why does grub.cfg need help to find disk with
> distro if it already contains a refence to it?

How does the info which disk inside the guest to use initially get into
grub.cfg?  The distro can certainly not know that in advance.  This is
like setting the boot-device, which is up to the host admin, not grub or
the distro.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'phcoder' Serbinenko]

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

There is a standard where to put it. See xen docs
On Apr 29, 2015 6:02 PM, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Wed, Apr 29, Vladimir 'phcoder' Serbinenko wrote:
>
> > This info is already in grub.cfg. Why does grub.cfg need help to find
> disk with
> > distro if it already contains a refence to it?
>
> How does the info which disk inside the guest to use initially get into
> grub.cfg?  The distro can certainly not know that in advance.  This is
> like setting the boot-device, which is up to the host admin, not grub or
> the distro.
>
> Olaf
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

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

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Wed, Apr 29, Vladimir 'phcoder' Serbinenko wrote:

> There is a standard where to put it. See xen docs

Yes, its like that:
kernel="/usr/whatever/distro/grub.xen"
extra="opt1=val opt2=val"

And grub2 does not grab the cmdline provided via extra=. I think that
providing root=xen/xvdb is the right way to control grub inside the
domU.
In anycase, what the OF does today in its init code is valid and should
stay.  Once I find the time I will do the very same for PV grub.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'phcoder' Serbinenko]

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

On Apr 29, 2015 6:28 PM, "Olaf Hering" <olaf@aepfle.de> wrote:
>
> On Wed, Apr 29, Vladimir 'phcoder' Serbinenko wrote:
>
> > There is a standard where to put it. See xen docs
>
> Yes, its like that:
> kernel="/usr/whatever/distro/grub.xen"
> extra="opt1=val opt2=val"
>
That's not what I meant. There is a standard on where to find files inside
the domU.
> And grub2 does not grab the cmdline provided via extra=. I think that
> providing root=xen/xvdb is the right way to control grub inside the
> domU.
> In anycase, what the OF does today in its init code is valid and should
> stay.
Mixing up namespaces is certainly not valid. This will lead to both
intended misuses like changing variables that shouldn't be and
unintentional when e.g. root=/dev/xvda2 meant for Linux will sneak into
grub breaking stuff
>  Once I find the time I will do the very same for PV grub.
>
> Olaf
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Wed, Apr 29, Vladimir 'phcoder' Serbinenko wrote:

> 
> On Apr 29, 2015 6:28 PM, "Olaf Hering" <olaf@aepfle.de> wrote:
> >
> > On Wed, Apr 29, Vladimir 'phcoder' Serbinenko wrote:
> >
> > > There is a standard where to put it. See xen docs
> >
> > Yes, its like that:
> > kernel="/usr/whatever/distro/grub.xen"
> > extra="opt1=val opt2=val"
> >
> That's not what I meant. There is a standard on where to find files inside the
> domU.

Sigh..
There are likely ways to find out where grub was loaded from even on a
PC, and use that as initial root=. In a PV guest no such thing exists
because itself grub is the firmware. In OF I can imaging that it might
be useful to point grub right away to some other device than listed in
/chosen/bootpath.

> > And grub2 does not grab the cmdline provided via extra=. I think that
> > providing root=xen/xvdb is the right way to control grub inside the
> > domU.
> > In anycase, what the OF does today in its init code is valid and should
> > stay.
> Mixing up namespaces is certainly not valid. This will lead to both intended
> misuses like changing variables that shouldn't be and unintentional when e.g.
> root=/dev/xvda2 meant for Linux will sneak into grub breaking stuff

Since the kernel= is grub and the stuff in cmdline is obviously meant
for that very kernel (grub), it can have no meaning for an OS that
possibly loaded later. It does not even know about that string.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'φ-coder/phcoder' Serbinenko]

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


> Sigh..
> There are likely ways to find out where grub was loaded from even on a
> PC, and use that as initial root=. In a PV guest no such thing exists
> because itself grub is the firmware.
grub-install already takes this into account.

> In OF I can imaging that it might
> be useful to point grub right away to some other device than listed in
> /chosen/bootpath.
>
We don't support loading modules from another version that what was
compiled with kernel. And if you move different parts of GRUB install
after grub-install, then you have only yourself to blame. Think of any
other program: if you start moving its files around it will not work.

>>> And grub2 does not grab the cmdline provided via extra=. I think that
>>> providing root=xen/xvdb is the right way to control grub inside the
>>> domU.
>>> In anycase, what the OF does today in its init code is valid and should
>>> stay.
>> Mixing up namespaces is certainly not valid. This will lead to both intended
>> misuses like changing variables that shouldn't be and unintentional when e.g.
>> root=/dev/xvda2 meant for Linux will sneak into grub breaking stuff
> 
> Since the kernel= is grub and the stuff in cmdline is obviously meant
> for that very kernel (grub), it can have no meaning for an OS that
> possibly loaded later. It does not even know about that string.
> 
The GRUB which is used for kernel= may be programmed to use /vmlinuz and
pass root= to it. merging unrelated namespaces is always
> Olaf
> 
> _______________________________________________
> 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: 213 bytes --]

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> 
> > Sigh..
> > There are likely ways to find out where grub was loaded from even on a
> > PC, and use that as initial root=. In a PV guest no such thing exists
> > because itself grub is the firmware.
> grub-install already takes this into account.

There is no grub-install in that case.

We run in circles, and to get out of the loop I have to show code.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 07.05.2015 16:54, Olaf Hering wrote:
> On Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> 
>>
>>> Sigh..
>>> There are likely ways to find out where grub was loaded from even on a
>>> PC, and use that as initial root=. In a PV guest no such thing exists
>>> because itself grub is the firmware.
>> grub-install already takes this into account.
> 
> There is no grub-install in that case.
> 
> We run in circles, and to get out of the loop I have to show code.
> 
No, you need to show an actual usecase with enough details and
explanation why the solutions that already exist are inadequate.
> Olaf
> 
> _______________________________________________
> 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: 213 bytes --]

Re: passing options to grub in xen,openfirmware and efi

[Andrei Borzenkov]

On Thu, May 7, 2015 at 5:59 PM, Vladimir 'φ-coder/phcoder' Serbinenko
<phcoder@gmail.com> wrote:
> On 07.05.2015 16:54, Olaf Hering wrote:
>> On Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>
>>>
>>>> Sigh..
>>>> There are likely ways to find out where grub was loaded from even on a
>>>> PC, and use that as initial root=. In a PV guest no such thing exists
>>>> because itself grub is the firmware.
>>> grub-install already takes this into account.
>>
>> There is no grub-install in that case.
>>
>> We run in circles, and to get out of the loop I have to show code.
>>
> No, you need to show an actual usecase with enough details and
> explanation why the solutions that already exist are inadequate.


The way pv-grub2 is built by distributions now is grub-mkstandalone
with grub.cfg that search several predefined directories for "real"
guest grub.cfg. Passing its location as boot argument would make it
possible to remove these harcdoded locations.

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 07.05.2015 17:03, Andrei Borzenkov wrote:
> On Thu, May 7, 2015 at 5:59 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>> On 07.05.2015 16:54, Olaf Hering wrote:
>>> On Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>
>>>>
>>>>> Sigh..
>>>>> There are likely ways to find out where grub was loaded from even on a
>>>>> PC, and use that as initial root=. In a PV guest no such thing exists
>>>>> because itself grub is the firmware.
>>>> grub-install already takes this into account.
>>>
>>> There is no grub-install in that case.
>>>
>>> We run in circles, and to get out of the loop I have to show code.
>>>
>> No, you need to show an actual usecase with enough details and
>> explanation why the solutions that already exist are inadequate.
> 
> 
> The way pv-grub2 is built by distributions now is grub-mkstandalone
> with grub.cfg that search several predefined directories for "real"
> guest grub.cfg. Passing its location as boot argument would make it
> possible to remove these harcdoded locations.
> 
most other firmwares like EFI or BIOS look for boot image at hardcoded
place e.g. MBR or ESP at predefined locations or uses NVRAM. The trouble
with passing this info from dom0 is that it's difficult to discover for
grub-install where to put image, in some cases this would even make
install impossible without modifying dom0. I feel like location which
changes all the time would create more confusion that hardcoded location
(E.g. I ran grub-install but my system still uses old GRUB)
> _______________________________________________
> 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: 213 bytes --]

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> most other firmwares like EFI or BIOS look for boot image at hardcoded
> place e.g. MBR or ESP at predefined locations or uses NVRAM. The trouble
> with passing this info from dom0 is that it's difficult to discover for
> grub-install where to put image, in some cases this would even make
> install impossible without modifying dom0. I feel like location which
> changes all the time would create more confusion that hardcoded location
> (E.g. I ran grub-install but my system still uses old GRUB)

What do you expect from grub-install in a PV guest? Whatever it does
today its result will be a noop. All that needs to be done is to write
/boot/grub2/grub.cfg. In a PV guest grub2 is the firmware (kernel= in
domU.cfg), and the NVRAM is the cmdline (extra= in domU.cfg).

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'phcoder' Serbinenko]

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

On May 8, 2015 12:10 PM, "Olaf Hering" <olaf@aepfle.de> wrote:
>
> On Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
> > most other firmwares like EFI or BIOS look for boot image at hardcoded
> > place e.g. MBR or ESP at predefined locations or uses NVRAM. The trouble
> > with passing this info from dom0 is that it's difficult to discover for
> > grub-install where to put image, in some cases this would even make
> > install impossible without modifying dom0. I feel like location which
> > changes all the time would create more confusion that hardcoded location
> > (E.g. I ran grub-install but my system still uses old GRUB)
>
> What do you expect from grub-install in a PV guest? Whatever it does
> today its result will be a noop. All that needs to be done is to write
> /boot/grub2/grub.cfg. In a PV guest grub2 is the firmware (kernel= in
> domU.cfg), and the NVRAM is the cmdline (extra= in domU.cfg).
>
That's not the plan which is pushed by xen guys. They propose to make grub
stored on dom0 to just load grub from a predefined place in domU. This I.a.
allows easier upgrade of bootloader for distros as they don't have to worry
about dom0 having very old grub.
Also if cmdline is nvram then please tell me how to modify it from domU.
> Olaf
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

Re: passing options to grub in xen,openfirmware and efi

[Andrei Borzenkov]

On Fri, May 8, 2015 at 1:57 PM, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
>
> On May 8, 2015 12:10 PM, "Olaf Hering" <olaf@aepfle.de> wrote:
>>
>> On Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>
>> > most other firmwares like EFI or BIOS look for boot image at hardcoded
>> > place e.g. MBR or ESP at predefined locations or uses NVRAM. The trouble
>> > with passing this info from dom0 is that it's difficult to discover for
>> > grub-install where to put image, in some cases this would even make
>> > install impossible without modifying dom0. I feel like location which
>> > changes all the time would create more confusion that hardcoded location
>> > (E.g. I ran grub-install but my system still uses old GRUB)
>>
>> What do you expect from grub-install in a PV guest? Whatever it does
>> today its result will be a noop. All that needs to be done is to write
>> /boot/grub2/grub.cfg. In a PV guest grub2 is the firmware (kernel= in
>> domU.cfg), and the NVRAM is the cmdline (extra= in domU.cfg).
>>
> That's not the plan which is pushed by xen guys. They propose to make grub
> stored on dom0 to just load grub from a predefined place in domU. This I.a.
> allows easier upgrade of bootloader for distros as they don't have to worry
> about dom0 having very old grub.

that's fine but you need to be able to confgure at least disk on which
guest grub is located, even if path to binary is fixed. How do you do
it wihout passing some information to dom0 grub?

> Also if cmdline is nvram then please tell me how to modify it from domU.
>> 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: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Fri, May 08, Andrei Borzenkov wrote:

> that's fine but you need to be able to confgure at least disk on which
> guest grub is located, even if path to binary is fixed. How do you do
> it wihout passing some information to dom0 grub?

If a domU starts to be able to modify its "firmware" in dom0 then this can
be used to modify its "NVRAM" as well.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Fri, May 08, Vladimir 'phcoder' Serbinenko wrote:

> That's not the plan which is pushed by xen guys. They propose to make grub
> stored on dom0 to just load grub from a predefined place in domU. This I.a.
> allows easier upgrade of bootloader for distros as they don't have to worry
> about dom0 having very old grub.

Thats news, where was that proposed and discussed?

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Andrei Borzenkov]

On Fri, May 8, 2015 at 2:15 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, May 08, Vladimir 'phcoder' Serbinenko wrote:
>
>> That's not the plan which is pushed by xen guys. They propose to make grub
>> stored on dom0 to just load grub from a predefined place in domU. This I.a.
>> allows easier upgrade of bootloader for distros as they don't have to worry
>> about dom0 having very old grub.
>
> Thats news, where was that proposed and discussed?
>

http://xenbits.xen.org/docs/unstable/misc/x86-xenpv-bootloader.html

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Fri, May 08, Andrei Borzenkov wrote:

> On Fri, May 8, 2015 at 2:15 PM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Fri, May 08, Vladimir 'phcoder' Serbinenko wrote:
> >
> >> That's not the plan which is pushed by xen guys. They propose to make grub
> >> stored on dom0 to just load grub from a predefined place in domU. This I.a.
> >> allows easier upgrade of bootloader for distros as they don't have to worry
> >> about dom0 having very old grub.
> >
> > Thats news, where was that proposed and discussed?
> http://xenbits.xen.org/docs/unstable/misc/x86-xenpv-bootloader.html

That is chainloading, and in that sense at a different layer.

The kernel= still looks just at the very first disk, or whatever disk is
returned by "search -f /path". If grub2 would start to look at extra= it
will be possible to select a configured disk.

I just browsed the code today, grub_xen_start_page_addr->cmd_line is
what /boot/chosen is in OF. Should be easy to add similar code to set
variables found in that cmdline. Its then up to the scripts running in
the binary referenced by kernel= to make use of such variables.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'phcoder' Serbinenko]

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

On May 8, 2015 1:58 PM, "Olaf Hering" <olaf@aepfle.de> wrote:
>
> On Fri, May 08, Andrei Borzenkov wrote:
>
> > On Fri, May 8, 2015 at 2:15 PM, Olaf Hering <olaf@aepfle.de> wrote:
> > > On Fri, May 08, Vladimir 'phcoder' Serbinenko wrote:
> > >
> > >> That's not the plan which is pushed by xen guys. They propose to
make grub
> > >> stored on dom0 to just load grub from a predefined place in domU.
This I.a.
> > >> allows easier upgrade of bootloader for distros as they don't have
to worry
> > >> about dom0 having very old grub.
> > >
> > > Thats news, where was that proposed and discussed?
> > http://xenbits.xen.org/docs/unstable/misc/x86-xenpv-bootloader.html
>
> That is chainloading, and in that sense at a different layer.
>
> The kernel= still looks just at the very first disk, or whatever disk is
> returned by "search -f /path". If grub2 would start to look at extra= it
> will be possible to select a configured disk.
>
> I just browsed the code today, grub_xen_start_page_addr->cmd_line is
> what /boot/chosen is in OF. Should be easy to add similar code to set
> variables found in that cmdline. Its then up to the scripts running in
> the binary referenced by kernel= to make use of such variables.
>
Last thing we want is to promote bad code to a more popular platform
> Olaf
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Fri, May 08, Andrei Borzenkov wrote:

> On Fri, May 8, 2015 at 2:15 PM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Fri, May 08, Vladimir 'phcoder' Serbinenko wrote:
> >
> >> That's not the plan which is pushed by xen guys. They propose to make grub
> >> stored on dom0 to just load grub from a predefined place in domU. This I.a.
> >> allows easier upgrade of bootloader for distros as they don't have to worry
> >> about dom0 having very old grub.
> > Thats news, where was that proposed and discussed?
> http://xenbits.xen.org/docs/unstable/misc/x86-xenpv-bootloader.html

Where is that implemented anyway? I fail to find code for that in grub2
sources. But as noted elsewhere, this is within the guest. Nothing would
load binaries from the suggested location. And there can be several
disks, each containing the suggested layout. Its still up to the host
admin to start a guest with a given kernel= and extra= from domU.cfg.

But without changes such as
<1431336508-17290-1-git-send-email-olaf@aepfle.de> it will be impossible
for the host admin to load files from a specific disk (be it a disk or a
cdrom). Imagine your PC without the BIOS provided boot menu behind F12
(or whereever), everything would need to go to the first disk.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Andrei Borzenkov]

On Mon, May 11, 2015 at 12:36 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, May 08, Andrei Borzenkov wrote:
>
>> On Fri, May 8, 2015 at 2:15 PM, Olaf Hering <olaf@aepfle.de> wrote:
>> > On Fri, May 08, Vladimir 'phcoder' Serbinenko wrote:
>> >
>> >> That's not the plan which is pushed by xen guys. They propose to make grub
>> >> stored on dom0 to just load grub from a predefined place in domU. This I.a.
>> >> allows easier upgrade of bootloader for distros as they don't have to worry
>> >> about dom0 having very old grub.
>> > Thats news, where was that proposed and discussed?
>> http://xenbits.xen.org/docs/unstable/misc/x86-xenpv-bootloader.html
>
> Where is that implemented anyway?

I do not think it is right now. I also do not really know what is the
status of this proposal. Still this two stage approach look more
interesting as it gives domU admin full control over boot loader to
use.

SUSE could be the first :)

>                                                            I fail to find code for that in grub2
> sources. But as noted elsewhere, this is within the guest. Nothing would
> load binaries from the suggested location. And there can be several
> disks, each containing the suggested layout. Its still up to the host
> admin to start a guest with a given kernel= and extra= from domU.cfg.
>
> But without changes such as
> <1431336508-17290-1-git-send-email-olaf@aepfle.de> it will be impossible
> for the host admin to load files from a specific disk (be it a disk or a
> cdrom). Imagine your PC without the BIOS provided boot menu behind F12
> (or whereever), everything would need to go to the first disk.
>
> Olaf
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Mon, May 11, Andrei Borzenkov wrote:

> SUSE could be the first :)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759018 indicates that
Debian uses the referenced patches. Looks like they are ignored
upstream.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'phcoder' Serbinenko]

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

The patch has been reviewed upstream and needs improvement
On May 11, 2015 12:43 PM, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Mon, May 11, Andrei Borzenkov wrote:
>
> > SUSE could be the first :)
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759018 indicates that
> Debian uses the referenced patches. Looks like they are ignored
> upstream.
>
> Olaf
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

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

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:

> The patch has been reviewed upstream and needs improvement

I see no followup to v2 of the patch.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Vladimir 'phcoder' Serbinenko]

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

It was sent on March 27
On May 11, 2015 1:04 PM, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
>
> > The patch has been reviewed upstream and needs improvement
>
> I see no followup to v2 of the patch.
>
> Olaf
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

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

Re: passing options to grub in xen,openfirmware and efi

[Olaf Hering]

On Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> most other firmwares like EFI or BIOS look for boot image at hardcoded
> place e.g. MBR or ESP at predefined locations or uses NVRAM. The trouble
> with passing this info from dom0 is that it's difficult to discover for
> grub-install where to put image, in some cases this would even make
> install impossible without modifying dom0. I feel like location which
> changes all the time would create more confusion that hardcoded location
> (E.g. I ran grub-install but my system still uses old GRUB)

Thats exactly the point: other firmware have a notion of a boot-device.
A PV guest currently has not, simply because grub has no code which
looks at the info passed to it. How that info is interpreted is up to
that very grub itself.

Regerading discovery:
In a PV domU storing the boot binary within that domU is equal to all
other systems: it goes where /boot/xen/ is. There is nothing to detect
from within domU. And in case some scripts have to refer to a disk, that
info is in sysfs: /dev/xvda translates to xen/xvda etc [1]. Not sure if
grub-install within domU does include such info into the binary. If it
does, fine. If not, we are back to square one:

 The first grub (kernel= in domU.cfg) may get a variable where to look
 for the second (guest admin controlled) grub. And this variable should
 be passed on to that second grub to make it aware where it was loaded
 from.

 If there is no variable the first grub is free to search for the second
 grub. Even in this case it makes sense to tell that second grub where
 it came from.

Olaf

[1]: I see grub-core/disk/xen/xendisk.c:fill uses either xen/ or xenid/
as prefix. No idea how the second case can happen in practice. I dont
know the backend/frontend protocol well enough. This case can likely be
detected as well within domU. After all the kernel has to assign some
name to such device.

Olaf

Re: passing options to grub in xen,openfirmware and efi

[Michael Chang]

2015-05-07 23:03 GMT+08:00 Andrei Borzenkov <arvidjaar@gmail.com>:
> On Thu, May 7, 2015 at 5:59 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>> On 07.05.2015 16:54, Olaf Hering wrote:
>>> On Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> The way pv-grub2 is built by distributions now is grub-mkstandalone
> with grub.cfg that search several predefined directories for "real"
> guest grub.cfg. Passing its location as boot argument would make it
> possible to remove these harcdoded locations.

Just want to make the description more clear. We seen that pvgrub2 as
a drop-in replacement for pvgrub. And pvgrub allows you specify config
to load in domU.cfg while we found that it's not possible for pvgrub2.

eg.
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"
extra = "(hd0,0)/grub/menu.lst"

Thanks,
Michael

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

Re: passing options to grub in xen,openfirmware and efi

[Curt Brune]

Hello,

This is a very interesting topic.

On Thu Apr 23 10:03, Olaf Hering wrote:
> 
> Is there a way to pass options to grub in a Xen PV domU, in openfirmware
> and in EFI environment?
> 
> In a PV domU arguments can be passed to the specified
> kernel="/path/file" with the extra="what ever" option.
> In openfirmware the arguments may come from the /boot/chosen node.
> In EFI it may be possible as well, not my area of expertise.

I am particularly curious about the EFI part of Olaf's question.

Is there anyway to pass arguments to GRUB via EFI variables or other
bits of data in the Boot#### load option variable?

Cheers,
Curt