Re: Running the preset option more than once

[Christoph Plattner]

Hello !

We have to look, if this is real a problem, that the preset
menu is executed on every menu load, but using

        bootp --with-configfile

is definitly wrong in the preset menu, as far I can remeber.

Why ?

The preset menu is a config file which is executed, before
the main menu is loaded and shown !

So `bootp' without option loaded the net config itmes, so also
TAG-150, the name of the menu file and overwrites the stored
default menu file name.

After the preset menu is executed, the menu is loaded and
started using the stored menu name (which is overwritten
by TAG-150). 

Therefore the preset menu only should contain `bootp' and
definitly not `bootp --with-configfile' as the menu is 
always executed afterwards.

The later added option `--with-configfile' is only to force
a new loading of a menu instead of loading the default menu
via TAG-150 or locally defined (not diskless support).

Example: You have a locally installed GRUB with network
support, and GRUB starts and loads the defined menu, for
example `(hd0,0)/boot/grub/menu.lst' and you want to start
a menu from net, then you must do a `bootp' and force
GRUb to restart the new laoded menu with `--with-configfile'.

I hope I could clarify this point. The preset menu only holds
onfigurations and a "fallback menu", but should not really
do actions.

With friendly regards
Christoph P.



Damian Ivereigh wrote:
> 
> Hi guys,
> 
> I think this is a bug, but would like it confirmed. I set the preset
> menu/config (i.e. the menu compiled into grub) to be "bootp
> --with-configfile" - this is an extension of the diskless setup. The
> idea being that once grub starts it will automatically get a bootp/dhcp
> address and then run the config file specified in the T150 tag of the
> bootp response.
> 
> This all works until it comes to execute the new config file: it re-runs
> the preset menu/config, which of course issues another bootp and get
> another config file, endless loop.
> 
> I have enclosed a patch that will fix this by checking the return value
> from the setjmp, such that if it is not the first time through, it
> "closes" the preset menu, which turns it off. However maybe there is
> some other way to do this.
> 
> Thoughts?
> 
> Damian
> 
> --
> Damian Ivereigh
> CEPS Team Lead
> http://wwwin-print.cisco.com
> Desk: +61 2 8446 6344
> Fax: +61 2 8446 8498
> Mob: +61 418 217 582
> 
>                                 Name: grub-0.92-fixpreset.patch
>    grub-0.92-fixpreset.patch    Type: unspecified type 
> (application/octet-stream)
>                             Encoding: x-uuencode

-- 
  +--------V--------+   address@hidden
  |  A L C A T E L  |   -----------------------------
  +-----------------+   Phone: +43 1 27722 3706 
         T A S          Fax:   +43 1 27722 3955