Unable to upload images

[Tom Elliott]

@Doctrg It could be, but replication doesn’t play (shouldn’t) a value in dealing with uploads.
I’ll see if I can confirm but I assure you this shouldn’t be the case. Only example I could think that might make it a problem, is if lftp is actually running, essentially making the file unable to be removed.

[Doctrg]

@Tom-Elliott It would great if there were a global setting for disabling replication. I have updated one of our other storage nodes that was failing before 1.3.2 and with replication unchecked it uploaded without an issue.

[Tom Elliott]

@Doctrg I wonder if this isn’t a bug, but it cannot remove the original image file because it’s trying to push the images down to the other nodes?

As a test would you be able to do say:

service FOGImageReplicator stop (but keep the image with replication on?)

The image replicator service wouldn’t be trying to do anything and any stuck transfers would be killed on the stopping of the replicator service. Can you upload then?

[george1421]

@Doctrg said in Unable to upload images:

@Tom-Elliott It would great if there were a global setting for disabling replication…

Stop the FOGReplicator service and then all replication will stop.

But I see Tom’s point the only time the image will be locked is when it is currently in the replication state.

[Doctrg]

@Tom-Elliott I stopped the Replicator service and tried uploading with replicate checked. It failed uploading.

[Doctrg]

@Doctrg I’m told by one of our other techs that even with the service off and the replicate image unchecked that it still fails.

[cadams]

I just came to stop by and say I’m monitoring this thread as I have the same issue. Thanks for your hard work.

[george1421]

@cadams said in Unable to upload images:

I just came to stop by and say I’m monitoring this thread as I have the same issue. Thanks for your hard work.

Do you have multiple storage nodes in your setup? If not we might want to start a new thread just to keep the issues split because the conditions are different.

[cadams]

@george1421 Sorry! My intention was not to hijack, but you are correct, the conditions seem to be different. I will start my own thread.

[Doctrg]

@Tom-Elliott So seeing that 1.3.3 had been published, should I update to this to see if it fixes my issue?

[Tom Elliott]

@Doctrg You can, though I don’t think anything in 1.3.3 has anything to fix the problems you were seeing with uploading. None of that has changed. It certainly won’t hurt at the least.

[Doctrg]

@Tom-Elliott I have not updated to 1.3.3 yet, but I found another issue that we are having. I was able to image a computer, but it is not auto joining to the domain. I also inputted the domain password just to make sure it was using the right password.

[Tom Elliott]

@Doctrg The issue joining to domain could be related to the other posts. What version are you on currently?

[Doctrg]

@Tom-Elliott Running Version 689680
SVN Revision: 6059

[Tom Elliott]

@Doctrg Mind jumping onto working-1.3.4 and installing?

I don’t think it will fix your capture woes, but it should at least get your client back to a semi-functional state.

[Doctrg]

@Tom-Elliott I’ll give it a try.

[Doctrg]

@Tom-Elliott Where is 1.3.4 located at?

[Tom Elliott]

You’re on git correct?

cd fogproject
git checkout working-1.3.4
git pull
cd bin
./installfog.sh -y

[Doctrg]

@Tom-Elliott No, I’ve been getting the update using:
sudo -i
wget http://downloads.sourceforge.net/project/freeghost/FOG/fog_1.3.2/fog_1.3.2.tar.gz
tar xzf fog_1.3.2.tar.gz
cd fog_1.3.2/bin
./installfog.sh

[Tom Elliott]

Try this please:

wget --no-check-certificate http://mastacontrola.com/fog_1.3.4.tar.gz
tar xzf fog_1.3.4.tar.gz
cd fog_1.3.4/bin
./installfog.sh -y