Problem laying image on a virtual machine

[george1421]

This is an interesting one. I don’t know Hyper-V virtualization, but is there a disk controller type that is not set correctly?

One thing to test is to schedule another deploy to this target computer, but before you hit the schedule task button, tick the debug checkbox. Now pxe boot the target computer. After a few screens of text that you need to clear with the enter key you will be dropped to a linux command prompt. Key in lsblk and post the results.

Now that you are in debug mode you can start the imaging process by keying in fog and pressing enter at the fos linux command prompt. You will need to hit the enter key at each break point in the program, but it will continue imaging in debug mode. Proceed until you see the error and then press Ctrl-C to exit out of the imaging program. At this point you should see a similar error on the screen. Again key in lsblk and post he results. What the error is saying is the disk is disappearing after erasing the gpt table.

[davemccracken]

@george1421

Okay, this is what I have running debug

[davemccracken]

@george1421

And the output after running the FOG command

[george1421]

@davemccracken The unknown request type null is strange here. You should only see that if you boot FOS Linux from a usb stick AND you don’t have an active task schedued in the FOG webui. Looking at the kernel parameters they are not complete either.

The lsblk command IS showing a 40GB sata attached disk which is expected.

Do you have deployment issues when you use a physical computer. This way we can rule out a fog issue and then just focus on the hyper-v side. My bet is that a physical computer will image just fine.

[davemccracken]

@george1421 I will have to get a physical machine set up to and join it to the domain on the virtual machines then. I have tried to keep it away from physical machines and direct access to the corporate network until tested out, so I will have to work on that.

[george1421]

@davemccracken OK so the physical is out of the picture at the moment. As I said before I don’t know about hyper-v, so this may be inaccurate (or just wrong term). But is this target machine a type 1 or type 2 hyper-v client. If I remember correctly the type 1 hyper-v is more like a bios based system.

Also what host OS are you running hyper-v on?

[Sebastian Roth]

@davemccracken How exactly did you schedule the debug task? This shouldn’t happen on PXE boot. In the “Unknown request type” picture we see that the kernel command line is missing parameter type=down that we see in the picture of your initial post. Please try this again. Go to schedule a deploy task as you normally would but just before you hit the button to create the task there is a checkbox to enable debug mode for this deployment.

Then boot up the Hyper-V machine you want to deploy to and when you get to the shell start the deployment with fog command. It should show pretty much the same output as posted in the first picture (if you haven’t changed anything) and when it errors out you just type in: sgdisk -gl /images/Win10-Gold/d1.mbr /dev/sda

My guess is we’ll see that the disk of the target machine is just a little too small…

[Quazz]

@george1421 The unknown request type null also occurs when you try to start the imaging task without having booted in “imaging mode” (aka you can’t start fog capture/deploy from debug, only from Capture, Deploy or Debug Capture/Debug Deploy)

[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