FOG .33b PXE Boot woes
-
File exists and FOG has permission to use it. The contents are pointing to the IP of the Server. It was set to Net0 so i changed that to net1 as I am using eth1 for the connections but that had no effect.
This is what my default.ipxe file looks like.
[CODE]#!ipxe
chain http://192.168.1.99/fog/service/ipxe/boot.php?mac=${net1/mac}[/CODE] -
net net0/mac is for the client’s network interface, not the FOG Server’s network interface.
Are you sure 192.168.1.99 is being hosted properly then?
Can you tftp the default.ipxe file:
[code]tftp -i 192.168.1.99 get default.ipxe[/code] -
I was able to download default.ipxe with that command successfully. I am thinking I will start over on my FOG config using what I have learned with this thread and see where that gets me.
-
Okay, I hope all goes well.
I don’t know why it’s not pulling the default file, but before you start all over, maybe try restarting the tftpd-hpa service.
-
I had rebooted the server machine completely with the same result. Though when i try to restart the tftpd-hpa service it hangs and does not seem to want to start it again. And after a reboot when trying to restart the service the machine hangs at shutdown. Sounds like I may have other issues anyway. Would sorta make sense, i have been all over the place trying to get this thing to work.
-
[quote=“Paul Freeman, post: 25459, member: 23545”]I had rebooted the server machine completely with the same result. Though when i try to restart the tftpd-hpa service it hangs and does not seem to want to start it again. And after a reboot when trying to restart the service the machine hangs at shutdown. Sounds like I may have other issues anyway. Would sorta make sense, i have been all over the place trying to get this thing to work.[/quote]
I would definitely start fresh. I can confirm these settings work for a linksys router. But if you are in a production environment, adjustments will need to be made. This is the most basic setting a ltsp.conf can have to boot.
I updated the wiki.
In order to use boot commands you will need to symlink undionly.kpxe to undionly.0
[code]
cd /tftpboot
sudo ln -s undionly.kpxe undionly.0
[/code]Then edit your ltsp.conf edit these two lines
[code]
#pxe-prompt=“Press F8 for boot menu”, 3
to
pxe-prompt=“Press F8 for boot menu”, 3You may change the number value after we get it working. 0 will instantly boot your first command.
#pxe-service=X86PC, “Boot from network”, pxelinux
to
pxe-service=X86PC, “Boot from network”, undionly.0
[/code] -
Hello again all.
I would like to thank you all for your hard work and dedication to the FOG project and all the support you offer everyone and to myself.
After seeing that .33 was in RC status I decided to wait for the full release. Now I have a fresh install of 1.01 on linux Mint 16 running in production using Cisco router DHCP on 1 NIC.
I have followed the instructions via the WIKI for using DNSMASQ and after completion I was able to get a PC to start to load into iPXE. It had stopped at trying to load /default.ipxe and I was not sure why, so I rebooted the server and now the machines will no longer boot to iPXE. It now stops again at [I]PXE-E32: TFTP open timeout[/I]. I have verified that both TFTPD-HPA and DNSMASQ services are running.
I do not understand why it would stop working after a reboot when nothing else has changed.
-
[quote=“Paul Freeman, post: 28676, member: 23545”]Hello again all.
I would like to thank you all for your hard work and dedication to the FOG project and all the support you offer everyone and to myself.
After seeing that .33 was in RC status I decided to wait for the full release. Now I have a fresh install of 1.01 on linux Mint 16 running in production using Cisco router DHCP on 1 NIC.
I have followed the instructions via the WIKI for using DNSMASQ and after completion I was able to get a PC to start to load into iPXE. It had stopped at trying to load /default.ipxe and I was not sure why, so I rebooted the server and now the machines will no longer boot to iPXE. It now stops again at [I]PXE-E32: TFTP open timeout[/I]. I have verified that both TFTPD-HPA and DNSMASQ services are running.
I do not understand why it would stop working after a reboot when nothing else has changed.[/quote]
What happens if you restart the services even though they are running?
-
Restarted the service and now it will boot back into iPXE. Now it stops at [I]/default.ipxe… No such file or directory ([url]http://ipxe.org/2d12603b[/url]) [/I]This reads to me like a permissions issue since the file is in the /tftpboot directory.
-
Changed ownership of /tftpboot to fog user and group and restarted the services and no change.
-
can you retrieve undionly.kpxe by tftp from another computer from command line?
-
Yes, I am able to retrieve undionly.kpxe and default.ipxe via TFTP.
-
can you verify that both the undionly.kpxe and default.ipxe are in the same directory and their permissions are 644
-
Both files are in the /tftpboot folder and are set to 644. Still throwing the same error. I currently have fog as the owner of the /tftpboot directory, should i change this back to root?
-
so long as the file can be read anonymously, ownership doesn’t matter
-
Good point. Is there another config file somewhere that deals with the path to the default.ipxe? I assume it just looks for it in the /tftpboot directory but perhaps this isnt the case?
-
the undionly.kpxe file automatically searches for default.ipxe in the same directory as itself.
changing that setting requires recompiling undionly.kpxe -
Not sure if this will help, but here is a screen shot of what I am getting on the client PC.
[ATTACH=full]863[/ATTACH]
[url=“/_imported_xf_attachments/0/863_20140530_143053.jpg?:”]20140530_143053.jpg[/url]
-
Try this:
[code]sudo ln -s /tftpboot/undionly.kpxe /var/lib/tftp/undionly.kpxe
sudo ln -s /tftpboot/default.ipxe /var/lib/tftp/default.ipxe[/code]Restart your client and report.
-
I had to create the tftp directory in /var/lib. After running the commands and rebooting the client i have the same message on screen. I also tried creating the links to /var/lib/tftpboot since that was an existing directory, though that also had no effect.
I also just tried with a newer client and receive the same error.
