<div class="gmail_quote">Since 1.0.0 is in rc phase, thought I'd mention three issues I've been patching in my usage.<div><br></div><div>One is that on IBM firmware (not BBS compliant), there is a way of working better with boot order via hooking int18 instead of int19 (as well as a few other changes. I have attached the patch I use, it does the following:</div>
<div>-Does not save off BIOS handlers (simply because they are never used in this case)</div><div>-Hooks int18 instead of int19</div><div>-Exits via iret rather than calling int18/int19</div><div>-saves and restores registers</div>
<div>Note that I am not in a position to evaluate where besides IBM firmware BBS is not available. I ask that if there is concern over other non-BBS systems having a problem with this, that someone make this controllable via a config/general.h flag, analogous to how it was done in etherboot.</div>
<div><br></div><div>My second issue is a tad more tricky. I got gPXE to netboot on a single ethernet segment of thousands of servers, but I had to patch as the general noise of such a large network caused gPXE some pain allocating resources (see etherboot-discuss thread from July 1, 2009). I noted an afflicted gPXE system encountered:</div>
<div>-Massive unrelated ARP traffic</div><div>-Various systems unrelated to the boot process trying to do ICMP ECHO REQUEST to the system, evoking echo replies</div><div>-Various systems attempting to connect to TCP services on the system while it was in gPXE, causing it to have to send TCP reset packets</div>
<div>My big problem here is that my attempts to reproduce the problem on a smaller testbed than thousands of systems have not panned out, and after this patch, I have no justification in scale-testing without the patch on a large system anymore, since the patch can get them into production faster. As you can guess, my patch includes the one from Michael Brown that only pulls in ARP if it is a reply, and additionally disables ICMP ECHO REPLY and TCP RESET packets. I have no idea if problematic conditions would have been resolved there. I have attached that patch for discussion as well.</div>
<div><br></div><div>A third issue is a bug with older KVM stacks (including RHEL5.4). The bug is KVM's, but I worked around it in gpxe. I have attached the rather simplistic, if odd looking, workaround I've been using of sticking some nops in.</div>
<div><br>I apologize if the patches turn out unclean, they are provided as I use them and I don't look closely to see if it applied cleanly or fuzzy (shouldn't hit rejects though). If there is an issue, let me know. I apply other patches (iBFT on PXE, 'hdboot' command to call int13), but those are features and I've submitted those ideas (available via etherboot-discuss somewhere if someone wants them) and potentially better designs than mine were suggested. I don't know if any were implemented though.</div>
<div><br></div><div><br></div>
</div><br>