FOG will not resize a hard drive after deployment.

[m.fitzgerald]

@george1421

We use a multi site environment with one main site and 10 remote sites. If I were to switch to the Dev Branch I assume I would need to upgrade all servers to match, correct?

[george1421]

@m-fitzgerald yes, and understand it is a one way street too. You should not roll back to 1.4.4 once you update. In 1.5.0 the webgui has changed (for the better btw).

[m.fitzgerald]

@george1421 What the hell, I am a gambling man. Point me in the right direction!

[george1421]

@m-fitzgerald No pain no gain then…

https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

The key is this command

git checkout dev-branch

Then when 1.5.0 is released you change your install back with

git checkout master

Then rerun the installer.

[Wayne Workman]

As well as: https://wiki.fogproject.org/wiki/index.php?title=Getting_FOG

[m.fitzgerald]

@george1421
I updated to 1.5 and took my same machine that Ii was having the image size issue with and deployed the image again. Have the same resizing issue.

Should I recreate my master image now that I have switched to 1.5? Also I am not sure if it matters but i do not run sysprep prior to capturing an image. It is something i have never done.

[Sebastian Roth]

@m-fitzgerald Please post the contents of the following files from your image directory: d1.partitions, d1.minimum.partitions, d1.fixed_size_partitions and d1.original.fstypes.

[m.fitzgerald]

@sebastian-roth

d1.partitions

label: dos
label-id: 0xae2e5b63
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 1024000, type=7, bootable
/dev/sda2 : start= 1026048, size= 973697024, type=7
/dev/sda3 : start= 974723072, size= 2048000, type=27

d1.original.fstypes

/dev/sda1 ntfs
/dev/sda2 ntfs

d1.minimum.partitions

label: dos
label-id: 0xae2e5b63
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 119716, type=7, bootable
/dev/sda2 : start= 1026048, size= 86818208, type=7
/dev/sda3 : start= 974723072, size= 2048000, type=27

d1.fixed_size_partitions

:3

[Quazz]

@m-fitzgerald What language is Windows installed in?

[m.fitzgerald]

@quazz English (American, not proper English )

[Quazz]

@m-fitzgerald Did you try capturing again after upgrading to 1.5? If not, please do so. (and if it still doesn’t resize after deployment, please post the contents of the partition files again)

There’s definitely some problems with your current image (such as your boot partition not being marked as unresizable)

[m.fitzgerald]

@quazz Ok, I will do so now and report back

[m.fitzgerald]

I have captured a new image and now I think I may have a different issue or the same issue with a different result.

Now when i deploy the newly captured image onto a PC that would not resize I get the below picture. I have tried this new image on 3 PC’s and all three come back the same. I also get the same result on any of the old images. I am not sure if this is a resize issue or not.

For reference, we use FOG to deploy images already setup as we need. Meaning that we take a brand new unactivated PC and load our needed software onto the PC. Once done I select the host in FOG and request a capture. This is the same method we have done for the past 8 months or so and we used it routinely to “freshen” up PC’s. Only until i switched to a new server and reinstalled FOG with a fresh download did the re-size issue pop up.

[m.fitzgerald]

I solved the above boot issue by doing the below from command prompt on the target PC.

Bootrec /rebuildbcd

Now the PC boots. Also the hard drive is the proper size. What I do not know is why the BCD showed unknow for Device as well as OSdevice. Once I ran /rebuildbcd the Device and OSdevice both now show the proper partition=c:

So it seems we have solved the Hard Drive issue and now have a new issue. Thoughts?

Below picture BCDedit is Before

[george1421]

Just collecting some background information, what version of Win10 is this regarding? 1709?

Also have you tried to identify which of the 3 bootrec commands actually repaired the issue?

And for clarity, this is a uefi system, with a gpt disk, without bitlocker?

[m.fitzgerald]

@george1421
Yes it is 1709
Bootrec /rebuildBCD did the trick.
It is a UEFI with GPT and no bitlocker

[Sebastian Roth]

@sebastian-roth said in FOG will not resize a hard drive after deployment.:
@m-fitzgerald I was not fast enough to look at the d1-files you posted to give you a hint on that. To me it seems like something prevents FOG from seeing your boot partition (which I expect to be sda1) as such. But to be sure I need to see those files again now that you upgraded FOG and recaptured the image. So please post the contents of the files from your image directory again: d1.partitions, d1.minimum.partitions, d1.fixed_size_partitions and d1.original.fstypes.

[m.fitzgerald]

@sebastian-roth

D1.Fixed
:3

d1.min
label: dos
label-id: 0xae2e5b63
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 119716, type=7, bootable
/dev/sda2 : start= 1026048, size= 85513176, type=7
/dev/sda3 : start= 974723072, size= 2048000, type=27

d1.orig
/dev/sda1 ntfs
/dev/sda2 ntfs

d1.part
label: dos
label-id: 0xae2e5b63
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 1024000, type=7, bootable
/dev/sda2 : start= 1026048, size= 973697024, type=7
/dev/sda3 : start= 974723072, size= 2048000, type=27

[Sebastian Roth]

@m-fitzgerald Can you please edit d1.fixed_size_partitions and make it 1:3. Then re-deploy that image to a fresh machine and see what you get.

As well can you take a picture of the disk management view in Windows on the source machine and post here?

[m.fitzgerald]

@sebastian-roth That solved the boot issue! Thanks. Now all is working as normal. Hard drives are re-sizing properly now. We have tested it on 4 machines.

Case Solved.