Partition not expanding

[Taspharel]

Re: Hard drive resize is not expanding

Well … not sure its the exact same problem, thus opening the new thread, we can merge if its the same.

I am using FOG to install our Windows 10 Golden Image via the network.

The install works fine on most computers, BUT: The image no longer expands to fill the partition as it used to.

I did change a few things in the Golden Image prior to it no longer working, but nothing that I could think of that has to do with any partition or HD - size related stuff. Answer file is as was. Image type is still single disk resizable. The image has about 48Gig on Client.

No error messages during install as far as I can see.

Running FOG on a Centos Server, installing Windows 10 Professional 64Bit from an updated Golden Image that used to work.
FOG is on 1.5.0 RC-10

Any ideas where I can start looking?

[Taspharel]

Soooo…
Didnt do the suggested thing yet because I had another problem with my partitions - had to resize the Data Partition in my VMs hard drive in order to install the Windows 10 Fall Creators Update 1709 - and decided to change the partition order while I was at it. Turns out that is not as easy as I would have hoped.

If anybody else needs to move their EFI Partition sometime in Windows:

Situation: You have a system set up for UEFI. You have your data partition and after that the EFI GPT Partition.
When I speak of after or left and right its always as displayed in the Windows Disk Management from left to right.

Make a BACKUP !! - before anything else.

1. Use a Partition Tool (e.g. Minitool Partition Wizard or anything else you’re familiar with, M-PW is free) and make sure that you have a free space preceding your Data partition that is at least as big as the EFI GPT Partition behind your Data Partition. For example you can Resize your data partition to free some space and make it unallocated at the right position (which is left of the data partition).

2. Copy the existing EFI GPT Partition to the free unallocated space.

3. After reboot - necessary to apply changes - reboot again using gparted live ISO / USB / whatever suits you (https://gparted.org/

4. In Gparted: Set the flags for the new copied EFI Partition to: Boot & ESP (Right click on the partition -> manage flags)

5. You can also delete the old EFI partition in this step if you aren’t afraid - if you delete it and your copy doesnt work you are probably going to be stuck with a non-booting system. Again, make sure you have a backup / snapshot.

After letting gparted do its thing and rebooting into Windows you should have the correct order of partitions down.

In my machine the order from left to right is now as follows:

Recovery partition
EFI Partition
Windows 10 Data Partition

I’ll try and update if anything changes.

[Sebastian Roth]

@Taspharel You might start by posting the contents of d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions of that image here in the forum.

Has the installation been done from a alternative language medium (French, Italian, …)?

[Taspharel]

The image is an english international Windows 10 Professional but there is a german language package installed.

File contents as suggested:

d1.fixed_size_partitions
:3:1

d1.minimum.partitions

label: gpt
label-id: 06F1156D-A1CD-11E7-B138-080027E94607
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 104857566

/dev/sda1 : start=        2048, size=     1024000, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=06F1156A-A1CD-11E7-B138-080027E94607, name="attrs="RequiredPartition GUID:63"

/dev/sda2 : start=     1026048, size=   103626240, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=06F1156B-A1CD-11E7-B138-080027E94607

/dev/sda3 : start=   104652288, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=06F1156C-A1CD-11E7-B138-080027E94607, name="attrs="GUID:63"

d1.partitions

label: gpt
label-id: 06F1156D-A1CD-11E7-B138-080027E94607
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 104857566

/dev/sda1 : start=        2048, size=     1024000, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=06F1156A-A1CD-11E7-B138-080027E94607, name="attrs="RequiredPartition GUID:63"

/dev/sda2 : start=     1026048, size=   103626240, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=06F1156B-A1CD-11E7-B138-080027E94607

/dev/sda3 : start=   104652288, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=06F1156C-A1CD-11E7-B138-080027E94607, name="attrs="GUID:63"

Thank you for your support!

[Sebastian Roth]

@taspharel From my point of view your partition layout is kind of upside down. Let me explain. The recovery partition (type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC) is first, second comes the Windows system partition and third is your EFI boot partition (type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B).

So with that FOGs magic resize scripts detect sda1 and sda3 to not be resizable and also not movable as it would break the Windows boot process if it’d be on a legacy BIOS MBR type of system.

Though I can’t promise, I think you might be fine changing d1.fixed_size_partitions from :3:1 to just 1 and do a redeploy to one of your machines. It’s probably not perfect as it will probably expand sda2 and sda3 accordingly. See what you get. And keep your fingers crossed that it won’t break the UEFI boot process.

In your initial post you said:

I did change a few things in the Golden Image prior to it no longer working, but nothing that I could think of that has to do with any partition or HD - size related stuff.

Could it be the case that you moved your Golden image from being legacy MBR to UEFI/GPT?

[Taspharel]

Hi and thanks for your feedback and suggestions so far.

I will try changing the d1.fixed… file as suggested and see what happens.

Regarding the changes:
The change from MBR to UEFI did happen, but has been made already a long time ago. So not with the most recent changes to the image.

[Taspharel]

Soooo…
Didnt do the suggested thing yet because I had another problem with my partitions - had to resize the Data Partition in my VMs hard drive in order to install the Windows 10 Fall Creators Update 1709 - and decided to change the partition order while I was at it. Turns out that is not as easy as I would have hoped.

If anybody else needs to move their EFI Partition sometime in Windows:

Situation: You have a system set up for UEFI. You have your data partition and after that the EFI GPT Partition.
When I speak of after or left and right its always as displayed in the Windows Disk Management from left to right.

Make a BACKUP !! - before anything else.

1. Use a Partition Tool (e.g. Minitool Partition Wizard or anything else you’re familiar with, M-PW is free) and make sure that you have a free space preceding your Data partition that is at least as big as the EFI GPT Partition behind your Data Partition. For example you can Resize your data partition to free some space and make it unallocated at the right position (which is left of the data partition).

2. Copy the existing EFI GPT Partition to the free unallocated space.

3. After reboot - necessary to apply changes - reboot again using gparted live ISO / USB / whatever suits you (https://gparted.org/

4. In Gparted: Set the flags for the new copied EFI Partition to: Boot & ESP (Right click on the partition -> manage flags)

5. You can also delete the old EFI partition in this step if you aren’t afraid - if you delete it and your copy doesnt work you are probably going to be stuck with a non-booting system. Again, make sure you have a backup / snapshot.

After letting gparted do its thing and rebooting into Windows you should have the correct order of partitions down.

In my machine the order from left to right is now as follows:

Recovery partition
EFI Partition
Windows 10 Data Partition

I’ll try and update if anything changes.

[george1421]

@taspharel Just an additional datapoint to your workflow. If you would create your reference image (vm) with MDT you can control the partitions and order of creation.

The default partition layout is

1. Boot (efi) 500MB fat32
2. MSR (microsoft reserve partition) 128MB
3. Windows (Primary) 99% remaining space
4. Recovery 100% remaining space.

In our case we remove the recovery partition because its easier (and faster) to reload the image than try to repair it using recovery tools.

[Tom Elliott]

Does this mean this “bug” can be solved?

[Taspharel]

It does. Thanks!

While George’s solution might have worked for the “bug” the cleaner solution is probably doing it right with the partition order…is it “frech” to mark my own post as solution?