"grub-probe -t partmap" doesn't work with software RAID

"grub-probe -t partmap" doesn't work with software RAID

[Robert Millan]

Hi,

I'm forwarding you a bug report from Debian.  It seems that the grub-probe
-t partmap feature I just added doesn't play nice with RAID.  Unfortunately,
I have no idea how software RAID is implemented.  Is it okay to just exit
succesfuly and install core.img without any partmap module?

On Wed, May 09, 2007 at 04:37:45PM +0100, Sam Morris wrote:
> On Wed, 2007-05-09 at 17:16 +0200, Robert Millan wrote:
> > On Wed, May 09, 2007 at 03:02:48PM +0100, Sam Morris wrote:
> > > 
> > > Yes, "grub-probe: error: Cannot detect partition map for md0". The
> > > message doesn't appear when grub-pc's postinst is run, however.

Note to GRUB maintainers: earlier this caused a segfault.  I fixed it in
CVS to print that error instead.

> > > > Also, what is the result of "parted /dev/md0 print" ?
> > > 
> > >         Disk /dev/md0: 300GB
> > >         Sector size (logical/physical): 512B/512B
> > >         Partition Table: loop
> >                            ^^^^
> > This means there's indeed no partition table, just a filesystem.
> > 
> > Did you install Debian on purpose without creating any partition table, or is
> > this just the normal result when using software RAID?  What does parted say
> > about your real disk(s)?
> 
> Interesting. This system has been installed for quite a few years; I
> moved it to raid1 by hand.
> 
> The system has several disks; md0 consists of hdb2 and hdg2. Here's what
> parted says about hdb:
> 
>         Disk /dev/hdb: 300GB
>         Sector size (logical/physical): 512B/512B
>         Partition Table: msdos
>         
>         Number  Start   End    Size   Type     File system  Flags
>          1      32.3kB  543MB  543MB  primary                    
>          2      543MB   300GB  300GB  primary  ext3         raid 
> 
> When you say there is no partition table, I guess you mean inside md0
> itself? AFAIR, the array was created before partitionable md arrays were
> added to Linux... or at least before mdadm had the option to create
> them.
> 
> I just ran this on a system that uses RAID which I created with the etch
> installer:
> 
>         Disk /dev/md8: 57.5MB
>         Sector size (logical/physical): 512B/512B
>         Partition Table: loop
>         
>         Number  Start   End     Size    File system  Flags
>          1      0.00kB  57.5MB  57.5MB  ext3              
> 
> Which appears to confirm my belief that partitionable arrays are unusual
> rather than the default.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: "grub-probe -t partmap" doesn't work with software RAID

[Robert Millan]

On Sun, May 13, 2007 at 12:02:26PM +0100, Sam Morris wrote:
> On Sat, 2007-05-12 at 22:16 +0100, Sam Morris wrote:
> > On Wed, 2007-05-09 at 18:13 +0200, Robert Millan wrote:
> > > I'm forwarding you a bug report from Debian.  It seems that the grub-probe
> > > -t partmap feature I just added doesn't play nice with RAID.  Unfortunately,
> > > I have no idea how software RAID is implemented.  Is it okay to just exit
> > > succesfuly and install core.img without any partmap module?

... so apparently it isn't.  We still need to detect this somehow, or maybe we
could just print "pc gpt".. anyone can cast some light on this?

> I experimented some more. At the command prompt I entered 'insmod raid'
> and got the message 'error: out of disk'. I assume that is because the
> partition containing my RAID1 array extends past the area readably by
> BIOS functions. However, I was able to ignore the message: if I then ran
> 'ls', '(md0)' showed up in the list of devices just fine!

How strange.  If you can't access the disk, you wouldn't be able to insmod
anything.  Can you check the following (before running 'insmod raid'):

  - That raid is not already loaded (with lsmod).
  - The 'prefix' variable (with set).
  - Whether you can access (ls) the directory pointed to by 'prefix'.

> I had to do one more thing to boot up correctly: edit the command line.
> It had 'root=md0' but it needed 'root=/dev/md0'. It appears that
> 'grub-probe -t device /boot/grub' outputs 'md0' when it should be
> outputting '/dev/md0' (just as it outputs e.g., '/dev/hde1' instead of
> 'hde1' for 'grub-probe -t device /mnt'). Shall I file a separate bug for
> that?

Please do.

