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

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

[Seth Goldberg]

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

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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

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

[Seth Goldberg]

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

   Sorry -- this is wrong.  If gzio is before normal on the mkimage command 
line, grub_dl_load()'s call of grub_dl_get() will return it and it will NOT be 
retrieved from the $prefix dir.

  --S

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]


>  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.
The dependence is subtle: set_prefix may require working
partitions_iterate (I think it does on EFI).
I'll think how to fix the matters but since normal.mod isn't meant to be
preloaded, I see the matter as minor.
> Were these two functions put after grub_load_modules() before they
> might require modules loaded there?
>
>  --S
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

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

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 729 bytes --]



Quoting Vladimir 'φ-coder/phcoder' Serbinenko, who wrote the following on...:

>
>>  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.
> The dependence is subtle: set_prefix may require working
> partitions_iterate (I think it does on EFI).
> I'll think how to fix the matters but since normal.mod isn't meant to be
> preloaded, I see the matter as minor.

   I think it's pretty reasonable to preload normal if it's embedded in a pxe 
image, but there is a workaround, so it's not super-urgent.

  --S