FOG service on 0.10.6 not restarting after reboot
-
@Arrowhead-IT said in FOG service on 0.10.6 not restarting after reboot:
I have one optiplex 790. So I’ll do some checking on that computer to see if perhaps this is happening and I missed something.
Well poo. Mine is doing the same thing…
@JbobI checked it and the fog service was stopped. Which it did mid-update from .9.12 to .10.5. I started it and then after a couple minutes it updated itself to .10.6. Gave it a reboot and the service did not start. Checking this one another computer I’m testing. An Intel Computer Stick that I did a fresh install of windows 10 32 bit enterprise. The fog client is already on it and joined it to the domain. Checking that to see if I can isolate the issue.
-
On the fresh install of windows 10 32 bit LTSB it works perfectly fine.
The other computer is a CB image, is it possible that this is a problem from a recent windows 10 update?
-
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.
-
@tmerrick Where did you get the windows 10 installation disk from? I’m assuming the windows volume licensing service center?
If you don’t use the LTSB version, then the 1511 update is included in the install in all it’s default app resetting glory. -
The more I’m looking into to whether or not this is happening, the more I am seeing it happen on any computer with the latest updates and on the windows 10 1511 upgrade.
There was another program I have called papervision that stopped working on the latest version too. It worked perfectly fine before, but suddenly it can’t communicate with web browsers. Just giving another example of windows 10 updates breaking programs that were working before. At least they give the option to defer upgrades via group policy.
Perhaps setting the fog service to delayed start is not to bad of a workaround?
-
@Jbob @tmerrick
I found something in the event viewer
Event 7009 A timeout was reached (30000 milliseconds) while waiting for the FOGService service to connect.
followed by
Event 7000 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.
In the services console their are options for automatic recovery that we can try. I hadn’t noticed these before, perhaps they’re new? Either way I’m giving a 3 time minute delay a try.
-
@Arrowhead-IT The recovery options didn’t seem to do anything. Setting to delayed start seems to do the trick.
-
@Arrowhead-IT @jbob Scratch that, delayed start didn’t do the trick and I have discovered this issue happens on all windows 10 x64 1511 computers. Why oh why did I not just use LTSB to begin with?
-
@Arrowhead-IT What’s interesting is that on delayed start the Fog service may not start, but the fog user service and the fog tray pop up no problem.
With delayed start there is nothing in the event viewer concerning the fogservice, it simply never started. -
Does the issue present itself when you re-install the client on the machine (be sure to reset encryption data when doing so) with this update?
-
@Jbob You’d think I would have tried that since I suggested it to this guy, but I have not tried that because I am dumb.
-
I’ve actually been noticing that the fog client isn’t starting for me in Win10. I didn’t think anything of it, because manually starting the service works… I’ll have to look into that.
-
@jbob A re-install of the service appears to work. Should the service not be installed in the image for windows 10 and just be added as part of a firstlogon/sysprep type script?
-
While that is a band aid, it should work until I can narrow down the root cause. Just use the msi’s switches in silent mode in your setup complete file (and then start it or restart the machine).
-
@tmerrick do you still have some computers experiencing this issue? I am attempting to track down exactly what’s failing but can’t replicate the issue.
-
I do - I had a lab of 28 computers imaged on a fresh image of win10 edu/1511. Setupcomplete re-enables FOGService after it was disabled for sysprep. Image has nothing else added except office 2016.
Of the 28 computers, 2 of them failed to start fogservice during the setupcomplete, and 8 more of them failed to start fogservice after a snapin called for a reboot after install. All 28 computers are identical, bought at the same time. i5@2.3g,4gb ram.
As with the other examples here, the fog.log has nothing in it except stating it’s gone to sleep - no exit info for shutting down with the system, and no startup. Zazzles.log doesn’t appear to exist…
I’ve changes my setupcomplete.cmd to have this in it…
sc config FOGService start= delayed-auto waitfor /t 5 null sc failure FOGService reset= 86400 actions= restart/60000/restart/60000/restart/60000 waitfor /t 5 null sc failureflag FOGService 1 waitfor /t 5 null sc start FOGService
to see if this has any effect. Note that the failure flag of 1 tells the system to restart the service if it exits unexpectedly (non-0 exit code) using the failure sequence.
This workaround won’t be tested until next deploy (next weekend maybe?)
Also - I had periodically experienced this in a VM guest (VMware ESXi 6.0 host, 4virt cpu, 8gvem). Server was practically idle at the time, and is ridiculously fast (deploy, oobe, reboot, desktop takes about 6 minutes). This same guest after another reboot started the service fine, and had been used to test images repeatedly. I’d say it was only about a 5% rate of failure to start the service in the VM.
-
v0.11 of the client should prevent this. The FOG Service will have a dependency of
dnscache
which is Window’s DNS Client. The DNS Client is one of the last network services to start and all version of Windows within reason use it. -
v0.11.0 is released and fixes this issue. Can you test when you have a chance?
-
@Joe-Schmitt I am having a similar issue though I have already updated to client 11.1 after I read this post a couple days ago. Ubuntu 14.0.4, FOG trunk 8095. In a lab of 25 Dell 790’s I had 10 or so not join the domain. I found the FOG service not running on each of them. I had no problems with my lab of Dell 7020’s or Dell 7040’s, both of which have better processors and more memory. The fog.log has no errors, immediately after imaging it commands a shutdown to rename/rejoin and then the logging stops. Unfortunately I am off-site until Monday so I can’t reach a machine to test much but I am trying to get one of my slower VM’s tested to see if it happens there.
-
Please update your server again. v0.11.2 was released and patches another power issue.