[syslinux] Option 211: reboottime and remote reliability

Curtis Doty Curtis at GreenKey.net
Wed Jul 12 07:52:16 PDT 2006

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.


More information about the Syslinux mailing list