grub-install on powermac newworld

grub-install on powermac newworld

[Mike Small]

I'd meant to try the grub-install script for powerpc a long time ago,
when Hollis sent out the patch in October, but got distracted.  Now
that I have tried it, a couple of comments:

1. The path to ofpathname is hard-coded in the script as /usr/sbin.
For me running on debian that doesn't seem right.  Since it's not
currently part of a package, I'd probably end up putting it in
/usr/local/sbin instead.  Maybe its presence and location should be
detected by configure?  Also, there's a script named ofpath that comes
with yaboot that would be present in most distributions which I
suspect could be detected and used for the same purpose if ofpathname
weren't present, if that's something you'd want to do.

2. The script seems to assume that /boot/grub/ will be where my boot
partition is mounted.  This was mentioned in the original mail, and I
could set things up this way, but in my opinion it would be more
natural to be able to specify the install directory exactly without
mandating any particular directory structure.  eg if I enter
  $ grub-install --root-directory=/mnt 
...(which is how I ran it, forgetting that part of the email) then
grub and its modules would go directly into /mnt and not into a
/mnt/boot/grub.

I didn't really exercise the nvsetenv part of the script since I've
had problems setting the boot device on this machine before (466
Powermac G4 - it seems to want to add ,\\:tbxi to whatever
boot-device string I set) and, since I didn't follow the directory
structure the script was expecting, it stopped before trying to set the
env variables ("/mnt/boot/grub is not a mount point!").  Let me know
if it would be helpful to test out that part and I'll give it a try
with my boot partion mounted at /boot/grub.

After I moved the files from /mnt/boot/grub to the root of my boot
partition (which is hfs) and rebooted, grub seemed to work okay (more
than okay really, I love that you can cat files from the bootloader -
neat stuff) until I typed in an initrd command.  Then I got the error
message: "Can not claim memory."  This was with a backported 2.6.12
kernel from a debian developer's site (Sven Luther) but the same thing
happened with the standard Sarge 2.6.8 kernel.  The kernel was 4641711
bytes and the initrd image was 4820992 bytes.

Is grub/ppc at the point where it makes sense to be testing initrd
yet?  I was about to reboot with an extra debugging message to try to
get more information, thinking this might have something to do with
the values of these variables in grub_rescue_cmd_initrd...

  addr = linux_addr + linux_size;
  size = grub_file_size (file);

... but I don't really know how grub_claimmap is supposed to work here
or what exactly to look for or report.

-- 
Mike Small
smallm@panix.com

Re: grub-install on powermac newworld

[Hollis Blanchard]

On Wed, 2005-11-16 at 23:17 -0500, Mike Small wrote:
> I'd meant to try the grub-install script for powerpc a long time ago,
> when Hollis sent out the patch in October, but got distracted.  Now
> that I have tried it, a couple of comments:

Thanks for your report!

> 1. The path to ofpathname is hard-coded in the script as /usr/sbin.
> For me running on debian that doesn't seem right.  Since it's not
> currently part of a package, I'd probably end up putting it in
> /usr/local/sbin instead.  Maybe its presence and location should be
> detected by configure?

Perhaps. I know people were thinking about getting ofpathname into
Debian proper, but I suspect I need to poke some people about that.

> Also, there's a script named ofpath that comes
> with yaboot that would be present in most distributions which I
> suspect could be detected and used for the same purpose if ofpathname
> weren't present, if that's something you'd want to do.

That would be ok, although I haven't played with it much. (Also I don't
believe it makes any sense to require the yaboot package in order to
install grub2.)

> 2. The script seems to assume that /boot/grub/ will be where my boot
> partition is mounted.  This was mentioned in the original mail, and I
> could set things up this way, but in my opinion it would be more
> natural to be able to specify the install directory exactly without
> mandating any particular directory structure.  eg if I enter
>   $ grub-install --root-directory=/mnt 
> ...(which is how I ran it, forgetting that part of the email) then
> grub and its modules would go directly into /mnt and not into a
> /mnt/boot/grub.

What made you expect --root-directory was a valid option? Other packages
use that option? Which?

We could add an option like that, but I'm more expecting grub2 to be
installed by distributions, and the distributions will
arrange /boot/grub accordingly.

Of course, this option would be useful in the event of booting from a
rescue CD, for example. I agree, it should be added.

> I didn't really exercise the nvsetenv part of the script since I've
> had problems setting the boot device on this machine before (466
> Powermac G4 - it seems to want to add ,\\:tbxi to whatever
> boot-device string I set)

