Capturing Windows 10 Error Virtual Machine Environment

[george1421]

@imagingmaster21 For debug mode, you need to terminate the current task that is running. Since imaging didn’t complete then the previous task didn’t close out.

When you schedule a new task. Just before you hit the submit button there are a few options you can choose for the job, like wake on lan or debug. If you click debug and then submit the job, when you pxe boot the client it won’t start image capture right away. This is what we want.

But now that I see you are using virtual box, let me look through the settings to see if something is obvious.

[george1421]

I’m not really seeing anything out of order on this one. You are just using a standard bios build, with the sata controller in ahci mode. It “should” just work.

[imagingmaster21]

@george1421
Here is the results of running the lsblk command.

[Tom Elliott]

@imagingmaster21 That is not lsblk at all. You see the message above that that says “Please press enter to continue”

You typed lsblk, yes, but enter just moved to the next section.
If you press enter one more time you will have the “command prompt” then you can type lsblk and get us the output.

[imagingmaster21]

@tom-elliott Try this?

[george1421]

@imagingmaster21 that’s better but says there are no partitions on sda. Run the lsblk command on your fog server to see what I mean.

[george1421]

So what FOS is telling you about the partition table is correct. As far as FOS and Linux is concerned that 32gb disk is blank

[imagingmaster21]

[george1421]

@imagingmaster21 OK so you see on the fog server there are partitions on /dev/sda like (/dev/sda1 and /dev/sda2 and so on) and on the FOS engine (target computer) there is only /dev/sda

[george1421]

@george1421 So what does that really mean. Are there partitions on that drive, is the disk empty, is FOS blind? Well at this point all we know is that FOS can’t see the partitions on that disk. Can you confirm by adding that drive as a second hard drive on another computer and use windows to confirm that the disk contains partitions.

[imagingmaster21]

@george1421
I think I got it working. Seems to be capturing now. I used another Win 10 machine I made.

[george1421]

@imagingmaster21 Hopefully one that has partitions on the disk and not under them

[imagingmaster21]

@george1421

Just tested it and everything seems fine. Now will there be a difference when I do this on actual machine that have UEFI BIOS?

[george1421]

@imagingmaster21 There shouldn’t be a problem with a real machine. I think there was something wrong with your first disk, or structure or something. I capture from an EFI vm to a physical machine and it works well.

[imagingmaster21]

@george1421

So when you make a Windows 10 Machine, lets say you install Office 2016 on it. When I did that and captured it, it captured fine. But when I deployed it to one machine when it starts up after imaging it says Windows Recovery Options. Is there something else you have to do before you capture an image with program installations. Also this image does have Edge removed.

[george1421]

@imagingmaster21

Did you sysprep the machine?
Did you have sysprep power off the machine?

If you are not using sysprep, then did you shutdown the machine using the following command shutdown -s -t 0 to ensure the system was powered off correctly? You must know that the start menu shutdown is not really a shutdown, but an enhanced sleep to support a rapid startup. This “fancy” shutdown condition will leave the system in an unstable state for imaging.

[Sebastian Roth]

As well it can depend on the partition layout. Some layouts are really terrible and make things break. Please paste the contents of d1.partitions from that image (should be in /images/Win10/ directory on your FOG server) here so we can have a look.

[imagingmaster21]

@george1421
I am going to try that command since I am not using sysprep. Do you think removing Edge would also cause an issue, or any of the other Windows 10 Apps?

[george1421]

@imagingmaster21 I “think” it related to the system not being shutdown correctly. But I’m a bit surprised that partclone didn’t complain about the disk being “dirty” and refusing to image it. There is also a possibility that we are chasing a bug that was in 1.4.4 in the single disk resizable code that was address in 1.5.0RC4 (I think). This is the development build of 1.5.0 that hasn’t been released yet. If shutting down the system properly doesn’t work, we may need to you try the dev build to see if your specific issue has been resolved in 1.5.0RC9 (the latest development build of 1.5.0).

[imagingmaster21]

@george1421
I tried doing that still with no luck, here is my settings for the image. It seems to be capturing fine.