On 09/15/2010 08:55 PM, Joey Korkames wrote: > 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. > It looks like you confused grub-setup (called from grub-install) with grub-mkconfig (called from update-grub). Former accesses only to /boot/grub and it needs to know about /boot/grub in order to configure image correctly. grub-mkconfig on the other hand probes for root but you don't have to use it. If you prefer the old way of doing things you can simply remove grub-mkconfig and write grub.cfg yourself. > 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 >
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel