PXE Boot issue - default.ipxe permssion denied
-
I guess it’s time for you to look into wireshark and tcpdump… capture the packets on the FOG server while your client boots up. Try to investigate yourself or upload the pcap file if you want us to have a look.
[CODE]sudo tcpdump -i eth0 -w dump.pcap udp[/CODE]
Startup your client right after this and stop the command (Ctrl+C) when your client fails… Then copy the pcap file to another computer where you have wireshark installed and open it up. Try display filters ‘bootp’ (for DHCP) and ‘tftp’…
-
Hi - Thanks. Ok I captured the boot of both the Dell and my Acer laptop, both up to the point of failure and then restarting (or in the case of the Dell waiting on F1 to retry). The difference between the two is that the Acer doesn’t ask for the TFTP server name (option 66) for some reason but the Dell does. The responses back from the DHCP server look right to me but I’m not really familiar with DHCP. And then after that …nothing. Here is the link to the [URL=‘https://drive.google.com/open?id=0B_kJyPnsAGFZQl9iU2s3c2dFZms&authuser=0’]Acer pcap[/URL] and the link to Dell pcap is [URL=‘https://drive.google.com/open?id=0B_kJyPnsAGFZOUlITXBvanVWUk0&authuser=0’]here[/URL]. My OSX DHCP/TFTP server IP is 10.250.144.2 and the Fog box 10.250.144.11.
Cheers -
I was pretty confused when looking at those dump files and I couldn’t see any TFTP traffic whatsoever. Then I noticed that I asked for the wrong capture files!
Please run tcpdump on your OSX server (hosting DHCP and TFTP…)!
[CODE]sudo tcpdump -i en0 -s 0 -w dump.pcap[/CODE]
From what I can see so far the DHCP server seems ok. At least you see ‘Configuring (net0 …’ which meens ipxe binary gets loaded from the TFTP server!
-
OK didn’t know that wireshark provided in-built filters for tftp, many thanks for that. Really useful - I’ve struggled with trying to analyse the logs for tftp in the past so that’s great.
Anyway - [URL='https://drive.google.com/open?id=0B_kJyPnsAGFZVlpwY1lUNnk1REU&authuser=0’]here’s the pcap for the Dell[/URL]; it seems like it’s failing on the absolute path for /default.ipxe…not even sure where that would try and get the file from…I tried copying it to the root directory of my osx server but it made no difference. Had a brief look to see if I could remove the path from undionly.kpxe? but that looks not so trivial…
With my acer laptop that looks to be an entirely different issue, maybe the implementation of PXE on that isn’t compatible, as the requested TFTP filename seems screwed up with a string of appended bytes (the server address?). The [URL=‘https://drive.google.com/open?id=0B_kJyPnsAGFZMlJPZEVCaG85NnM&authuser=0’]Pcap for that is here[/URL], but that isn’t my main issue…
CheersEdit: Sorry - set the link for acer.pcap correctly now
-
Access rights…? Could it be that easy?? Why didn’t that come to my mind earlier?? Please post the output of ‘ls -al /tftboot’ on your OS X server!
Edit: Sorry, I just re-read your postings and saw that you have successfully downloaded default.ipxe from other host via TFTP… right??
Edit2: TFTP server’s root is /tftpboot. So ‘get /default.ipxe’ should translate to ‘/tftpboot/default.ipxe’ on the server. Does anyone know if Mac OS X is doing things different here?? Can’t find anything on the web about it… DEFAULT TFTP dir is: /private/tftpboot, right? ‘ls -al /private/tftpboot’ then…
Edit 3: Both links to pcap files are the same… can’t see any new one for Acer
-
[quote=“Uncle Frank, post: 44484, member: 28116”]Access rights…? Could it be that easy?? Why didn’t that come to my mind earlier?? Please post the output of ‘ls -al /tftboot’ on your OS X server!
Edit: Sorry, I just re-read your postings and saw that you have successfully downloaded default.ipxe from other host via TFTP… right??
Edit2: TFTP server’s root is /tftpboot. So ‘get /default.ipxe’ should translate to ‘/tftpboot/default.ipxe’ on the server. Does anyone know if Mac OS X is doing things different here?? Can’t find anything on the web about it… DEFAULT TFTP dir is: /private/tftpboot, right? ‘ls -al /private/tftpboot’ then…
Edit 3: Both links to pcap files are the same… can’t see any new one for Acer[/quote]
Yes - have successfully downloaded default.ipxe from the OSX server. The default is indeed /private/tftpboot. ls -la yields:
drwxrwxrwx 24 root wheel 816 27 Mar 09:54 .
drwxr-xr-x@ 8 root wheel 272 7 Jul 2014 …
-rw-r–r–@ 1 root wheel 6148 29 Aug 2014 .DS_Store
drwxrwxrwx 3 root wheel 102 18 Jul 2014 NetBoot
-rwxrwxrwx@ 1 service wheel 2425 1 Oct 15:41 at800s.txt
-rwxrwxrwx 1 service wheel 840 21 Nov 15:21 boot.txt
-rwxrwxrwx 1 service wheel 295 21 Nov 15:21 default.ipxe
drwxr-xr-x 5 root wheel 170 5 Mar 09:38 deploystudiopc
-rw-r–r-- 1 service wheel 3605993 27 Mar 09:41 dump.pcap
drwxrwxrwx 8 root wheel 272 27 Feb 14:27 fog
-rwxrwxrwx 1 service wheel 389009 21 Nov 15:21 ipxe.kkpxe
-rwxrwxrwx 1 service wheel 389057 21 Nov 15:21 ipxe.kpxe
-rwxrwxrwx 1 service wheel 388044 21 Nov 15:21 ipxe.krn
-rwxrwxrwx 1 service wheel 389073 21 Nov 15:21 ipxe.pxe
-rwxrwxrwx 1 service wheel 25340 21 Nov 15:21 memdisk
drwxr-xr-x 13 root wheel 442 5 Mar 09:38 pxelinux
-rwxrwxrwx 1 root wheel 16794 20 Dec 2013 pxelinux.0
-rwxrwxrwx 1 service wheel 16794 21 Nov 15:21 pxelinux.0.old
-rwxrwxrwx 1 service wheel 165088 21 Nov 15:21 snponly.efi
-rwxrwxrwx 1 service wheel 101989 21 Nov 15:21 undionly.kkpxe
-rwxrwxrwx 1 service wheel 102037 21 Nov 15:21 undionly.kpxe
-rwxrwxrwx 1 service wheel 382650 21 Nov 15:21 undionly.kpxe.INTEL
-rwxrwxrwx 1 service wheel 102053 21 Nov 15:21 undionly.pxe
-rwxrwxrwx 1 service wheel 147728 21 Nov 15:21 vesamenu.c32Haven’t cleaned it up since migrating from 0.32…
Edit: Also I’ve set the Acer.pcap link correctly now I think…
Edit2: Also my OSX tftp server uses the insecure (-i) parameter - caused me no end of grief before getting 0.32 working…
Edit3: I can set the path on the TFTP server so maybe I should try it with /tftpboot (copying everything first of course)?
Cheers -
Did you ever try to download ‘/default.ipxe’ (WITH slash!) from another PC??
-
[quote=“Uncle Frank, post: 44487, member: 28116”]Did you ever try to download ‘/default.ipxe’ (WITH slash!) from another PC??[/quote]
Good Point. Just tried this and it fails…Error on server ??? Connect request failed
I’m guessing that the OSX Tftp server does attempt to get from the root directory but because it’s outside /private/tftpboot it fails. I’ll try moving my tftp default directory to /tftpboot but that will probably fail for the same reason I imagine… -
OK tried setting the default to /tftpboot and it had no effect - same problem occurs. If I read it right, reading the [URL=‘https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/tftpd.8.html’]man page for tftpd[/URL] it looks like using “/” in the file name will definitely get refused by the OSX tftp server unfortunately. Can’t quite see a way around this.
Edit: Success! But nervous of the cost. I fixed it by allowing the TFTP server access to “/” and making a symlink there to /tftpboot/default.ipxe. But that does allow TFTP access to the root directory of my OSX server…as I’m the only one imaging perhaps I’ll turn off TFTP access unless I’m using it…
-
Great to hear. No need to open up your whole system and symlink files if you go ahead and build you own custom undionly.kpxe binary… [url]http://fogproject.org/forum/threads/build-ipxe-from-source.10152/[/url]
Follow those steps. Maybe it’s a coincidence but in this post Tom suggests building the embedded script without the leading slash!!
Maybe Tom can tell us why the official binaries are build with ‘/default.ipxe’…
-
They were not built with the leading slash. All it does is chain to default.ipxe in 1.2.0. Most systems worked fine but on occasion some systems what the protocol implicitly defined which is what you see now on the development fog.
-
I am having the same issue with the default.ipxe permission denied error. I have gotten one client to successfully boot and inventory. It got the error but booted on the next try. I have had four more though that fail no matter what. I am new to fog and it is a fresh install on ubuntu 12.04. Is there any answer on fixing this issue?
-
@datastream It’s weird that it’s inconsistent… Are the ones that succeeded and the ones that failed the same model or different models?
-
They are all the same model. I tried a couple more and I can only get the one to PXE boot. The rest give me that same error.
-
@datastream What’s different about that one? Something special about that port on the switch? Is there a difference in BIOS settings?
Also, the problem you’re describing smells a lot like an IP conflict.
-
Well that was dumb of me. I rebooted the server and everything is working now.