Does your image have the FOG Client installed?

@zta104 And TaskReboot service is running?

Oh, and Filenames ARE case sensitive.

So “smartinstaller.exe” should be “SmartInstaller.exe”

404 Means that it cannot communicate to the FOG Server.

So either your client is not configured appropriately to look at the server (maybe it’s looking for fog-server instead of ip of fog server?)

Please post the C:\Program Files (x86)\FOG\etc\config.ini (64 bit windows) or C:\Program Files\FOG\etc\config.ini

@george1421 I have to add a caveat.

The Legacy client will not auto update to the new fog client. So if you’re running FOG version 1.2.0 with the FOG client, just updating to the RC’s will not push the New Fog client down onto the host.

And 192.168.1.203 IS the fogserver IP address?

@Polii123 http://stackoverflow.com/questions/8843776/mysql-table-is-marked-as-crashed-and-last-automatic-repair-failed

@Wayne-Workman you are correct.

@george1421 @Wayne-Workman @THEMCV If it’s disabled why should we replicate it? This relates namely to snapins and images though. Of course it’s possible to assign the definition, but it could be protected. This way deploys won’t work and an upload would not be allowed.

@george1421 correct. But disabling tells fog you want nothing to do with it. Protecting an image definition won’t prevent a user from deploying it, but it will also fail to deploy to the host trying to use it. It won’t be able to find the normal image files. It will also not be able to be uploaded over when I’m the protected state. The protected state is just a check box in the GUI, so you can still put new files in the “drivers” image. Replication will compare the files and update the files that need to be updated.

@sjensen Is the IP Address of the FOG Server 192.168.28.18

Luckily this wasn’t due to a schema issue or anything.

This was due to somebody installing the capone plugin from a much older version of FOG but with recent changes, it was still in place just looking at the wrong places for values.

Removed the capone plugin and all is well.

@sjensen Your information is conflicting.

You state the FOG Server and the client are on the same subnet, but the post before that you state they’re on different VLAN’s.

Now, being issued different IP’s is fine as your DHCP controller can handle passing the boot files and with the use of IP Helpers all will seem to work fine.

The difference, however, is something is obviously not right and we now have conflicting information making it that much harder to figure out.

If they are on separate vlan’s I’m assuming there’s a switch handing out information and there’s probably a central point where all things reach out through. After that, there’s probably a firewall and traffic is all routed to that point?

I’m just trying to understand the layout. Two clients on the same subnet (Server and host) should have no problems mounting an NFS share. But if you throw a firewall into the mix and separate vlan’s, I can only guess the network has no idea where to go, or it’s entirely blocked from that particular connection.

@george1421 Yessir.

@sjensen run sudo -i then run all the commands

@THEMCV If I had to guess as to the issue, I don’t think it’s anything wrong with the GUI or the snapin running. Rather, the installation is requiring some user action? This is just a guess considering it just “stuck” there for an indefinite amount of time.

Of course seeing the install.bat file would probably help (removing any licenses in the batch file to show us).

@Quazz Sometimes, yes.

I was able to help fix the issue though. I don’t know if things are up and running now (and the OP is out for holiday’s).

I remoted in and after the first (mostly successful) it changed the ‘fog’ user’s password. to what was unexpected.

They logged into the server as a guest and I was able to read the /opt/fog/.fogsettings file. We pulled out the new password, and reset it to what they were expected. I updated the fogsettings file and had them re-run the installer.

@tom.langenfeld please post the log found in:

~/fogproject/bin/error_logs/fog_error_1.3.0.log

From the sounds of things, you haven’t uploaded an image yet? You told it to run a deploy task, but no image associated with it to even put on the disk.

It looks like you’re trying to use the file bzImage_tablet for the kernel, adn that file currently doesn’t exist in your installation. (The file is missing from /var/www/fog/service/ipxe/)