Great work, thanks 🙂

@DarkStorm007 This is a very old post you opened up again. FOG was very different and has changed a lot. Please open your own topic and leave this old one alone.

Start the new one by telling us what version of FOG you are running and maybe the names of the fields you ask about (I guess it’s about printers but why should I have to guess, just tell us!!). Maybe even post a picture if you don’t want to spend words on it.

@tom-elliott

Tom,

We’re good on the cancellation issue, but I’m still seeing a series of packets with the same start time and ever increasing durations times for each subsequent snapin.
0_1502401559812_8e8425e1-fa40-46a0-a798-24addf32556d-image.png

I didn’t get that you made a change. I doubt I can be of any help with the code, but I’ll look.

The screenshot above is a single deployment of an image with several snapins. There’s a reboot after 0-W7PostImageCleanup and another after 1-UACDisable. So there are 3 “series” of snapins in this deployment.

2017-08-10 12:24:36 (2 snapins)

2017-08-10 12:25:28 (1 snapin)

2017-08-10 12:26:14 (6 snapins)

All scheduled as part of the image deployment and all separated only by reboots implemented by FOG as part of a snapin.

Jim

@themcv

OK - so yeah, maybe it was a DNS issue on the client side after all. One of the snapins I’m working on dorked the DNS search list.

I determined this by examining the spanins deployed to the host - 100% alignment with snapin that dorks the DNS searchlist.

Go Figure…

Thanks and sorry for the trouble…

Jim

Trying using noapic as a kernel argument.

Fixed, we appear to be uploading now.

@tom-elliott
I just tested Host registration and deploying image. So I confirm. It works.

@caw001 If that is the process you followed then something is not right with either the fog server or the usb module. Let me look into it. The kernel parameters don’t look correct. There should be more info in the kernel parameters almost like the grub config file is damaged. It should list the web server and storage info.

@chris178 I was able to fix the issue. If you can do a git pull from the fog-community-scripts directory on your server, you’ll get the latest copy - then rerun the installer and everything should work.

If you’re curious about changes, you can see them here:
https://github.com/FOGProject/fog-community-scripts/commits/master

Hi,
Now it works, I forgot to change the IP address in storage management.
Thanks a lot.

Nvm. Fixed. Ran the following from the troubleshooting page.
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL

DELETE FROM `hosts` WHERE `hostID` = '0'; DELETE FROM `hostMAC` WHERE hmID = '0' OR `hmHostID` = '0'; DELETE FROM `groupMembers` WHERE `gmID` = '0' OR `gmHostID` = '0' OR `gmGroupID` = '0'; DELETE FROM `snapinGroupAssoc` WHERE `sgaID` = '0' OR `sgaSnapinID` = '0' OR `sgaStorageGroupID` = '0'; DELETE from `snapinAssoc` WHERE `saID` = '0' OR `saHostID` = '0' OR `saSnapinID` = '0'; DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC` WHERE `hmPrimary` = '1'); DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC`); DELETE FROM `hostMAC` WHERE `hmhostID` NOT IN (SELECT `hostID` FROM `hosts`); DELETE FROM `snapinAssoc` WHERE `saHostID` NOT IN (SELECT `hostID` FROM `hosts`); DELETE FROM `groupMembers` WHERE `gmHostID` NOT IN (SELECT `hostID` FROM `hosts`); DELETE FROM `tasks` WHERE `taskStateID` IN ("1","2","3"); DELETE FROM `snapinTasks` WHERE `stState` in ("1","2","3");

Thanks for your feedback.

Cleaning the databases didnt solve it, will wait for the change to come to one of the higher stable branches.

@gotesson I’m only recommending searching for any bugs you might run into with the RC-6. If you’re unsure go ahead and post, and I’ll likely let you know if it’s known about/fixed or not anyway.

that worked, thanks everyone for the troubleshooting.

@msaglioc99 Has it worked in the past? What changed? Network, router, …?

Another thing that shows up in the log:

Several of the modules (for example: TaskReboot or the HostnameChanger) list:

Middleware::Response Module is disabled on the host

Where would I even do that? On the server - as far as I can see from the web-gui - the modules are activated. I also deactivated and reactivated them to see if that would kickstart anything - no success.

EDIT:
Okay … I just saw that one of the two hosts I deployed the image to had the modules deactivated in the Service Settings. I have no idea why, it is enabled globally and the other machine does not have them deactivated.
Now in the fog.log the Modules are shown with a response success on the one machine (the one that had the services disabled) but the “Unable to get subsection” message still appears on the other machine.

EDIT2:
The computer that had the services disabled just restarted - so in that case it seems everything works.

EDIT3: After reading some more I tried resetting the Encryption Data and aw and behold - everything seems fine now. Thanks for reading along if you have 🙂

Sorry if I’m being complicated - just trying to figure this out 😕

Thanks George !
Sorry for thanking you too late but i didn’t think that i will get the answer that fast haha !
Anyway Thanks again !

#Resolved

@sebastian-roth I worked around the issue using an iPXE boot ISO.

@dirtyhandz lets start with how did you create this dvd to begin with? Did you have instructions?

-Or- My intuition just said; break that dvd into smaller bits. A win32 iso, a win64 iso and then utilities iso.

@JLE Looks quite interesting that packet dump. Something I have not come across in a long time. I am trying to write down what I see in the PCAP to hopefully make any sense as I don’t see what’s wrong yet. Maybe George can add to that as well.

First the PXE ROM of the NIC sends a DHCP Discover and does not get an answer. So 8 seconds later it sends another Discover (same information but just a new DHCP transaction ID). The second DHCP Discover is answered with a DHCP Offer very promptly (delay only ms). Transaction IDs of the second Discover and the following Offer match so the answer is definitely not a delayed one to the first Discover. Question: Why is the first DHCP Discover not answered? (this is happening again later on) As far as I can see the DHCP Offer looks good (next-server and filename set properly). Now the client is quiet for 16 seconds before sending a DHCP Request packet to complete the DHCP communication. This Request packet is promptly answered by a proper looking DHCP ACK. So client is finally happy I suppose. Then I suspect the TFTP transfer to happen which was not captured. See the next bullet point. Another 12 seconds after the first DHCP DORA (Discover, Offer, Request, ACK) finished I see a new DHCP Discover from that client. This time option 175 is set which is a clear sign for iPXE sending the packet. And the same thing is happening again. No answer from the DHCP server for 8 seconds and the client (now iPXE instead of the PXE ROM) sends another DHCP Discover which is promptly answered with a fine DHCP Offer. After the Offer the client sends a third DHCP Discover and then a DHCP Request just a second later. I think this is where things start to go really wrong. I suppose iPXE is very confused about the DHCP server only answering the second DHCP Discover (matching transaction ID). I haven’t checked the iPXE code yet but I guess this is something unexpected now causing an issue in your case. Following are a row of DHCP Request packets from the client which are all answered by DHCP NAK (non ACK!) packets. So the DHCP server declines to give that offered IP information to the client. Result is the “No configuration methods succeeded” message in iPXE. In the packet dump I see the same thing happening again a minute later. But one thing is different this time. The very first DHCP Discover sent by the client’s PXE ROM is answered within one second this time. But for the DHCP Discover sent by iPXE I see again the exact same behavior as described above.

I guess this can be fixed in iPXE but I doubt this is the right place to do so. There is something wrong within your network. Do those first DHCP Discover packet get lost somewhere along the way? Why is the second one answered so promptly then?

Ok, I’ll leave this ti you for now. We all need to think about it and I am sure someone will come up with a proper explanation on what’s going wrong here.