Partitions is not shrinking in windows 10



  • Server
    • FOG Version: 1.3.2
    • OS: Ubuntu 14.04
    Client
    • Service Version: 0.11.8
    • OS: Windows 10
    Description

    I am trying to capture an image from a windows 10 machine. (Our windows 7 machines captured fine.) The issue is, when single disk resizable is selected, it does not resize. Before partclone begins it says “not shrinking, fixed size.” When partclone is running it shows the correct device size (498.6gb) and the correct space in use (18.3gb).

    This is going to prevent me from deploying to clients with a smaller hard drive.

    Why isnt fog able to shrink the C: partition to the 18gb that are in use? Is there a problem with how the partitions were created?

    Thanks!

    I am seeing the same problem in 1.3.1 and 1.3.2 and now in 1.3.3.



  • @Tom-Elliott The resize worked correctly. Thank you for quickly finding the solution!


  • Senior Developer



  • @Quazz Thanks! I will try on Monday and report back.


  • Moderator

    @coop90 There’s a program named Terminal (on Ubuntu you can search for this by clicking on the icon top left and typing, assuming default theme). Paste them in there



  • I wont be able to try until Monday.

    I am not so familiar with linux, where/how can I run the wget commands?


  • Senior Developer

    @coop90 Have you had a chance to try the wget and new inits to see if capturing the disk is now working for you?


  • Senior Developer

    @Wayne-Workman I haven’t either, but the OP is installing windows 10 on a legacy system using, more or less, a single partition layout as described earlier. It may have been setup manually rather than letting windows do its think naturally (or there’d likely be at least one more partition).


  • Moderator

    @Tom-Elliott said in Partitions is not shrinking in windows 10:

    So if the windows 10 in this thread is:
    465 gb to /dev/sda1
    450mb to /dev/sda2
    It would not be able to (properly) shrink because we were implicitly making partition 1 on any hdd a fixed partition.

    I’ve never seen a disk laid out like this. But I think the less assumptive the code is, the better.


  • Senior Developer

    @Wayne-Workman The fact that the statement is showing it is really in resizable I think the GUI checks (while useful) would not prove any more helpful.

    The message the OP is seeing is:
    “Not shrinking (fixed size)”.

    This message ONLY comes from resizable images.


  • Senior Developer

    @george1421 lsblk would definitely help us with seeing how the partitions are defined.

    That said, from what I’m gathering of this thread, the issue is specifically only because we were always making partition 1 (unless it was literally the only partition) a fixed size.

    So if the windows 10 in this thread is:
    465 gb to /dev/sda1
    450mb to /dev/sda2
    It would not be able to (properly) shrink because we were implicitly making partition 1 on any hdd a fixed partition.


  • Moderator

    @Tom-Elliott Do you think we should have the OP setup a debug capture/deploy to get the output of lsblk ? This way we have a solid idea what the partition structure looks like?

    It could also be akin to the issue that you coded for in the postinstall script where the disk structure is a bit different between win7 and win10. On win7 p2 was the C: drive and on win10 p3 was the c: drive.


  • Senior Developer

    I believe I might have figured out a fix for this.

    Just a guess, your partition layout is:

    /dev/sda1 = c:
    /dev/sda2 = recovery

    The issue of not resizing is we were always making the first partition a fixed size. This will be corrected for I hope. I think it was more a fail safe to the typical partitioning scheme, but again it was assumptive in nature.

    I’ve changed the code base to hopefully handle this more properly as fixed size partitions will typically be automatically populated if/when/where possible. Of course, you can still specify your own fixed size partitions after the image gets uploaded (or via postinitscripts now) as you see fit.

    Please try the wget commands:

    wget -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz
    wget -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xz
    

    With any luck this will help address this issue. I suppose we could consider it a bug, but an originally (semi) intentional one. I think we were meaning to just be safe with how to handle these things.


  • Moderator

    @coop90 I don’t know where your knowledge level with fog is - but maybe this post will help future readers so… a few things.

    • If an image is captured as non-resizable, you cannot change it to resizable w/o re-capture and expect it to deploy correctly.
    • For an image to be resizable, it must be captured as resizable.
    • It helps greatly with resizing if the disk is well-defragmented before the capture process.
    • For the partitions to be resized, there needs to be free space on the partitions.

    I would suggest double checking what image is assigned to the host you are capturing from. Do not assume this, go and actually literally check the host (via the web interface) and see what image it is assigned - then go look at that image and ensure it’s set as resizable.



  • Its MBR.

    C: takes up 465gb which is followed by a 450mb recovery partition.


  • Moderator

    @coop90 Going to ask for more details.

    MBR or GPT layout?
    What does the partition layout look like?



  • After updating to 1.3.3, it is doing the same thing. It isnt shrinking the main C: partition.



  • Thanks! I will update and retry the capture tomorrow.


  • Moderator

    This is a known issue in 1.3.2, and is fixed in 1.3.3. See the news release for details: https://news.fogproject.org/fog-1-3-3-officially-released/


Log in to reply
 

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