Topics created by Mark Shelton

@Mark-Shelton As seen in the picture the version of partclone is 0.2.89 which is the version we used in FOG 1.5.7. Sadly it’s not able to deploy images that were created with the newer version of partclone (0.3.13) which is now used in FOG 1.5.8.

Partclone 0.3.13 can deploy older images created by version 0.2.89 but not the other way round. Please upgrade your Raspberry Pi FOG install to FOG 1.5.8 (manually fixing the udpcast compile issue) or FOG development version (dev-branch has the udpcast compile fixed already).

@Mark-Shelton Great, thanks for the feedback. I just added a fix to the code.

I’ve marked the thread as solved so as to ensure I don’t go crazy looking at “unsolved” threads. RC-8 will have the fix for the replication issues as well as a few other fixes that were rather not issues (in the directest sense of the word) but just redundant.

The additional fixes just ensure that if all files are matching, it doesn’t try to resync the data between the two sides (causing unnecessary load – if only for a second or two).

A part of the “whole” is it will also enable ALL services to update their loop update times properly. Only MulticastManager had been working properly apparently, not that many would’ve noticed a serious issue. It will properly check the new sleep times and start using the new sleeptime after the next cycle runs (if it isn’t already running).

For example, say your FOGMulticastManager is setup to go in 10 second intervals (which is the default) and you want FOGMulticastManager to go in 300 second (5 minute) intervals, if you updated the FOGMulticastManager sleeptime to use 300, it will update after the next check, or when this current check is complete.

@Wayne-Workman Thanks, yes I may move to 64 bit. However it’s good that my issue has highlighted the inconsistency in the code which sounds like it only shows up in 32 bit OS’s. I’m guessing there mustn’t be too many others with my setup out there, otherwise this would have been reported a while ago. Glad its a relatively easy fix, I’ve rebuilt these boxes a few times recently and didn’t wish to have to do it again. Regards, Mark

@Mark-Shelton said:

Thanks for the info, it helped.
I have 3 nodes in total. One was an older version of ubuntu with an earlier SVN, and this was affecting the bandwidth monitor. I removed it and the 2 up-to-date nodes come up on the monitor. Thanks Wayne.

Thanks for the thanks, but you solved this one yourself. Props where it’s deserved, good job.

No idea if this is currently possible or not, I’ve not gotten the opportunity to mess with the location plugin yet…

But this is a good idea.

I went back to 1.2.0 …too much grief with the last couple of SVN’s for a live system! 🙂

[quote=“Tom Elliott, post: 45098, member: 7271”]@ch3i,

Are you still having this issue?[/quote]

Tom, I update from 3200 to 3222 without problem, It’s fixed for me.

Thank you 😉

Regards,
Ch3i.

An update for those viewing this post. Tom Elliot has advised me that we now see just the bandwidth info for the node selected in the disk space piechart. So bandwidth information is no longer shown for all nodes at once.

This might be possible with hooks in the future.

What is your normal data transfer rate through the IPSec tunnel using FTP, outside of FOG. If it’s slow doing a normal FTP, HTTP, or SMB file transfer from site to site, then you might try troubleshooting it from a VPN IPSec performance angle instead of FOG.