Sebastian, Try adjusting the Compression ratio on 0.33. This can now be done through the FOG GUI under FOG Configuration->FOG Settings->FOG Boot Settings->FOG_PIGZ_COMP.

It has a range of 0 thru 9. A 9 is the highest compression rating and takes the longest time to process and upload as it is compressing data quite a bit. 0 is the worst compression rating, and takes the shortest time to process and upload. In years past, the default was at 3, but it was Hardcoded into the init.gz file. This setting allows you to decide how much compression you would like. It auto set’s at 9 though so I would start here.

Sabastian M.

Change your Option 67 from pointing to pxelinux.0 to undionly.kpxe as we’ve since moved to iPXE for booting. pxelinux.0 is no longer used.

Yes, right 😉 Thank you for you effort!

I will try.

Happend on the systems where we tried to directly link to the NAS.

I don’t know of a method of confirming the actual svn revision. Maybe somebody else can be of more help in this regard.

The IOCTL error isn’t particularly important then. I see it with my home-made kernel because it has RAID drivers built in, but the devices don’t have raid drives. If you’re having issues with imaging a specific drive, it may point you in the right direction, but by itself it’s perfectly fine.

Sorry all,

I forgot to read that you guys were having the issue with FOG 0.33b. I posted all of this information on FOG 0.33 Bugs forum as well.

Yeah I marked at solved a 3 years old topic !

@Dark000- I’m happy that I helped in the smallest of ways, and only hope this helps others.

All,

I don’t know that FOGPrep or Partition adjustments, alone, corrected this problem. One way, I guess, to test would be to recreate the image, without FOGPrep. I’m more than certain the partition adjustments didn’t do this as the imaging process doesn’t know anything about the partitions them selves. All Partimage does is copy the data to the file, it’s really the FOG Scripts that create the partition specific images. Because of this, I am pretty certain these were not a problem in the first place.

I’m almost sure FOGPrep wouldn’t have been the fix for this either. Mostly because, to my knowledge, all FOGPrep does is get the UUID information (hostname and hardware specifics) cleaned up from the registry. At that point, it really doesn’t care.

It’s starting to sound, more, like the Image being under a certain size has helped improve the speed of this issue.

Well, if it’s deploying RAW and you get a bootable image and want to use it… I guess I’d deploy it, verify the hidden 100mb partition was restored by Windows, sysprep it, then upload the image again as Single Partition/Single Drive, and it should be able to resize it as intended and save you a lot of space and deploy time.

Unless I’m missing something or not understanding something else, I think that might work.

If you wanted to be sure, I’d just start with a new image of a fresh Win7 install that had the 100mb partition and verify your fog setup is accepting the Single Partition/Single Drive upload before attempting anything else. It’ll save a lot of time down the road, in my opinion. Once you’ve verified that part is working as intended, it’ll be easier to find any other issues that might occur.