clone to smaller disk
-
How was this image captured? WIth 1.3.5RC11 the developers have spent many hours getting image resize to work correctly. So this is going to be a disappointing post for them.
Please try to provide as much details about this image as possible. Like target OS, partition layout, how it was captured. As much detail as you know about this image.
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
@george1421 Yes with rc 11
its a windows 10 operating system
i deployed it using the standard compression rate “6”
and i get this error with a smaller harddrive
-
@george1421 said in clone to smaller disk:
How was this image captured? WIth 1.3.5RC11 the developers have spent many hours getting image resize to work correctly. So this is going to be a disappointing post for them.
Please try to provide as much details about this image as possible. Like target OS, partition layout, how it was captured. As much detail as you know about this image.
Yeah, I got RC11 from your firsts post. To answer your question, no its not normal for FOG.
-
@george1421 ive edited reply since
-
Seeing as RC 12 is out shouldn’t we start there?
-
To add on, the resizing system in the past was far from a perfect beast. It should be much better now, though RC 11 did have an issue or two as well. (This was because forgetting about 4k drives.)
If the issue is still happening, it would seem, to me, that the partition it’s trying to work with is much smaller than what was expected to be on the main system.
So if the image was captured from a 1tb drive, and trying to be placed on a disk the size of 250GB, you’re greatly cutting down the size, possibly to a point that it cannot resize appropriately.
Disk sizing is based slightly off the originating disk. The way it works, now, is:
Find the originating disk size, figure out the originating partition size, how much of the originating disk did the partition use? Using the new disk, use the same a percentage of disk space available to create the drive.
You might be able to do the tasking using a fixed size partition in place, though i may have to review the code a bit to make sure the “original” size is used as the fixed space, and not the “minimized” size.
-
@Tom-Elliott said in clone to smaller disk:
Seeing as RC 12 is out shouldn’t we start there?
yes @Tom-Elliott but i was not sure if the issue had been addressed in rc-12.
I shall try it and report back!!!
-
I’m on 1.3.4 and have this exact same problem with Windows 10. You need to add 1 to a file in /images/YourWindows10ImageName/d1.fixed_size_partitions. I haven’t upgraded to R12 to see it addressed this issue. R10 did not addressed it so I reverted back to 1.3.4.
-
@TaTa said in clone to smaller disk:
d1.fixed_size_partitions
im currently imaging with rc12 of 1.3.5 and it auto created the file “d1.fixed_size_partitions” so lets see what happens. Ill report progress as soon as the imaging is complete
-
@Tom-Elliott Still a no go as of rc 12 135.
I have imaged a 1tb hd and it refuses to fit to a 500 gig drive though ive done the same with fog all this time.
keeping in mine the drive only has about 360 worth of data on it
-
@dureal99d Well,
Resize is a balance between disk sizes unfortunately. I cannot change much in how this is handled either. Is it failing to image at all, or not expanding the partitions?
The math involved is dealing in “percentages” of the originating disk size when compared to the new disk size.
If you have a 1tb drive and partition one uses 200GB of data, a 500GB drive will halve the size down to 100GB. If the data on the partition this is referencing is greater than the 100GB, then FOG won’t be able to image.
It was decided to use this approach as the approaches in the past were much less forgiving. It dealt with volumes and resizing (shrinking or expanding) in terms of variable space. This “variable” space idea works but with a few draw backs.
- Variable space required the use of the originating partition table vs. the minimum file. (So why bother using the minimum file at all?) – This is where I can change the code slightly, but the issue would likely still be present.
- Variable space didn’t scale very nicely (or was much worse than the new system). This is because using the “variable” space actually left SMALLER partition sizes than this new approach. The math’s involved are now based on the percentage of the whole disk rather than the “variable” space. This is so data being applied to an “exact same sized drive” will be applied in “exactly” the same manner as was originally laid out. Variable adjustments were not able to do this.
The last thing to consider, for now, is a 360GB of data size is still a bit of a misnomer. FOG leaves some “gap” space for each of its resizable partitions. This gap space is intended to help ensure the OS has enough room to do normal actions on reboot and is part of why systems don’t just halt working if expanding the drive failed.
This gap space is typically defaulted to about 5 percent of the size of the partition. For example, a partition with 200GB that might contain only 100GB of data would be resized to about 105GB (100 * .05 = 5, 100 + 5 = 105GB.) So a drive with 360GB of data might actually require a drive of larger than 500GB.
-
Just experienced this problem. Stated with a normal windows 7 “single partition” image on a 1 TB drive and restored to a 500 MB drive. The usual 100 meg system partition was reduced to 50 meg and the error was similar to the above.
Running Version 1.3.4
SVN Revision: 6066The two files with relevant information from the image folder are:
d1.minimum.partitions:
abel: dos
label-id: 0x86308630
device: /dev/sda
unit: sectors/dev/sda1 : start= 2048, size= 204800, type=7, bootable
/dev/sda2 : start= 206848, size= 31875436, type=7d1.partitions:
label: dos
label-id: 0x86308630
device: /dev/sda
unit: sectors/dev/sda1 : start= 2048, size= 204800, type=7, bootable
/dev/sda2 : start= 206848, size= 976564224, type=7Cheers
-
@John-Sayce update to RC13, problem will go away
-
@Junkhacker Not quite.
The image would need to be recaptured first.
-
@John-Sayce Thanks, will do.
