grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Caseless UUID comparsion in search command


From: Pavel Roskin
Subject: Re: [PATCH] Caseless UUID comparsion in search command
Date: Wed, 08 Jul 2009 02:26:05 -0400

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




reply via email to

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