Posts made by tmerrick

Nope. It is 10.3.64.58 on the storage management page and the interface there is set to eth0 also.

I am running Red Hat 6.7 at FOG 7671 and multicasting is not working. I traced it down to the following message:

[05-18-16 10:19:33 am]  | CMD: cat /images/CSCI10/d1p1.img | /usr/local/sbin/udp-sender --interface eth1 --min-receivers 4 --max-wait 600 --portbase 60806 --full-duplex --ttl 32 --nokbd --nopointopoint;cat /images/CSCI10/d1p2.img | /usr/local/sbin/udp-sender --interface eth1 --min-receivers 4 --max-wait 600 --portbase 60806 --full-duplex --ttl 32 --nokbd --nopointopoint;
[05-18-16 10:19:33 am]  | Task (51) Multicast Quick Deploy has started.
Udp-sender 20120424
Using mcast address 232.168.1.15
UDP sender for (stdin) at 192.168.1.15 on eth1 
Broadcasting control to 224.0.0.1

It is using eth1 even though the FOG_UDPCAST_INTERFACE is set to eth0 under the Multicast Settings. As a result all of the client computers get to partclone and just sit there.

Mine definitely fails during the imaging process. The delayed start seems to make it work, but this is not a fix.

The image is definitely up to date and may have the dreaded 1511 upgrade installed. I have not been able to tell if it does or not. It is not showing up under windows updates.

I installed it fresh on a client without all of the CAD programs and it worked. So it is not a 10 Enterprise problem.

I then did a fresh install on the client - Deleting the FOG program folder and re-installing (and resetting the Encryption key). And this also has worked.

I have updated the server copy and I am sysprepping right now. I will let you know the results in about an hour.

I already tried to uninstall/reinstall the service to no avail. It was a clean install of windows, but now is very customized with CAD and other programs. The physical boxes are Dell Optiplex 960-990 intel i5 computers where the image was also created.

X23 - yes the delayed start does seem to work in the few cases that I have tried so far. Also, this is Windows 10 Enterprise on older physical machines with only 4 GB memory.

“c:\Program Files (x86)\FOG” does not have a zazzles log file in it. It only has the .dll and .xml files in it.

There is nothing in the FOG log after the reboot. The job is failing before it writes to it. Did you want the log before the reboot?

I found two more entries in the Event Log. Here are all 3:

Task Scheduler service found a misconfiguration in the NT TASK\FOG\0@23@s definition. Additional Data: Error Value: C:\Program Files (x86)\FOGPower.exe.

The FOGService service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion

A timeout was reached (30000 milliseconds) while waiting for the FOGService service to connect.

The first one is keeping GreenFog from working. The last one (first in time order) was why the FOGService failed. This should either have a much longer timeout or dependency as it is taking Windows 10 too long to initialize things.

That is how I detected that the service was not running. The fog.log stays at the last time stamp and never updates. So there are no entries there. But the event log has:

FOGService service failed to restart due to the following error: The service did not respond to the start or control request in a timely fashion.

I seem to be seeing a race condition on the FOG service on Windows 10 where the startup fails after windows starts. My server is at 7647 and the client FOG service runs okay after I start it up via the services panel. Just to test it out I added an automatic restart on the service after it fails and this starts it up after a reboot. Is it dependent on the Task Scheduler service?

Could we add a feature to fog that automatically resets the encryption data on successful imaging? It will never be valid in this case and would reduce the need for resetting the encryption in most cases.

All of mine are new clients. I will check again next Wednesday. I first saw this during multicast setup under group, but the last few have not been touched for awhile and just seem to disappear. I have a local program and I had to set it to ignore host entries with null names.

I am seeing the same thing on 4493 on Red Hat 6. Random deactivations or even complete deregistration of clients. I had 49 in one classroom and now it is only showing 47. This started happening sometime after 4266 and has been randomly failing since then.

It works now in git 4493.

Here is the directory of the fog certificate area on the server:

-rw-r--r-- 1 apache apache  1287 Aug 25 07:51 ca.cert.der
-rw-r--r-- 1 apache apache  1797 Aug 25 07:51 ca.cert.pem
-rw-r--r-- 1 apache apache 35147 Aug 25 07:51 gpl-3.0.txt
-rw-r--r-- 1 apache apache    89 Aug 25 07:51 hostimport.csv
-rw-r--r-- 1 apache apache  4493 Aug 25 07:51 index.php
drwxr-xr-x 2 apache apache  4096 Aug 25 07:51 ssl
[root@clstfogi other]# ls -l ssl
total 4
-rw-r--r-- 1 apache apache 1675 Aug 25 07:51 srvpublic.crt

It looks like all of the files were regenerated when I reinstalled this morning, unless there is one missing. Are the files being created wrong?

I have some more information. I deleted the fog certificate and then did a repair on fog and got the message “Failed to download CA certificate”. So it still looks like a problem with the certificate on the server.

Later I uninstalled the fog client, rebooted, and successfully reinstalled it. Still getting the same errors though.

I just upgraded to 4491 and now the hostnamechanger fails on my clients also with an Invalid Host Certificate. I am running on Red Hat 6.6 and it did work before the upgrade. I have taken one client and uninstalled/reinstalled the new client and it still does not work. I am also seeing problems on previously installed new clients when the hostnamechanger runs on them.

Here is part of the access log for each computer and it happens every minute, not 5 minutes that I thought that I had set above.
access_log.txt

Fog version 4266, Red Hat 6.6 server.