Target partition is smaller than source

[Scott B]

This issue was originally brought up by @Roger-Saffle in THIS THREAD but we didn’t want to hijack the OP’s original post.

We have noticed an issue when pulling down our images where we receive the error below at which point it reboots in 1 min. If you let host try and try again, the images eventually does download. Could be on 1 reboot, could be on 10, but so far eventually it does finish.

"Target partition size (XXXXXX MB) is smaller than source (XXXXXX MB).  Use option -C to disable size checking.

As seen in this image as well.

All of our images are now Win10x32 set to “Multiple Partition Image - Single Disk (Not Resizable)” using Partclone. This is also our first time using sysprep in the image creation so I don’t know if we are doing something wrong in its setup that could cause this.

We have been testing mostly with our HP 4000 desktops, info on their image is below.

root@FOG:/images/4000SYSPREP# ls -al
total 9917704
drwxrwxrwx  2 root root        4096 Jun  2 13:09 .
drwxrwxrwx 19 fog  root        4096 Jun  2 13:09 ..
-rwxrwxrwx  1 root root     1048576 Jun  2 12:59 d1.mbr
-rwxrwxrwx  1 root root    10370946 Jun  2 12:59 d1p1.img
-rwxrwxrwx  1 root root 10144291774 Jun  2 13:09 d1p2.img
-rwxrwxrwx  1 root root         190 Jun  2 12:59 d1.partitions
root@FOG:/images/4000SYSPREP#

root@FOG:/images/4000SYSPREP# cat d1.partitions
label: dos
label-id: 0x9132375b
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=     1024000, type=7, bootable
/dev/sda2 : start=     1026048, size=   155273392, type=7

FOG SVN: 7959
OS: Ubuntu 14.04.4 LTS

[Wayne Workman]

/dev/sda2 is the second partition. It’s possible the destination drive is a little smaller. One sector less would break it, but I think you have a hand-full of sectors smaller in this case.

Pop the hood on the reference machine and troubled machine - compare HDDs, look at sector count per head/cylinder. Look at model numbers.

Is there a good reason for not using resizable images?

[Scott B]

@Wayne-Workman said in Target partition is smaller than source:

/dev/sda2 is the second partition. It’s possible the destination drive is a little smaller. One sector less would break it, but I think you have a hand-full of sectors smaller in this case.

Pop the hood on the reference machine and troubled machine - compare HDDs, look at sector count per head/cylinder. Look at model numbers.

Just for testing I made the image on an 80GB drive and the destination workstation is a 250GB. The sysprep host is a VM based on a 40GB drive.

[Wayne Workman]

@Scott-B Where does the sysprep host come into play?

[Scott B]

@Wayne-Workman The master image with 99% of our settings/changes are done on the VM. Then that image is installed on one of each type of host (5 main ones). Then any specifics for that type are made and then syspreped again to create a master for that specific model.

[Wayne Workman]

@Scott-B Can you try a resizable image? If for no other purpose than to see the result?

[Scott B]

@Wayne-Workman Sure, I’ll report back what I find.

[Wayne Workman]

@Scott-B Remember after changing that on the image you need to re-upload. Or just create a new image.

[robza]

