Problem laying image on a virtual machine

[davemccracken]

@Quazz @george1421 @Sebastian-Roth

Okay, I now went to the tasks page and deleted all tasks, then to the “List all Hosts” page and started the deploy task checking the box next to debug. Whatever I had done before, when clicking deploy it didn’t give me those options, but this time it did, so I must have done something different.

These are the output screens with the lsblk command before and after the Fog run.

Thank you for your responses. They are really helping me.

Dave
Dave

[Sebastian Roth]

@davemccracken Good start but read my message again. After you hit the error now manually run: sgdisk -gl /images/Win10-Gold/d1.mbr /dev/sda

Take a picture and post here.

[george1421]

@davemccracken So in Sebastian’s thoughts, what is the size of the source disk where you captured the image from? I see the target disk is 40GB, what happens if you bump that to 60GB on the target computer?

[davemccracken]

@Sebastian-Roth

The final screen

[Sebastian Roth]

@davemccracken Your destination disk seems to be too small. Make it 60GB and try again.

[davemccracken]

@george1421 @Sebastian-Roth @Quazz

Thank you all. It was indeed a disk size issue, as the last screenshot showed. I recreated the hard drive the same size as the one on the VM used for the image source and it is now working.

I am learning the things to watch out for so the next test, I will not run into such basic issues again. Thank you.

Dave

[george1421]

@Sebastian-Roth I’m wondering if there is some way to trap this error prior to image deployment? I know we can capture the lsblk output with lsblk -d |awk '{print $1 " " $4}' (note this command was a quick hack to solve a problem in another thread) to return the target disk size. Is there some way to build the minimum space needed from the metadata collected during image capture?

[Sebastian Roth]

@george1421 said in Problem laying image on a virtual machine:

Is there some way to build the minimum space needed from the metadata collected during image capture?

I am sure there is. Something like tail -1 d1.partitions | awk '{print $4+$6}' (or d1.minimum.partitions if that exists) would get the minimum sector count of the destination disk needed. And for sector count of the disk in question I’d run blockdev --getsz $disk

[davemccracken]

@Sebastian-Roth @george1421

The image was deployed, but when I booted the virtual machine, there isn’t a valid boot file at SCSI 0,0 found. I should probably start a new thread?

[davemccracken]

@davemccracken @george1421 @Sebastian-Roth

This is the current screen I get when I try to boot the target VM

[george1421]

@davemccracken Understand we are still testing here, but if you run the recovery tools can you fix the problem with boot?

Its still not clear if its something wrong with your image or the way FOG has deployed to this target computer. If you can fix the issue with the recovery tools we will know that FOG has deployed the image intact.

Another question, did you sysprep this image before it was captured?

[davemccracken]

@george1421

Yes, I syspreped before capture.

I will try the recovery tools. One question which comes to mind though, although since the partition tables are recreated I doubt this is the case, but does that target drive have to have had a working operating system on it prior to the FOG deployment?

Thank you,
Dave

[george1421]

@davemccracken said in Problem laying image on a virtual machine:

does that target drive have to have had a working operating system on it prior to the FOG deployment?

No FOG doesn’t care what was there before to deploy it. The point being you can deploy to bare metal or a previous OS, FOG doesn’t care because it destroys the partition table and creates a new one. This error kind of tells me the boot partition is not in a sane state.

[davemccracken]

@george1421 Okay, but the gold image VM boots fine, and so, I am somewhat unsure what would cause a block by block copy of it to have a bad boot partition.

Interestingly, once I booted from a Win10 ISO file, it then says the registry is missing or has errors. This has me wondering if I should just try to deploy again, as maybe something got lost or corrupted between the image and the target.

What do you think? Can this be a possibility?

Dave

[Sebastian Roth]

@davemccracken said in Problem laying image on a virtual machine:

I am somewhat unsure what would cause a block by block copy of it to have a bad boot partition.

Using image type MPS (Multiple Partitions Single Disk) is not really a block by block copy. Although it is pretty save to properly deploy to another system fine! As you didn’t use the resizable image type (as we see in the picture you posted) partition problems are not very likely. My guess is this has something to do with how you sysprep.

[davemccracken]

@Sebastian-Roth

I agree with you that something must be wrong with the image. It has done the same thing on 3 virtual machines so far. I originally had done a multicast for the first 2 and a single machine deploy for the last.

I am going to go back to the VM with the gold image, and re-sysprep and capture it. Then try the deploy again. Do you have recommended sysprep parameters? I was using /oobe /shutdown

[george1421]

@davemccracken Here is my unattend.xml file and the sysprep command I use: https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem/7

Make sure you put the unattend.xml file in c:\windows\panther only.

[davemccracken]

@george1421 @Sebastian-Roth @Quazz

Thanks George, I tried to use your unattend file, but it kept bluescreening on the host once imaged, so I tried creating a new one today and it worked fine. I probably didn’t change enough things in it, and missed something important, but I got around it now.

I greatly appreciate all the help you kind folks have provided. It is very much appreciated. I couldn’t have gotten to this point without it,

Dave