FOG Client 0.11.2 not starting right

[Wayne Workman]

We’re using FOG 1.3.0 RC-2 with 0.11.4 on the server.

We just imaged some EliteBook 8730w laptops with Windows 10 LTSB. The image has fog client 0.11.2 installed on it.

It would appear that the fog client on the image isn’t able to update, not sure why.
Here’s the log, there are only a couple of new entries since imaging at the very bottom.

0_1469555360762_fog.log

Here’s the user log:
0_1469555513796_.fog_user.log

After a reboot, it appears to work right.

The image is not sys-prepped.

[Tom Elliott]

What I see is the client couldn’t communicate with the server. That said, it also only shows the errors from 6/30/2016 then it shows the zazzles issue from this morning.

Can you try restarting that client?

Also, can you update? We’ve released 1.3.0-RC-3, just haven’t posted the news article yet.

[Wayne Workman]

@Tom-Elliott I’ll reboot the laptop first and see what it does. I would expect it to work, since all the other laptops of this model and image work after a reboot.

[Wayne Workman]

It works fine after a manual reboot.

But this is still bad news for people not in a position to manually reboot.

[Joe Schmitt]

It appears 0.11.4 is failing to start. What’s odd about your log file is that there no client updater section that is reporting an available update, it just jumps straight to loading the new client.

Did you manually update this? If not are you using a fog.log in the program files directory? If so is there another fog.log floating around somewhere? (Like c:\fog.log)

[Wayne Workman]

@Joe-Schmitt I did not manually update it. We were just using the image we made maybe a month ago, and found the issue. all 30ish laptops were affected.

I’ve never told the fog client to use a different location. Every image we have, its c:\fog.log

Other information that may or may not matter:
Wifi was turned on in the image, but laptops were also connected to a LAN for imaging and domain joining.
there are 5 snapins associated with these hosts. Avast, Meraki, SmartNotebook, a batch script that sets the timezone, and one that installs Chrome.
These machines are core 2 duos, but are very beefy for their age.
64 bit Win10 LTSB.
Onboard ATI Radion graphics, which aren’t really bad at all.

Post-imaging, windows starts downloading windows updates. The amount it does depends on how soon we rebooted them manually.

[Joe Schmitt]

@Wayne-Workman according to your log files the client never updated, or even tried to do so. In addition how did you make your image? According to the log file it was running on 6/30/2016, and immediately jumps to 7/26/2016. The odd thing about that is inbetween those two there is no reference to a service controller stop/unload request. This means the client was killed directly (possibly an immediate host computer shutdown) instead of using the service controller like a standard shutdown does.

[Wayne Workman]

@Joe-Schmitt I can’t say I really remember how I shut it down a month ago.

Typically, I use the basic windows 10 shutdown method, just Start -> Power -> Shutdown.

It’s possible I could have forced shutdown, like how Windows sometimes asks when things are waiting to terminate still. I don’t remember.

[Tom Elliott]

@Wayne-Workman I’ve marked this question as unsolved and moved it, for now, into FOG Problems.

The reason for the move is if 0.11.2 were indeed the problem (itself) I’m fairly certain it would’ve been brought up by now.

We do have the occasional weirdness things popping up from time to time but this would have been immediately seen.

I suspect what happened is the “force shutdown” occurred and the the “rug was pulled right out from its feet” if you will.

I don’t think this is a bug, rather just a bad timing that happened to have been captured in the “strange” state.

[Wayne Workman]

Crosslinking related threads:
https://forums.fogproject.org/topic/8189/power-management-scheduled-shutdown-flakey