FOG will not resize a hard drive after deployment.



  • Fog Server 1.4.4

    Looking for assistance with a new issue we had pop up.

    We have been using FOG without issues until maybe 2 months ago. Now when we deploy a new image perhaps 60% of the time the Hard Drive does not resize. It keeps the imaged hard drive the same size as the image being pushed out and leaves any remaining space as unallocated. On the ones that do not resize properly we run a powershell script to resize the hard drive after install. This puts everything back to normal.

    The only change we made from when it worked fine to now is a change to a new server and a fresh download of FOG from the website.

    Any thoughts?


  • Developer

    @m-fitzgerald Good to hear this fixed the issue for you. Though from my point of view it’s only partly solved. If you capture the image again you will need to edit that file again. So question remains why it does not recognize your boot partition as such. Usually this happens if Windows is not installed as English version or partition labels have been modified by hand. As I said, take a screen shot of the disk management view in Windows and post here. I am fairly sure we can figure out why that is.

    Follow on question though. How do I edit the order of Storage Nodes?

    We try to keep topics separate. Please open a new thread for this! Won’t answer here.



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


  • Developer

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



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


  • Developer

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



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


  • Moderator

    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?



  • 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
    0_1513971324136_20171222_140732 [800x600].jpg



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

    0_1513961067537_20171222_114056 [800x600].jpg



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


  • Moderator

    @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 English (American, not proper English ;) )


  • Moderator

    @m-fitzgerald What language is Windows installed in?



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


  • Developer

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



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




  • Moderator

    @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 What the hell, I am a gambling man. Point me in the right direction!


 

490
Online

41.8k
Users

12.3k
Topics

116.1k
Posts