FOG fails to handle odd-sized Windows 7 boot partitions properly
-
[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. -
[quote=“Dave_A, post: 30250, member: 24638”][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.[/quote]While I understand your problem, there is no real nice way to make this a fix. The reason you’re having issues is pretty much as you suspect. We are hardcoding the partitions on resizable images.
That being said, this is exactly what the Multi-part imaging types are designed for.
While they’re not resizable, persay, so long as the hdd the image is created on is smaller or exactly the same size as the prospective receiving system there should be no issues.
EDIT:
To add to this, the hardcoded information is based on a fresh base install from windows. It doesn’t take considerations of custom boot partitions and the like.
-
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??
-
[quote=“Dave_A, post: 30281, member: 24638”]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??[/quote]
Yes, that’s very possible. The problem is, the mbr is what determines the size of the disk, so after “re-mapping” the drive with the MBR data, it would be limited to the size of the original disk, which leads to the same thing you have with multi-part images.