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

[Olaf Hering <olaf@aepfle.de>]

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