[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: grub2 disk error with kvm
From: |
Robert Millan |
Subject: |
Re: grub2 disk error with kvm |
Date: |
Mon, 11 Aug 2008 16:40:00 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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."