I thought I'd enumerate the remotely significant patches I apply for my purposes to iPXE (against ipxe today).<br><div><br></div><div>I take the kernel cmdline size from 0x100 to match syslinux' 0x7ff.  I think newer bzImage format is handled nicer, but 'older' (aka current in enterprise world) kernels are overlimited compared to pxelinux:</div>
<div><a href="https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-cmdlinesize.patch">https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-cmdlinesize.patch</a></div><div><br></div><div>
I use iPXE scripts to load kernel but provide BOOTIF that looks just like IPAPPEND 2.  The catch was that gPXE had no variable for the NIC mac that would format the same (hyphen instead of : delimited).  This patch gave me the 'machyp' variable so I could mimick IPAPPEND 2 exactly.</div>
<div><a href="https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-machyp.patch">https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-machyp.patch</a></div><div><br></div><div>I have had a NIC vendor tell me that gPXE failed as a chainloaded payload on their nic because they didn't do interrupts quite as gPXE expected.  The following workaround was needed to proceed on their NIC, though I think it's potentially worrisome:</div>
<div><a href="https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-undinetchange.patch">https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-undinetchange.patch</a></div><div><br></div>
<div>One patch submitted before to gPXE, gives me the ability to expand variables in the filename parameter from DHCP.  The biggest downside would be that if using signed payloads to verify trust of scripts before potentially expanding 'secret' variables, this would provide a way to divulge those variables via malicious DHCPOFFERs.</div>
<div><a href="https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-expandfilename.patch">https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-expandfilename.patch</a></div><div>The most interesting aspect is for 'next-server' to be defined at the subnet level of dhcp config, and the 'filename' in a host-declaration and having client assemble the full url. </div>
<div><br></div><div>And finally, for lack of debug I cannot provide an ongoing assessment of how required it is, but I disabled arp table population on non-arp traffic, ICMP echo replies and TCP resets because with thousands of nodes on a vlan, gPXE's neighbor table wasn't quite coping with the chaotic traffic (tried to learn too many incidental macs and didn't manage to get the boot servers in the table).  Unfortunately, debugging thousands of nodes booting at once is not a frequent test case and I had no need of 'proper' network behavior, so I took a hatchet to it:</div>
<div><a href="https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-droppackets.patch">https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-droppackets.patch</a></div><div>It could be possible to reproduce the problem more synthetically at small scale for a 'proper' fix, but I didn't try given a good enough solution to my problem.</div>
<div><br></div><div><br></div>