Wouldn’t it be possible to add a step to the image-collection process, that grabs the partition map of the source via Linux fdisk or parted, and pushes it up as a text file with sys & rec images - then pull down and parse that file in the restore part of the script, to recreate the original map??

[B]Background:[/B]

The organization I work for has a standard image, but deploys it manually in most locations (by taking PCs to an ‘Imaging Center’ within the .org). My project-team set up FOG for use with our systems, and uploaded a PC with the existing master up-and-running on it…

The machine we are uploading from is configured as follows:
Windows 7 Enterprise
350MB B[/B] Windows 7 Boot Partition
250GB Windows System partition.

Collected via [B]‘Single Disk, Resizable (NTFS Only)’[/B]

FOG collected the image properly but fails to restore it. On boot we see ‘Missing Operating System’

An analysis of the restore errors indicates that the ‘size’ of the boot partition appears to be hard-coded in the FOG restore process. On restore, there is a ‘partition to be restored is larger than on disk’ error…

Specifically, it seems that no matter what the size of the original boot partition, FOG always tries to cram it into 105MB.

I don’t know if no one considered that some Windows installs would use different sizes, but it is-what-it-is…

[B]Suggested fix:[/B]
Get rid of the hard-coding, and save the original size of the boot partition in the image data - then restore it at the exact same size that it originally was.