Fog Not Resizing Captured image
-
Hey, I am currently using Fog 1.3.3, I have no problems at all registering hosts with windows or linux, the only proplem I get from time to time is when I capture an image using “Single Partition-Resizable” if I capture from a Desktop with 450GB it captures all 450GB and takes hours, if I capture a Laptop with 450GB HD it resizes and captures between 20 and 40 GB depending on what is on the computer(Programs etc…). Here are the specs for each… Desktop is a Lenovo DT and Dell Laptop, same programs and software on both…Any ideas???
-
Just guessing but if you watch the capture that takes hours does it say Raw somewhere on the partclone screen? If so, is this a win10 instance, or I guess also win7 where bitlocker is enabled? If so partclone can’t read the partitions (because they are encrypted) so the only option it has is to read the entire disk, possibly taking hours.
ref: https://forums.fogproject.org/topic/10824/image-upload-deploy-taking-a-long-time/54
-
@george1421 Hey George, never noticed that but I will check, I don’t use bitlocker on any of my devices but it is possible that the user has activated it somehow. Thanks for the quick reply
-
@creative1204 I just posted a reference link that talks about the same as you are seeing. There was something mentioned about bitlocker encrypting free space. Also the link has the commands you can use to disable bitlocker for image capture. FWIW If bitlocker is on, that will keep your image from being portable (kind of the point of full disk encryption).
-
@creative1204 What OS is installed on the Desktop? George is probably spot on. Or it could be a Linux system with LVM, see here: https://forums.fogproject.org/topic/11387/first-time-capturing-centos-linux-image-drive-won-t-shrink
And by the way - FOG 1.3.3 is years old! There won’t be any fixes to that anymore.
-
@george1421 Hey George,
I checked the systems I was capturing images from and the bitlocker encryption is turned off, do you have any other ideas as to why the capture is copying all 450 GB and not resizing? any help is appreciated. -
@creative1204 So lets try to gather more information. For that schedule a debug task (capture or deploy does not matter) and when you get to the command shell run
blkid -po udev /dev/sdaX
- put in1
,2
,3
and so on forX
to get the information for all the partitions on your system! Take a picture of every single output (you can clear the screen withclear
in between) and post here. As well post a screen of the image settings in the web UI for us. -
@creative1204 If you look at this post: https://forums.fogproject.org/topic/10824/image-upload-deploy-taking-a-long-time/41 the poster also said that bitlocker was not enabled. In the post by @themcv he provides the commands to ensure that bitlocker is off.
Then if you look at this post: https://forums.fogproject.org/topic/10824/image-upload-deploy-taking-a-long-time/59
Its stated: “The problem is Microsoft is pushing for more BitLocker, so while it is technically off, it is encrypting the free space on the drive causing FOG to want to make it a raw image. I don’t know if this is just on pre installs or with the latest version of Windows, but I ran into this with the latest Surface Pro.”
I’m not saying this your exact issue, but it does align up with what was said and done in that thread.
-
@george1421 I will check this out thanks
-
@creative1204 Please also do what Sebastian suggested. We really need to understand what is happening because you are not the first (or probably the last) to see this issue.
-
@creative1204 I ran the code manage-bde -status && manage-bde -off
told me it was off and encrypted. -
@creative1204 said in Fog Not Resizing Captured image:
off and encrypted
Bitlocker was off but encrypted?
-
I’m going to assume that once a volume has been encrypted, it remains that way even if bitlocker gets turned off, but it simply lends anyone access to it. (and is therefore generally not an issue for users).
If you could please use the commands Sebastian posted so we can see what partitions we’re dealing with, we might be able to figure this out.