Target partition is smaller than source



  • 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.

    ScreenShot

    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


  • Developer

    @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.


  • Moderator

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


  • Developer

    @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?!?


  • Developer

    @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.



  • 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 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.


  • Developer

    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.




  • Moderator

    @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.



  • @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?


  • Moderator

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


  • Senior Developer

    @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.


  • Developer

    @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?



  • @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.


  • Developer

    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 had similar problem. Try solution from [here](link https://forums.fogproject.org/topic/7628/partclone-failed-imaging-failed)


  • Moderator

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



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


  • Moderator

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


Log in to reply
 

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.