> BTW, it would be convenient if I could override the detected GRUB_DEVICE
> by editing /etc/default/grub; however it seems that update-grub ignores
> the environment variable and always overrides it with the value output
> by grub-probe. It might be useful to allow the user to specify the grub
> device manually in this manner.

Another bug please? :-)

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: "grub-probe -t partmap" doesn't work with software RAID

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

On Sun, May 13, 2007 at 06:44:07PM +0200, Robert Millan wrote:
> On Sun, May 13, 2007 at 12:02:26PM +0100, Sam Morris wrote:
> > On Sat, 2007-05-12 at 22:16 +0100, Sam Morris wrote:
> > > On Wed, 2007-05-09 at 18:13 +0200, Robert Millan wrote:
> > > > I'm forwarding you a bug report from Debian.  It seems that the grub-probe
> > > > -t partmap feature I just added doesn't play nice with RAID.  Unfortunately,
> > > > I have no idea how software RAID is implemented.  Is it okay to just exit
> > > > succesfuly and install core.img without any partmap module?
> 
> ... so apparently it isn't.  We still need to detect this somehow, or maybe we
> could just print "pc gpt".. anyone can cast some light on this?

How about this as temporary solution?  It's ugly, but it's not worse than what
we had before.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

[-- Attachment #2: raid_partmap.diff --]
[-- Type: text/x-diff, Size: 1596 bytes --]

Index: util/i386/efi/grub-install.in
===================================================================
RCS file: /sources/grub/grub2/util/i386/efi/grub-install.in,v
retrieving revision 1.1
diff -u -r1.1 grub-install.in
--- util/i386/efi/grub-install.in	16 May 2007 15:05:02 -0000	1.1
+++ util/i386/efi/grub-install.in	18 May 2007 06:48:02 -0000
@@ -187,7 +187,7 @@
 fi
 
 # Then the partition map module.
-partmap_module=`$grub_probe --target=partmap --device-map=${device_map} ${grubdir}`
+partmap_module=`$grub_probe --target=partmap --device-map=${device_map} ${grubdir} || echo pc gpt`
 if test "x$partmap_module" = x -a "x$modules" = x; then
     echo "Auto-detection of a partition map module failed." 1>&2
     echo "Please specify the module with the option \`--modules' explicitly." 1>&2
Index: util/i386/pc/grub-install.in
===================================================================
RCS file: /sources/grub/grub2/util/i386/pc/grub-install.in,v
retrieving revision 1.13
diff -u -r1.13 grub-install.in
--- util/i386/pc/grub-install.in	7 May 2007 19:54:46 -0000	1.13
+++ util/i386/pc/grub-install.in	18 May 2007 06:48:02 -0000
@@ -217,7 +217,7 @@
 fi
 
 # Then the partition map module.
-partmap_module=`$grub_probe --target=partmap --device-map=${device_map} ${grubdir}`
+partmap_module=`$grub_probe --target=partmap --device-map=${device_map} ${grubdir} || echo pc gpt`
 if test "x$partmap_module" = x -a "x$modules" = x; then
     echo "Auto-detection of a partition map module failed." 1>&2
     echo "Please specify the module with the option \`--modules' explicitly." 1>&2

Re: Bug#422851: "grub-probe -t partmap" doesn't work with software RAID

[Robert Millan]

On Sat, May 19, 2007 at 01:49:53AM +0100, Sam Morris wrote:
> On Fri, 2007-05-18 at 08:51 +0200, Robert Millan wrote:
> > On Sun, May 13, 2007 at 06:44:07PM +0200, Robert Millan wrote:
> > > On Sun, May 13, 2007 at 12:02:26PM +0100, Sam Morris wrote:
> > > > On Sat, 2007-05-12 at 22:16 +0100, Sam Morris wrote:
> > > > > On Wed, 2007-05-09 at 18:13 +0200, Robert Millan wrote:
> > > > > > I'm forwarding you a bug report from Debian.  It seems that the grub-probe
> > > > > > -t partmap feature I just added doesn't play nice with RAID.  Unfortunately,
> > > > > > I have no idea how software RAID is implemented.  Is it okay to just exit
> > > > > > succesfuly and install core.img without any partmap module?
> > > 
> > > ... so apparently it isn't.  We still need to detect this somehow, or maybe we
> > > could just print "pc gpt".. anyone can cast some light on this?
> > 
> > How about this as temporary solution?  It's ugly, but it's not worse than what
> > we had before.
> 
> I've now tested hardcoding the modules to 'pc gpt'.

I suspect some part of GRUB might be thinking you talk about a single module
named 'pc gpt' (which would be found in '/boot/grub/pc gpt.mod').

Can you try passing these to grub-install instead of modifiing the source?

Like: grub-install --modules="pc gpt"

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: Bug#422851: "grub-probe -t partmap" doesn't work with software RAID

[Robert Millan]

On Sat, May 19, 2007 at 12:47:46PM +0100, Sam Morris wrote:
> > 
> > Can you try passing these to grub-install instead of modifiing the source?
> > 
> > Like: grub-install --modules="pc gpt"
> 
> Ok, I'll try that... would grub-mkimage not throw an error in that case
> though?

It shouldn't.

> BTW, where does 'gpt' come into this at all... do I not need 'pc' and
> 'raid'?

Yes, but we need a solution that works for gpt users as well.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: Bug#422851: "grub-probe -t partmap" doesn't work with software RAID

[Robert Millan]

On Sat, May 19, 2007 at 02:10:32PM +0100, Sam Morris wrote:
> 
> Ok, here are the results.
> 
> 'grub-mkimage --output=/boot/grub/core.img ext2 pc gpt _chain' crashes
> at the menu

But raid is missing here.  Does "ext2 pc gpt raid _chain" work?  (at least,
to get to the rescue console)

> I wonder if I am hitting the rescue console because of the "out of disk"
> error that I see when inserting the 'raid' module by hand? The
> partitions in my raid array are 300 GiB, which is larger than the 128
> GiB limit imposed by LBA-28 addressing.
> 
> If this is the case then I guess the error is really my fault and I
> should fix it by creating a separate partition at the start of the disk
> for /boot. However, the code that brings me to the rescue console
> doesn't actually print any errors, it just dumps me there, so I may just
> be barking up the wrong tree. :)

