Unable to upload images

[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

[Doctrg]

@Tom-Elliott This fixed the reboot/join issue. Thought I’d mention that it did not fix the upload issue as forecast.

[Tom Elliott]

@Doctrg Okay,

I’ve updated the code base in an attempt to have it print out the actual so we could further see how to help you out.

You will probably need to remove the old installer folder.

you could ensure all is well if you cd to /opt first.

Possibly the steps would look like:

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

Cancel the current upload tasking if you haven’t already.
If you can run the capture task again but select the “Schedule as Debug before confirming” boot the system you’re trying to get the image from.

It will ask you to press [Enter] twice. Then it will drop you into a shell.

From there you can run:
fog

You will have to press enter a bunch of times, but it should allow us the time we need during the completion of the upload that is currently failing.
It also means you don’t have to try to beat the clock to capture the picture.

[Tom Elliott]

Once you get the picture, please post it here so we can be of more assistance.

[Tom Elliott]

@Doctrg I’ve added a enabler/disabler feature set to the working-1.3.4 branch. This feature set just allows you to check a box in the FOG Settings that tells us if the service is allowed to run or not. The master daemon of the service is still running, and will still checkin based on its sleep time.