Sending Discover..... in loop
-
On HP Compaq dc5850
Upload image task
IP address is assigned correctly by DHCP.
but it shows the message ‘Sending discover…’ in loop…[ATTACH=full]1642[/ATTACH]
FOG Version 2942 on XUbuntu 14.04
[url=“/_imported_xf_attachments/1/1642_screenshot.jpg?:”]screenshot.jpg[/url]
-
Is this a USB device?
-
[quote=“Tom Elliott, post: 41456, member: 7271”]Is this a USB device?[/quote]
its not USB device,
-
Is it, then, possible you have multiple DHCP servers (maybe using proxyDHCP for pxe boot)?
-
I am seeing the same issue at a campus but it is port dependent not machine when the machine is brought back to our central office the machine images fine. We will investigate this tomorrow and let you know what we find.
-
[quote=“Tom Elliott, post: 41459, member: 7271”]Is it, then, possible you have multiple DHCP servers (maybe using proxyDHCP for pxe boot)?[/quote]
I have two DHCP servers on my network. MAC binding is done for each computer on network on DHCP servers.
Machine is getting the correct IP parameters from FOG Server.
-
It’s getting correct IP parameters and forwarding NIC Boot parameters to the proper server, but when it’s in the init.xz/init_32.xz it’s no longer requesting on the NBP system and needs to pick up the IP respective to itself.
From the Discovers that you’re seeing I imagine it’s getting requests from Both DHCP servers at the same time. This would explain why it’s not handing you the DHCP address. Based on what I can tell, it sounds to me like it’s receiving DHCP offers from both DHCP servers. As it has to acknowledge both, it doesn’t know which one to use.
These are just my guesses. Are you able to, temporarily, disable one of the DHCP servers during the bootup of this machine and see if you get better luck?
-
I have also checked disabling the second DHCP Server, the problem remains there.
I also removed the host from server and tried Full Registration form FOG menu but the same message ‘Sending Discover…’ displays for indefinite time.
Should I try to use FOG 1.2.0. Will my current database support FOG 1.2.0 ?
-
2942 downgraded to 1.2.0 will not work.
I don’t think it’s the menu though either.
If you want you could try upgrading 2950 being the latest svn. I did have to update the kernel between 2942 and 2950 so maybe there was a kernel issue? Have you had this problem for a long time or only since the last update?
-
Now I am having 2950 but the issue remains there.
It was working fine up to Jan 16, 2015, i uploaded and downloaded the images on that day. But i don’t remember the version which i was using. After that I upgraded three or four times from svn.
Is there any updation log on fog server that can tell me which version I was using on Jan.16, 2015.
-
No there isn’t a log directly telling you what revision you may have been on.
I don’t know if you where updated to anything that was on January 16 either.
The only guess I have is the kernel you were using and even that is unknown at this point.
The revisions that were pushed on January 16 where SVN 2904 thru 2908.
I don’t know what has happened, but if it all worked, then randomly (seemingly) stopped, I lead towards there being a potential for a “Rogue” DHCP server that’s handing out information that’s unexpected.
Why? Well beyond the point where I basically broke networking on the kernel which has now been fixed, Nothing from a DHCP standpoint has changed. There’s’ been some code changed in the init, and in the GUI, but nothing relating to how your systems get IP addresses. If it was working, then just stopped, it would seem to me that it would be environment related.
-
I think I was using svn 26xx version (don’t remember the ‘xx’) of FOG. Can you please tell me from where i can download that version.
Thanks
-
I would think downgrading at this point would be a bad idea I would suggest getting up to the latest svn which as of today is at 2961 and see if that resolves your issue.
-
To reinforce what Hales is saying, downgrading is a very tricky business. The SQL database that FOG uses evolves with some of our SVN updates, that’s why when you upgrade you have the “Schema upgrader” web page. In order to downgrade you would either need to start form scratch or manually revert the db to its prior state, which without backups would be quite an accomplishment. You’re best bet is to keep trying the latest svn (we release new builds daily), and keep debugging, this sounds like a network configuration issue.
-
I updated to the latest svn 2974. But the problem remains the same.
I also isolated the Server and Host from main network and connected them using a separate network switch.
- The host gets correct boot IP.
- The host displays FOG menu correctly.
on selecting any of the menu options
‘Perform Full Host Registeration…’ OR
‘Quick Regiseration and Inventory’ OR
‘Client System Information …’screen displays
/bzimage… ok
/init.xz … okAfter this the same continuous screen display…
‘Sending Discover …’
‘Sending Discover …’ -
Anything in the logfiles (probably /var/log/syslog on ubuntu/debian), for example:
[CODE]Feb 3 18:14:44 free dhcpd: DHCPDISCOVER from 52:54:00:12:34:56 via eth0
Feb 3 18:14:45 free dhcpd: DHCPOFFER on 192.168.0.12 to 52:54:00:12:34:56 via eth0
Feb 3 18:14:47 free dhcpd: DHCPREQUEST for 192.168.0.12 (192.168.0.250) from 52:54:00:12:34:56 via eth0
Feb 3 18:14:47 free dhcpd: DHCPACK on 192.168.0.12 to 52:54:00:12:34:56 via eth0[/CODE]Would you mind running tcpdump to capture the packets while this is happening and upload the packet dump?? Please install tcpdump and run this on the server while the client boots up (change ‘eth0’ to whatever your FOG interface is):
[CODE]tcpdump -i eth0 -nn -s 0 -w dhcp-problem.pcap[/CODE]Probably a good idea to keep your setup isolated (just server and client) to not fill the capture with lots of nonsense packets too. ZIP/TAR.GZ the pcap-file before uploading.
-
I’m not sure if it’s related but I have a similar issue on a box that has more that 1 network card. The initial boot sequence will use the main ethernet port, then the latter portion of the boot sequence wants to use the second port.
In my case what happens is that ethernet port #1 will properly load the bzImage and init_32.xz. After that the s40network script brings up eth0 but now eth0 points to the second network port.
I’m using the SVN version from yesterday, BTW.
-
[quote=“kirk_, post: 41722, member: 27883”]I’m not sure if it’s related but I have a similar issue on a box that has more that 1 network card. The initial boot sequence will use the main ethernet port, then the latter portion of the boot sequence wants to use the second port.
In my case what happens is that ethernet port #1 will properly load the bzImage and init_32.xz. After that the s40network script brings up eth0 but now eth0 points to the second network port.
I’m using the SVN version from yesterday, BTW.[/quote]
I was having the exact same problem, “Sending discover” just constantly looped
Took the second NIC out of the PC and it’s working like normalI’m running SVN 2973
EDIT: I was trying to do a full registration, the PC wasn’t registered yet and hadn’t tried adding it manually
-
Have you tried adding both MAC addresses to FOG?
-
[quote=“Joseph Hales, post: 41724, member: 18131”]Have you tried adding both MAC addresses to FOG?[/quote]
I tried adding another MAC address on a different host and the add MAC button doesn’t do anything when I click it
