From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JAtJv-0005v5-Rz for mharc-grub-devel@gnu.org; Fri, 04 Jan 2008 15:39:11 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JAtJu-0005uJ-Ft for grub-devel@gnu.org; Fri, 04 Jan 2008 15:39:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JAtJt-0005tx-Nz for grub-devel@gnu.org; Fri, 04 Jan 2008 15:39:10 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAtJt-0005tm-H2 for grub-devel@gnu.org; Fri, 04 Jan 2008 15:39:09 -0500 Received: from aybabtu.com ([69.60.117.155]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JAtJt-0001cB-Av for grub-devel@gnu.org; Fri, 04 Jan 2008 15:39:09 -0500 Received: from [192.168.10.6] (helo=thorin) by aybabtu.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JAtJl-0001aO-7I for grub-devel@gnu.org; Fri, 04 Jan 2008 21:39:01 +0100 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1JAtIO-0003E2-2R for grub-devel@gnu.org; Fri, 04 Jan 2008 21:37:36 +0100 Date: Fri, 4 Jan 2008 21:37:36 +0100 From: Robert Millan To: The development of GRUB 2 Message-ID: <20080104203736.GA9375@thorin> References: <20071231233451.GA6782@thorin> <20080102014604.mokv4nr54w48kcg0@webmail.spamcop.net> <20080102103218.GB4295@thorin> <20080103030917.jl75lsuhkc8gk4w8@webmail.spamcop.net> <20080103121112.GB6169@thorin> <20080103102846.mhnl7v6xw4ksk48k@webmail.spamcop.net> <20080103155734.GA25410@thorin> <20080103112301.a1rs2lyk0oc8wsws@webmail.spamcop.net> <20080104123224.GA6657@thorin> <1199471219.17196.35.camel@dv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1199471219.17196.35.camel@dv> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: Testing on PowerMac G4 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 20:39:10 -0000 On Fri, Jan 04, 2008 at 01:26:59PM -0500, Pavel Roskin wrote: > > > > AFAICT, it can only happen in three ways: > > > > 1- The firmware doesn't like GRUB image, and aborts with bogus errors before > > transferring control to GRUB. You can easily tell this appart by checking > > for early "Welcome to GRUB" message. > > I'm quite sure now that it's the case. That's how it looks on the > surface, I just was extra cautious before I had a chance to learn more > about OpenFirmware and the GRUB code. > > Not only there is no "Welcome to GRUB" message, but the screen is not > erased and remains black on white. "CLAIM failed" is followed by the > OpenFirmware prompt. There are no messages that the execution was > interrupted, which would appear in other failure cases. > > I tried to convert grub-mkimage output to the binary format, and found > that objcopy doesn't like it. If you want to confirm that it's grub-mkimage's fault, you can try booting kernel.elf directly. In theory it should give you a rescue prompt. > In fact, the image doesn't even survive > simple objcopy intact. "objcopy grubof.modules grubof.modules1" > produces a file 208 bytes long. What is grubof.modules ? I never heard of it. > We just cannot expect OpenFirmware to process invalid ELF files. It can > be looking for the section headers and finding non-zero data is the gap > is not wide enough. It can be just anything. > > A quick look into util/elf/grub-mkimage.c finds "Don't bother preserving > the section headers". I don't even know if the problem is specifically > with the section headers or with something else. Perhaps > util/elf/grub-mkimage.c should be rewritten as a linker script, or maybe > it should use the BFD library that comes with binutils. I'm optimistic > about the linker script, since all we need is essentially linking. There's another [1] outstanding problem with elf/grub-mkimage.c: http://lists.gnu.org/archive/html/grub-devel/2007-10/msg00056.html I think what you propose is a good idea. It sounds odd that we have to reimplement ELF handling when another GNU project already has. But I don't know how the GRUB maintainers think about it. [1] or, perhaps, it's the same problem? > > > There is a possibility that grub_errno remains set to some error. > > > > Well, that's easy to tell appart with some printfs. > > What I see is the last invocation of grub_ofdisk_open() has grub_errno > set to 13 (EACCESS) throughout the code. Wait, that would be EACCES in Linux errno codes. In GRUB, grub_errno 13 means GRUB_ERR_UNKNOWN_DEVICE (at the time of writing; there isn't a stable ABI for this afaik). If grub_errno was set you should've seen an error message somewhere. It seems there's something wrong in our error handling. :-/ > A quote from the glibc manual: > > These functions do not change `errno' when they succeed; thus, the value > of `errno' after a successful call is not necessarily zero, and you > should not use `errno' to determine _whether_ a call failed. The proper > way to do that is documented for each function. _If_ the call failed, > you can examine `errno'. > > grub_ofdisk_open() is in direct violation of that rule. The execution > can reach the "fail:" label without having failed anywhere, yet the code > returns grub_errno unconditionally. Yeah, would be nice if functions had their behaviour more similar to Glibc equivalents. I'm not sure how much of a "policy" is this in GRUB, though. > That's not to negate your findings, of course. I would really check the GRUB_IEEE1275_FLAG_NO_PARTITION_0 issue. It was just a guess, but it smells really badly :-) -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.)