There are two separate problems here.  I can't comment on the LBA addressing
issue, but if we can isolate the partmap detection one, then at least we can
"fix" [1] this (which is what affects the majority of users).

[1] With a kludge that loads "pc gpt" when partmap cannot be detected.  Not sure
    if this is suitable for official grub, but at least we would enable it in
    Debian.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

fallback for "grub-probe -t partmap" failures

[Robert Millan]

(please keep CC to upsteam..)

So, do we put this in upstream grub CVS, or do we hold it off untill a
better fix is available ?

On Sat, May 19, 2007 at 03:34:13PM +0100, Sam Morris wrote:
> On Sat, 2007-05-19 at 16:08 +0200, Robert Millan wrote:
> > On Sat, May 19, 2007 at 02:10:32PM +0100, Sam Morris wrote:
> > > 
> > > Ok, here are the results.
> > > 
> > > 'grub-mkimage --output=/boot/grub/core.img ext2 pc gpt _chain' crashes
> > > at the menu
> > 
> > But raid is missing here.  Does "ext2 pc gpt raid _chain" work?  (at least,
> > to get to the rescue console)
> 
> Yes, this works fine too.
> 
> > There are two separate problems here.  I can't comment on the LBA addressing
> > issue, but if we can isolate the partmap detection one, then at least we can
> > "fix" [1] this (which is what affects the majority of users).
> > 
> > [1] With a kludge that loads "pc gpt" when partmap cannot be detected.  Not sure
> >     if this is suitable for official grub, but at least we would enable it in
> >     Debian.
> 
> Sounds good to me!
> 
> -- 
> Sam Morris
> http://robots.org.uk/
> 
> PGP key id 1024D/5EA01078
> 3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

problem with RAID and LBA addressing

[Robert Millan]

Forwarding to upstream.  Anyone knows why Sam's mails aren't echoed in the
list, despite grub-devel@gnu.org is in CC ?

