Uploaded Image Sizes And Restores
Running 1.2.0 on Centos 6.6. I upload 15-25 workstation images weekly, and I’ve used this setup for over a year without any major problems. Recently, my image uploads are greatly reduced in size (from ~50GB one month to ~15GB the next on the same machine) and, after testing a restore, the machine fails to boot. I’ve looked at the web GUI imaging log, and it tells me they’ve been taking 50 mins - 1 hr each, which is pretty normal. I’ve tried adjusting the FOG_PIGZ_COMP, but it doesn’t seem to have any effect.
What’s stranger is that it’s intermittent - if I upload one day they may all be fine, but another day they seem to corrupted somehow. Is there some more detailed log where I can see what exactly is happening?
I’m not aware of any logs specific to this. Normally, people are able to post a photo of an error, or type an error out… the overachievers post videos - those are the best.
And you don’t have to upload an hour long (likely HD) video. If you see an error in your video, take screen shots of it and post the pictures here.
It does happen overnight, and the images are moved from /dev to the proper folder in /images. I was doing them all on Fridays, then I switched to another night to see if that was the issue. It worked fine at first on the other night, then the same issue popped up. I was hoping to find a log of some kind that could describe what’s happening, but failing that I’ll try to figure out a way to get a camera on one and capture an error message. The problem is that it’s intermittent; taking the same image at a different time usually works fine.
Wayne Workman last edited by Wayne Workman
Do these uploads happen at night? Can you stay one night and supervise? Use a camcorder if you can (or any video recorder). If there are any sort of errors, it’s imperative that we (and you) know what they say in order to get this resolved.
Also, does the image transfer from the /dev folder to the /images folder properly??
Looks like the partition size is actually 93.2 GB. I assume the compression is responsible for getting to ~50 GB. This is in line with most of our workstation images.
This might seem silly, but can you go check and see if the user is actually using 50ish GB on that partition? What if they simply just deleted a bunch of crap they didn’t want anymore?
OK, here’s some more info. This is the ls-lahRt of the corrupted image, taken 6/17:
total 11G drwxrwxrwx 2 fog fog 4.0K Jun 18 15:15 . drwxrwxrwx. 4 fog root 4.0K Jun 18 15:14 .. -rwxrwxrwx 1 fog fog 11G Jun 17 01:07 d1p3.img -rwxrwxrwx 1 fog fog 177M Jun 17 00:00 d1p2.img -rwxrwxrwx 1 fog fog 77K Jun 17 00:00 d1p1.img -rwxrwxrwx 1 fog fog 512 Jun 17 00:00 d1.mbr
Here’s the same image, taken 6/18:
total 53G drwxrwxrwx. 79 fog root 4.0K Jun 18 23:09 .. -rwxrwxrwx 1 root root 53G Jun 18 23:09 d1p3.img drwxrwxrwx 2 root root 4.0K Jun 18 22:24 . -rwxrwxrwx 1 root root 177M Jun 18 22:24 d1p2.img -rwxrwxrwx 1 root root 77K Jun 18 22:23 d1p1.img -rwxrwxrwx 1 root root 512 Jun 18 22:23 d1.mbr
So the upload process is cutting out during the upload of the third partition. Is it a permission issue?
This command would tell us a lot:
[CODE]ls -lahRt /images[/CODE]
Please post all of it’s output using a code box. (far right tool in the editor here)