FOG 1.2 - Target partition smaller than source - Windows 7/X-Image

[groinksan]

I’m brand-new to the whole FOG thing. I’m trying to develop a method to perform a mass roll-out of Dell Latitude and Precision computers. The disk image was sent to us as a Ghost GHO file. I then used Ghost 11 to image a 320GB hard disk drive. After imaging with Ghost, the hard drive is partitioned as follow (using Windows’ DISKPART / LIST PARTITION):

Partition 1 - OSDisk
Type - primary
Size - 294 GB
Offset - 1024KB

Partition 2 - BDEDrive
Type - primary
Size - 3180 MB
Offset - 294 GB

The image is Windows 7 64-bit based. The image uses X-Image, which is a Dell product that prepares Windows 7 for the specific hardware platform (kernel, drivers, etc.) So it is like sysprep but on steroids. X-Image is placed into the image before I ever receive it. so I have no control of that process.

When using Ghost, the BDEDrive partition size is untouched, while the OSDisk takes up the remainder of the hard drive, regardless of the hard drive size. So, I’m hoping FOG/Partclone can do the same thing. So even though the original drive is 320GB, I can image a 1TB drive and have the entire drive, minus BDEDrive, dedicated to OSDisk.

Right after Ghosting the master hard drive, with it in pre-X-Image state, I uploaded the hard drive contents to FOG, using the following settings:

Operating System: Windows 7 (5)
Image Type: Single Disk - Resizable (1)

The contents of d1.original.partitions generated by FOG are:

unit: sectors
/dev/sda1 : start = 2048, size=618625024, Id= 7
/dev/sda2 : start = 618627072, size=6512640, Id= 7, bootable
/dev/sda3 : start = 0, size = 0, Id= 0
/dev/sda4 : start = 0, size = 0, Id= 0

I then tried imaging a different computer that has a 1 TB hard drive. The hard drive has been erased, so no partitions are currently on the drive. During imaging, it comes up with the following error in Partclone:

Target partition size(105 MB) is smaller than source(316737 MB). Use option -C to disable size checking(Dangerous).

It works when I use the multiple partition image - single disk (not resizable), but I cannot use this option for the following reason: it places DBEDrive after OSDisk, so once I’m booted into Windows 7, I cannot adjust OSDisk to take up the rest of the free space, as Windows requires contiguous free space (not in this case, since DBEDrive is smack dab in-between OSDisk and the remaining free space.) So I was hoping the Single Disk option would work like Ghost.

Sorry for the long post, but I want to be as thorough as possible! Thanks!

[Wayne Workman]

Judging from the blank last two partitions, your base image is GPT, for that I would recommend FOG Trunk… read on…

@Tom-Elliott had a hunch in other threads (below) that it has to do with the start sector. Dells are weird, they don’t start at sector 63 normally. You’re particular image here starts at sector 2048. I have both had this exact problem and have seen others with this exact problem. I myself have simply made an image from scratch, and I’ve had no problems with re sizable images doing this (MBR and GPT both).

https://forums.fogproject.org/topic/5220/target-partition-size-is-smaller-than-source
(Same names, different threads)
https://forums.fogproject.org/topic/5026/target-partition-size-is-smaller-than-source

Here is some output from some resizable Win7 images I have on my home fog server to perhaps help out… I find it odd that I have a start sector of 2048 on these as well but they re-size fine. Keep in mind these are made-from-scratch images.

[root@fog images]# ls

CentOS7Optiplex745UpdateBASE           Fedora22LivingRoom                   Ubuntu15L530
dev                                    optiplex380RAID1CentOS7              Win7
EliteBook8730wUbuntu15Sep2015Robotics  Optiplex745WinXPconfiguredApril2015  Win7SC2LenovoL530
EliteBook8730wWin7                     postdownloadscripts

[root@fog images]# cat Win7SC2LenovoL530/d1.partitions

label: dos
label-id: 0x2bd2c32a
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=      204800, type=7, bootable
/dev/sda2 : start=      206848, size=   976566272, type=7

[root@fog images]# cat Win7SC2LenovoL530/d1.minimum.partitions

