Fog Upload Issues

[wlsnfmly]

Tried to upload an image today and encountered an issue. Client error shows lack of diskspace, but we have 600gb free space on the system.

[george1421]

What version of FOG are you running?

Also upload is ambiguous, were you doing a capture or deploy?

[wlsnfmly]

I’m doing a capture. here is the screen shot of the output for df -h

[george1421]

@wlsnfmly You might also want to post a screen shot of how you have your storage node settings for this server. What you have is not standard. We need to have a clear picture of what is setup.

[wlsnfmly]

@george1421 here is the image of the error

[wlsnfmly]

@george1421

[george1421]

@wlsnfmly My initial reaction is that your image path and ftp path should be the same.

/storage1 != /images

[wlsnfmly]

so I can just change the ftp path from image to /storage and that should work??

[wlsnfmly]

@george1421 Tried that, still failed, same error

[wlsnfmly]

Anybody have any other ideas on this? I’m drowning here.

[Tom Elliott]

The only idea I have is your /storage1 folder is missing the dev folder?

Can you try:

mkdir /storage1/dev
touch /storage1/{,dev/}.mntcheck
chmod -R 777 /storage1

Also your ftp patch should simply be /storage1 as your Image path.

[wlsnfmly]

@Tom-Elliott I tried that, still failed. Same error. The system looks like it is going to work, it gets to about 1% on the progress bar, then goes haywire and fails.

[TaTa]

@Tom-Elliott Does he needs to add /storage1 to /etc/exports?

[george1421]

@Tom-Elliott Sorry i should have updated this thread yesterday.

I remoted into the user’s computer and we set out to debug this issue. I checked the fog server and it is setup correctly (even with the /storage1 setup). The /storage1 share and mount point are connected to the OPs second hard drive /dev/sdb. As far as I can tell/check the FOG server is functioning correctly.

We setup a debug capture on the target computer and stepped through the capture process. On the second run through we caught a quick flash of an error from partclone indicating a bad sector on the target system hard drive which was aborting the partclone capture at 12% (or 2% I can’t remember) each time. Each run through the image would make it to the same percentage and abort.

(Guess)When partclone aborted because of a bad disk sector, FOS picked that up as the FOG server being out of disk space.

Wlsnfmly was going to inspect the target system more to try to determine what the root cause of the issue is/was. He saw locally that partclone reporting the disk being dirty and that’s why it aborted. The error was only on the screen for about 1/2 a second so it wasn’t easy to read the entire message.

That is the results of testing yesterday afternoon.

[Tom Elliott]

@george1421 The error message is just a “here is something you might be able to check” as the error codes returned by partclone don’t have any specificity. Meaning it’s always going to error with the same exit code regardless of the actual problem. This is why I now try to provide the partclone.log too.

[wlsnfmly]

@george1421 After further troubleshooting, we determined that the issue was due to a bad sector on the hd. Moved to a different HD and the system worked like a champ. Thanks George for assisting in finding that little blurb about faulty sectors during the timeout