Posts made by mronh

@Sebastian-Roth as you are one of the developer, let me ask what is the “business rule” of the replication…

its a cron in the server side making checksums of the parts comparing with the cron in the node side, if mismatch delete and "lftp -e "?

@Sebastian-Roth, sorry by the delay of response… yes I can try the working branch,

I’ll make the git pull and return with the result

@Wayne-Workman not this at all, my storage had an 3 Tb HDD, just 1 TB used… but the clue above is a north to guide…

@Sebastian-Roth OK Thanks for the info

Hello there, Im having a problem with the replication in FOG 1.5.4, I have a node storage on and working perfectly until im upgraded both server and node versions

the replication never ends… always make one or more parts of images “not matching” as show below

“[09-24-18 3:56:34 pm] | Sala 204_207 Anexo I: No need to sync d1p2.img.106 file to 2 - Storage (X.X.210.208)
[09-24-18 3:56:31 pm] | Deleting remote file: /images/Sala204_207AnexoI/d1p2.img.105
[09-24-18 3:56:31 pm] | Files do not match on server: 2 - Storage (X.X.210.208)
[09-24-18 3:56:28 pm] | Sala 204_207 Anexo I: No need to sync d1p2.img.104 file to 2 - Storage (X.X.210.208)”

but the thing is: the source image was never changed since its creation… =/ and anytime I need to deploy a PC with images from this node the windows BSOD, from the ServerNode works fine…

Any clues?
thanks in advance, sorry by my english, not my native language.

@tom-elliott theres something we can do to ‘fix’ this to fog dont hang that long on that stage? ( i tried diskpart in debug mode, but no effect at all) =/

thanks in advance

Same here, 1.5.1 to 1.5.3… before was nearly instantaneous, now at least 3 minutes ( counting on the clock…)
feel the data base more slow also, during the update after deploy/capture

in capture/cloning mode takes even more time in the “saving original disk parts uuids”, bout 5 minuts minimum… =/