@george1421 Thank you very much! I was able to modify the script to fit our setup. Everything is working smoothly now.

Thanks again!

@george1421 Thank you so much! This has resolved my issue.

@jon-fuentes The disk space error message is an incorrect one. The issue is partclone is not passing enough information back to FOG on why it aborted. The answer is probably sprawled across the partclone screen just above the screen shot you provided. The fog service only can tell that partclone aborted for some reason and the “guess” was the hard disk on the fog server is full. Rerun your imaging again and watch what message partclone displays.

Also you might consider upgrading your version of FOG sooner or later. FOG 1.5.1 is waiting for release so you might want to hold off for a bit to upgrade, but you should upgrade once 1.5.1 there are quite a few disk imaging fixes in 1.4.4 with a handful more in 1.5.1. So you should consider upgrading to make your imaging a bit smoother.

nevermind

With a quick teamviewer session this issue has been resolved. The issue was just the sequence of install and ensuring eth0 was up before installing FOG.

@amadrigal Just want to bring up my initial thought about maybe OpenVZ not being able to properly handle multicast in the first place. Can you try setting up another test FOG server as KVM instance just to rule out that possible issue!?

@george1421 Oke! Say it when you found something.

@msi Never mind. After I re-ran the installation from the Git. Problem solved.

Is there a way to reduce how often the fog node’s are checking back into the master server’s mysql?

@kafluke said in How do I schedule FOG image replication for after hours?:

@george1421 thank you so much! These are even the exact times that I needed to set the job for! You da man! This can be marked resolved now.

That is why I get paid the big bucks… oh wait… never mind.

@tesparza the file you are running doesn’t appear to be the installer. It appears to be a self extracting archive that contains the installer. Once you give it a path, it should place all of its install files there, including a DXSETUP.exe, which would accept /silent.

My suggestion is to either find a different version of the installer, such as an MSI, or to take the extracted files and create a snapinpack out of them.

Just going to add in here that when I want to see how busy my HDD’s are during tasks, I use nmon. Can run as normal user and press d to view disk activity percentage. Very friendly to a newb. Press n to also view network stats and c to view CPU as well.

If I was you, i’d bring a computer over to the same physical switch that your FOG server takes the image on. See if it sustains a better speed or not to determine if network routing is to blame or not.

@george1421 That is sent to you. Let me know what you find.

Thanks,

Just for an additional bit of information. Your reference/golden image should never be connected to AD before you sysprep it. Even if it was connected to AD, then removed from AD before system. The first time you connect a computer to AD the target computer will be tattooed causing every image created from that golden image problems down the road.

You can mark this as solved.

@tom-elliott said in Can't login to FOG web Interface:

@msi when you login guess what page it automatically takes you too?

Hi,
Make sense… Please close the discussion with satisfaction. Just to recap, below solved the problem for now. Hopefully, newer version will solve all the problem, including delays.
@msi said in Can't login to FOG web Interface:

[root@caor-fogmain ~]#sudo -i [root@caor-fogmain ~]#yum -y install git [root@caor-fogmain ~]# sudo -i [root@caor-fogmain ~]# cd /root [root@caor-fogmain ~]# git clone https://github.com/FOGProject/fogproject.git [root@caor-fogmain ~]# cd fogproject/ [root@caor-fogmain fogproject]# git checkout working-1.5.1 Branch working-1.5.1 set up to track remote branch working-1.5.1 from origin. Switched to a new branch 'working-1.5.1' [root@caor-fogmain fogproject]# git pull Already up-to-date. [root@caor-fogmain fogproject]# cd bin/ [root@caor-fogmain bin]# ./installfog.sh -y

@Paulo-Guedes See update here: https://forums.fogproject.org/topic/11207/error-could-not-open-inode-xxxxxx-through-the-library

that worked amazingly thank you very much!

@tiagoluz

Yes, you can manually rsync the images over. I’m doing the replication between nodes so my coworkers who know nothing of Linux can synchronize images across FOG installations without asking me to do it.

The active snapin tasks appeared empty, but when I typed the hostname in the search it showed up as queued. I deleted that queue and ran:

DELETE FROM `snapinTasks` WHERE `stState` in ("1","2","3");

in mysql for good measure. Everything appears to be working now.

Thanks for your help and all that you do!