FOG 1.2 - Target partition smaller than source - Windows 7/X-Image
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!
… 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.
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?
@groinksan Well then you might want to try FOG trunk. See Wayne’s post. Thanks Tom for clarifying.
@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.
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.
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.
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).
(Same names, different threads)
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:
Try it out and let us know. We are here to help.