Re: [PATCH] Scan root device dynamically at startup

[Robert Millan <rmh@aybabtu.com>]

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 /.)