Partitions is not shrinking in windows 10

[coop90]

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

[Wayne Workman]

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/

[coop90]

Thanks! I will update and retry the capture tomorrow.

[coop90]

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

[Quazz]

@coop90 Going to ask for more details.

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

[coop90]

Its MBR.

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

[Wayne Workman]

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

[Tom Elliott]

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.

[george1421]

@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 drive and on win10 p3 was the drive.

[Tom Elliott]

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

[Tom Elliott]

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

[Wayne Workman]

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

[Tom Elliott]

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

[Tom Elliott]

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

[coop90]

I wont be able to try until Monday.

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

[Quazz]

@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

[coop90]

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

[Tom Elliott]

@coop90 https://news.fogproject.org/fog-1-3-4-rc-1/

[coop90]

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