Re: `"prefix" is not set` error message in early GRUB startup

[Seth Goldberg]

Hi,

  Following up on this, I tried moving the calls to grub_machine_set_prefix() 
and grub_set_root_dev() before the call to grub_load_modules(), and while it 
does result in the prefix and root variables getting set earlier, it's still 
possible to have error messages emitted, depending on the module load order. 
If the driver for the device referenced by $prefix or $root is loaded before 
others that make use of these variables, then everything will work fine. 
However, if modules are loaded before the driver for the type of "disk" device 
referenced in $prefix and/or $root and those modules attempt to open a file 
using the values of $prefix or $root, an error message like "no such disk" 
will be displayed.  Ideally, it would be nice if "driver" modules had an 
identifying attribute that the dynamic linker could use to load them first, 
then load all other modules (the assumption being that "driver" modules 
wouldn't try to access anything using $prefix or $root explicitly).  However, 
as a workaround, the order in which the modules are listed on the mkconfig 
command line should provide a means to avoid these error messages, however 
there's a problem -- if gzio does exist on the tftp server and it's loaded, 
when we hit gzio during the grub_load_modules() iteration, a fatal error 
occurs (we should be able to detect this and just ignore the fact that the 
module as already been loaded).

 --S

Quoting Seth Goldberg, who wrote the following on Sat, 25 Dec 2010:

> Hi,
>
>  Recently, I've been seeing the error message in the subject line while 
> GRUB2 is starting.  I've tracked it down to code in normal.mod (specifically, 
> the code in GRUB_MOD_INIT(normal) that tries to grub_dl_load the gzio module. 
> Since normal.mod is loaded by the call to grub_load_modules() in main() and 
> that call is BEFORE the call to grub_machine_set_prefix(), the prefix is not 
> used to find gzio (another interesting thing to note is that even if gzio is 
> embedded in the core image, if it is present AFTER normal.mod, the loader 
> does not realize this and tries to load it from the prefix directory -- that 
> should probably be fixed also).  Another interesting thing to note is that 
> normal's init function, by virtue of calling grub_context_init(), calls 
> grub_env_export for both prefix and root (which has the side effect of 
> setting them to the empty string if they don't exist at the time).  This can 
> also cause subtle problems if other modules access root or prefix during the 
> course of grub_load_modules().
>
> My suggested fix is to move the calls to grub_machine_set_prefix() and 
> grub_set_root_dev before grub_load_modules().  A cursory examination of these 
> functions doesn't reveal any dependence on any loadable modules, but I'm not 
> 100% sure about that. Were these two functions put after grub_load_modules() 
> before they might require modules loaded there?
>
> --S
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel