Re: appropriate code for a GRUB-specific option

[Christoph Plattner <christoph.plattner@alcatel.at>]

We should consider, that a server admin has to define bootp (or dhcp)
to allow diskless booting of grub.To define the boot file the
'bf=' option is used. So we should overthink, if we should not use 
another tag, which is normaly used and reserved, but which is not
used in context of GRUB. For example the root-path 'rp='. Why can
GRUB not have the root path for itself to find his own 'menu.lst' ?

I think this is not the worst violation of the bootp tag numbering
scheme.

But there is one drawback. I think about a new featuer added to GRUB,
to have the possibility to load a menu.lst over network on a local
boot GRUB. 

Example <1>
	- Grub loads a local menu.lst
	- Clicking on one menu entry lets switch to a netbooted menu.lst
	    but which menu.lst should be a tag of bootp (otherwise
	    it is no new feature, as GRUB is able to do this now with
	    the command 'configfile' in combination with 'bootp' and
	    'root (nd)'.
	- In the netbooted menu a back link to the local menu is included
	    like 'configfile (hd0,0)/boot/grub/menu.lst' (this must be
	    fix ! or the config_file must be saved).

Example <2>
	- Grub boots local but loads config file fix over bootp/tftp !

In this case, on the server the boot-file tag 'bf=' is ignored, but
the root-path tag 'rp=' or similar can also be used !

With friendly regards

	Christoph Plattner





OKUJI Yoshinori wrote:
> 
> From: Michael Riepe <michael@stud.uni-hannover.de>
> Subject: Re: appropriate code for a GRUB-specific option
> Date: Sun, 28 May 2000 16:10:54 +0200
> 
> > future.  Codes 128 ... 254 may have been assigned by the local network
> > administrator and are not an option for GRUB.
> 
>   That depends on how you interpret the sentence in RFC 2132:
> 
>          Option codes 128 to 254 (decimal) are reserved for site-specific
>          options.
> 
>   My interpretation for this is different from yours, since RFC 1497
> says:
> 
>          Reserved Fields (Tag: 128-254, Data: N bytes of undefined
>          content)
> 
>             Specifies additional site-specific information, to be
>             interpreted on an implementation-specific basis.  This
>             should follow all data with the preceding generic tags 0-
>             127).
> 
> So I think it's fair to assume that "site-specific" is used as an
> alternative word to "implementation-specific". In fact, Etherboot
> defines several vendors extensions in the documentation:
> 
> http://etherboot.sourceforge.net/doc/html/vendortags.html
> 
> Anyway, how can a local administrator use the site-specific
> information if no (client) implementation supports it? ;)
> 
> > anyway, i.e. use a built-in default configuration.  Of course, you could
> > also follow the procedure outlined in RFC 2132, section 10, and register
> > a new code for GRUB...
> 
>   That's right, but I don't think they will accept an
> implementation-specific feature.
> 
>   Therefore, if the Etherboot developers have no opinion, I'll pick an
> arbitrary code which is not used by Etherboot at least for now.
> 
> Thanks,
> Okuji
> ===========================================================================
> This Mail was sent to netboot mailing list by:
> OKUJI Yoshinori <okuji@kuicr.kyoto-u.ac.jp>
> To get help about this list, send a mail with 'help' as the only string in
> it's body to majordomo@baghira.han.de. If you have problems with this list,
> send a mail to netboot-owner@baghira.han.de.

-- 
  +--------V--------+	Christoph.Plattner@alcatel.at
  |  A L C A T E L  |	-----------------------------
  +-----------------+	Phone: +43 1 27722 3706	
         T A S		Fax:   +43 1 27722 3955
===========================================================================
This Mail was sent to netboot mailing list by:
Christoph Plattner <christoph.plattner@alcatel.at>
To get help about this list, send a mail with 'help' as the only string in
it's body to majordomo@baghira.han.de. If you have problems with this list,
send a mail to netboot-owner@baghira.han.de.