From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Hq7hq-0002nJ-BY for mharc-grub-devel@gnu.org; Mon, 21 May 2007 09:13:46 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hq7ho-0002mz-3j for grub-devel@gnu.org; Mon, 21 May 2007 09:13:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hq7hm-0002mm-Qr for grub-devel@gnu.org; Mon, 21 May 2007 09:13:43 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hq7hm-0002mj-L6 for grub-devel@gnu.org; Mon, 21 May 2007 09:13:42 -0400 Received: from neonescio.viaisn.org ([82.94.249.43]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Hq7hm-0003Xt-7k for grub-devel@gnu.org; Mon, 21 May 2007 09:13:42 -0400 Received: from dijkstra.dekkers.cx ([2001:960:7a0:0:213:d4ff:fe9c:2487] ident=Debian-exim) by neonescio.viaisn.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32 CV=0) (Exim 4.63 #1) id 1Hq7hk-0005L1-BZ; Mon, 21 May 2007 15:13:40 +0200 Received: from localhost ([127.0.0.1] helo=dijkstra.dekkers.cx ident=jeroen) by dijkstra.dekkers.cx with esmtp (Exim 4.63) (envelope-from ) id 1Hq7hj-0006Gf-Mq; Mon, 21 May 2007 15:13:39 +0200 Date: Mon, 21 May 2007 15:13:39 +0200 Message-ID: <871whauxoc.wl@dekkers.cx> From: Jeroen Dekkers To: The development of GRUB 2 In-Reply-To: <1179750218.4178.17.camel@xerces> References: <20070509151643.GB16077@aragorn> <1178725065.4102.65.camel@xerces> <20070509161344.GA25183@aragorn> <1179004601.3922.4.camel@xerces> <1179054146.4014.9.camel@xerces> <20070513164407.GA11143@aragorn> <20070518065137.GA2485@aragorn> <1179535793.4466.3.camel@xerces> <20070519093336.GA19265@aragorn> <1179575266.4466.5.camel@xerces> <20070519121051.GA7186@aragorn> <1179580232.4542.8.camel@xerces> <1179584038.4145.10.camel@xerces> <877ir2v3gd.wl@dekkers.cx> <1179750218.4178.17.camel@xerces> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (x86_64-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-detected-kernel: Linux 2.6 (newer, 3) Cc: Thomas Stewart , 423022@bugs.debian.org, Robert Millan Subject: Re: Bug#423022: Bug#422851: "grub-probe -t partmap" doesn't work with software RAID 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, 21 May 2007 13:13:44 -0000 At Mon, 21 May 2007 13:23:38 +0100, Sam Morris wrote: > > On Mon, 2007-05-21 at 13:08 +0200, Jeroen Dekkers wrote: > > At Sat, 19 May 2007 15:13:58 +0100, > > Sam Morris wrote: > > > In addition, it would be nice if the 'out of disk' error could be > > > deferred until grub actually tries to read a block that is out of range, > > > as grub-legacy does > > > > The problem is that it actually tries to do that, because the RAID > > superblock is located at the end of the partition. > > Oh, good point. My only remaining point of confusion is how I am able to > access the (md0) device fine from within grub, since it can't read the > superblocks. Does it just assume that any pc partitions of type 0xfd > with unreadable superblocks are part of a RAID 1 array, or is it > possible that something else is going on? > > My array is made up of partitions on two disks; the first is the primary > master on the motherboard's ATA controller, and the second is on a > Promise PCI card. > > Now, AFAIK the promise card cannot do 48-bit LBA addressing without a > bios flash that I never applied. But is it possible that my > motherboard's controller is able to do 48-bit addressing? > > If this were the case it would explain how grub is able to access an > (md0) device (via the fully-readable (hd0,2) device), and also where the > 'out of disk' error comes from (from trying to read the superblock of > (hd3,2)). > > If this is the case, it would be nice if the raid module would only > throw a warning if some of the component devices could not be added to a > RAID1 array. I think the handling of errors/warnings in GRUB2 can probably be improved, but it shouldn't give an error in this case. See the code in raid.c line 344. Can you test whether this patch makes the error go away? Index: disk/raid.c =================================================================== RCS file: /cvsroot/grub/grub2/disk/raid.c,v retrieving revision 1.3 diff -u -p -r1.3 raid.c --- disk/raid.c 17 May 2007 23:23:03 -0000 1.3 +++ disk/raid.c 21 May 2007 13:10:25 -0000 @@ -344,7 +344,10 @@ grub_raid_scan_device (const char *name) err = grub_disk_read (disk, sector, 0, GRUB_RAID_SB_BYTES, (char *) &sb); grub_disk_close (disk); if (err) - return 0; + { + grub_errno = GRUB_ERR_NONE; + return 0; + } /* Look whether there is a RAID superblock. */ if (sb.md_magic != GRUB_RAID_SB_MAGIC) ============================================================ Jeroen Dekkers