> 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
