From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1EcctP-0006Ux-JM for mharc-grub-devel@gnu.org; Thu, 17 Nov 2005 01:05:07 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EcctM-0006Uq-TE for grub-devel@gnu.org; Thu, 17 Nov 2005 01:05:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EcctL-0006Ud-QU for grub-devel@gnu.org; Thu, 17 Nov 2005 01:05:04 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EcctL-0006Ua-Mo for grub-devel@gnu.org; Thu, 17 Nov 2005 01:05:03 -0500 Received: from [207.69.195.64] (helo=pop-knobcone.atl.sa.earthlink.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EcctL-00078K-Hm for grub-devel@gnu.org; Thu, 17 Nov 2005 01:05:03 -0500 Received: from user-0vvde2g.cable.mindspring.com ([63.246.184.80] helo=[192.168.0.4]) by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EcctK-0001mr-00 for grub-devel@gnu.org; Thu, 17 Nov 2005 01:05:02 -0500 From: Hollis Blanchard To: The development of GRUB 2 In-Reply-To: <20051117041735.GD3883@panix.com> References: <20051117041735.GD3883@panix.com> Content-Type: text/plain Date: Thu, 17 Nov 2005 00:05:00 -0600 Message-Id: <1132207501.2541.26.camel@silence> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit Subject: Re: grub-install on powermac newworld X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2005 06:05:05 -0000 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