[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] set prefix on PPC
Re: [patch] set prefix on PPC
Mon, 14 Feb 2005 19:01:14 +0000
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
Hollis Blanchard <address@hidden> writes:
> On Feb 13, 2005, at 12:35 PM, Marco Gerards wrote:
>> Hollis Blanchard <address@hidden> writes:
>>> This code sets the GRUB "prefix" environment variable from the OF
>>> /chosen/bootpath property. It must therefore translate between the two
>> 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
> msg00008.html as an example), but he doesn't like to substantiate his
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
> 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
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
>> 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 <address@hidden>
>> * 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
It is separated with a blank line to make clear they do not serve the
Re: [patch] set prefix on PPC, Marco Gerards, 2005/02/21
- [patch] set prefix on PPC, Hollis Blanchard, 2005/02/13
- Re: [patch] set prefix on PPC, Marco Gerards, 2005/02/13
- Re: [patch] set prefix on PPC, Hollis Blanchard, 2005/02/13
- Re: [patch] set prefix on PPC,
Marco Gerards <=
- Re: [patch] set prefix on PPC, Hollis Blanchard, 2005/02/15
- Re: [patch] set prefix on PPC, Marco Gerards, 2005/02/15
- Re: [patch] set prefix on PPC, Hollis Blanchard, 2005/02/19
- Re: [patch] set prefix on PPC, Marco Gerards, 2005/02/20
- Re: [patch] set prefix on PPC, Hollis Blanchard, 2005/02/24