Issues booting to fog using dnsmasq
-
dnsmasq is strange, the way it (or fog) was coded, it changes extensions to .0 Tom has looked and looked, can’t find where it’s happening. That said, to use dnsmasq, the file you want to use needs to be copied as <filename>.0
I’ve always skipped this bug by just specifying undionly.0 and making sure it exists.
have you looked at this? [url]http://fogproject.org/wiki/index.php/Troubleshoot_TFTP[/url]
-
Yes, I looked at that and it got me to this point. Like I said I can use TFTP from my Windows System to get every file except the symlink undionly.0.
Guess I will try some more tomorrow.
-
It’s possible to symlink, but if you can’t get it via TFTP, that’s a big issue.
I recommend getting rid of that and just making a copy.
[CODE]rm /tftpboot/undionly.0
cp /tftpboot/undionly.kpxe /tftpboot/undionly.0[/CODE]Then set the permissions & ownership on your new undionly.0
-
I did that and I still get the file not found when I try and boot a system from the Network, but I can get it using tftp from my Windows Workstation.
I switched everything back to using undionly.kpxe and it gives me the same thing I was getting with my original ltsp.conf.
[url]http://i847.photobucket.com/albums/ab34/Rehendril/20150506_084816_zpsevb4sjy1.jpg[/url]
[url]http://i847.photobucket.com/albums/ab34/Rehendril/20150506_084933_zpsho5mcdr0.jpg[/url]
[url]http://i847.photobucket.com/albums/ab34/Rehendril/20150506_084835_zpsvyktfjt7.jpg[/url][CODE]port=0
log-dhcp
tftp-root=/tftpboot
dhcp-boot=undionly.kpxe,172.25.5.80,172.25.5.80
dhcp-option=17,/images
dhcp-option=vendor:PXEClient,6,2b
dhcp-no-override
pxe-prompt=“Press F8 for boot menu”, 0
pxe-service=X86PC, “Boot from network”, undionly.kpxe
pxe-service=X86PC, “Boot from local hard disk”, 0
dhcp-range=172.25.5.80,proxy,255.255.0.0[/CODE]
-
As your boot file is looking for undionly.kpxe, do you have the file undionly.kpxe.0?
-
Yes, I do. If I specify that though it goes back to File not found even though I can GET it on my Windows Workstation using TFTP.
-
Please post the output of this:
[CODE]ls -laR /tftpboot[/CODE]
-
Here it is.
[url=“/_imported_xf_attachments/1/1969_commandoutput.txt?:”]commandoutput.txt[/url]
-
You have all the files you need. Permissions are 777 across the board. There are some ownership differences for the files you copied but the 777 permissions should make that not matter…
Lets see what’s happening in the traffic ? There’s steps for TCPDump in the WiKi. Can you look through the resulting PCAP file, or post it here?
-
The part that’s weird to me is the fact that it’s not trying to pull the file from the ltsp located server is it?
-
Correct. If you look at the jpegs I attached to an earlier post.
If I change the ltsp.conf to use undionly.0 it boots to network and imediatly gives me file not found. With the conf set as in my last post containing that info, it boots to the Network, goes to the second JPEG then attempts to try downloading default.ipxe from the DHCP server rather than the FOG Server where TFTP is set up and running. And as I stated if I stop dnsmasq on the FOG Server there is nothing else on the network handling Network boots so the systems fail that and go to their HDD.
I will go through the TCPDump steps and post the output.
-
Here is the issue.pcap. I will transfer it to my Windows box and look at it with Wireshark, but figured you guys would find stuff faster than I. Changed extension to .txt since it wouldn’t let me upload .pcap or .tar.gz
[url=“/_imported_xf_attachments/1/1972_issue.txt?:”]issue.txt[/url]
-
Forgot the Destination MAC. It is 78:45:C4:3D:8F:E7
-
Based on what you’re telling us, it sounds like your DHCP server is setup to hand out a next-server and/or filename address.
Could you see about having this disabled?
-
I have run into this issue as well. By doing heavy amounts of research I came to the following conclusions:
[LIST=1]
[]DnsMasq is hard coded to add a .0 to the end of a file. There is no good reason for this. That’s just how it do.
[]There are some PXE clients (computer firmwares) that have issues with it. They assume the “next-server” to be the DHCP unless given a specific Option 66, unlike most other PXE clients that assume the “next-server” to be the same as where they were told to get the boot file. Once again, no good reason for this, just how they do.
[/LIST] -
I checked the only active DHCP server and neither option 66 or option 67 are checked/enabled. I will talk to the vendor that handles our Network to see if there is anywhere else this might be set up.
From need2’s comment it looks like I might just need to have Option 66 set. I was really hoping to not have to touch the DHCP server as I am new to this company and don’t want to push my boundries yet.
-
Your client asks 172.25.5.80 for undionly.kpxe.0 - that’s correct.
And it looks like it gets the file, too.
However you’ve got some ARP issues… (duplicate use of 172.25.100.43 detected!) I’m not sure what that’s about.
So why is it saying file not found when I can see with my eyes that it’s finding the file and getting it?
-
Options 66 and 67 will make your life easier. It’s MUCH more simple than dnsmasq.
When you set those, disable dnsmasq on the FOG server.
-
I was getting all sorts of weird packets from dnsmasq when I was fiddling with it. It looks like it does some really hacky things to inject the extra DHCP code without being a DHCP server.
-
need2 was correct. I tried on some newer systems and it boots properly. My Test machine is older and we only have about 10 in production so I am okay with it not working on those systems till we get them replaced. On our newest systems Dell Optiplex 9020, when it gets to the point where is was trying to go to the DHCP server for the default.ipxe file, it asks for the TFTP server IP. Once I put that in it boots to Fog normally.
I am good with the state I have it right now and will inquire about changing the DHCP options with the Vendor and my Boss.
