Passing state/args/data to chainloaded iPXE

[svenx]

How do I easily pass state/args/data from iPXE, to another chainloaded iPXE binary? I have to do a multi-stage boot chain, to load an iPXE binary with the correct console output device (serial COM1, COM2, VGA, etc), and break the loop afterwards.

My use case, step by step:

1. Network card's native PXE stack requests DHCP.
2. DHCP server returns the file parameter pointing to undionly.kpxe or snponly.efi, depending on architecture.
3. First-stage iPXE requests DHCP.
4. DHCP server detects feature flags and user-class, and returns file parameter pointing to http://install/netboot.ipxe?op=consoledetect&product=${smbios/product}
5. Server-side netboot.ipxe script cleans up SMBIOS product string, and maps it to another iPXE filename, such as: undionly_serialcom1.kpxe, undionly_serialcom2.kpxe, snponly_serialcom1.efi, etc. All combinations are built and available.
6. First-stage iPXE chainloads the second-stage iPXE binary.
   

At this point, how can the second-stage iPXE binary know that it is at the second stage, and then set a user-class that will indicate this to the DHCP server? (Which will then return the main iPXE boot script to the client.)

While I could build a set of binaries that embed a script that sets the user-class to "iPXE-stage2" or something, it makes it rather inflexible.

Can I instead embed a single script that can be used in both stage 1 and 2, and have access to some sort of variable/argument that tells it to set the DHCP user-class option?

[mcb30]

(2016-02-22 17:53)svenx Wrote:  How do I easily pass state/args/data from iPXE, to another chainloaded iPXE binary?

If your second iPXE binary is in a format that supports a command line (such as .lkrn or .[k]pxe), then you can use the command line to pass arbitrary instructions to the second iPXE.

Michael

[mcb30]

(2016-02-28 23:03)mcb30 Wrote:  If your second iPXE binary is in a format that supports a command line (such as .lkrn or .[k]pxe), then you can use the command line to pass arbitrary instructions to the second iPXE.

Although for this specific use case, it's probably easier to fix up the "console" command to support runtime reconfiguration of the serial port. There's a work-in-progress commit at http://git.ipxe.org/people/mcb30/ipxe.gi...ff/a589a06.

Michael