[syslinux] PXERETRY directive

Geert Stappers stappers at stappers.nl
Mon May 9 08:37:07 PDT 2016


On Thu, May 05, 2016 at 06:30:30PM +0300, Ady via Syslinux wrote:
> > > On Thu, Apr 21, 2016 at 10:30 PM, Ady via Syslinux <syslinux op zytor.com> wrote:
> > > > Would someone please be so kind to explain / describe the PXERETRY
> > > > directive?
> > > 
> > > $ git grep -ni pxeretry
> > > com32/elflink/ldlinux/readconfig.c:1305:    else if (looking_at(p, "pxeretry"))
> > > com32/elflink/ldlinux/readconfig.c:1306:        PXERetry =
> > > atoi(skipspace(p + 8));
> > > 
> > > core/fs/pxe/pxe.c:275:    int i = PXERetry;
> > > 
> > > 
> > > It's used in pxe_searchdir() to affect how many times it retries to
> > > open a file and added in commit 4f989f247 for 4.03.
> > > 
> > > -- 
> > > -Gene
> >  
> > If possible, I would appreciate some additional information, perhaps 
> > aimed at common users?
> > 
> > Some of the following questions might sound strange to some readers, 
> > but I have found no information nor examples (nor experiences by 
> > others), at all, that could help describe the behavior for a common 
> > user.
> > 
> > Some of the questions that come to mind...
> > 
> > _ Does it affect the initial configuration file (e.g., 
> > "pxelinux.cfg/default")? At first sight, this question might seem to 
> > have no sense, considering that the configuration file needs to be 
> > found and be parsed first, before being able to act according to the 
> > PXERETRY directive in it. But, as a common user, I am not sure whether 
> > there could be some situation in which the / a configuration file is 
> > re-read and/or re-parsed -- the CONFIG directive, the INCLUDE 
> > directive, and the config.c32 module perhaps could be relevant for this 
> > question.
> > 
> > _ Does it affect every single file? For instance, if the user tries to 
> > execute a c32 module, does PXERETRY affect the command? And what about 
> > kernel / initrd file(s)? What happens when using pxechn.c32 or when 
> > loading a different network bootloader / NBP (for instance, with the 
> > PXE directive)?
> > 
> > _ Does it have any effect when using (vesa)menu.c32? Could it (perhaps 
> > unintentionally) affect the presentation of the boot menu itself (e.g. 
> > by loading the menu on screen several times, according to the PXERETRY 
> > value)?
> > 
> > _ Is the PXERETRY directive "sticky" (similarly to the SERIAL 
> > directive)? Can it be reset or changed by loading a different 
> > configuration file? Or perhaps, is it reset automatically after any 
> > particular situation / action / behavior?
> > 
> > _ Is there a valid range of values? Are non-decimal values accepted?

 From http://www.syslinux.org/archives/2016-April/025149.html
   What is a recommend value for the directive?
   Has it a default value?


> > _ Would I be correct by assuming this is a global directive?
> > 
> > _ Is it valid for pxelinux.0 only? What about lpxelinux.0? What about 
> > syslinux.efi? Others?
> > 
> > _ Could someone please describe a usage case for this directive? Why 
> > might it be needed? What for? In which circumstances? Which behavior 
> > (or log's content) would trigger the need / desire for this directive? 
> > Which advantage or positive consequence(s) would it provide?
> > 
> > 
> > I wish I would have the means to actually test all these cases by 
> > myself, instead of asking here.
> > 
> > I hope these questions might also trigger the curiosity of others to 
> > test and report back, considering that this directive is not very 
> > well-known.
> > 
> > I also hope the potential replies / answers would help users to find 
> > this email thread as (initial) documentation for this PXERETRY 
> > directive, considering that it is not documented anywhere else (or at 
> > least, I couldn't find it).
> > 
> > TIA,
> > Ady.
> >  
> 
> Anyone?

Please elaborate where PXERETRY was encountered,
so we known which documentation peace needs additional information.
 
(yes, that is like http://www.syslinux.org/archives/2016-April/025147.html )


Groeten
Geert Stappers
-- 
Leven en laten leven


More information about the Syslinux mailing list