Re: Various build failures in current bzr tree

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

On 10.02.2012 19:18, Lennart Sorensen wrote:
> On Fri, Feb 10, 2012 at 05:11:16PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> Imagine following setup: 2 disks with msdos and one with gpt. GPT
>> one is missing on install time and so no part_gpt is inserted. On
>> boot time is then one of msdos disks is missing and so GPT one is
>> needed to complete a readable device but it's inaccessible since no
>> GPT module is loaded.
> Well I only hit this because one of Debian's update-grub scripts tried to
> do a grub-probe and failed.  It wasn't an important one in my case,
> so I disabled that script.  I do think most people would have a fully
> working system before installing the boot loader so not a major problem.
I agree that it should be fixed but the question is how.
>> This and the rest of your e-mail is because of confusion of 2
>> concepts: grub_device and install_device.
>> grub_device is whereever GRUB modules reside and is determined from
>> $boot_directory/grub (default is /boot/grub)
>> install_device is whereever the core is and is the argument to grub-install.
>> They are independent since you want to put core wherever firmware
>> will find it independently of where your root is.
>> install_device is not infered from grub_device or vice-versa.
>> In mdraid example grub_device=mduuid/<UUID>  but install_device is
>> still /dev/sdaX
> So if I tell grub-install to use /dev/sda1 as install_device, should
> it not include the partition table support for sda?
No
>    Currently it only
> tries to include partition table support for grub_device, which being
> an md raid returns nothing.
This is a problem. It should return the partmap of underlying device and 
we have code for that. What does grub-probe -t partmap -d /dev/mdX is?


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko