Sending Discover..... in loop
-
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
-
The problematic systems are : HP dx2480, HP dc5850, Dell Vostro 360 and HP Compaq CQ3273
[B]While Dell Optiplex 390 are working fine.[/B] -
hi
i have the same kind of situation with a laptop dell Latitude E7440. Did you finally find a solution ?Pat
-
Do you have two network cards in that laptop? Which version of FOG do you use?
-
yes ethernet and wifi. But on the boot menu, i choosed to boot from the ethernet
1.2.0 Version: 3142
Unofficial Published Kernels
Kernel - 3.19.1 TomElliott
Date : March 10, 2015
Version: 3.19.1
FOG Type: TomElliott
Arch Type: (x86_64)
