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