Posts made by sysadmininstalls

this is the result of someone changing the image type to raw when it is not.
This was solved by switching the image type back to the correct option.

We are on fog 1.2.0 and attempting to restore images made back with fog 0.32 is giving the message "Can’t read the following volume file: /stdin001 ".

They are set to partimage since they are so old.

The /images directory contains the correct files and they all have 777 perms.

The snapin was saved a week ago. After the rename it appears to have become unassigned from the machines. The snapin is still there.

Helpdesk team reported the issue wrong.

They renamed the snapin, and that caused it to disappear. Ideally, that would not break the association. They had thought a guid or something like that was used, but that might not be the case.

Centos 5
Fog 1.2

We are looking at each host. They assign fine, but disappear once they are applied.

This is based on the claims of my helpdesk team. I am looking into it.

We assign/link snapins to hosts and once they are deployed they no longer appear to be assigned. Is that the expected behavior?

We had hoped that they would stay assigned for future use.

Thanks, turns out restarting apache was not enough to make it work. Reboot solved the issue.

While the change in format was not the cause, it sure as heck looks confusing.

1.2.0 on Centos 5.11

If we attempt to schedule a snapin task, it refuses saying the it is in the past.
[CENTER][SIZE=16px][FONT=Ubuntu][COLOR=#ff0000]Failed to create deployment tasks for the following Hosts[/COLOR][/FONT][/SIZE][/CENTER]
[SIZE=16px][FONT=Ubuntu][COLOR=#ff0000][CENTER] [/CENTER][/COLOR][/FONT][/SIZE]
[LIST]
[*]FJQXNM1: Scheduled date is in the past. Date: 2015/20/02 12:27
[/LIST]
The format changes from YYYY/MM/DD to YYYY/DD/MM as you see in the error.
I tested this by scheduling a job for the 3rd of March which works fine. Meaning that the date format changing between selection and actual scheduling is the problem.

I have several hundred machines, so reimaging them all is out. I am trying to update the various DLLs and see where that gets me.

in the logs I see the machine tried to access

/fog/service/register.php?mac=00:18:8B:8C:2C:0D&hostname=6P1QBC1&ip=10.10.222.166&os=1
If I view that in a browser from the same machine I get
#!er:Invalid Version Number, please update this module.

The windows desktops display “unable to register host with fog server due to an unknown error” every time they are booted. The fog.log shows nothing of any interest and I am unsure where to go from here.

Fog 1.2
Centos 5.11

Not sure if it is related, but installing any snapin works, then we get the following:
2/16/2015 3:57 PM FOG::SnapinClient FOG Snapin Installtion complete.
2/16/2015 3:57 PM FOG::SnapinClient Installation returned with code: 0
2/16/2015 3:57 PM FOG::SnapinClient Attempting to connect to fog server…
2/16/2015 3:57 PM FOG::SnapinClient Unknown error, module will exit.
2/16/2015 3:58 PM FOG::GUIWatcher Message found, attempting to notify GUI!
2/16/2015 3:58 PM FOG::GUIWatcher Dispatch OK!
Which means until the service is restarted no more snapins can be deployed.

I am not sure what you mean by every time.
We upgraded fog and any machine we reboot the snapin service works fine. Any machine not rebooted no snapins are deployed. Even simply restarting the fog service on the client resolves the issue. Eventually all the machines will be rebooted and that will have solved the issue. It is simply unexpected that we would need to reboot them.

XP, unfortunately.
As soon as the service is restart either via reboot or net stop and net start it works fine.

Sorry, I simply should have said only working on machines that we have reinstalled fog client on.

Upon further testing, the service needs to be restarted to function properly. On every machine that I have restarted the service on, it works fine. Otherwise it never installs the snapin. Perhaps this should be noted in the upgrade notes, or maybe it is due to something we did.

We upgraded from 0.32 to 1.2 and snapins are working only for machines with the new fog client service, is this expected behavior? Is there any method to have it tell these clients to update?

2/12/2015 2:21 PM FOG::SnapinClient The remote server returned an error: (500) Internal Server Error.
2/12/2015 2:21 PM FOG::SnapinClient at System.Net.WebClient.DownloadFile(Uri address, String fileName)
at System.Net.WebClient.DownloadFile(String address, String fileName)
at FOG.SnapinClient.startWatching()
2/12/2015 2:21 PM FOG::SnapinClient Attempting to connect to fog server…
2/12/2015 2:21 PM FOG::SnapinClient Module is active…
2/12/2015 2:21 PM FOG::SnapinClient Snapin Found:
2/12/2015 2:21 PM FOG::SnapinClient ID: 2
2/12/2015 2:21 PM FOG::SnapinClient RunWith:
2/12/2015 2:21 PM FOG::SnapinClient RunWithArgs:
2/12/2015 2:21 PM FOG::SnapinClient Name: Libre Office Installer
2/12/2015 2:21 PM FOG::SnapinClient Created: 2015-02-12 17:35:26
2/12/2015 2:21 PM FOG::SnapinClient Args:
2/12/2015 2:21 PM FOG::SnapinClient Reboot: No
2/12/2015 2:21 PM FOG::SnapinClient Starting FOG Snapin Download

Which lead me to inspect my php config and I found the issue. Memory_limit was way too low.

During the fog upgrade fog tried to install php which failed conflicting with php53. So uninstalled that and let it install php. That broke fog, so we swapped back to php53. I think during that we lost some config settings.

It appears I know have it working.

Might be nice to not have fog try to install php if a php is already installed.

[quote=“Junkhacker, post: 42166, member: 21583”]what do the client logs look like?[/quote]

Where are those kept? I can’t seem to find any documentation about them.

We updated from 0.32 to 1.2 and now our snapins do not install. They can be assigned, and attempt deployment, but they just sit in the active queue. Which shows a little warning shield overtop of the snapin icon. Not sure what that is about.

We have run “[FONT=Consolas]truncate table snapinJobs; truncate table snapinTasks;[/FONT]” which did not help. We also uninstalled the fog client service on a test machine and that did not help. We have snapins enabled both globally and on all hosts.