Re: grub2 disk error with kvm

[Robert Millan <rmh@aybabtu.com>]

On Mon, Aug 11, 2008 at 02:08:58PM +0200, Daniel Dehennin wrote:
> Hello,
> 
> I post a bug report here as asked by nyu on #grub.
> 
> === IRC LOG ===
> [13:32] <nyu> nebuchadnezzar: could you report the grub one first?  the problem
>     is grub_biosdisk_get_diskinfo_standard() fails, but this call wasn't used
>     when probing for drives (and I think it should be)
> === IRC LOG ===
> 
> I have a kvm machine featuring debian lenny (now upgraded to sid).
> It has only one disk configured, with one partition as LVM so I
> install grub2 1.96+20080724-7.
> 
> When booting I have the following error:
> 
> ===
> error: unknown drive hd15
> Entering rescue mode...
> ===

Hi,

Summary of the problem, based on what Daniel told me:

  - grub_biosdisk_iterate() probes for hard drives by trying to read their first
    sector with grub_biosdisk_rw_standard().  In Daniel's setup, it finds 16
    hard disks (the maximum), although only one exists.

  - raid.mod (or anything else) sees the hard disks and tries to use them.

  - grub_biosdisk_open() fails with "cannot get C/H/S values" because
    grub_biosdisk_get_diskinfo_standard() is not usable.

A possible solution would be to allow grub_biosdisk_get_diskinfo_standard()
to fail as long as we have total_sectors, and let CHS values be set to 0
(AFAIK, as long as LBA works they're not essential).  This wouldn't make the
fake drives disappear (it's a KVM bug after all), but would prevent GRUB from
aborting when this happens [1].

Another one would be to integrate grub_biosdisk_get_diskinfo_standard() as
part of the probing routine in grub_biosdisk_iterate(), thus preventing the
disks from appearing at all.

Or another one would be to do nothing, since it will be fixed in KVM sooner
or later [2].  However, I think it's good if we can make GRUB behave more
robustly, just in case we find similar bugs in propietary BIOSes.

[1] Then again, I think the last RAID patch from Felix would archieve the
    same effect.  No reason we can't have both things though.

[2] Daniel, feel free to report this.  You can point to this mail for their
    reference.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."