SVN 5209 Not able to pxe boot
-
within a couple minutes the total requests has tripled.
-
fixed per SVN 5211, but pxe problems still exist
-
What do you see in apache error and access log when trying PXE boot?
-
Where is the access log under ubuntu 14.
-
@Sebastian-Roth I’m not seeing anything actually pertaining to the ip assigned to machine while pxe booting
-
/var/log/apache2/access.log and /var/log/apache2/error.log
-
@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.
-
-
Also unable to iPXE boot with r4285
-
@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 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.
-
@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 -
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} || ...
-
@Tom-Elliott Thank you sir…I’m sorry I didn’t have much info to help diagnose. Appreciate everyone’s help.