From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1D0m0b-0004c6-5K for mharc-grub-devel@gnu.org; Mon, 14 Feb 2005 14:35:49 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D0m0Y-0004Zc-Dc for grub-devel@gnu.org; Mon, 14 Feb 2005 14:35:46 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D0lv2-0002Zt-98 for grub-devel@gnu.org; Mon, 14 Feb 2005 14:30:07 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D0lux-0002Rj-7f for grub-devel@gnu.org; Mon, 14 Feb 2005 14:29:59 -0500 Received: from [145.74.66.11] (helo=mail-cn.han.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D0lSw-00018D-LF for grub-devel@gnu.org; Mon, 14 Feb 2005 14:01:03 -0500 Received: from vscan-cn.han.nl (venus.han.nl [145.74.65.6]) by mail-cn.han.nl (Postfix) with ESMTP id 225C6916B for ; Mon, 14 Feb 2005 20:01:02 +0100 (CET) Received: from mail-cn.han.nl ([145.74.66.11]) by vscan-cn.han.nl (venus.han.nl [145.74.65.6]) (amavisd-new, port 10024) with ESMTP id 15044-06 for ; Mon, 14 Feb 2005 20:01:00 +0100 (CET) Received: from mail1.han.nl (mail1.han.nl [145.74.103.11]) by mail-cn.han.nl (Postfix) with ESMTP id B0C649179 for ; Mon, 14 Feb 2005 20:01:00 +0100 (CET) Received: from marco.marco-g.com (mgerards.xs4all.nl [82.92.27.129]) by mail1.han.nl (Postfix) with ESMTP id 6A8D3C045 for ; Mon, 14 Feb 2005 20:01:00 +0100 (CET) Mail-Copies-To: metgerards@student.han.nl To: The development of GRUB 2 References: <20050213165452.GA4503@miracle> <87mzu8tiid.fsf@marco.marco-g.com> <5c9273e9e7f6eba181c088feaedb314c@penguinppc.org> From: Marco Gerards Date: Mon, 14 Feb 2005 19:01:14 +0000 In-Reply-To: <5c9273e9e7f6eba181c088feaedb314c@penguinppc.org> (Hollis Blanchard's message of "Sun, 13 Feb 2005 13:52:48 -0600") Message-ID: <87mzu7arut.fsf@marco.marco-g.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new (2.2.0) at vscan-cn.han.nl Subject: Re: [patch] set prefix on PPC 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: Mon, 14 Feb 2005 19:35:47 -0000 Hollis Blanchard writes: > On Feb 13, 2005, at 12:35 PM, Marco Gerards wrote: > >> Hollis Blanchard writes: >> >>> This code sets the GRUB "prefix" environment variable from the OF >>> /chosen/bootpath property. It must therefore translate between the two >>> syntaxes. >> >> Personally I don't like setting prefix to the path grubof was loaded >> from. Mainly because of the way how things work on the macintosh. It >> has a special HFS[+] boot partition (at least my installation, but I >> think this is the common practice). >> >> I don't like installing all modules and the configuration file on this >> partition. There were some problems with writing to this partition >> IIRC and it is not comfortable to use. It should not be touched by a >> user, I just can't remember why. I will look that up. > > Please let me know if you find any actual data. I have heard the ybin > author rant about this for years (see > http://lists.penguinppc.org/yaboot-users/2002/yaboot-users-200210/ > msg00008.html as an example), but he doesn't like to substantiate his > claims. this is interesting. We could put a warning in the manual (when writing it), but I most certainly don't want to force people to use some kind of partition. > I believe there were two problems with keeping /boot on an HFS > partition: > 1) The Linux HFS driver wasn't overly reliable. That's unfortunate if > you're writing a kernel there, or editing grub.cfg. For that reason, > /boot is typically kept as a Linux-native filesystem, and to install a > kernel ybin invokes hfsutils to do the copying to the "bootstrap" > partition. (Note the similarity in names "boot" and "bootstrap" causes > confusion.) Yeah, ok. This is something we should not worry about at the moment. If the HFS filesystem is broken, which I doubt, we could either fix it or install GRUB there using a similar script. > 2) HFS has a concept called "blessed"; basically the firmware can > automatically find and boot blessed executables without needing to > specify a file name or even partition. Some versions of Mac OS > allegedly will unbless a non-Mac OS blessed file. For that reason, > ybin prefers the HFS "bootstrap" partition be of a type that Mac OS > will not mount (and so will not alter). How is the file blessed and why does that make it a problem to keep /boot on a HFS partition? > However, please do not mistake "this is how ybin does it" for "this is > the only way to do it". I have never seen these problems (though I > personally ran an HFS /boot partition that Mac OS mounted), and I have > never seen data as to what exact software versions or scenarios cause > a problem. The user in the URL above claims no problems either, and I > haven't heard of other users with these problems. No, of course not. But I usually take warnings seriously. And yaboot is full of those. :) >> What I would prefer is a way to encode the prefix into the grubof >> binary. The only disadvantage is that it might be hard to detect this >> install time. > > If possible, placing grub.cfg next to grubof will be the easiest > solution. That way, no matter how or where you boot GRUB (even from > rescue CD or whatever), you will always know what grub.cfg it will > load. Right. >> What I would prefer is this: >> >> 1) Set prefix to whatever was set in the binary. > > This would involve more post-compilation ELF manipulation. To > accomplish that, if we do decide to go that route, I think it would be > worth converting the existing module segment into a more > general-purpose segment, containing all the added arguments. Ok. If we use your patch, this is not that important, I guess. If it works right that is. > Remember, right now we load modules at a fixed address. At runtime, > GRUB finds at that address: > 1. the size of the modules in memory > 2. the module binaries > > We can change this to be more general-purpose, e.g. a chain or > "parameter" structures that could contain the module binaries, the > size of modules, the prefix, etc. This might be nice someday. >> 2) If nothing was set, use `bootpath'. > > So it's not such a bad idea after all huh? :) :) >> 3) Read the arguments and if a prefix was passed to GRUB, use it to >> override the prefix. >> >> For #3 I wrote a patch, but I forgot to send it to grub-devel... It's >> included with this email. As far as I am concerned #1 is what is >> really important for us. >> >> 2005-02-13 Marco Gerards >> >> * kern/powerpc/ieee1275/init.c (grub_machine_init): Initialize the >> prefix env variable with the bootargs when it has a valid value. > > I don't like that this assumes bootargs only contains the prefix. For > example, if we ever get our fancy debugging support, it would be very > nice to boot grub with "debug=all" as an argument. I don't want to add a fancy parser yet. At the moment we just use a single argument. If more will be used, this code has to be changed. >> * loader/powerpc/ieee1275/linux.c (grub_rescue_cmd_linux): Don't >> initialize `init_addr' yet, set it to 0 instead. > > Confused... how is this related to bootargs and prefix? It is required to make GNU/Linux boot here, just like the bootargs stuff. ;) It is separated with a blank line to make clear they do not serve the same purpose. Thanks, Marco