Are you sure it's not ybin trying to do that? I would be very surprised
if nvsetenv or OF itself do.

> and, since I didn't follow the directory
> structure the script was expecting, it stopped before trying to set the
> env variables ("/mnt/boot/grub is not a mount point!").  Let me know
> if it would be helpful to test out that part and I'll give it a try
> with my boot partion mounted at /boot/grub.
> 
> After I moved the files from /mnt/boot/grub to the root of my boot
> partition (which is hfs) and rebooted, grub seemed to work okay (more
> than okay really, I love that you can cat files from the bootloader -
> neat stuff) until I typed in an initrd command.  Then I got the error
> message: "Can not claim memory."  This was with a backported 2.6.12
> kernel from a debian developer's site (Sven Luther) but the same thing
> happened with the standard Sarge 2.6.8 kernel.  The kernel was 4641711
> bytes and the initrd image was 4820992 bytes.
> 
> Is grub/ppc at the point where it makes sense to be testing initrd
> yet?

GRUB for PPC certainly is ready to load initrds. More debug output would
be useful here.

> I was about to reboot with an extra debugging message to try to
> get more information, thinking this might have something to do with
> the values of these variables in grub_rescue_cmd_initrd...
> 
>   addr = linux_addr + linux_size;
>   size = grub_file_size (file);
> 
> ... but I don't really know how grub_claimmap is supposed to work here
> or what exactly to look for or report.

Those are indeed the relevant lines.

grub_claimmap is a call to firmware to request access to a particular
area of memory. Trying to access memory without it could result in
scribbling over memory somebody else (e.g. OF itself) is using, or could
result in a page fault because it wasn't mapped.

Two related notes: I believe Marco mentioned that we should keep
attempting to find a space for the initrd. We do this already for the
kernel (notice the for loop around the other grub_claimmap call), but
not yet for initrd.

Second, the grub_dprintf calls you see are to enable dynamic debugging
output. In this case, if you "set debug=loader" at the "grub>" prompt,
you will see all those messages. In this case, they don't help you,
because the initrd debug message comes after grub_claimmap(). I would
greatly appreciate a patch that puts "attempting to claim" messages
before both calls to grub_claimmap, and loops over the initrd
grub_claimmap() call.

I consider the grub_dprintf calls to be critical for remote debugging as
more users begin testing GRUB2, and will happily add debug messages that
helps you solve this problem.

Thanks!

-Hollis

Re: grub-install on powermac newworld

[Yoshinori K. Okuji]

On Thursday 17 November 2005 07:05 am, Hollis Blanchard wrote:
> > 1. The path to ofpathname is hard-coded in the script as /usr/sbin.
> > For me running on debian that doesn't seem right.  Since it's not
> > currently part of a package, I'd probably end up putting it in
> > /usr/local/sbin instead.  Maybe its presence and location should be
> > detected by configure?
>
> Perhaps. I know people were thinking about getting ofpathname into
> Debian proper, but I suspect I need to poke some people about that.

Mike is right. We should add --with-ofpathname and reasonable detection code 
to configure. 

> What made you expect --root-directory was a valid option? Other packages
> use that option? Which?

Please look at grub-install for PC. We should keep grub-install as compatible 
as possible among various architectures.

Okuji

Re: grub-install on powermac newworld

[Mike Small]

[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]

On Thu, Nov 17, 2005 at 12:05:00AM -0600, Hollis Blanchard wrote:
...
> > I didn't really exercise the nvsetenv part of the script since I've
> > had problems setting the boot device on this machine before (466
> > Powermac G4 - it seems to want to add ,\\:tbxi to whatever
> > boot-device string I set)
> 
> Are you sure it's not ybin trying to do that? I would be very surprised
> if nvsetenv or OF itself do.

I was confused here.  What I thought was the appended string was
hd:,\\:tbxi and it was only the next column over in the openfirmware
printenv output, showing the factory defaults.  I was fooled because
the long device string pushed the columns out of alignment.  Sorry
about that.

I tried testing the nvsetenv part of grub-install and it almost
worked.  There's a problem with the regex that pulls off the partition
number from a device file name.  If you have more than one digit in
your partition (mine was at /dev/hda11) it only grabs the last one
because of greedy matching on .*.  I included a fix for this in the
attached patch.

> > After I moved the files from /mnt/boot/grub to the root of my boot
> > partition (which is hfs) and rebooted, grub seemed to work okay (more
> > than okay really, I love that you can cat files from the bootloader -
> > neat stuff) until I typed in an initrd command.  Then I got the error
> > message: "Can not claim memory."  This was with a backported 2.6.12
> > kernel from a debian developer's site (Sven Luther) but the same thing
> > happened with the standard Sarge 2.6.8 kernel.  The kernel was 4641711
> > bytes and the initrd image was 4820992 bytes.
...