label: dos
label-id: 0x2bd2c32a
device: /dev/sda
unit: sectors

/dev/sda1 : start=      2048, size=    204800, type= 7, bootable
/dev/sda2 : start=    206848, size= 106027468, type= 7

[root@fog images]# cat EliteBook8730wWin7/d1.partitions

label: dos
label-id: 0x2bd2c32a
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=      204800, type=7, bootable
/dev/sda2 : start=      206848, size=   312373248, type=7

[root@fog images]# cat EliteBook8730wWin7/d1.minimum.partitions

label: dos
label-id: 0x2bd2c32a
device: /dev/sda
unit: sectors

/dev/sda1 : start=      2048, size=    204800, type= 7, bootable
/dev/sda2 : start=    206848, size=  90465072, type= 7

[root@fog images]# ls Win7

d1.fixed_size_partitions  d1.minimum.partitions  d1.original.partitions  d1p1.img
d1.mbr                    d1.original.fstypes    d1.original.swapuuids   d1p2.img

[root@fog images]# cat Win7/d1.original.partitions

label: dos
label-id: 0x7d05107f
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=      204800, type=7, bootable
/dev/sda2 : start=      206848, size=   585904128, type=7

[root@fog images]# cat Win7/d1.minimum.partitions

label: dos
label-id: 0x7d05107f
device: /dev/sda
unit: sectors

/dev/sda1 : start=      2048, size=    204800,  type=7, bootable
/dev/sda2 : start=    206848, size=  71813190,  type=7

I’m fairly certain that the @Developers have worked something in to fix this in the current trunk revisions, and I think improvements in GPT handling have also been made in FOG Trunk. Since you’re brand new to fog, I’d highly recommend just diving right in and trying out the developmental trunk versions.

Read more here:
https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

Try it out and let us know. We are here to help.

[Tom Elliott]

I’m a little confused. Multipart non resize images do not move partitions around. Not in the slightest. Your first code output shows partition 1 as the OS and partition 2 as the bdedrive.

If this source disk is 1tb in size, and the receiving disk is 1tb in size, then your layout would, more or less, be identical between systems. Fog does not shift partitions around. In the case of resizable images, you would see very similar results to your description saying it cannot size them up properly.

[Sebastian Roth]

I am not too sure if this is GPT. Might be but I have seen a lot of disks starting the first partition on 2048 which is actually preferred on SSD!

There are a lot of partition schemes with recovery partitions and other “unusual” things out there. It’s very hard to make assumptions about all those things to be able to do resizeable images. Seeing two NTFS partitions FOG (1.2.0 and I think this is also true for trunk @Tom-Elliott??) assumes sda1 being the Windows boot partition and sda2 the System partition. Deploying to a different computer FOG just creates sda1 big enough to fit a windows boot partition into it (“Target partition size(105 MB) is smaller…”).

Sure this is far from perfect but it works for most users. We would need to spend heaps more time to make the capturing resizeable images fit all environments/partition schemes.

I don’t use resizeable and wasn’t involved in developing this code. So it is a bit of guess work. Take a look at the partition files: d1.fixed_size_partitions, d1.minimum.partitions, d1.original.partitions. Maybe post the contents and we might find a quickfix for you here.

[Tom Elliott]

@Sebastian-Roth trunk will only make assumptions on partition layout if the sys.img and/or rec.img files exist. Otherwise, it uses the d1.mbr to create the partition layout. I thought this was true of fog 1.2.0, but it has been a while.

[Sebastian Roth]

@groinksan Well then you might want to try FOG trunk. See Wayne’s post. Thanks Tom for clarifying.

[groinksan]

I’m going to try the FOG trunk route. Moving in this direction, and with my master’s partitioning scheme, should I continue to use the multiple partition/single drive resizable option?

[Sebastian Roth]

@groinksan said:

… should I continue to use the multiple partition/single drive resizable option?

Either that or you could try deploying the image once to a 1TB disk using ghost. Then pull an image from that using FOG (non-resizeable setting) and deploy it to your other hosts (if they all have 1TB disks). Should work with 1.2.0 as well.