[PATCH] Caseless UUID comparsion in search command

[PATCH] Caseless UUID comparsion in search command

[Daniel Mierswa]

[-- Attachment #1.1: Type: text/plain, Size: 536 bytes --]

Just like some time ago in search_fs_uuid() the search_fs() function of
search also needs to be caseless when comparing UUIDs, for some reason
GRUB2 didn't find my UUID although I entered it as reported by blkid. To
be on the safe side, just use strncasecmp. :) Patch against git master
and ChangeLog attached. I await your feedback. :-)

-- 
Mierswa, Daniel

If you still don't like it, that's ok: that's why I'm boss. I simply
know better than you do.
               --- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22

[-- Attachment #1.2: ChangeLog --]
[-- Type: text/plain, Size: 123 bytes --]

2009-07-06  Daniel Mierswa  <impulze@impulze.org>

	* commands/search.c (search_fs): use `strcasecmp' for UUID comparsion.

[-- Attachment #1.3: grub2.patch --]
[-- Type: text/plain, Size: 1116 bytes --]

From 02d806fe1e7603c38f2c885680007b6d14edeefa Mon Sep 17 00:00:00 2001
From: Daniel Mierswa <impulze@impulze.org>
Date: Mon, 6 Jul 2009 09:35:17 +0200
Subject: [PATCH] ignore case for uuid comparison in search

---
 commands/search.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/commands/search.c b/commands/search.c
index 647f408..52b5fd6 100644
--- a/commands/search.c
+++ b/commands/search.c
@@ -70,6 +70,13 @@ search_fs (const char *key, const char *var, int no_floppy, int is_uuid)
 
 	  fs = grub_fs_probe (dev);
 
+	  int (*compare_fn)(const char *s1, const char *s2);
+	  if (is_uuid) {
+	    compare_fn = grub_strcasecmp;
+	  } else {
+	    compare_fn = grub_strcmp;
+	  }
+
 #define QUID(x)	(is_uuid ? (x)->uuid : (x)->label)
 
 	  if (fs && QUID(fs))
@@ -79,7 +86,7 @@ search_fs (const char *key, const char *var, int no_floppy, int is_uuid)
 	      (QUID(fs)) (dev, &quid);
 	      if (grub_errno == GRUB_ERR_NONE && quid)
 		{
-		  if (grub_strcmp (quid, key) == 0)
+		  if (compare_fn (quid, key) == 0)
 		    {
 		      /* Found!  */
 		      count++;
-- 
1.6.3.3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] Caseless UUID comparsion in search command

[Pavel Roskin]

On Mon, 2009-07-06 at 09:57 +0200, Daniel Mierswa wrote:
> Just like some time ago in search_fs_uuid() the search_fs() function of
> search also needs to be caseless when comparing UUIDs, for some reason
> GRUB2 didn't find my UUID although I entered it as reported by blkid. To
> be on the safe side, just use strncasecmp. :) Patch against git master
> and ChangeLog attached. I await your feedback. :-)

Applied with minor stylistic and spelling fixes.

-- 
Regards,
Pavel Roskin

Re: [PATCH] Caseless UUID comparsion in search command

[Arthur Marsh]

Daniel Mierswa wrote, on 06/07/09 17:27:
> Just like some time ago in search_fs_uuid() the search_fs() function of
> search also needs to be caseless when comparing UUIDs, for some reason
> GRUB2 didn't find my UUID although I entered it as reported by blkid. To
> be on the safe side, just use strncasecmp. :) Patch against git master
> and ChangeLog attached. I await your feedback. :-)

Thanks, I tried it, but still didn't get any further with the following bug:

https://savannah.gnu.org/bugs/?26834 search for UUID fails with 
dedicated /boot filesystem on disk larger than what BIOS sees

Regards,

Arthur.

Re: [PATCH] Caseless UUID comparsion in search command

[Pavel Roskin]

On Tue, 2009-07-07 at 05:46 +0930, Arthur Marsh wrote:
> Daniel Mierswa wrote, on 06/07/09 17:27:
> > Just like some time ago in search_fs_uuid() the search_fs() function of
> > search also needs to be caseless when comparing UUIDs, for some reason
> > GRUB2 didn't find my UUID although I entered it as reported by blkid. To
> > be on the safe side, just use strncasecmp. :) Patch against git master
> > and ChangeLog attached. I await your feedback. :-)
> 
> Thanks, I tried it, but still didn't get any further with the following bug:
> 
> https://savannah.gnu.org/bugs/?26834 search for UUID fails with 
> dedicated /boot filesystem on disk larger than what BIOS sees

That's because ext3 UUID is lower case, so case sensitivity shouldn't be
an issue.

While trying to reproduce the issue, I found and fixed a memory
corruption bug affecting arguments of long options, but your case is not
affected.  You would only be affected it you use "--set=root" instead of
just "--set".

I could not reproduce the problem by setting up a separate partition,
and by instructing qemu to access part of the device.  I don't think
GRUB would fail to find a device by it's UUID if it can load the kernel
from it.  It's more like the UUID from grub.cfg doesn't match the one
GRUB sees.

Please show the output of "ls -l (hd0,1)" on the GRUB command line and
the output of "tune2fs -l /dev/hda1 |grep UUID" in Linux.

-- 
Regards,
Pavel Roskin

Re: [PATCH] Caseless UUID comparsion in search command

[Arthur Marsh]

Pavel Roskin wrote, on 2009-07-07 10:08:
> On Tue, 2009-07-07 at 05:46 +0930, Arthur Marsh wrote:
>> Daniel Mierswa wrote, on 06/07/09 17:27:
>>> Just like some time ago in search_fs_uuid() the search_fs() function of
>>> search also needs to be caseless when comparing UUIDs, for some reason
>>> GRUB2 didn't find my UUID although I entered it as reported by blkid. To
>>> be on the safe side, just use strncasecmp. :) Patch against git master
>>> and ChangeLog attached. I await your feedback. :-)
>> Thanks, I tried it, but still didn't get any further with the following bug:
>>
>> https://savannah.gnu.org/bugs/?26834 search for UUID fails with 
>> dedicated /boot filesystem on disk larger than what BIOS sees
> 
> That's because ext3 UUID is lower case, so case sensitivity shouldn't be
> an issue.
> 
> While trying to reproduce the issue, I found and fixed a memory
> corruption bug affecting arguments of long options, but your case is not
> affected.  You would only be affected it you use "--set=root" instead of
> just "--set".
> 
> I could not reproduce the problem by setting up a separate partition,
> and by instructing qemu to access part of the device.  I don't think
> GRUB would fail to find a device by it's UUID if it can load the kernel
> from it.  It's more like the UUID from grub.cfg doesn't match the one
> GRUB sees.
> 
> Please show the output of "ls -l (hd0,1)" on the GRUB command line and
> the output of "tune2fs -l /dev/hda1 |grep UUID" in Linux.
> 

using grub-emu at the moment. I'll try in real grub when I reboot.

Partition hd0,1: Filesystem type ext2, Last modification time 2009-07-07
  00:49:27 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea

tune2fs -l /dev/hda1 |grep UUID
Filesystem UUID:        bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea

Regards,

Arthur.

Re: [PATCH] Caseless UUID comparsion in search command

[Arthur Marsh]

> using grub-emu at the moment. I'll try in real grub when I reboot.
> 
> Partition hd0,1: Filesystem type ext2, Last modification time 2009-07-07
>  00:49:27 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea

Same result with real grub.

Re: [PATCH] Caseless UUID comparsion in search command

[Pavel Roskin]

On Tue, 2009-07-07 at 10:41 +0930, Arthur Marsh wrote:

> using grub-emu at the moment. I'll try in real grub when I reboot.

Could you please try booting Linux in grub-emu?  You can interrupt qemu
before the kernel tries to mount anything.  Or you can remove the
"linux" line.  What matters is whether the "search" command works.  That
would show if BIOS limitations play any role.

> Partition hd0,1: Filesystem type ext2, Last modification time 2009-07-07
>   00:49:27 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea
> 
> tune2fs -l /dev/hda1 |grep UUID
> Filesystem UUID:        bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea

That means that the search command indeed fails to find a partition that
GRUB sees.

Since you are getting "device not found" with the refactor patch, it
means that grub_device_iterate() doesn't set grub_errno.

If --set is given, the iteration would stop as soon as the matching
device is found.  Unfortunately, grub lists partitions backwards (we'll
need to look at that), so a problem with a later partition could confuse
GRUB.

Please run "ls -l" in GRUB to see if it finds any problems.  Also please
try running the "search" command manually on the command line.  Maybe
the config file has some weird symbol somewhere.  You can also search by
label, even though it's empty:

search -l ""

-- 
Regards,
Pavel Roskin

Re: [PATCH] Caseless UUID comparsion in search command

[Arthur Marsh]

Pavel Roskin wrote, on 07/07/09 11:28:
> On Tue, 2009-07-07 at 10:41 +0930, Arthur Marsh wrote:
> 
>> using grub-emu at the moment. I'll try in real grub when I reboot.
> 
> Could you please try booting Linux in grub-emu?  You can interrupt qemu
> before the kernel tries to mount anything.  Or you can remove the
> "linux" line.  What matters is whether the "search" command works.  That
> would show if BIOS limitations play any role.

I haven't used grub-emu to boot linux.

In grub-emu I get:

sh:grub> ls -l
Device hd0: Partition table
         Partition hd0,7: Filesystem type ext2, Last modification time 
2009-07-07
  03:21:45 Tuesday, UUID 96c96a61-8615-4715-86d0-09cb8c62638c
         Partition hd0,6: Filesystem type fat, UUID 7417-5aff
         Partition hd0,5: Unknown filesystem
         Partition hd0,1: Filesystem type ext2, Last modification time 
2009-07-07
  03:23:54 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea

sh:grub> search -l ""
Segmentation fault
victoria:/home/amarsh04#


> 
>> Partition hd0,1: Filesystem type ext2, Last modification time 2009-07-07
>>   00:49:27 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea
>>
>> tune2fs -l /dev/hda1 |grep UUID
>> Filesystem UUID:        bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea
> 
> That means that the search command indeed fails to find a partition that
> GRUB sees.
> 
> Since you are getting "device not found" with the refactor patch, it
> means that grub_device_iterate() doesn't set grub_errno.
> 
> If --set is given, the iteration would stop as soon as the matching
> device is found.  Unfortunately, grub lists partitions backwards (we'll
> need to look at that), so a problem with a later partition could confuse
> GRUB.
> 
> Please run "ls -l" in GRUB to see if it finds any problems.  Also please
> try running the "search" command manually on the command line.  Maybe
> the config file has some weird symbol somewhere.  You can also search by
> label, even though it's empty:
> 
> search -l ""

In real grub:

ls -l

hd0: Partition table
Partition hd0,1: Filesystem cannot be accessed
Device hd1: filesysetm cannot be accessed
Device hd2: filesystem cannot be accessed
Device fd0: Filesystem cannot be accessed
error: no such disk

search -l ""

hd1,5 hd1,3

The /boot partition is on (hd0,1)

Regards,

Arthur Marsh.

Re: [PATCH] Caseless UUID comparsion in search command

[Pavel Roskin]

On Tue, 2009-07-07 at 13:08 +0930, Arthur Marsh wrote:
> Pavel Roskin wrote, on 07/07/09 11:28:
> > On Tue, 2009-07-07 at 10:41 +0930, Arthur Marsh wrote:
> > 
> >> using grub-emu at the moment. I'll try in real grub when I reboot.
> > 
> > Could you please try booting Linux in grub-emu?  You can interrupt qemu
> > before the kernel tries to mount anything.  Or you can remove the
> > "linux" line.  What matters is whether the "search" command works.  That
> > would show if BIOS limitations play any role.
> 
> I haven't used grub-emu to boot linux.

Sorry, I was thinking about qemu when I wrote this.

> In grub-emu I get:
> 
> sh:grub> ls -l
> Device hd0: Partition table
>          Partition hd0,7: Filesystem type ext2, Last modification time 
> 2009-07-07
>   03:21:45 Tuesday, UUID 96c96a61-8615-4715-86d0-09cb8c62638c
>          Partition hd0,6: Filesystem type fat, UUID 7417-5aff
>          Partition hd0,5: Unknown filesystem
>          Partition hd0,1: Filesystem type ext2, Last modification time 
> 2009-07-07
>   03:23:54 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea
> 
> sh:grub> search -l ""
> Segmentation fault

This should be fixed in Subversion.  My mistake.  Please test it.  The
patch for unifying search won't help solve this problem.

> In real grub:
> 
> ls -l
> 
> hd0: Partition table
> Partition hd0,1: Filesystem cannot be accessed
> Device hd1: filesysetm cannot be accessed
> Device hd2: filesystem cannot be accessed
> Device fd0: Filesystem cannot be accessed
> error: no such disk

That means that grub_device_open() fails for all of them.  Something is
seriously wrong here.  Yet somehow the Linux kernel can be loaded.

One possibility is that some error condition happens when accessing
(hd0,1) and cannot be cleared.  Another possibility is a compiler bug.
Maybe we need more instances of NESTED_FUNC_ATTR.  What is the compile
version you are using to compile GRUB?

-- 
Regards,
Pavel Roskin

Re: [PATCH] Caseless UUID comparsion in search command

[Arthur Marsh]

Pavel Roskin wrote, on 2009-07-07 13:53:
> On Tue, 2009-07-07 at 13:08 +0930, Arthur Marsh wrote:
>> Pavel Roskin wrote, on 07/07/09 11:28:
>>> On Tue, 2009-07-07 at 10:41 +0930, Arthur Marsh wrote:
>>>
>>>> using grub-emu at the moment. I'll try in real grub when I reboot.
>>> Could you please try booting Linux in grub-emu?  You can interrupt qemu
>>> before the kernel tries to mount anything.  Or you can remove the
>>> "linux" line.  What matters is whether the "search" command works.  That
>>> would show if BIOS limitations play any role.
>> I haven't used grub-emu to boot linux.
> 
> Sorry, I was thinking about qemu when I wrote this.
> 
>> In grub-emu I get:
>>
>> sh:grub> ls -l
>> Device hd0: Partition table
>>          Partition hd0,7: Filesystem type ext2, Last modification time 
>> 2009-07-07
>>   03:21:45 Tuesday, UUID 96c96a61-8615-4715-86d0-09cb8c62638c
>>          Partition hd0,6: Filesystem type fat, UUID 7417-5aff
>>          Partition hd0,5: Unknown filesystem
>>          Partition hd0,1: Filesystem type ext2, Last modification time 
>> 2009-07-07
>>   03:23:54 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea
>>
>> sh:grub> search -l ""
>> Segmentation fault
> 
> This should be fixed in Subversion.  My mistake.  Please test it.  The
> patch for unifying search won't help solve this problem.
> 
>> In real grub:
>>
>> ls -l
>>
>> hd0: Partition table
>> Partition hd0,1: Filesystem cannot be accessed
>> Device hd1: filesysetm cannot be accessed
>> Device hd2: filesystem cannot be accessed
>> Device fd0: Filesystem cannot be accessed
>> error: no such disk
> 
> That means that grub_device_open() fails for all of them.  Something is
> seriously wrong here.  Yet somehow the Linux kernel can be loaded.

Yes, provided I remove the search line I can boot.

> 
> One possibility is that some error condition happens when accessing
> (hd0,1) and cannot be cleared.  Another possibility is a compiler bug.
> Maybe we need more instances of NESTED_FUNC_ATTR.  What is the compile
> version you are using to compile GRUB?
> 

gcc --version
gcc.real (Debian 4.3.3-13) 4.3.3

If needed, I could try a different version of gcc:

/usr/bin/gcc-3.4  /usr/bin/gcc-4.2  /usr/bin/gcc-4.4
/usr/bin/gcc-4.1  /usr/bin/gcc-4.3


Regards,

Arthur.

Re: [PATCH] Caseless UUID comparsion in search command

[Arthur Marsh]

Arthur Marsh wrote, on 07/07/09 14:10:
> Pavel Roskin wrote, on 2009-07-07 13:53:
>> On Tue, 2009-07-07 at 13:08 +0930, Arthur Marsh wrote:
>>> Pavel Roskin wrote, on 07/07/09 11:28:
>>>> On Tue, 2009-07-07 at 10:41 +0930, Arthur Marsh wrote:
>>>>
>>>>> using grub-emu at the moment. I'll try in real grub when I reboot.
>>>> Could you please try booting Linux in grub-emu?  You can interrupt qemu
>>>> before the kernel tries to mount anything.  Or you can remove the
>>>> "linux" line.  What matters is whether the "search" command works.  
>>>> That
>>>> would show if BIOS limitations play any role.
>>> I haven't used grub-emu to boot linux.
>>
>> Sorry, I was thinking about qemu when I wrote this.
>>
>>> In grub-emu I get:
>>>
>>> sh:grub> ls -l
>>> Device hd0: Partition table
>>>          Partition hd0,7: Filesystem type ext2, Last modification 
>>> time 2009-07-07
>>>   03:21:45 Tuesday, UUID 96c96a61-8615-4715-86d0-09cb8c62638c
>>>          Partition hd0,6: Filesystem type fat, UUID 7417-5aff
>>>          Partition hd0,5: Unknown filesystem
>>>          Partition hd0,1: Filesystem type ext2, Last modification 
>>> time 2009-07-07
>>>   03:23:54 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea

ok, after applying the "second take" search.c patch, I get:

  sh:grub> ls -l
Device hd0: Partition table
         Partition hd0,7: Filesystem type ext2, Last modification time 
2009-07-07
  06:24:14 Tuesday, UUID 96c96a61-8615-4715-86d0-09cb8c62638c
         Partition hd0,6: Filesystem type fat, UUID 7417-5aff
         Partition hd0,5: Unknown filesystem
         Partition hd0,1: Filesystem type ext2, Last modification time 
2009-07-07
  06:26:23 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea


>>>
>>> sh:grub> search -l ""
>>> Segmentation fault
>>
>> This should be fixed in Subversion.  My mistake.  Please test it.  The
>> patch for unifying search won't help solve this problem.

now I get:

sh:grub> search -l ""
  hd0,7 hd0,1
sh:grub>


>>
>>> In real grub:
>>>
>>> ls -l
>>>
>>> hd0: Partition table
>>> Partition hd0,1: Filesystem cannot be accessed
>>> Device hd1: filesysetm cannot be accessed
>>> Device hd2: filesystem cannot be accessed
>>> Device fd0: Filesystem cannot be accessed
>>> error: no such disk

With the second-take patch I get the same result.

With real grub and the first and second-take patch I get:

search -l ""

hd1,5 hd1,3

>>
>> That means that grub_device_open() fails for all of them.  Something is
>> seriously wrong here.  Yet somehow the Linux kernel can be loaded.
> 
> Yes, provided I remove the search line I can boot.
> 
>>
>> One possibility is that some error condition happens when accessing
>> (hd0,1) and cannot be cleared.  Another possibility is a compiler bug.
>> Maybe we need more instances of NESTED_FUNC_ATTR.  What is the compile
>> version you are using to compile GRUB?
>>
> 
> gcc --version
> gcc.real (Debian 4.3.3-13) 4.3.3
> 
> If needed, I could try a different version of gcc:
> 
> /usr/bin/gcc-3.4  /usr/bin/gcc-4.2  /usr/bin/gcc-4.4
> /usr/bin/gcc-4.1  /usr/bin/gcc-4.3
> 
> 
> Regards,
> 
> Arthur.

Arthur.

Re: [PATCH] Caseless UUID comparsion in search command

[Pavel Roskin]

On Tue, 2009-07-07 at 16:21 +0930, Arthur Marsh wrote:

> ok, after applying the "second take" search.c patch, I get:
> 
>   sh:grub> ls -l
> Device hd0: Partition table
>          Partition hd0,7: Filesystem type ext2, Last modification time 
> 2009-07-07
>   06:24:14 Tuesday, UUID 96c96a61-8615-4715-86d0-09cb8c62638c
>          Partition hd0,6: Filesystem type fat, UUID 7417-5aff
>          Partition hd0,5: Unknown filesystem
>          Partition hd0,1: Filesystem type ext2, Last modification time 
> 2009-07-07
>   06:26:23 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea

So it's something triggered by a condition in the real bootloader.

> >>> sh:grub> search -l ""
> >>> Segmentation fault
> >>
> >> This should be fixed in Subversion.  My mistake.  Please test it.  The
> >> patch for unifying search won't help solve this problem.
> 
> now I get:
> 
> sh:grub> search -l ""
>   hd0,7 hd0,1
> sh:grub>

Good.

> >>> In real grub:
> >>>
> >>> ls -l
> >>>
> >>> hd0: Partition table
> >>> Partition hd0,1: Filesystem cannot be accessed
> >>> Device hd1: filesysetm cannot be accessed
> >>> Device hd2: filesystem cannot be accessed
> >>> Device fd0: Filesystem cannot be accessed
> >>> error: no such disk
> 
> With the second-take patch I get the same result.

It looks like there are several issues are at play here.  There is an
issue with hd0,1, and then there is an issue with error handling.  I
think we should deal with the error handling first, as it will stand in
the way.

> With real grub and the first and second-take patch I get:
> 
> search -l ""
> 
> hd1,5 hd1,3

It looks like hd0 is ignored.

> > gcc --version
> > gcc.real (Debian 4.3.3-13) 4.3.3

I think this version has no issues with nested functions.

> > If needed, I could try a different version of gcc:
> > 
> > /usr/bin/gcc-3.4  /usr/bin/gcc-4.2  /usr/bin/gcc-4.4
> > /usr/bin/gcc-4.1  /usr/bin/gcc-4.3

No, I don't think anymore that gcc is the real culprit here.

-- 
Regards,
Pavel Roskin

Re: [PATCH] Caseless UUID comparsion in search command

[Arthur Marsh]

Pavel Roskin wrote, on 08/07/09 15:56:
> On Tue, 2009-07-07 at 16:21 +0930, Arthur Marsh wrote:
> 
>> ok, after applying the "second take" search.c patch, I get:
>>
>>   sh:grub> ls -l
>> Device hd0: Partition table
>>          Partition hd0,7: Filesystem type ext2, Last modification time 
>> 2009-07-07
>>   06:24:14 Tuesday, UUID 96c96a61-8615-4715-86d0-09cb8c62638c
>>          Partition hd0,6: Filesystem type fat, UUID 7417-5aff
>>          Partition hd0,5: Unknown filesystem
>>          Partition hd0,1: Filesystem type ext2, Last modification time 
>> 2009-07-07
>>   06:26:23 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea
> 
> So it's something triggered by a condition in the real bootloader.
> 
>>>>> sh:grub> search -l ""
>>>>> Segmentation fault
>>>> This should be fixed in Subversion.  My mistake.  Please test it.  The
>>>> patch for unifying search won't help solve this problem.
>> now I get:
>>
>> sh:grub> search -l ""
>>   hd0,7 hd0,1
>> sh:grub>
> 
> Good.
> 
>>>>> In real grub:
>>>>>
>>>>> ls -l
>>>>>
>>>>> hd0: Partition table
>>>>> Partition hd0,1: Filesystem cannot be accessed
>>>>> Device hd1: filesysetm cannot be accessed
>>>>> Device hd2: filesystem cannot be accessed
>>>>> Device fd0: Filesystem cannot be accessed
>>>>> error: no such disk
>> With the second-take patch I get the same result.
> 
> It looks like there are several issues are at play here.  There is an
> issue with hd0,1, and then there is an issue with error handling.  I
> think we should deal with the error handling first, as it will stand in
> the way.
> 
>> With real grub and the first and second-take patch I get:
>>
>> search -l ""
>>
>> hd1,5 hd1,3
> 
> It looks like hd0 is ignored.

Yes.

I still get that with 'search -l ""' on real grub, but now (SVN 2402?) 
grub-emu shows:

sh:grub> search -l  ""
  hd0,7 hd0,1 hd3,5 hd3,3

sh:grub> ls
(host) (hd0) (hd0,7) (hd0,6) (hd0,5) (hd0,1) (hd1) (hd1,5) (hd1,1) (hd3) 
(hd3,7)
  (hd3,6) (hd3,5) (hd3,3) (hd3,1)
sh:grub>

By way of explanation, here is what is on the machine:

# fdisk -l

Disk /dev/hda: 320 GB, 320070320640 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1        1044     8385898   83  Linux
/dev/hda2            1045       38913   304174710    f  Extended LBA
/dev/hda7            1045       34462   268422052   83  Linux
Warning: Partition 7 does not end on cylinder boundary.
/dev/hda6           34463       38639    33543720   1b  Hidd FAT32
Warning: Partition 6 does not end on cylinder boundary.
/dev/hda5           38640       38913     2192872   82  Linux swap
Warning: Partition 5 does not end on cylinder boundary.
Warning: Unable to open /dev/hdb read-write (Read-only file system). 
/dev/hdb has been opened read-only.
Error: /dev/hdb: unrecognised disk label

Disk /dev/hdc: 40 GB, 40057113600 bytes
255 heads, 63 sectors/track, 4870 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/hdc1   *           1        1785    14337981   1c  Hidd FAT32 LBA
/dev/hdc2            1786        4040    18105255    f  Extended LBA
/dev/hdc5            1786        3313    12265627   83  Linux
Warning: Partition 5 does not end on cylinder boundary.
/dev/hdc6            3314        3428      915705   82  Linux swap
Warning: Partition 6 does not end on cylinder boundary.
/dev/hdc7            3429        4040     4907857   1b  Hidd FAT32
Warning: Partition 7 does not end on cylinder boundary.
/dev/hdc3            4041        4870     6658942   83  Linux

Disk /dev/sda: 8 GB, 8134801920 bytes
255 heads, 63 sectors/track, 989 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         990     7952143   83  Linux
Warning: Partition 1 does not end on cylinder boundary.

Disk /dev/sdb: 4 GB, 4334722560 bytes
255 heads, 63 sectors/track, 527 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1         261     2096451    6  FAT16
/dev/sdb2             262         527     2128612    f  Extended LBA
/dev/sdb5             262         527     2128612    b  FAT32
Warning: Partition 5 does not end on cylinder boundary.
Error: /dev/md0: unrecognised disk label


Regards,

Arthur.