Re: Testing on PowerMac G4

[Robert Millan]

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 /.)