iPXE discussion forum

Hi all.
I've encountered several mentions of the "ipxe.scriptlet" dhcp option (encap: 175:81) on the forums and around, but couldn't find documentation or a good example. Is it deprecated or something?

I'd like to use it to set a variable used later in the main script, so I set dnsmasq to pass this inside the option:
Now, how do I execute it? Testing in the interactive shell, the obvious ${scriptlet} tries to use the entire string as a command name:

The definition can be found at https://git.ipxe.org/ipxe.git/blob/d8c50...hcp.h#l381
The call is then done in https://git.ipxe.org/ipxe.git/blob/d8c50...oot.c#l600

As I'm reading the code without having tested, this is the same as having an embedded script.
So it should be something like "dhcp && chain http://xxxx/xxx.ipxe"

If you already have an embedded script in iPXE it should take precedence over the scriptlet
and if you have scriptlet then filename would not be used.

One example can be found at http://ipxe.org/buildcfg/vmware_settings even if that is defined by different methods then dhcp
And here is a post that describes what it does, even if it doesn't describe how to define it in dhcp: http://forum.ipxe.org/showthread.php?tid...09#pid9709

(2018-03-14 19:47)NiKiZe Wrote: [ -> ]As I'm reading the code without having tested, this is the same as having an embedded script.
So it should be something like "dhcp && chain http://xxxx/xxx.ipxe"

Thanks, I'll check tomorrow when I get to it. I'm wondering if variables set via the scriptlet persist across the chain call - so I could do something like "set var something && chain http://.../main.ipxe". In case they don't, is it possible to pass the data as argument for ipxe, i.e. "chain http://.../main.ipxe something" ? (How would I refer to the argument in the ipxe script?)

EDIT: Well, I tried setting the option to echo something, wait and then boot the main script - no dice. If i leave DHCP option 67 in place (which is set to the main script), it just boots straight into the main script, and if I unset it, it just loops at the DHCP stage (iPXE is chainloaded from onboard PXE).

Actually, thinking it over some more, I realized, the "live-netdev=eth1" option will be required on per-model basis, rather than per-machine, so I'll just add the decision logic into my main script and be done with it.

Still, I find it quite strange that this option, which seems to date back to gPXE days, remains undocumented.

Just as described in http://forum.ipxe.org/showthread.php?tid...98#pid4798
It sounds like it would be better for you to use some other dhcp option to send the values of those settings
and then pick them up in your normal script, you would add something like this to your script:

and I think your dnsmasq config would be

(2018-03-15 08:44)NiKiZe Wrote: [ -> ]Just as described in http://forum.ipxe.org/showthread.php?tid...98#pid4798
It sounds like it would be better for you to use some other dhcp option to send the values of those settings
and then pick them up in your normal script, you would add something like this to your script:
<snip>

EDIT: Just for the record, the correct dnsmasq configuration:
to reference the value as ${128:string}, or
to reference the value as ${175.82:string}

Anyway, I think I found the closest thing to scriptlet documentation: http://etherboot.org/pipermail/gpxe-deve...00482.html

Quote:If the "scriptlet" NVO is set, gPXE will execute its value as a script
before executing any embedded script and before attempting to
autoboot. This allows users to override or augment compiled-in boot
behaviour by setting "scriptlet" using the gPXE command line
interface. Scriptlets may be up to 255 characters long, but may be limitted
by available NVO storage.

Useful scriptlets need not be long. Some examples are:
"ifopen net0\nsanboot ${net0/root-path}":
sanboot without DHCP, using NVO "ip", "netmask", and "root-path" settings.
"autoboot\nloopif 1"
autoboot, retrying forever, using the experimental "loopif" command.

Being able to modify boot behaviour without recompiling can be useful
to users under the following circumstances:
* The user does not have tools required to burn a ROM.
* The user cannot conveniently recompile because they use an OS
that cannot rebuild gPXE, or cannot reprogram ROMs.
* The user cannot conveniently access the web (for ROM-o-matic), because
they are in a secure facility without Internet access.
* The user cannot reprogram NICs without removing them from a machine.
(This is a big deal when you have hundreds of machines.)

---