I am getting DCHP/BootP: Reply not for us. Or PXE- E51 :no dhcp or proxyDHCP offers were recieved
-
When you installed FOG, did you setup the Options 66/67 properly in your environment?
-
Tom, the issue seems to lie in imaging only.
The FOG server we set up was originally installed with version .32 on Ubuntu 10.04; we have since upgraded to version 1.0.1 on the same server. DHCP is served through Windows Server 2008 R2, options 66/67 are configured correctly. We are using the 3.14.2 kernel. With no tasks created, systems are loading the iPXE chain fine. Registration works fine. Once a task is submitted (either through registration or through the web GUI), the process fails.
After a lease is obtained, iPXE does its thing and we receive a screen as below:
[IMG]http://i1258.photobucket.com/albums/ii540/aepriest/fog1_zpsb43d6342.png[/IMG]
[IMG]http://i1258.photobucket.com/albums/ii540/aepriest/fog2_zps582d4601.png[/IMG]
Interestingly enough, this doesn’t happen for all hosts. We have a few virtual machines that we use for keeping our deployment images up to date, and they still FOG just fine. It is, however, not contained to just one set of hardware; there are a few different systems that do this.
I’ll check Apache, but everything seems to be served over http just fine.
-
[quote=“MoellerAerospace, post: 28498, member: 24407”]Tom, the issue seems to lie in imaging only.
The FOG server we set up was originally installed with version .32 on Ubuntu 10.04; we have since upgraded to version 1.0.1 on the same server. DHCP is served through Windows Server 2008 R2, options 66/67 are configured correctly. We are using the 3.14.2 kernel. With no tasks created, systems are loading the iPXE chain fine. Registration works fine. Once a task is submitted (either through registration or through the web GUI), the process fails.
After a lease is obtained, iPXE does its thing and we receive a screen as below:
[IMG]http://i1258.photobucket.com/albums/ii540/aepriest/fog1_zpsb43d6342.png[/IMG]
[IMG]http://i1258.photobucket.com/albums/ii540/aepriest/fog2_zps582d4601.png[/IMG]
Interestingly enough, this doesn’t happen for all hosts. We have a few virtual machines that we use for keeping our deployment images up to date, and they still FOG just fine. It is, however, not contained to just one set of hardware; there are a few different systems that do this.
I’ll check Apache, but everything seems to be served over http just fine.[/quote]
Just remember, most of my signature is valid, but in your case you’re probably right that apache won’t do anything with it.
Do you have two DHCP servers though? Based on the pictures you’ve provided (extremely helpful now) it appears to be doing it’s thing properly. Why you’re seeing those messages is beyond me, but do things still operate? Based on the messages I’m seeing there’s could be a couple of things.
First, let me ask, are you booting from a USB NIC? I don’t think you are but this could be the reason you’re seeing these messages.
Second, does anything happen if you let it wait a few minutes? THe DHCP/BOOTP don’t seem to be an “issue” persay but just informative that whatever it’s receiving isn’t for the device your system is attempting to get from.
Third, if it’s not going past this part, can you perform a client compatibility check? Choose the Client System information. You may see the same dhpc/bootp messages, but it should get you to the menu option. Then choose option 4 and you should see something like:
[Disk]…PASS
[Network]…PASSOr fail.
-
Single DHCP server. Everything except for imaging for a few systems works fine (iPXE menu loads, registration works, etc).
Integrated network adapter (Intel 82567LM-3 Gigabit)
Waiting doesn’t do anything. We let the system sit all night (12+hours) thinking it might just take a good while to initialize; no go.
Compatibility test is PASS for both Disk and Network.
Now, I’m not 100% sure what all of these files do, but here’s what we’ve tried updating / changing:
Tried undionly.kpxe that was included in the source install (93.3kb) as well as one fromsourceforge.net/p/freeghost/code/1312/tree/trunk/packages/tftp/ (98.1kb) - no change in behavior.
Tried kernel 13.14.2, 13.14.4 (both the TomElliot version, not Core); no change. -
Unsure what could have changed just recently… everything is suddenly working for the systems that we had issues with.
I re-applied the 13.14.4 kernel, and everything started functioning. I’ve tried to update the kernel with different versions that we had been trying, but they all seem to be working now as well. Maybe there was just a problem with the kernel when it was downloaded. At any rate, the issues seems to have gone away. If I run into this again, I’ll try to post what kernel we have installed and all relevant configuration information.
-
Fog has been acting odd since 1.0.1
-
[quote=“Oscar Hilliker, post: 28525, member: 24172”]Fog has been acting odd since 1.0.1[/quote]
Care to elaborate?
-
Tom,
Just referring to the issue we had with it in this thread. I was wondering when it is deploying fog says “invalid bios please report” where do we report bios or computer types? -
[quote=“Oscar Hilliker, post: 28527, member: 24172”]Tom,
Just referring to the issue we had with it in this thread. I was wondering when it is deploying fog says “invalid bios please report” where do we report bios or computer types?[/quote]Only when it’s deploying or during the sending inventory part? My guess is the dmidecode that’s trying to read the bios is reporting it can’t find the information. It isn’t something you should report to us, but rather to the software maintainers for dmidecode or report to the motherboard manufacturer if you feel it’s necessary. Most people can just ignore the message though.
-
Are you still seeing this? We are getting it too. Two identical PCs right next to each other. One will work fine, the other will get the “not for us” message.
-
Roger, it took us several attempts to get fog to respond. Read Tom’s comment about options 66/67. Keep in mind that like Tom says if you have voip phone’s or anything using TFTP or DHCP server it will sometimes say “response not for us”. I noticed some computers have problems with iPXE, it’s not like the old PXE where you could fog just about anything. Check your TFTP settings on your fog server and sometimes updated the computer’s firmware helps.
-
UPDATE: we found that if we pull the AC power and the network cable then plug them back in that the PCs image just fine.
-
[quote=“Roger Saffle, post: 30483, member: 24521”]UPDATE: we found that if we pull the AC power and the network cable then plug them back in that the PCs image just fine.[/quote]
I still can’t believe this worked but it did!!
We were having issues imaging Dell Precision T3500’s. All other computers on the network FOG’ed just fine (with the exception of Dell Optiplex 3020’s but that’s another issue). While researching the 3500’s, I heard my coworker chuckle in the other cubicle. I asked what could make her laugh after fighting with these for days. She mentioned this fix and we went and tried it. Still feeling dumbfounded but the entire classroom is queued up and will be cloning overnight.
I really can’t believe this.
-
Interesting.
You pulled both power and ethernet?
If you have this issue again could you try just pulling the ethernet cable? There may be a possibility an insertion of a dhcp reset could fix the issue. Maybe?
[B]Edit:[/B]
Note added to Dell [FONT=sans-serif][COLOR=#000000]Precision T3500 and linked it to your post.[/COLOR][/FONT]
[FONT=sans-serif][COLOR=#000000][url]http://fogproject.org/wiki/index.php/WorkingDevices#Computers[/url][/COLOR][/FONT] -
I’m guessing that it’s actually a case of the network card not initializing properly. it’s previous state was not being completely cleared on shutdown, but removing power cleared it.
-
Added to more multicasting troubleshooting.
[url]http://fogproject.org/wiki/index.php/Multicasting#Power_cycle_and_Ethernet[/url]
