@UWPVIOLATOR said in Interface not ready, waiting for it to come up FOG 1.5.8:

I could not do grep php /opt/fog/.fogsettings as I tried a fresh install. fogsettings-firstInstall

I think we are mixing up way too many things in this one topic. It was about FOG on CentOS 7 and upgrades. Now we are talking about Ubuntu 19.04 fresh install. May I please ask you to open new topics for new issues to prevent confusion and missunderstanding? Please open a fresh topic for the Ubuntu fresh install and I will move the posts over.

While I am not sure yet it seems like there is an issue with PHP version numbers when using FOG 1.5.8 on Ubuntu 19.04. The later is end of life already and we won’t backport fixes to FOG 1.5.8 either. So you might want to think about giving the most current versions a try as it seems to be a fresh install anyway.

@UWPVIOLATOR said in Error trying to restore GPT partition tables. Exit returned code 4:

CentOS Linux 7.7.1908
FOG 1.5.6

Close this. I am pretty sure it was my connection where I was uploading and testing. It was having issues thus giving me errors.

@UWPVIOLATOR If you can’t get the application to behave with respect to the restarts, you could always create a snapin pack bundling the executable with a script. In the script, you could check to see if the application was already installed and of the correct version, then if it wasn’t perform the install. if you wanted to kick off the application and then do something like loop while the executable was running, you might want to play with the start command, something like start "" installer.exe -args. https://ss64.com/nt/start.html

@george1421 the /k flag runs the specified command then leaves the command window open. https://ss64.com/nt/cmd.html

@UWPVIOLATOR Did you get to test the script?

Meanwhile we have released a new version of the fog-client which should print out a text instead of the hash when it catches the unhandled exception.

Either you can update to the latest dev-branch version to get the new fog-client or you can switch over manually: Download SmartInstaller and MSI and put those in /var/www/html/fog/client/ (rename the old binaries to be sure you have a backup copy in case). Then edit /var/www/html/fog/lib/fog/system.class.php and change the line where you see the client version from 0.11.16 to 0.11.17. Be aware that all your hosts with running fog-client will download the SmartInstaller from your FOG server and attempt to auto update!

@Tom-Elliott Thank you for figure this out. Here is the correct query.

Insert into groupMembers (gmHostID,gmGroupID) Select hostID,'212' from hosts where Right(hostName,6) in ('D02595','110563')

So this can get marked as resolved. Everything worked as expected except when you update the nodes the GUI did not show the new version until after we updated the Master. All the issues we had with 1.5.4 were resolved with 1.5.6. Very happy with this update.

GUI is super fast!
The freezing on formating MBR/GPT on start of imaging is back to only a few seconds. Replication seems to be acting normal again.

@Sebastian-Roth this can be addressed from the location plugin under the fog configuration. Location adds a fog setting for allowing snapins to be downloaded from the host location or the master storage node the snap in resides within.

@tom-elliott @george1421 So it is taking forever to replicate just 1 Node drivers. We rsynced before but its almost copying every file again. What do we need to do to make the copies be the same and speed up replication? What does FOG use to check the file to see if it matches?

@uwpviolator I’m not sure if such a file/key exists. We should ask @joe-schmitt about that. You could just do a wholesale - uninstall and reinstall for all your machines.

@gnichols I am sorry but we can’t help if we don’t know more details about your setup and what exactly goes wrong. Most situations/setups are more or less different and we need to know all your details to help. Start by opening a new thread and answering the following questions: FOG version? Has it ever worked for you? When did it break and why (update…)? Can you take a picture of the exact error on your screen and post that too?

So, worked remotely and was able to help determine part of the problem.

Installed apachetop and took a look, found a lot of things still looking at servicemodule-active.php. We moved away from this call as it had some weird issues on its own. Moved the file and the GUI become much less sluggish. Worked to get phpmyadmin working as well. This wasn’t a problem with php-fpm vs. libapache2-mod-php (though I did make sure phpmyadmin would access using the php-fpm system). Part of the problem that was happening was the rewrite rules that handles api system.

Moved the rewrite rules into the directory stanza of the fog.conf. Made this update in the working-1.5.1 branch as well. I haven’t had time to test whether this move actually still allows the system to work, but it should. Will work on that this weekend (testing to see it works properly).

Also, we are still working to help purge the db of old stuff that’s no longer needed.

Hi,

in normal you don’t need any autologons, i just use it because i am working with windows 10 pro oem where you cannot have setupcomplete.cmd executed automatically, therefore i used the autologon stuff with first logon commands in my unattend.xml.

If you don’t need to do anything special remove autologons in your unattend.xml

Regards X23

@UWPVIOLATOR This has been fixed in v0.11.14, which will be released with the next server RC. I’d still recommend using process-explorer to find out why the file is locked though.

To get v0.11.14 you can either wait for the next server release, or download it from here: https://github.com/FOGProject/fog-client/releases/tag/0.11.14

@wayne-workman as in RC12? Ok I have another Issue I will be posted but testing again to make sure I can replicate it before posting. Its with Snapins not reporting they are finished and then keep trying to run over and over again. Windows 10 and Windows 7.

Trying to avoid updating to RC and waiting for next stable but if its fixed in an RC we might have to go for it.

@uwpviolator Yep, I sure am calling the unattend. I’m imaging the same way I have been for a while.

Would you be able to sanitize your unattend and provide, and I’ll do a line by line? As stated, my Unattend hasn’t really been updated since hte Win7 days, so I’d love to see a modern one that is known working…

No Problem. Thank you

You can get the inits here, without upgrading to 1.5.0RC series. Here is the wget command to use from the FOG server’s linux console.

wget https://fogproject.org/inits/init.xz wget https://fogproject.org/inits/init_32.xz

These files go in /var/www/html/fog/service/ipxe. Make sure you backup the current files before you update them with these.

With these new inits there is no need to use the postinit patch method I described below.

@UWPVIOLATOR You can make the call with curl or powershell. If you go the curl route, there is an executable for windows called curl.exe that will do need or you can call it from a linux command prompt.

@Wayne-Workman has some very fine examples of curl calls in this thread: https://forums.fogproject.org/topic/9779/can-i-use-some-kind-of-script-to-create-image-and-ghost-my-lab-machines

@george1421 I copied what your pasted and changed the permissions. Maybe it was the permissions to fog:root that did it?

@UWPVIOLATOR the others aren’t concerning. Feel free to fix them though. Google is your friend.