From: Pavel Roskin <proski@gnu.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Caseless UUID comparsion in search command
Date: Wed, 08 Jul 2009 02:26:05 -0400 [thread overview]
Message-ID: <1247034365.2895.16.camel@ct> (raw)
In-Reply-To: <8s7bi6-vqf.ln1@ppp121-45-136-118.lns11.adl6.internode.on.net>
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
next prev parent reply other threads:[~2009-07-08 6:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-06 7:57 [PATCH] Caseless UUID comparsion in search command Daniel Mierswa
2009-07-06 20:14 ` Pavel Roskin
2009-07-06 20:16 ` Arthur Marsh
2009-07-07 0:38 ` Pavel Roskin
2009-07-07 1:11 ` Arthur Marsh
2009-07-07 1:43 ` Arthur Marsh
2009-07-07 1:58 ` Pavel Roskin
2009-07-07 3:38 ` Arthur Marsh
2009-07-07 4:23 ` Pavel Roskin
2009-07-07 4:40 ` Arthur Marsh
2009-07-07 6:51 ` Arthur Marsh
2009-07-08 6:26 ` Pavel Roskin [this message]
2009-07-08 8:26 ` Arthur Marsh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1247034365.2895.16.camel@ct \
--to=proski@gnu.org \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.