On Thu, May 29, 2008 at 06:46:25PM +0800, Bean wrote: > > > > I've been thinking a bit more about this, and my impression is that it the > > approach is quite ad-hoc. For example, some similar problems that this > > solution wouldn't solve, but that a very similar solution would: > > > > a- normal.mod was built into grub.elf (perhaps because the firmware can > > load > > big files). Then the problem is finding grub.cfg instead of normal.mod. > > If the firmware support large image file, then it's no problem. For > image ~ 64K, we can include normal and some basic command. But for > image ~ 32K (like vista boot loader), it can only contain kernel and > one of the file system driver.
Yes. But then, how do you find grub.cfg? The grub.cfg that is generated by update-grub can't be part of grub.elf, and you need a way to find it. Your proposed hack would work for that, simply by replacing "normal.mod" with "grub.cfg". > > b- User has a disk liing around which happens to have a normal.mod from > > an earlier version of grub (let's assume different ABI). Turns out this > > disk is used for something else and can't be supressed. A solution could > > be to use UUIDs for the search, but that can't always work since we need > > a "smart" install process that can probe for them (unlike in the > > situation > > you described -- I can't imagine doing fancy stuff in bare-bones Vista). > > > > I think this is the most convenient way of installing grub2 in vista. > [...] It probably is; what I'm describing is another situation in which the most convenient way is almost like that but not quite. Then we would need another module for that, which is a mess. That's why I think a generic solution would be best, if possible. > > c- Search for normal.mod was ok, but then this particular port of grub > > can't > > accept the prefix variable from your module, because it already got this > > variable from the firmware (OFW does this). And the variable from > > firmware > > happens to be completely unusable. > > The module initialization code is run in grub_load_modules (), It's > before the platform code grub_machine_set_prefix (). If findroot has > find the prefix, it won't use the firmware value anymore. But it is run after grub_machine_init(), and it is permissible that grub_machine_init() already sets the prefix (ieee1275 does that). Maybe your proposed module should override this setting, then? > > I think a solution that would fit well here is to use memdisk to embed a > > grub.cfg. Then in each situation we could have a different grub.cfg script > > that finds appropiate prefix using the search command. > > memdisk is not so useful in such situation. grub.cfg need normal.mod > for its script engine. So we need to embed normal.mod. and at least > search.mod. Such image is well above 32K limit. That's unfortunate... do you think this approach could be extended/modified somehow to address the other situations? -- Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What good is a phone call… if you are unable to speak? (as seen on /.) _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