On Sat, May 19, 2007 at 03:13:58PM +0100, Sam Morris wrote:
> clone 423022 -1
> retitle -1 Errors that cause the user to enter rescue mode are not displayed
> thanks
> 
> On Sat, 2007-05-19 at 14:10 +0100, Sam Morris wrote:
> > 'grub-mkimage --output=/boot/grub/core.img ext2 pc raid _chain' dumps me
> > to the rescue console.
> > 
> > I wonder if I am hitting the rescue console because of the "out of disk"
> > error that I see when inserting the 'raid' module by hand? The
> > partitions in my raid array are 300 GiB, which is larger than the 128
> > GiB limit imposed by LBA-28 addressing.
> 
> I patched kern/disk.c to return GRUB_ERR_NONE instead of throwing the
> 'out of disk' error and, now I can boot up perfectly! So it appears this
> is indeed the problem.
> 
> > If this is the case then I guess the error is really my fault and I
> > should fix it by creating a separate partition at the start of the disk
> > for /boot. However, the code that brings me to the rescue console
> > doesn't actually print any errors, it just dumps me there, so I may just
> > be barking up the wrong tree. :)
> 
> Ideally grub would display the the error message that causes the user to
> be thrown into the rescue console.
> 
> 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 (even through it doesn't 'see' the RAID partition as
> such, I can still boot from it without complaint). But this is less
> important, as I should really have a working system to begin with. I
> won't clone a separate bug for this unless you think it's worthwhile.
> 
> I wonder if d-i warns the user that they may be creating an unbootable
> system if the partition that contains /boot does not exist wholly within
> the first 7.8 GiB/128 GiB/128 PiB (depending on the addressing mode in
> use) of the disk? :)
> 
> -- 
> Sam Morris
> http://robots.org.uk/
> 
> PGP key id 1024D/5EA01078
> 3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: fallback for "grub-probe -t partmap" failures

[Sam Morris]

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

On Sat, 2007-05-19 at 17:32 +0200, Robert Millan wrote:
> (please keep CC to upsteam..)
> 
> So, do we put this in upstream grub CVS, or do we hold it off untill a
> better fix is available ?

I think falling back to 'pc raid gpt' is ok. Perhaps if the fallback is
used, a warning could be displayed prompting the user to set
GRUB_INSTALL_partmap_module in /etc/default/grub (the presence of which
prevents grub-probe -t partmap from being run at all).

Of course there is the question of how to handle lvm (assuming it has
this same problem). I guess it could be included in the fallback list,
but I am unfamiliar with the drawbacks with increasing the size of the
generated core.img. I guess that as its size increases, the likelihood
that it becomes too fragmented for all its blocks to be listed in the
MBR increases?

Maybe instead grub-install could be made more intelligent; if grub-probe
-t partmap fails then fall back to 'pc gpt' and also examine the
device's sysfs entry; if it's /sys/block/md[0-9]+ then add 'raid', if
it's /sys/block/dm-[0-9]+ then add 'lvm'.

As an aside, /sys/block/dm-[0-9] does not automatically mean LVM... it
just means that the block device is a device-mapper device, so it could
be dm-crypt, or using dmraid... perhaps some other check for LVM should
happen before grub-install goes to /sys. Come to think of it, the
initramfs-generators, initramfs and yaird, have this same problem. I
wonder if their detection code can be re-used...

Anyway, the sysfs path of the block device can be obtained fairly simply
once you have the major/minor device numbers with code like this:

        find /sys -name dev | while read line; do
          if test "$(<$line)" = '9:0'; then
            echo $(dirname $line);
            break;
          fi;
        done

Perhaps libsysfs even has a function to do this. If sysfs is not
available then grub-install can directly poke around /dev, /proc/mounts
and so on.

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: problem with RAID and LBA addressing

[Robert Millan]

On Sat, May 19, 2007 at 05:06:21PM +0100, Sam Morris wrote:
> On Sat, 2007-05-19 at 17:51 +0200, Robert Millan wrote:
> > Forwarding to upstream.  Anyone knows why Sam's mails aren't echoed in the
> > list, despite grub-devel@gnu.org is in CC ?
> 
> I'm not subscribed. I've been getting bounces from
> grub-devel-owner@gnu.org, but I figured you were bouncing my messages to
> the mailing list, since they are showing up via gmane's NNTP interface.
> But I see they aren't visible in the list archives so I'll subscribe
> now.

Uhm :/

Okuji, maybe you should consider accepting mail from non-subscribers.  Otherwise
we'll have this problem often when forwarding bug reports from debian.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: problem with RAID and LBA addressing

[Yoshinori K. Okuji]

On Saturday 19 May 2007 18:45, Robert Millan wrote:
> On Sat, May 19, 2007 at 05:06:21PM +0100, Sam Morris wrote:
> > On Sat, 2007-05-19 at 17:51 +0200, Robert Millan wrote:
> > > Forwarding to upstream.  Anyone knows why Sam's mails aren't echoed in
> > > the list, despite grub-devel@gnu.org is in CC ?
> >
> > I'm not subscribed. I've been getting bounces from
> > grub-devel-owner@gnu.org, but I figured you were bouncing my messages to
> > the mailing list, since they are showing up via gmane's NNTP interface.
> > But I see they aren't visible in the list archives so I'll subscribe
> > now.
>
> Uhm :/
>
> Okuji, maybe you should consider accepting mail from non-subscribers. 
> Otherwise we'll have this problem often when forwarding bug reports from
> debian.

