Re: Various build failures in current bzr tree

[Vladimir 'φ-coder/phcoder' Serbinenko]

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