FOG Not resizing partition Windows 10 v1909

Derek Newbold

Hi,

We have built a new image based on Windows 10 v1909 and having trouble deploying it. When the computer boots up it errors during the OOBE process. We’ve not had this same issue with previous Windows 10 images, including v1903.

After some investigation we ended up shutting the computer down directly after the deploy image process and then plugged the imaged hard drive into another computer using a USB adapter. We found that it appears as though it is not resizing the C:\ partition to take up the remaining hard drive space. We are thinking this is probably causing our OOBE errors as the drive gets completely full.

As a test we extended the C:\ partition while it was plugged into the other computer, and now we have put it back into the original computer and let it bootup. It then went through the OOBE process and it worked fine with no errors.

We recorded the end of the imaging process and it seems like it says it resizes the NTFS volume (/dev/sda4) OK. I’m guessing that refers to the C:? Or is it actually referring to the unallocated space as there appears to be 3 actual partitions on the drive (Recovery, No-Name, and C:).

We made the image using a VM with a 100GB hard drive allocated. The destination SSD drives are 240GB so that shouldn’t be a problem. We’ve also tried running a ‘chkdsk /F’ before capturing, but maybe we didn’t do the chkdsk quite right as per this wiki page https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit but as we aren’t seeing any errors during the FOG capture/deploy processes I’m not sure if this would be our problem?

Any ideas? Should we be following that Windows Dirty Bit guide more closely?

FOG version: 1.5.4

Thankyou, Derek

Derek Newbold

@Sebastian-Roth @sudburr @Boyan-Biandov

Thanks everyone! We’ve changed our image capture to a fixed disk size now and we already happened to have the <extendpartition> bit in the unattended.xml file. This arrangement is now working for us and the partition has been automatically extended on our test machine.

We don’t really need the ‘Single Disk-Resizable’ if we can get the partition to extend in another way. Our VM that we capture is set to 100GB and all our destination computers have SDD drives larger than that.

I will look into updating FOG when I get some time to focus on it properly. Unfortunately for us we have difficulty updating/installing FOG through our Departments internet filtering/firewall which we don’t have full access too. I could connect it up to a direct internet connection, but that could involve a different IP address being required. I was told FOG doesn’t really like the server having it’s IP address changed, so I wasn’t sure if I should attempt to do that or not.

Sebastian Roth

Hey, can you please post the contents of the text files d1.partitions, d1.minimum.partitions and as well d1.fixed_size_partitions (the later probably not playing a role but while you are at it…) of your new image here in the forums. You find those files in /images/#IMAGENAME# on your FOG server.

@Derek-Newbold said in FOG Not resizing partition Windows 10 v1909:

FOG version: 1.5.4

Which version of the init.xz files do you use? Still the ones that are delivered with 1.5.4 or did you manually update at some point? Please run ls -al /var/www/html/fog/service/ipxe/init* and post output here.

Boyan Biandov

@Derek-Newbold I’ve had HDD expansion issues using FOG’s native feature for years and even though it maybe fixed by now here’s what I’ve used.

I have a “last boot” script as part of the sysprep and there the HDD happens. Simple power shell script to expand it to maximum physical size possible:


$size = (Get-PartitionSupportedSize -DiskNumber 0 -PartitionNumber 2)
Resize-Partition -DiskNumber 0 -PartitionNumber 2 -Size $size.SizeMax

Derek Newbold

@Sebastian-Roth thankyou for helping with this

d1.partitions

label: gpt
label-id: B62AFA65-B825-4E56-94C3-FD0F767DC41C
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 209715166

/dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=CFEE5F7A-A283-44D1-AE88-BF7C5E9DA222, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/sda2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=23B34044-D2F1-40D9-996D-88707020B564, name="EFI system partition", attrs="GUID:63"
/dev/sda3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=FB7F6919-A4A8-45DD-B053-1826506A9607, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda4 : start=     1320960, size=   208392192, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=C326A6E9-C39C-4692-9BCF-96D9FDF34AC4, name="Basic data partition"

d1.minimum.partitions

label: gpt
label-id: B62AFA65-B825-4E56-94C3-FD0F767DC41C
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 209715166

/dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=CFEE5F7A-A283-44D1-AE88-BF7C5E9DA222, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/sda2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=23B34044-D2F1-40D9-996D-88707020B564, name="EFI system partition", attrs="GUID:63"
/dev/sda3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=FB7F6919-A4A8-45DD-B053-1826506A9607, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda4 : start=     1320960, size=   143069068, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=C326A6E9-C39C-4692-9BCF-96D9FDF34AC4, name="Basic data partition"

d1.fixed_size_partitions

:2:3:1

I do not recall manually updating the init.xz files so they are probably still the ones delivered with 1.5.4

ls -al /var/www/html/fog/service/ipxe/init*
-rw-r--r-- 1 fog www-data 19254252 Jun 28  2018 /var/www/html/fog/service/ipxe/init_32.xz
-rw-r--r-- 1 fog www-data 19948692 Jun 28  2018 /var/www/html/fog/service/ipxe/init.xz

Derek Newbold

@Boyan-Biandov thankyou for that tip! I will try that if we fail to get FOG resizing it correctly.

Do you put that in the ‘C:\Windows\Setup\Scripts\SetupComplete.cmd’ script? Your code appears to be Powershell based, so I’m guessing you must run it in a seperate script? If so, how do you call that script to run?

