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?

  • Moderator

    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.

  • Moderator

    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.

  • Moderator


    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?

  • Moderator

    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)

Log in to reply





Looks like your connection to FOG Project was lost, please wait while we try to reconnect.