> grub_claimmap is a call to firmware to request access to a particular
> area of memory. Trying to access memory without it could result in
> scribbling over memory somebody else (e.g. OF itself) is using, or could
> result in a page fault because it wasn't mapped.
> 
> Two related notes: I believe Marco mentioned that we should keep
> attempting to find a space for the initrd. We do this already for the
> kernel (notice the for loop around the other grub_claimmap call), but
> not yet for initrd.

This worked for me, and I've enclosed a patch with the a similar loop
to the one used for the linux command.  It also has debugging messages
before the grub_claimmap calls.  

I'm wondering though, does it matter very much how grub grabs memory?
Once the operating system takes over it takes all of memory and
whatever grub allocated doesn't matter anymore.  Is that correct?  The
reason I ask is that I tried making that loop retry the claim at every
4 bytes instead of at every megabyte and found it settled on an
address only four bytes higher than the one it failed on.  So maybe
it's possible to be more precise than the code in this patch is.

My guess would be that open firmware allocates with a resolution of 8
bytes, at least on my machine.  In that second test, the address that
the grub_claimmap failed on was 1b99F84 and the one it succeeded on
was 1b99F88.  1b99F84 was the exact end of the space allocated by the
linux command (at 1400000, size 799f84), so if o.f. grabbed in 8 bytes
increments it would have had up to 1b99F88, causing the failure.
Plausible?

-- 
Mike Small
smallm@panix.com

