grub-setup inflexibility

[Joey Korkames]

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