Target partition is smaller than source

[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

[Sebastian Roth]

@Scott-B said:

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

Well then I am not able to help. Can you please try again and again till it fails? And if it fails then run sfdisk -d /dev/sda and post a picture here, please.

[Sebastian Roth]

@Scott-B said in Target partition is smaller than source:

@Wayne-Workman 0_1464981879587_4000SYSPREP.zip

This is really confusing! In that ZIP there is d1.minimum.partitions and d1.fixed_size_partitions which you only get with resizable image type, while in your first post you said this is non-resizable. My guess is you uploaded as resizable once and then changed image type to non-resizable. The error is still weird but maybe that can explain the issue?!?

[Wayne Workman]

@Sebastian-Roth That makes a lot of sense to me. Does the inits assume it’s re-sizable if those files are present?

[Sebastian Roth]

@Wayne-Workman said:

That makes a lot of sense to me. Does the inits assume it’s re-sizable if those files are present?

While I am still not sure this was the issue I am pretty sure that things can go wrong if you simply change from resizable to non-resizable (plus use different size destination disks) without uploading again. But the inits do not assume resizable just because those files are there - they do the image type configured in the DB and just try to use the partition information available (d1.partitions in case of non-resizable) ignoring the other stuff.

As I said: It doesn’t have to cause trouble but it’s likely to.