Issues booting to fog using dnsmasq
-
does /tftpboot/undionly.0 exist?
-
Yes on the Fog Server it does exist, but not on the DHCP server where it is looking for it.
-
[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.0
pxe-service=X86PC, “Boot from local hard disk”, 0
dhcp-range=172.25.5.80,proxy,255.255.0.0
[/CODE]Backup your current file mv /path/ltsp.conf /path/ltsp.conf.old
then make a new one vi /path/ltsp.conf
enter insert mode: i
then past this,
exit insert mode: escwrite and quit: :wq
then restart your dnsmasq service on the FOG server.
-
That conf setup gives me a file not found. I can use tftp on my Windows 7 system to get all the other files, including undionly.kpxe and according to the permissions on undionly.0 all users have Read Write access.
-
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.
