grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#423022: Bug#422851: "grub-probe -t partmap" doesn't work with so


From: Jeroen Dekkers
Subject: Re: Bug#423022: Bug#422851: "grub-probe -t partmap" doesn't work with software RAID
Date: Mon, 21 May 2007 15:13:39 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shij┼Ź) APEL/10.7 Emacs/22.0.95 (x86_64-pc-linux-gnu) MULE/5.0 (SAKAKI)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]