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