Re: device.map (Re: Next release?)

[Pavel Roskin <proski@gnu.org>]

On Sat, 2008-07-19 at 17:14 +0200, Robert Millan wrote:

> > 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.

We could do it in theory.  Even with device.map.  It's not much more
insane than having /boot/grub on a different drive.  The boot drive can
have a "bad" geometry with too few sectors per track.  Or it could be
formatted as one partition.  Or it could be a slow floppy drive.  Or it
could be in ROM.  Or BIOS may not report the boot drive correctly.

How can we fail to support this configuration and claim that the
elimination of device.map would reduce flexibility?  If we card about
flexibility, let's support hardcoding the boot drive into the
bootloader.

Actually, the groundwork is already present in grub-setup and the
bootsector, but grub-install doesn't have an option to force a drive for
core.img embedding.

> > 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 ;-)

Then all be need it to have an option in grub-install to enable this
logic.

-- 
Regards,
Pavel Roskin