Re: grub-setup inflexibility

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]