FOG will not resize a hard drive after deployment.
-
If I remember correctly there is a bug under certain circumstances in 1.4.4 that keeps the drive from expanding properly. Those issues should be addressed in FOG 1.5.0 (stable) when its released. You can get a preview of the fix if you install the dev branch release 1.5.0RC10. This release should be the one that will be promoted to 1.5.0 stable.
-
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?
-
@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).
-
@george1421 What the hell, I am a gambling man. Point me in the right direction!
-
@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.
-
-
@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.
-
@m-fitzgerald Please post the contents of the following files from your image directory:
d1.partitions
,d1.minimum.partitions
,d1.fixed_size_partitions
andd1.original.fstypes
. -
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=27d1.original.fstypes
/dev/sda1 ntfs
/dev/sda2 ntfsd1.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=27d1.fixed_size_partitions
:3
-
@m-fitzgerald What language is Windows installed in?
-
@quazz English (American, not proper English )
-
@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)
-
@quazz Ok, I will do so now and report back
-
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.
-
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
-
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?
-
@george1421
Yes it is 1709
Bootrec /rebuildBCD did the trick.
It is a UEFI with GPT and no bitlocker -
@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
andd1.original.fstypes
. -
D1.Fixed
:3d1.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=27d1.orig
/dev/sda1 ntfs
/dev/sda2 ntfsd1.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 -
@m-fitzgerald Can you please edit
d1.fixed_size_partitions
and make it1: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?