Re: Testing on PowerMac G4

[Pavel Roskin]

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