Posts made by tmerrick

The FOGScheduler logs just show my 7 scheduled cron wake up jobs. I have disabled all of the FOG services and they still started up. Thus it does not appear to be FOG. I am trying to get a hold of a network analyzer to trace who is really sending this signal. Thanks for your help in understanding how FOG works, it has helped me narrow down who is causing the problem.

I know it is a WOL being sent as my boot is SSD, then IP/PXE and it is PXE booting. Also, it is only happening in one of my three buildings. And only about 1/3 to 1/2 of the computers that I have in that building. So it looks like I have a rogue server somewhere in that building.

I did not receive any packets from the server subnet using your tcpdump command. Unfortunately the computers in question are on a different subnet. I know that it is a WOL packet since the following shows up in the server messages log:

Dec 16 23:04:02 clstfogi in.tftpd[16975]: tftp: client does not accept options
Dec 16 23:04:02 clstfogi in.tftpd[16976]: Client 10.4.134.75 finished undionly.kpxe
Dec 16 23:04:07 clstfogi in.tftpd[17006]: tftp: client does not accept options
Dec 16 23:04:07 clstfogi in.tftpd[17007]: Client 10.4.134.78 finished undionly.kpxe
Dec 16 23:04:09 clstfogi in.tftpd[17053]: Client 10.4.134.75 finished default.ipxe
Dec 16 23:04:14 clstfogi in.tftpd[17111]: Client 10.4.134.78 finished default.ipxe

The computers all boot to the SSD, but have WOL+PXE boot enabled. So I should not see anything unless it is a WOL boot. So it does not appear to be a FOG issue, but rather a rogue server on that subnet.

Found about 140 rows, but they still turn back on. I even rebooted to make sure that nothing was in memory.

There are only two scheduled tasks for deploying snapins to other computers. Power management only shows a scheduled 11pm shutdown, but then turn back on 15 min later.

I have FOG 1.4.4 on RedHat and most everything seems to be working okay. Except that I have a number of hosts that get turned back on by FOG about 10-20 min after I shut them down (either manually, remote desktop, or via FOG power management). I have not been able to find anything in FOG’s logs to indicate that this is happening. I assume that I have something in my database that is causing this since is only happening on 35 of 280 computers. Any ideas of where to look?

The error that I had was a firefox problem.

What privileges do I need to upload a picture?

Windows 10

How do you do that? It is whatever it loaded when the client updated. In the Programs and Features list there is no .net less than 4.5.

I have a client with 2 power management cron jobs and the following error happens when I reimage the client:

------------------------------------------------------------------------------
--------------------------------PowerManagement-------------------------------
------------------------------------------------------------------------------
 8/17/2016 9:26 AM Client-Info Client Version: 0.11.5
 8/17/2016 9:26 AM Client-Info Client OS:      Windows
 8/17/2016 9:26 AM Client-Info Server Version: 1.3.0-RC-8
 8/17/2016 9:26 AM Middleware::Response Success
 8/17/2016 9:26 AM PowerManagement ERROR: Data conversion using the DataContract FOG.Modules.DataContracts.PowerManagement failed
 8/17/2016 9:26 AM PowerManagement ERROR: Cannot deserialize the current JSON object (e.g. {"name":"value"}) into type 'System.Collections.Generic.List`1[FOG.Modules.PowerManagement.Task]' because the type requires a JSON array (e.g. [1,2,3]) to deserialize correctly.
To fix this error either change the JSON to a JSON array (e.g. [1,2,3]) or change the deserialized type so that it is a normal .NET type (e.g. not a primitive type like integer, not a collection type like an array or List<T>) that can be deserialized from a JSON object. JsonObjectAttribute can also be added to the type to force it to deserialize from a JSON object.
Path 'tasks.1'.

I am not sure if this is a client and/or server issue.

It had to do with an old 0.10.6 fog client not being able to run. I tried to update it with the 0.11.5 msi installer, but got the above error. I went ahead and reimaged that client. Now I cannot duplicate it on that client or a number of others. So it was probably my client that was corrupt.

This is on a Windows 10 client using the msi installer.

When I try to install the fog client manually, I get a JSON error while creating the settings file and it aborts installation.

Confirm that it works in GIT 8259.

Any idea if this is a client or server problem? The client seems to be forming the URL with the information in it. BTW this is not a new problem with 0.11.2.

I agree. There should be a delete all power management entries on the group power management screen.

UserTracker does not seem to be working. I see the entries in the fog.log file, but nothing appears on the Red Hat server via the reports or my own program.

------------------------------------------------------------------------------
----------------------------------UserTracker---------------------------------
------------------------------------------------------------------------------
 6/24/2016 8:41 AM Client-Info Client Version: 0.11.2
 6/24/2016 8:41 AM Client-Info Client OS:      Windows
 6/24/2016 8:41 AM Client-Info Server Version: 8241
 6/24/2016 8:41 AM Middleware::Response Success
 6/24/2016 8:41 AM Middleware::Communication URL: http://10.3.64.58/fog/service/usertracking.report.php?action=login&user=CI347-04\tmerrick&mac=18:66:DA:09:24:6C||00:00:00:00:00:00:00:E0&newService&json
------------------------------------------------------------------------------

 6/24/2016 8:41 AM Middleware::Communication URL: http://10.3.64.58/fog/management/index.php?sub=requestClientInfo&configure&newService&json
 6/24/2016 8:41 AM Middleware::Response Success
 6/24/2016 8:41 AM Service Sleeping for 239 seconds
 6/24/2016 8:45 AM Middleware::Communication URL: http://10.3.64.58/fog/management/index.php?sub=requestClientInfo&mac=18:66:DA:09:24:6C||00:00:00:00:00:00:00:E0&newService&json
 6/24/2016 8:45 AM Middleware::Response Success
 6/24/2016 8:45 AM Middleware::Communication URL: http://10.3.64.58/fog/service/getversion.php?clientver&newService&json
 6/24/2016 8:45 AM Middleware::Communication URL: http://10.3.64.58/fog/service/getversion.php?newService&json

 6/24/2016 8:45 AM Service Creating user agent cache
 6/24/2016 8:45 AM Middleware::Response Success
 6/24/2016 8:45 AM Middleware::Response Module is disabled globally on the FOG server
 6/24/2016 8:45 AM Middleware::Response Module is disabled globally on the FOG server

I am not sure about the last two entries. I think that everything is enabled for UserTracker as in the first part but there is never a middleware success response to the actual reporting of the logon.

Yes, I have a working solution.

It is failing on both Toshiba (Class 10) and Samsung (Class 20) SSDs. I am not sure what the difference from a plan old Samsung EVO and these are, but the EVO sanboots fine.

I usually use PXE boot as they are student computer labs that I multicast 2-3 times a year.

Yes, it was SANBOOT before. As I recall, the exit type failed also, but the grub first hard drive does work. Yes, they are traditional sata attached ssds.

They are bios with global exit mode. Yes, I have about 200 computers that work fine, but these are the first with SSDs. The host registration/imaging part works fine. It is just the chain to the local SSD that is failing.