Target partition is smaller than source
-
@Scott-B Where does the sysprep host come into play?
-
@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.
-
@Scott-B Can you try a resizable image? If for no other purpose than to see the result?
-
@Wayne-Workman Sure, I’ll report back what I find.
-
@Scott-B Remember after changing that on the image you need to re-upload. Or just create a new image.
-
@Scott-B had similar problem. Try solution from [here](link https://forums.fogproject.org/topic/7628/partclone-failed-imaging-failed)
-
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.
-
@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.
-
@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?
-
@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.
-
@Sebastian-Roth @Tom-Elliott I agree. Since the disaster has been averted, there’s now time to dig deeper.
-
@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.
-
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.
-
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.
-
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.
-
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?
-
-
@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.
-
-
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. -
@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.
-
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
-
@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. -
@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
andd1.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?!? -
@Sebastian-Roth That makes a lot of sense to me. Does the inits assume it’s re-sizable if those files are present?