From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JArG4-00023e-He for mharc-grub-devel@gnu.org; Fri, 04 Jan 2008 13:27:04 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JArG3-00023D-6S for grub-devel@gnu.org; Fri, 04 Jan 2008 13:27:03 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JArG1-00022s-LA for grub-devel@gnu.org; Fri, 04 Jan 2008 13:27:01 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JArG1-00022p-Im for grub-devel@gnu.org; Fri, 04 Jan 2008 13:27:01 -0500 Received: from c60.cesmail.net ([216.154.195.49]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1JArG1-0002y7-ER for grub-devel@gnu.org; Fri, 04 Jan 2008 13:27:01 -0500 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 04 Jan 2008 13:26:59 -0500 Received: from [192.168.1.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id 006F0618FE1; Fri, 4 Jan 2008 13:26:59 -0500 (EST) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <20080104123224.GA6657@thorin> References: <1199090700.15525.17.camel@peder.flower> <1199140655.7332.15.camel@dv> <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> Content-Type: text/plain Date: Fri, 04 Jan 2008 13:26:59 -0500 Message-Id: <1199471219.17196.35.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 (2.12.2-2.fc8) Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Cc: Jan Nieuwenhuizen 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 18:27:03 -0000 On Fri, 2008-01-04 at 13:32 +0100, Robert Millan wrote: > On Thu, Jan 03, 2008 at 11:23:01AM -0500, Pavel Roskin wrote: > > >Why? Does the firmware impose this restriction, or is it GRUB itself that > > >gets confused? > > > > I wish I knew it. 0x7000 is not OK, 0x8000 is OK. Less granularity > > makes no sense since the value is aligned at the 0x1000 boundary. > > 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. In fact, the image doesn't even survive simple objcopy intact. "objcopy grubof.modules grubof.modules1" produces a file 208 bytes long. Moreover, "objdump -h grubof.modules" doesn't show any sections at all, whereas "objdump -p grubof.modules" shows the segments. It seems to me that grub-mkimage produces something that looks like and ELF file and the first glance, but is not a valid ELF file. I can reproduce this problem with linuxbios images on i386. 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 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. It's never unset by any successful operations. I think some filesystem module may be resetting grub_errno to 0. It's strange that I don't even see EACCESS in the code. 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. That's not to negate your findings, of course. -- Regards, Pavel Roskin