grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: passing options to grub in xen,openfirmware and efi
Date: Thu, 07 May 2015 16:45:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0

> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]