Colin Watson writes:
On Xen (I'm told), it's possible to assign disk images in the host to
things that are named rather like partitions in the guest (e.g.
/dev/sda1), but that don't have an associated disk (e.g. /dev/sda);
indeed, the latter device is nonexistent. This confuses
grub_util_biosdisk_get_grub_dev.
There's really no other situation in which I think it's terribly
plausible that you might have /dev/sda1 but not /dev/sda, so it seems to
me that in this case we can reasonably treat the apparent "partition" as
a disk in its own right.
Can we make some of these 'decisions' switchable on the command line?
I perform a lot of block device redirections (Xen, iSCSI,
nbd, etc) or work from live cd's (where / is merely rootfs+unionfs with
no disk, but /boot is a mounted disk), and grub-setup raises fatal
objections that I would like to override when _I_ know what devnodes
the bootblocks and the filesystems belong on.
Some of this probe logic is starting to delve into sysadmin logic, which can
be terribly obtuse and site-specific. I really don't think the install code
should be _solely_ implemented in compiled languages - it should be
possible to install grub2 boot blocks in alternative/scriptable ways like
it was with grub1 (dd if=/boot/grub/stage1 of=/dev/foo bs=446 count=1 conv=notrunc).
That also lets you install pre-assembled grub cores from
non-grub2-supported platforms, which is useful for no-physical-access OS
conversion.
This is somewhat like the "where is stage1" complaints the list has been
getting, but I'd like to see this minor inflexibility resolved in the
awesome grub2 framework vs. just asking to keep bugfixing ancient grub1.
thanks for reading
-joey
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