[-- Attachment #2: initrdclaim.patch --]
[-- Type: text/plain, Size: 2652 bytes --]


#
# Patch managed by http://www.holgerschurig.de/patcher.html
#

--- grub2/ChangeLog~initrdclaim
+++ grub2/ChangeLog
@@ -1,3 +1,15 @@
+2005-11-21  Mike Small  <smallm@panix.com>
+
+	* util/powerpc/ieee1275/grub-install.in (grubdir): Fixed partition
+	number regex so multidigit numbers are recognized correctly.
+
+2005-11-20  Mike Small  <smallm@panix.com>
+
+	* loader/powerpc/ieee1275/linux.c (grub_rescue_cmd_linux): Add a
+	debugging message before attempting to claim memory.
+	(grub_rescue_cmd_initrd): A new claim debugging message and try
+	multiple addresses in case of failure.
+
 2005-11-18  Timothy Baldwin  <T.E.Baldwin99@members.leeds.ac.uk>
 
 	* genmk.rb: Fixed list rules moved to Makefile.in.  Recognise
--- grub2/loader/powerpc/ieee1275/linux.c~initrdclaim
+++ grub2/loader/powerpc/ieee1275/linux.c
@@ -173,6 +173,8 @@
      try some other addresses just like yaboot does.  */
   for (linux_addr = entry; linux_addr < entry + 200 * 0x100000; linux_addr += 0x100000)
     {
+      grub_dprintf ("loader", "Attempting to claim at 0x%x, size 0x%x.\n", 
+		    linux_addr, linux_size);
       found_addr = grub_claimmap (linux_addr, linux_size);
       if (found_addr != -1)
 	break;
@@ -261,7 +263,9 @@
 {
   grub_file_t file = 0;
   grub_ssize_t size;
+  grub_addr_t first_addr;
   grub_addr_t addr;
+  int found_addr = 0;
 
   if (argc == 0)
     {
@@ -279,10 +283,21 @@
   if (! file)
     goto fail;
 
-  addr = linux_addr + linux_size;
+  first_addr = linux_addr + linux_size;
   size = grub_file_size (file);
 
-  if (grub_claimmap (addr, size) == -1)
+  /* Attempt to claim at a series of addresses until successful in
+     the same way that grub_rescue_cmd_linux does.  */
+  for (addr = first_addr; addr < first_addr + 200 * 0x100000; addr += 0x100000) 
+    {
+      grub_dprintf ("loader", "Attempting to claim at 0x%x, size 0x%x.\n", 
+		    addr, size);
+      found_addr = grub_claimmap (addr, size);
+      if (found_addr != -1)
+	break;
+    }
+
+  if (found_addr == -1)
     {
       grub_error (GRUB_ERR_OUT_OF_MEMORY, "Can not claim memory");
       goto fail;
--- grub2/util/powerpc/ieee1275/grub-install.in~initrdclaim
+++ grub2/util/powerpc/ieee1275/grub-install.in
@@ -171,7 +171,7 @@
 
     # Get the Open Firmware device tree path translation.
     dev=`echo $install_device | sed -e 's/\/dev\///' -e 's/[0-9]\+//'`
-    partno=`echo $install_device | sed -e 's/.*\([0-9]\+\)$/\1/'`
+    partno=`echo $install_device | sed -e 's/.*[^0-9]\([0-9]\+\)$/\1/'`
     ofpath=`$ofpathname $dev` || {
 	echo "Couldn't find Open Firmware device tree path for $dev."
 	echo "You will have to set boot-device manually."

Re: grub-install --root-directory

[Hollis Blanchard]

On Nov 16, 2005, at 10:17 PM, Mike Small wrote:
>
> 2. The script seems to assume that /boot/grub/ will be where my boot
> partition is mounted.  This was mentioned in the original mail, and I
> could set things up this way, but in my opinion it would be more
> natural to be able to specify the install directory exactly without
> mandating any particular directory structure.  eg if I enter
>   $ grub-install --root-directory=/mnt
> ...(which is how I ran it, forgetting that part of the email) then
> grub and its modules would go directly into /mnt and not into a
> /mnt/boot/grub.

Upon further inspection, this part of grub-install is identical to the 
x86 grub-install behavior. On both architectures,
	grub-install --root-directory /foo
will install *.mod, *.lst, and the output of grub-mkimage into 
/foo/boot/grub.

I'm open to allowing an override for this, but that's not a PPC-only 
question. I guess a user uses --root-directory when they have booted 
from a CD/floppy and wish to install GRUB onto their hard disk. In that 
case, even if the hard disk's root partition has been manually mounted 
on /mnt, there is no guarantee that the firmware-accessible filesystem 
has also been mounted on /mnt/boot/grub.

Given that, Okuji, what do you think about a --grub-directory switch 
instead of (or in addition to) --root-directory?

-Hollis

Re: grub-install on powermac newworld

[Hollis Blanchard]

On Nov 21, 2005, at 12:00 AM, Mike Small wrote:
>
> This worked for me, and I've enclosed a patch with the a similar loop
> to the one used for the linux command.  It also has debugging messages
> before the grub_claimmap calls.

Looks good, thanks! I've just committed this.

> I'm wondering though, does it matter very much how grub grabs memory?
> Once the operating system takes over it takes all of memory and
> whatever grub allocated doesn't matter anymore.  Is that correct?

Correct.

> The
> reason I ask is that I tried making that loop retry the claim at every
> 4 bytes instead of at every megabyte and found it settled on an
> address only four bytes higher than the one it failed on.  So maybe
> it's possible to be more precise than the code in this patch is.
>
> My guess would be that open firmware allocates with a resolution of 8
> bytes, at least on my machine.  In that second test, the address that
> the grub_claimmap failed on was 1b99F84 and the one it succeeded on
> was 1b99F88.  1b99F84 was the exact end of the space allocated by the
> linux command (at 1400000, size 799f84), so if o.f. grabbed in 8 bytes
> increments it would have had up to 1b99F88, causing the failure.
> Plausible?

Hmm, yeah, that's a good theory. On the one hand, it would be easy to 
align the initrd address up (to say a 4KB boundary), and that would 
avoid this problem. On the other hand, the loop solves the more general 
case, and I guess that solves this particular problem too.

The increment (1MB) does seem a bit excessive, but on the other hand we 
could have really run into an area reserved by firmware itself, which 
is likely to be several MB at least. After initially being tempted to 
muck with it, I'm now inclined to leave the code as-is (until the next 
person reports a problem ;).

Thanks!

-Hollis

Re: grub-install --root-directory

[Yoshinori K. Okuji]

On Wednesday 23 November 2005 04:55 am, Hollis Blanchard wrote:
> Upon further inspection, this part of grub-install is identical to the
> x86 grub-install behavior. On both architectures,
> 	grub-install --root-directory /foo
> will install *.mod, *.lst, and the output of grub-mkimage into
> /foo/boot/grub.
>
> I'm open to allowing an override for this, but that's not a PPC-only
> question. I guess a user uses --root-directory when they have booted
> from a CD/floppy and wish to install GRUB onto their hard disk. In that
> case, even if the hard disk's root partition has been manually mounted
> on /mnt, there is no guarantee that the firmware-accessible filesystem
> has also been mounted on /mnt/boot/grub.
>
> Given that, Okuji, what do you think about a --grub-directory switch
> instead of (or in addition to) --root-directory?

Not bad.

Okuji