device.map (Re: Next release?)

[Robert Millan <rmh@aybabtu.com>]

On Wed, Jul 16, 2008 at 12:08:57PM -0400, Pavel Roskin wrote:
> On Wed, 2008-07-16 at 07:11 -0700, Colin D Bennett wrote:
> 
> > > That's a very advanced setup.  I actually cannot imagine why anyone
> > > would use different boot and root drives.  Well, maybe the boot drive
> > > has no partitions that GRUB or the host OS can access? 
> > 
> > I have used machines that have multiple Linux versions spread across
> > two drives, but one common /boot partition so they can all be booted
> > from GRUB.  This doesn't seem unusual to me.
> 
> As I understand it, there are two cases where we have to hardcode the
> drive number.
> 
> 1) MBR and core.img (embedded or not) are on different drives.

If embedded, then they're not different drives (core.img is put right after
MBR).

Otherwise it's a no-go, and device.map won't solve your problem since it's
merely guessing which drive it'll be.  I think it's better to detect this at
install time and fail, than make the user rely on our guesswork.

> 2) core.img and /boot/grub are on different drives.
> 
> The second case can be mitigated because core.img can search all
> available drives.  We can even tell it whether to search only hard
> drives or only floppies.  After switching to lzma, we have some space in
> core.img we can use for that logic.

This is mostly implemented already.  I sent a proof of concept in a mail
titled "[PATCH] disk/fs_uuid.c".

It will only search hard drives unless no match is found (in that case your
boot is broken, so you wouldn't care much that floppy is being probed ;-)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)