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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