Thinking about it, I’m not sure it will help us as Windows is erroring during the OOBE process (due to lack of C:\ disk space we suspect) which I think would be before it even runs the SetupComplete.cmd script where we could possibly resize the partition.

I guess what we could do is not use the ‘Single Disk-Resizable’ FOG image option, and use a fixed size one instead, then your script would probably work OK and we would have enough C:\ space still for the OOBE process to run?

Derek Newbold

@Boyan-Biandov I forgot to ask in my last post, what does your partition table look like in your image that you use your script on? I see you have it set to resize partition 2.

We have 3 partitions (although the FOG partition information files lists 4 hmm) and it’s the 3rd partition that needs resizing.

Would we need to change the script to 3 or does the numbering start at 0 so 2=3rd partition?

Sebastian Roth

@Derek-Newbold said in FOG Not resizing partition Windows 10 v1909:

We have 3 partitions (although the FOG partition information files lists 4 hmm) and it’s the 3rd partition that needs resizing.
Would we need to change the script to 3 or does the numbering start at 0 so 2=3rd partition?

I might comment on this quickly so you don’t get this wrong. You actually have four (4!) partitions on your drive. You only see three because Windows disk management console is hiding one of them (I think it’s probably sda3 in your case). I am not exactly sure if powershell actually sees 3 or 4 partitions in your case. You might want to open a powershell window as Admin and run Get-Partition first to get a list of all partitions on all disks. It also prints the size of each partition and with that you should be able to find the right one to resize.

Now back to why FOG doesn’t expand to full size for you in the first place. From the partition listings you posted it looks all fine to me. So there is no obvious reason I think. Your inits/setup being one and a half year old might cause this issue. There have been a lot of fixes and changes in the inits since then. While chances are high this is fixed in the latest already I can’t promise you anything. What I can say for sure is that we won’t backport any fix to 1.5.4 so if you want to see this fixed you need to update.

Not exactly sure but you should be able to just use the latest inits and kernels to run with your 1.5.4 install. There are a few things to consider. If you are keen to give it a try, let us know.

sudburr

For a sysprep solution look here.

<extendospartition>
	<extend>true</extend>
</extendospartition>

Boyan Biandov

@Derek-Newbold You’re correct, the ps1 is called from C:\Windows\Setup\Scripts\SetupComplete.cmd but since it is a power shell script it can not be pasted into the bat file, so I use powershell.exe -executionpolicy bypass -file “C:\Windows\Setup\Scripts\expandhdd.ps1”

As for partition numbers, this was a trial and error process, the disk only has 2 partitions, windows reserved and the OS so that is how it came about.

I do agree that if your OOBE bombs out due to disk space issues then my suggestion won’t work, the HDD expansion happens downstream

Derek Newbold

@Sebastian-Roth @sudburr @Boyan-Biandov

Thanks everyone! We’ve changed our image capture to a fixed disk size now and we already happened to have the <extendpartition> bit in the unattended.xml file. This arrangement is now working for us and the partition has been automatically extended on our test machine.

We don’t really need the ‘Single Disk-Resizable’ if we can get the partition to extend in another way. Our VM that we capture is set to 100GB and all our destination computers have SDD drives larger than that.

I will look into updating FOG when I get some time to focus on it properly. Unfortunately for us we have difficulty updating/installing FOG through our Departments internet filtering/firewall which we don’t have full access too. I could connect it up to a direct internet connection, but that could involve a different IP address being required. I was told FOG doesn’t really like the server having it’s IP address changed, so I wasn’t sure if I should attempt to do that or not.

Sebastian Roth

@Derek-Newbold said in FOG Not resizing partition Windows 10 v1909:

I was told FOG doesn’t really like the server having it’s IP address changed, so I wasn’t sure if I should attempt to do that or not.

While it’s not as trivial as change the Linux IP settings and ready set go it can still be done and we have documentation on that: https://wiki.fogproject.org/wiki/index.php/Change_FOG_Server_IP_Address

Derek Newbold

@Sebastian-Roth in that guide one of the first steps is to re-run the installer after changing the IP address of the OS and in the /opt/fog/.fogsettings file.

My problem is that once I change the IP address and network connection back to what we normally run FOG under, I lose my direct (unfiltered/firewalled) internet access, so I’m back to not being able to run the installer. Is there any way around that?

Sorry this post is probably going a bit off-topic now.

Sebastian Roth

@Derek-Newbold said in FOG Not resizing partition Windows 10 v1909:

Sorry this post is probably going a bit off-topic now.

Yeah, we should probably open a new topic on this? Will you? We also have a community script that does the IP change for you: https://github.com/FOGProject/fog-community-scripts/tree/master/updateIP

Though this is not well maintained and I can’t promise you anything right now. But we can work on this if you would like to assist with testing and report here in the forums.

Derek Newbold

@Sebastian-Roth thankyou! I’ll open another topic if need be when I get a chance to look at upgrading FOG.

Boyan Biandov

@Derek-Newbold FYI I have seen ton of people running FOG in AWS with totally public IP and that works outside of any firewall issues, of course those instances involve people who have access to the local sites DHCP so they can update the tftp option in their scopes with the public IP

In my case it’s a private IP but I do have access to the networking side of things so sites throughout the organization can boot fine from HQ FOG server.

FOG Not resizing partition Windows 10 v1909

282

11.6k

17.1k

154.6k