Syslinux - Jan 2005 - RFC 3942 notice: PXELINUX, DHCP options 208-211

Dear friends,

In accordance with RFC 3942 I would like to submit the following DHCP 
options for official consideration.  These options are used by PXELINUX, 
which is part of the SYSLINUX distribution, and although exact usage 
count is impossible to determine, is widely held to be the most widely 
used method for booting Linux from a network.

----------

Option 208: pxelinux.magic (string)
Must be set to F1:00:74:7E (241.0.116.126) for PXELINUX to recognize any 
special DHCP options whatsoever.

Option 209: pxelinux.configfile (text)
Specifies the PXELINUX configuration file name.

Option 210: pxelinux.pathprefix (text)
Specifies the PXELINUX common path prefix, instead of deriving it from 
the boot file name. This almost certainly needs to end in whatever 
character the TFTP server OS uses as a pathname separator, e.g. slash 
(/) for Unix.

Option 211: pxelinux.reboottime (unsigned integer 32 bits)
Specifies, in seconds, the approximate time to wait before reboot in the 
event of TFTP failure. 0 means wait forever (in reality, it waits 
approximately 136 years.)

----------

Out of these, option 208 is strictly use as a safety and is obviously 
not required if 209-211 become official assignments.

It is my belief that 209, 210 and 211 are of general interest and should 
be promoted to official.  In particular a more withspread use of 211 
would probably improve remote booting reliability by giving the server 
explicit control over the early boot failure policy.

Option 210 could arguably be considered redundant with option 17, but I 
personally feel they are distinct enough to warrant separate 
assignments.  In particular, 210 is more of a "current working 
directory" than a root image path.

	-hpa

Thanks Peter!

Do you intend to write the required Internet-Draft (for submission as an
RFC) or do you want to have these options included in a "general"
options
draft (for which I'm willing to act as editor).

- Bernie
> -----Original Message-----
> From: H. Peter Anvin [mailto:hpa at zytor.com] 
> Sent: Tuesday, January 18, 2005 7:48 PM
> To: iana at iana.org; dhcwg at ietf.org; volz at cisco.com; David W.
Hankins
> Cc: SYSLINUX at zytor.com
> Subject: RFC 3942 notice: PXELINUX, DHCP options 208-211
> 
> 
> Dear friends,
> 
> In accordance with RFC 3942 I would like to submit the following DHCP 
> options for official consideration.  These options are used 
> by PXELINUX, 
> which is part of the SYSLINUX distribution, and although exact usage 
> count is impossible to determine, is widely held to be the 
> most widely 
> used method for booting Linux from a network.
> 
> ----------
> 
> Option 208: pxelinux.magic (string)
> Must be set to F1:00:74:7E (241.0.116.126) for PXELINUX to 
> recognize any 
> special DHCP options whatsoever.
> 
> Option 209: pxelinux.configfile (text)
> Specifies the PXELINUX configuration file name.
> 
> Option 210: pxelinux.pathprefix (text)
> Specifies the PXELINUX common path prefix, instead of 
> deriving it from 
> the boot file name. This almost certainly needs to end in whatever 
> character the TFTP server OS uses as a pathname separator, e.g. slash 
> (/) for Unix.
> 
> Option 211: pxelinux.reboottime (unsigned integer 32 bits) 
> Specifies, in seconds, the approximate time to wait before 
> reboot in the 
> event of TFTP failure. 0 means wait forever (in reality, it waits 
> approximately 136 years.)
> 
> ----------
> 
> Out of these, option 208 is strictly use as a safety and is obviously 
> not required if 209-211 become official assignments.
> 
> It is my belief that 209, 210 and 211 are of general interest 
> and should 
> be promoted to official.  In particular a more withspread use of 211 
> would probably improve remote booting reliability by giving 
> the server 
> explicit control over the early boot failure policy.
> 
> Option 210 could arguably be considered redundant with option 
> 17, but I 
> personally feel they are distinct enough to warrant separate 
> assignments.  In particular, 210 is more of a "current working 
> directory" than a root image path.
> 
> 	-hpa
>

H. Peter Anvin wrote:
> Option 211: pxelinux.reboottime (unsigned integer 32 bits)
> Specifies, in seconds, the approximate time to wait before reboot in the 
> event of TFTP failure. 0 means wait forever (in reality, it waits 
> approximately 136 years.)
>
> ----------
>
> Out of these, option 208 is strictly use as a safety and is obviously 
> not required if 209-211 become official assignments.
>
> It is my belief that 209, 210 and 211 are of general interest and should 
> be promoted to official.  In particular a more withspread use of 211 
> would probably improve remote booting reliability by giving the server 
> explicit control over the early boot failure policy.
>
> Option 210 could arguably be considered redundant with option 17, but I 
> personally feel they are distinct enough to warrant separate 
> assignments.  In particular, 210 is more of a "current working 
> directory" than a root image path.
>   
I know this is an old thread. But hopefully my comment is still on topic.

Here, I've found a related corner case that should deserve additional
attention. If the pxelinux.0 filename is successfully loaded via tftp,
but then the config file fails to match, it will fall through to a
default kernel image. If that default kernel is not found, it will then
hang indefinitely at the boot: prompt.

I don't speak asm but a quick glance at the code makes me think this is
the bad_kernel case and is separate case from the reboottime. Maybe
others still want the indefinite hang behavior on bad_kernel? But in my
case where the network is more dynamic, I would like to see it reboot
indefinitely until a *complete* setup is available on the network.

Is this possible with the existing PXELINUX or am I right in assuming
that bad_kernel needs to be hacked to pause politely and then jump
kaboom under these circumstances? If so, then the polite pause could use
the reboottime value.

../C