Image upload & deploy taking a long time
-
@sebastian-roth this originally create on the newer 1.4.4.
-
@Brad-Schumann Sorry to ask again but this is from the source master system, right?
And this is Windows 10/7/Vista?
-
@sebastian-roth No worries, this is from the the source 5580 that we created (at least that is what my PC team tells me
)
… and it is Win 10 64bit. I can re-create the image with a fresh version of windows on the master again and re-upload it to my Fog server, a -
@Brad-Schumann No, don’t recreate it yet. Possibly we’ll figure it out. Seems like we need to dig into the
udevstuff to see why it doesn’t recognize the filesystem at all. Please post a picture of the output when running this command:udevadm info --query=all --name=sda3 -
-
@brad-schumann I would like to give you a hint and a request as long as you have the FOS engine running there.
First the hint.
At the FOS command prompt (as in the picture) do the following- Key in
ip addr showand note the IP address of the FOS target computer. - Give root a temporary password by keying in
passwdthen give it a simple password likehelloThis password will be lost when FOS reboots, so don’t worry. - Now from a windows computer connect to the FOS engine at the address gleaned at step 1 using putty (3rd party windows ssh application)
- Login with
rootand the password you defined in step 2.
You can use putty to copy and paste stuff into the FOS engine from windows. It makes it easier to key stuff in and post to the forums because you can cut the text directly off the putty window and paste here.
Now for my request (if Sebastian already asked for this you can ignore). Key in the following at the command prompt
fdisk /dev/sda- At the fdisk prompt key in
p - Copy the contents and paste it here.
- At the fdisk prompt key in
qand you will be back at the FOS command prompt.
What I’m interested in is the
Idvalue in the 6th column. - Key in
-
@george1421 I didn’t see a 6th column below (assuming you meant row) is what I got.
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 8897879E-4ECF-42A1-A6DC-F682422F50B6 Device Start End Sectors Size Type /dev/sda1 2048 1026047 1024000 500M EFI System /dev/sda2 1026048 1288191 262144 128M Microsoft reserved /dev/sda3 1288192 975800319 974512128 464.7G Microsoft basic data /dev/sda4 975800320 976637447 837128 408.8M Windows recovery environment
-
@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 LVMIt 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 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. -
@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 -
@george1421 we are not using legacy mode in the bios we are using the UEFI boot mode.
-
-
@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!?!
-
@sebastian-roth this all you were looking for? or did you need more detail on a particular drive?
-
@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.
-
@george1421 But we don’t activate/use Bitlocker…
-
@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.
-
OMG!!! Thank god we figured this out. I thought I was lost in this.
-
@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!
-
@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.