@Scott-B had similar problem. Try solution from [here](link https://forums.fogproject.org/topic/7628/partclone-failed-imaging-failed)

[Sebastian Roth]

Thanks for cross-linking this @robza. Looks pretty similar to me and I think we should definitely figure that one out. As you both say this is working sometimes but sometimes not I guess this will be very ugly to reproduce and figure out - but hey that’s what we do!

@Scott-B said:

Just for testing I made the image on an 80GB drive and the destination workstation is a 250GB. The sysprep host is a VM based on a 40GB drive.

Can you please be a bit more specific on the exact steps you take till you hit that error. From the d1.partitions you posted it looks like the image on the FOG server was pulled from a roughly 80GB disk (1026048 sectors + 155273392 sectors * 512 bytes per sector / 1024 / 1024 / 1024 = ~74GB). While your first sentence is totally clear I don’t understand where the 40GB sysprepped host/image enters the game. Please give me some advice on this.

PS: I am still wondering if both problems have the same root. One is GPT/4 partitions while the other is MBR/2 partitions. But both are non-resizable.

[Scott B]

@Wayne-Workman said in Target partition is smaller than source:

@Scott-B Can you try a resizable image? If for no other purpose than to see the result?
@Scott-B Remember after changing that on the image you need to re-upload. Or just create a new image.

I made new images and made them realizable. They all seem to be working just fine that way so I’ll go with it.

[Sebastian Roth]

@Scott-B Would you still be so kind to answer my question(s) so I might be able to find the issue to get it fixed eventually?

[Tom Elliott]

@Sebastian-Roth said in Target partition is smaller than source:

@Scott-B Would you still be so kind to answer my question(s) so I might be able to find the issue to get it fixed eventually?

I’m with you there. While I’m glad it’s working I would also much prefer a potential way to fix the problem as indicated.

[Wayne Workman]

@Sebastian-Roth @Tom-Elliott I agree. Since the disaster has been averted, there’s now time to dig deeper.

[Scott B]

@Wayne-Workman , @Tom-Elliott, @Sebastian-Roth

@Scott-B Would you still be so kind to answer my question(s) so I might be able to find the issue to get it fixed eventually?

No problem.

1. I start on a VM that has a 40GB hdd. I install windows and make a sysprep image. I image that up to FOG. I call it sysprepmaster in FOG.

2. I deploy that sysprepmaster image to the pcs we have in our classrooms. We are lucky to only have 5 basic models. That sysprepmaster comes down to those pcs with no issue.

3. On each of those specific types of PCs I make any other changes that need done specific to their model or use. Then I run sysprep to make and image for each one of them. 4000SYSPREP or DAK81SYSPREP for example. These machines have different hard drive sizes, 80GB in the case of the 4000SYSPREP which is where my previous post examples come from.

4. Finally I pull down the model specific images on the other similar models. That’s where I see the error in question.

What other information can I give you to help?

[Wayne Workman]

@Scott-B The contents of all those small text files in the images directory plus the MBR in there too. Zip em all up and upload.

[Scott B]

@Wayne-Workman 0_1464981879587_4000SYSPREP.zip

[Sebastian Roth]

Now that I have done some testing I don’t think this is the same issue than @robza has. He’s got a totally different partition layout (which I mentioned already) which we don’t do a very good detection on yet. His problem will never be fixed by re-trying I am sure! Will get to this later.

Now back to @Scott-B’s issue. Your partition layout is very simple and should not cause any trouble. Don’t get me wrong. Not saying that I don’t believe you but I need to kindly ask you to give us some more information. The picture you posted is Roger Saffle’s. While I don’t mind reusing anyones pictures we really need your information here to figure out what’s going wrong (with your image/partition layout).

So can you please to me a favor: Create a new image definition (so you don’t need to mess with your working ones) and make it Single disk - non-resizable. Upload from the same client you have before (so we have the same information in d1.partitions). Then deploy this new image in debug mode to one of your clients. If you get an error, please take a picture and run the following command when you get back to the command shell: sfdisk -d /dev/sda (again take a picture). If it does not fail could you please try over and over till you see the error.

[Scott B]

@Sebastian-Roth said in Target partition is smaller than source:

Now that I have done some testing I don’t think this is the same issue than @robza has. He’s got a totally different partition layout (which I mentioned already) which we don’t do a very good detection on yet. His problem will never be fixed by re-trying I am sure! Will get to this later.

Now back to @Scott-B’s issue. Your partition layout is very simple and should not cause any trouble. Don’t get me wrong. Not saying that I don’t believe you but I need to kindly ask you to give us some more information. The picture you posted is Roger Saffle’s. While I don’t mind reusing anyones pictures we really need your information here to figure out what’s going wrong (with your image/partition layout).

So can you please to me a favor: Create a new image definition (so you don’t need to mess with your working ones) and make it Single disk - non-resizable. Upload from the same client you have before (so we have the same information in d1.partitions). Then deploy this new image in debug mode to one of your clients. If you get an error, please take a picture and run the following command when you get back to the command shell: sfdisk -d /dev/sda (again take a picture). If it does not fail could you please try over and over till you see the error.

I can, but won’t be able to get to it till Monday. @Roger-Saffle and I work together. Same machines in question.

[Scott B]

I created a test image as requested as a single disk non resizable. Info below. When deployed it worked fine.

root@FOG:/images/TEST1# ls -la
total 14356996
drwxrwxrwx  2 root root        4096 Jun  7 13:53 .
drwxrwxrwx 20 fog  root        4096 Jun  7 13:53 ..
-rwxrwxrwx  1 root root     1048576 Jun  7 13:40 d1.mbr
-rwxrwxrwx  1 root root    10371828 Jun  7 13:40 d1p1.img
-rwxrwxrwx  1 root root 14690122936 Jun  7 13:53 d1p2.img
-rwxrwxrwx  1 root root         190 Jun  7 13:40 d1.partitions

root@FOG:/images/TEST1# cat d1.partitions
label: dos
label-id: 0x9132375b
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=     1024000, type=7, bootable
/dev/sda2 : start=     1026048, size=    82857984, type=7