@tom-elliott So to clarify that last point Tom, the SQL should reflect under ngName both the Storage group name AND the Storage node name? DCSTORAGE in this case is the name of the Storage node master server for the Storage Group 3 storage group.

I’ve compared to the other image(s) which are only hosted on (and are being replicated from) the Master node and they only reflect the main storage group under ngName.

I’ve made note of the replicator service restart command, cheers. I went a bit neanderthal and just rebooted all my servers just now to see if that kicked things into life.

Checking the Image Replicator logs under FOG Configuration > Log Viewer it only references DCMASTER and the 2 nodes in its storage group. Does replication from the Storage master of the other storage group show in these logs? Or do we need to check local log files on the server itself?

cheers Tom

Just wanted to follow up on this for anyone else in same situation. Essentially the VtoV works just fine. As we had changed hostname and IP we only ended up having to reinstall the FOG client on the desktops for them to become in sync with the new FOG Master server. All other things just worked.

Cheers Tom

@Sebastian-Roth Hey Sebastian (and all other FOG devs and users out there) hope you and yours are staying safe and sound with whats going on in the world.

I’d forgotten about this post myself I confess - I’ve been busy trying go setup our entire workforce across several sites to work from home.

I know our service desk team would find this feature of great benefit as keeping reliable track of who was given a loaner laptop and when can be difficult without the right tool to do it. Excel sheets or even the ticketing system don’t manage this very well.

But given whats going on just now for everyone its very much on the distant, nice to have when the worlds in a better place list.

Stay safe everyone.

Kiweegie.

@AlexPDX Please open a new topic as your request has nothing to do with the initial post as far as I can see. Just copy and paste your text from this.

@Kiweegie said in Could not mount images folder (bin/fog.download) ... failed: Operation not supported:

Thoughts welcome

Do you have firewall restrictions in your MPLS or the VPN tunnel?

@Quazz Hi Quazz yes main problem of high cpu usage appears to be much better - main server with most number of hosts is sitting at 5-30% CPU load roughly with no active tasks running. I’m testing now with images running to double check under load.

cheers Kiweegie.

Cheers Wayne, you live and learn.

That sorted the issue. Please mark this as resolved.

Regards. Kiweegie.

@Sebastian-Roth The real question is the original issue that caused this post to be opened in the first place fixed?

@Kiweegie, are you solving this because the password/snapin issue is fixed or your server is no longer sufferring from the High CPU Usage from multiple httpd processes?

@Tom-Elliott Well I’m officially a twat. Sorry for wasting your time… I shall be booking myself into an Alzheimers clinic immediately!

@Wayne-Workman HI Wayne, we’re all good.

Only steps needed to get this operational above and beyond your suggestions were to run exportfs -a after editing path in etc/exports and then making sure a .mntcheck file existed in each locaton /home/fog/images and /home/fog/images/dev

regards Kiweegie

Image is still copying this morning but is being accurately limited to the 500kbps setting set on the storage node. Not sure what the issue was but suspect it may even have been erroneous reporting within our monitoring tool PRTG. Marking as resolved.

cheers, Kiweegie.

Tom Elliot has resolved the installer not asking for any info issue but now fails with error:

* Adding needed repository....................................Failed!

I’ve checked the log at /var/log/fog_error_5893.log which shows

Package epel-release-6-8.noarch already installed and latest version Nothing to do package http://rpms.remirepo.net/enterprise/remi-release-6.7.rpm is not installed Loaded plugins: fastestmirror Setting up Install Process Cannot open: http://rpms.remirepo.net/enterprise/remi-release-6.7.rpm. Skipping. Error: Nothing to do ../lib/common/functions.sh: line 439: yum-config-manager: command not found

So the remi repo needed to be enabled, doing this alone was not sufficient to fix problem, Tom Elliot also had to enable yum-config-manager. Tom has updated this in git and i’m now running on trunk@4617

Tom/Wayne, thanks again for your efforts, really do appreciate it.

regards Kiweegie.

@Wayne-Workman Hi Wayne, I had to give up on the Storage node set up and go with a separate Normal node as I need to get this back up and running sooner than later 🙂

The node which is causing issue is the storage node for head office so I’m just going to set up that box as a normal node instead and split the roles so we have one node for head office and one for the remote sites. It may even make things simpler.

I can spin up another Storage node at some point to aid in diagnosis of the original issue but for now my priority is getting our FOG solution back up and running again.

regards Kiweegie

@Sebastian-Roth @george1421

Hi both, thanks for the pointer to log, that showed me issue. Had reinstalled from trunk and while fog password was ok per my records in the below locations I had like a complete rookie forgotten to reset password on the server itseld post upgrade… d’oh!

Storage Management > All Storage Nodes > Default Member > Management Password
Fog Configuration > Fog Settings > TFTP Server > FOG_TFTP_FTP_PASSWORD

cheers all
Kiweegie.

@Wayne-Workman, @Kiweegie this should all be fixed now. Well a while ago but I’m just now updating lol.

@Wayne-Workman HI Wayne, thanks for this. I’ve upgraded to latest trunk and can confirm this now works as expected. Please mark call as resolved.

regards Kiweegie.

@Wayne-Workman Sorry Wayne ignore last re fog certificate. Issue was only on my laptop and has since been resolved.

If the filesize a are the same this would explain why they where in defunct status. The commands run but have no work to perform. I believe the defuncts you’re seeing are simply because of this. If you’re daring you could delete one of the images from the annex node and restart the replicator on the master. Then check your bandwidth and see if things are happening.

Thanks as always Tom for the quick fix - all good now, this can be marked as solved.

Ref the Apache and php files error - think that was an additional symptom of the sed missing character.

@Tom-Elliott Hi Tom, updated to latest git release now and indeed its working again. I did only update a few days ago after your last fix re the flashing issue.

regards Kiweegie.