That is why the report address is bug-grub. grub-devel is only for developers. 
Note that we get a lot of noise without this setting, so I wouldn't change 
it.

Okuji

Re: problem with RAID and LBA addressing

[Robert Millan]

On Sat, May 19, 2007 at 07:51:12PM +0200, Yoshinori K. Okuji wrote:
> >
> > Okuji, maybe you should consider accepting mail from non-subscribers. 
> > Otherwise we'll have this problem often when forwarding bug reports from
> > debian.
> 
> That is why the report address is bug-grub. grub-devel is only for developers. 
> Note that we get a lot of noise without this setting, so I wouldn't change 
> it.

Isn't bug-grub for GRUB Legacy only?  The website points to grub-devel for
bug reports related to GRUB 2:

  http://www.gnu.org/software/grub/grub-2-bugs.en.html

OTOH, I sent a mail a few days ago noting that GRUB 2 sources still point the
user to bug-grub for bug reporting.  Which one of these is correct?  Sounds
like either the website or the grub source needs to be fixed.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

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

[Jeroen Dekkers]

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.

> (even through it doesn't 'see' the RAID partition as
> such, I can still boot from it without complaint). 

That's probably because you have RAID1. The only difference between a
RAID and a non-RAID is that there is a RAID superblock at the end, you
can just mount a RAID1 partition as normal. This is how grub legacy
was always able to boot from RAID1 partitions. This won't work with
RAID0 or RAID5 however.

> I wonder if d-i warns the user that they may be creating an unbootable
> system if the partition that contains /boot does not exist wholly within
> the first 7.8 GiB/128 GiB/128 PiB (depending on the addressing mode in
> use) of the disk? :)

I think that 7.8GiB limit has been gone for a long time now, I don't
think there will be a lot of installations on such machines. My guess
is that the 128 GiB limit is still a problem.

Jeroen Dekkers

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

[Sam Morris]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

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.

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jeroen Dekkers]

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

Re: problem with RAID and LBA addressing

[Amin Azez]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

* Robert Millan wrote, On 19/05/07 17:45:
> On Sat, May 19, 2007 at 05:06:21PM +0100, Sam Morris wrote:
>   
>> On Sat, 2007-05-19 at 17:51 +0200, Robert Millan wrote:
>>     
>>> Forwarding to upstream.  Anyone knows why Sam's mails aren't echoed in the
>>> list, despite grub-devel@gnu.org is in CC ?
>>>       
>> I'm not subscribed. I've been getting bounces from
>> grub-devel-owner@gnu.org, but I figured you were bouncing my messages to
>> the mailing list, since they are showing up via gmane's NNTP interface.
>> But I see they aren't visible in the list archives so I'll subscribe
>> now.
>>     
>
> Uhm :/
>
> Okuji, maybe you should consider accepting mail from non-subscribers.  Otherwise
> we'll have this problem often when forwarding bug reports from debian.
>
>   
Or at least permitting a subscribe-to-post for those who prefer to use
gmain.

Mailman is a right pain in that respect. Just because I'm subscribed (to
post) doesn't mean I want any messages at all, I much prefer gmane's
NNTP to mailing list.

Sam

[-- Attachment #2: Type: text/html, Size: 1658 bytes --]

Re: problem with RAID and LBA addressing

[Sam Morris]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

> Or at least permitting a subscribe-to-post for those who prefer to use
> gmain.
> 
> Mailman is a right pain in that respect. Just because I'm subscribed
> (to post) doesn't mean I want any messages at all, I much prefer
> gmane's NNTP to mailing list.

FYI, you can disable message delivery via Mailman's web interface once
you have subscribed. That's what I tend to do for lists that I read via
gmane.

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Sam Morris]

On Mon, 21 May 2007 15:13:39 +0200, Jeroen Dekkers wrote:
>> 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?

It does indeed.

I also modified raid.mod to have a 'raidinfo' command that printed out 
the contents of the raid devices list, which seems to confirm my hunch--
md0 only consisted of hd1,2; and if I spend some time trying the ls 
command on various areas of hd3,2 I do get an 'out of disk' error.

> Jeroen Dekkers

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078