FOG 1.2.0 w/ DHCP/BOOTP Reply not for us
Current OS: Ubuntu 14.04
Current Fog: 1.2.0
Current Kernel: Unofficial Published Kernel 3.16.0 x86_64
Windows DHCP server with 067 set to pxelinux.0 and 066 set to ip of fog server
Followed [URL=‘http://fogproject.org/wiki/index.php/Chainloading_PXE_to_iPXE_using_pxelinux.0’]guide[/URL] to chainloading PXE to iPXE because we could not get undionly.kpxe to work.
Dell optiplex 755 gives a No DHCP or proxyDHCP offers were received. If allowed to boot to windows then restarted it will get past that and then give us a DHCP/BOOTP Reply not for us.
Optiplex 760’s also give the Reply not for us error but do receive a DHCP address with out going to windows first.
So far it seems to work just fine on our optiplex 745’s and Precision T1600’s.
This did work for the 760’s and 780’s as well. Thank you very much for the help Jbob, Junkhacker, and Tom
Jbob thank you that seems to be working on the 755, I will be able to test on the 760 and the 780 later this afternoon.
That error “No DHCP or proxyDHCP offers were received” sounds like the computers are looking to FOG for an ip address ( I have run into this issue but with a different model), this method should also get your undionly.kpxe working without the need of chainbooting. First undo the changed you have made to chainload PXE to IPXE. Once that is done,install dnsmasq by running [B]sudo apt-get install dnsmasq[/B] Then follow this guide. [url]http://www.fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#DNSMASQ_settings_for_iPXE[/url], (ltsp.conf is located in /etc/dnsmasq.d/)
If your computers are on the 192.168.x.x subnet, change the line in /etc/dnsmasq.d/ltsp.conf that says
Afterwards restart the dnsmasq service. If running [B]sudo service dnsmasq restart[/B] fails, use [B]sudo /etc/init.d/dnsmasq restart[/B] instead.
Ensure that you did that step where you made a symlink between undionly.kpxe and undionly.0, if you don’t computers won’t find a file to boot to.
Once you have completed those steps, test a computer.
If this method works, you can disable the 3 second time-out on network boots by changing the line [B]pxe-prompt=“Press F8 for boot menu”, 3[/B] in /etc/dnsmasq.d/ltsp.conf to [B]pxe-prompt=“Press F8 for boot menu”, 0[/B]
So what has changed from version .32 where this worked with no problems on our network to now? We do not have STP enabled on our network. All switches are Extreme Networks brand
i have tested the 755 and 780 myself, the problem is your network
I can now add a third model to my list that will not work. So total that I have on my campus that will not register with fog include Dell optiplex 755, 760, and 780. They all three give the DHCP/BOOTP Reply not for us error.
After letting them sit for awhile they do go into the registration process then do what is in the picture.[ATTACH=full]1264[/ATTACH]
I have tried both undionly.kpxe and undionly.kkpxe from official 3.14.2 kernel as well as the unofficial 3.16.0 kernel. They both still give me the DHCP/BOOTP Reply not for us message on the Optiplex 755 have not tried on the 760 yet.
if you set the network to boot to one of the ipxe file, like undionly.kpxe, that should be all you need to do. the chainloading is done by pxelinux.0, and if that’s not the network boot file, the chainloading isn’t done
I have a lab of 1600’s that is currently being deployed. Once it is done I will try that one and let you know. Is there a process I need to do to undo the chainloading of pxe to ipxe or will it matter?
Tom Elliott last edited by
Have you tried the undionly.kkpxe supplied?
I am not sure on portfast, STP is disabled but there is plans to enable extremes version of STP called ELRP.
do you have portfast enabled? is STP disabled?
Windows server is a 2008 R2 and all switches are extreme networks. Fog server is an optiplex 745.
then i suggest figuring out why undionly.kpxe isn’t working, and fix that. what kind of network equipment stands between the clients and the fog server, and the dhcp server?
When attempting undionly.kpxe we could not get any of them to work. After following the guide to chainloading PXE to iPXE we were able to get at least the 745’s and 1600’s to work.
“067 set to pxelinux.0”
this is wrong for any version of fog 1.0+
i have no idea how it could be working on any of your systems, unless you have configured pxelinux.0 chainloading. which is not the recommended method