SVN 5209 Not able to pxe boot

[Joseph Hales]

Where is the access log under ubuntu 14.

[Hanz]

@Sebastian-Roth I’m not seeing anything actually pertaining to the ip assigned to machine while pxe booting

[Sebastian Roth]

/var/log/apache2/access.log and /var/log/apache2/error.log

[Sebastian Roth]

@Hanz Well, without an error message or any other hints we won’t be able to help!

Try capturing DHCP and TFTP traffic on the server while booting one particular client. Please make sure only one client is booting at that time so the packet dump won’t be several MB big. Install package tcpdump and then:

tcpdump -i eth0 -w pxe.pcap port 67 or port 68 or port 69

Leave it there and PXE boot the client. After it failed stop tcpdump (Ctrl-c) and upload the PCAP file.

[Hanz]

@Sebastian-Roth pxe.pcap

[Raymond Bell]

Also unable to iPXE boot with r4285

[Sebastian Roth]

@Tom-Elliott Seams like the current undionly.kpxe binary (possibly also the other iPXE binaries too) is corrupt. Can you update again. Don’t think this is related to the script change (proxydhcp) as it completely crashes in my test QEMU setup. Script error wouldn’t crash I suppose.

[Joseph Hales]

I also saw this issue but couldn’t trouble shoot as I needed it up for production I also didn’t see anything weird in the logs. Right now I’m reverted to 4978.

[Wayne Workman]

@Sebastian-Roth said:

@Tom-Elliott Seams like the current undionly.kpxe binary (possibly also the other iPXE binaries too) is corrupt. Can you update again. Don’t think this is related to the script change (proxydhcp) as it completely crashes in my test QEMU setup. Script error wouldn’t crash I suppose.

I just tested and you are correct, something is corrupt/not right at all. I just did a test upload using the latest svn and it failed exactly as described here:
https://forums.fogproject.org/topic/6050/imaging-isseus-new-host-svn-5201

[Tom Elliott]

PXE Booting should be fixed.

We had a bad caller in the ipxe script.

Particularly, the code segment:

...
isset(${proxydhcp/next-server}) && set next-server ${proxydhcp/next-server}
...

It doesn’t fail out propery (releases back to BIOS if you will) if the proxydhcp/next-server variable is not set. The fix was simple, just make the segment as:

...
isset(${proxydhcp/next-server}) && set next-server ${proxydhcp/next-server} ||
...

[Hanz]

@Tom-Elliott Thank you sir…I’m sorry I didn’t have much info to help diagnose. Appreciate everyone’s help.