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 <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call, if you are unable to speak? (as seen on /.) _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
