Image upload & deploy taking a long time

[george1421]

@brad-schumann just for clarity this is what I expected to see.

Disk /dev/sda: 999.7 GB, 999653638144 bytes, 1952448512 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0004a2f3

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     4098047     2048000   83  Linux
/dev/sda2         4098048  1952448511   974175232   8e  Linux LVM

It just may be the difference in the versions of fdisk program. The Id column tells what the partition ID is marked as. It was not a wasted effort since we have been able to collect more info on your exact hardware.

I am bit intrigued that the Type in your screen shot says “Microsoft basic disk”

[george1421]

@george1421 Interesting when I boot FOS from my USB drive and run the fdisk program I get the ID column as I expected

In my case I have 3 partitions from this Win10 image running in bios/legacy mode.
The boot partition is type 7
So is the drive type 7
The recovery partition is type 27.

[Sebastian Roth]

@george1421 Probably a difference because @Brad-Schumann has a GPT layout and the one you posted is a legacy DOS layout. Still we see the partition type but in text instead of ID. The output posted looks ok to me. See here as well: https://en.wikipedia.org/wiki/Microsoft_basic_data_partition

Be careful to not mix up partition type ID and filesystem type. You can label a partition in fdisk to be Linux for example and still format it as NTFS (fs type). Linux will still be happy with that.

But I still have no idea why udev wouldn’t identify this to be an NTFS formated partition. @Brad-Schumann Are you able to mount the partition?

mkdir -p /mnt/win
mount.ntfs-3g /dev/sda3 /mnt/win
ls -al /mnt/win
umount /mnt/win

[Brad Schumann]

@george1421 we are not using legacy mode in the bios we are using the UEFI boot mode.

[Brad Schumann]

@sebastian-roth

[Sebastian Roth]

@Brad-Schumann From what it looks like there is no proper NTFS filesystem on sda3. How is it even possible that Windows boots from that? Can you please boot Windows up and post a picture of the disk management dialog. Maybe this can shed a light on this mystery!?!

[Brad Schumann]

@sebastian-roth this all you were looking for? or did you need more detail on a particular drive?

[george1421]

@brad-schumann Dind, ding, ding we have our answer.

Bitlocker encrypted drive == raw data file to fog.

Bitlocker needs to be activated after the target system has been created not before its captured.

[Brad Schumann]

@george1421 But we don’t activate/use Bitlocker…

[THEMCV]

@brad-schumann Try this, I ran into this on Surface’s.

Open command prompt as admin.

manage-bde -off

manage-bde -status

Fingers crossed that it will fix it. In my case, Windows was by default encrypting the free space which caused issues.

[Sebastian Roth]

OMG!!! Thank god we figured this out. I thought I was lost in this.

[x23piracy]

@themcv said in Image upload & deploy taking a long time:

@brad-schumann Try this, I ran into this on Surface’s.

Open command prompt as admin.

manage-bde -off

manage-bde -status

Fingers crossed that it will fix it. In my case, Windows was by default encrypting the free space which caused issues.

@Wayne-Workman #wiki worthy!

[THEMCV]

@Sebastian-Roth Glad I could help. Yeah, I hate that Windows gives you the option to “Turn On Bitlocker”, but don’t tell you that the free space is encrypted. I am not sure if this is a something with the latest update/service pack for Windows 10, but I know that I’ve only seen it on Surface’s so far. I haven’t made an image for the latest Windows 10 so we’ll see.

@x23piracy You’re too kind.

[Brad Schumann]

@themcv @Sebastian-Roth That is looking to be the fix… The on server size now shows ~48GB and only took 15min to upload to the server. I am deploying the image to another laptop and the ETA is 12min. Thank you for your help. FYI, we build our images from scratch with Win10 download from Microsoft with a SA agreement so it must be a built in thing .

[Wayne Workman]

@THEMCV @Sebastian-Roth @george1421 I need to clairify because I’ve not been following this thread and don’t really understand fully the problem or solution.

I understand the hardware is: Dell latitude 5580 laptop & Surface Pro

FOG was taking an image as RAW for some reason? Why?
@THEMCV What does the answer you posted do to fix it?
Might other hardware models have this problem?
What’s the best way to word the problem?

[THEMCV]

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

[THEMCV]

@wayne-workman manage-bde -status shows if BitLocker is encrypting the free space and -off starts the decryption process

[Sebastian Roth]

Though this is fixed I wanted to look into this a bit more to understand why this has happened and if we can do something about it to detect this. I am not sure if I can confirm the “free space encrypted” information. Reading this it sounds as if BitLocker was in a state of already encrypted (full disk) but not “activated” (whatever that means):

Waiting for Activation - BitLocker is enabled with a clear protector key and requires further action to be fully protected.

Though I am still not sure if and how we would be able to detect this. Oh wow, reading about this I just found out that you can actually mount bitlocker partitions from linux. Shall we add this to FOG?!? Well, we would need to ask people if they want to clone fast but have an unencrypted clone (mount bitlocked drive and do a file-aware cloning) or slow and have it encrypted on the destination. I don’t think we will be able to generate a fast and also encrypted target. So I reckon it’s not worth adding this feature at all.

[x23piracy]

@themcv afaik this is only enabled in the preinstall of the os the surface is shipped with (recovery).
I never saw that problem with my own images.

Regards X23

[Taspharel]

Same here, working with a clean Windows 10 1703 Professional Version, no such problems.