From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KSYaD-0005lL-Ag for mharc-grub-devel@gnu.org; Mon, 11 Aug 2008 10:41:17 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KSYa9-0005gW-H5 for grub-devel@gnu.org; Mon, 11 Aug 2008 10:41:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KSYa8-0005fC-FE for grub-devel@gnu.org; Mon, 11 Aug 2008 10:41:13 -0400 Received: from [199.232.76.173] (port=42524 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSYa8-0005f0-8J for grub-devel@gnu.org; Mon, 11 Aug 2008 10:41:12 -0400 Received: from aybabtu.com ([69.60.117.155]:43401) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KSYa7-0005DU-Pw for grub-devel@gnu.org; Mon, 11 Aug 2008 10:41:12 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KSYSD-0006GR-FH for grub-devel@gnu.org; Mon, 11 Aug 2008 16:33:02 +0200 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1KSYYy-0004Nd-EC for grub-devel@gnu.org; Mon, 11 Aug 2008 16:40:00 +0200 Date: Mon, 11 Aug 2008 16:40:00 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20080811144000.GC15950@thorin> References: <87vdy7g3dx.fsf@hati.baby-gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vdy7g3dx.fsf@hati.baby-gnu.org> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: grub2 disk error with kvm X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 14:41:14 -0000 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] 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."