Deploying to Hyper-V UEFI VMs w/v1.5.0 RC-6 Working Branch

[Jim Graczyk]

Has anyone attempted to deploy an image to a Gen2 VM in Hyper-v with the latest v1.5.0 RC?

I’m finding that my images are not expanding to include the whole disk drive.

This occurs only on VMs - at least based on the limited testing I did (1 HW PC).

I’m not sure when this stopped working, but I believe imaging for these VMs worked in previous v1.5.0 RCs. It certainly worked in v1.4.4.

As a test, I used FOG to deploy the image to a Gen2 VM and had it shutdown after imaging. I was able to mount the VHDX file and extend the volume using the Virtualization Host OS - so the volume is expandable. After dismounting the VHDX file, the VM booted and continued normally with FOG tasks (like joining the domain).

We also created an ExtendVolume Snapin that appears to work.

Snapin runs diskpart /s extend.txt

extend.txt has the following in it:
select disk 0
select volume 0
extend

I’m curious to know if we’re the only ones having this problem.

thanks,

Jim

[george1421]

You may need to do a debug deploy and single step through deployment process to see if you can capture the error why the partitions won’t expand.

You may also want to download the latest inits (manually) and install them in your fog server. The devs patch the inits last week to solve a specific issue with disk expansion.

wget https://fogproject.org/kernels/bzImage
wget https://fogproject.org/kernels/bzImage32

[Tom Elliott]

You’ll want the registered host kernel argument, for the time being, to be:

isdebug=yes ismajordebug=1

the isdebug=yes will make it so the host will always boot everything into debug, so you don’t have to keep checking the ‘Schedule task as debug’

The ismajordebug will print out more disk based information as the system processes.

To start the process of imaging at the command prompt (if that’s what you want to reference it as) run fog.

I’m pretty sure i know what’s wrong, but I don’t know of a good fix. Having the information as performed will be much more helpful. I’m sure I can get it, but understand trying to get these “little” things worked out is really causing more problems than it’s worth to continue tweaking. I fix one thing, but another thing breaks. It’s really way too finicky to keep adjusting for one, then the other.

Understand this isn’t a dig at you or anybody, just understand my brain is fried from trying to get ALL things working perfectly at his point.

[Jim Graczyk]

@tom-elliott

Tom,

I ran an image deployment with the kernel switches you list. At the start, it said it was logging. Can you tell me where the log is and how to get it to you? If I need to record another way, let me know.

There were no errors. All actions appeared to work as I stepped thru the deployment process. Specifically, resizing after the 4th partition was downloaded said Done, but the partitions wasn’t actually extended.

Also, should I take George1421’s recommendation that I wget bzImage and bzImage32 from fogproject.org or do I have the latest versions as part of the current working branch?

If this is something you don’t want to address right now, I have a work around with a Snapin that appears to work fine so I’m not dead in the water on EFI testing.

Thanks,
Jim

[Sebastian Roth]

@Jim-Graczyk Just take pictures of the screen using your smartphone or camera. Make absolutely sure you see Done for every stage.

Testing the most current kernels as could help as George said.

Please post the contents of d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions of this particular image here in the forum. Maybe we see something that is wrong with those.

[Tom Elliott]

If you’re running 1.5.0-RC-6, then the latest init’s and kernels are already in your FOG setup. So, no, it won’t hurt to do the wget commands as @george1421 or @Sebastian-Roth have suggested, but I don’t think there will be any difference.

[Jim Graczyk]

@tom-elliott

Here are the screenshots for each step of the fog iPXE process:

[Tom Elliott]

Can we remote please?

[Jim Graczyk]

@tom-elliott

Tom - I tested this on several Gen2 VMs and they all extended to the fill disk size.

Thanks - SOLVED.

Jim

[Sebastian Roth]

@Jim-Graczyk @Tom-Elliott Can you please let us know how you were able to fix this?

[Tom Elliott]

@sebastian-roth Yes.

GPT partition layouts with SFDISK tend to have the firstlba and lastlba sectors defined for the drive. The resizable element weren’t taking the firstlba into account for the variable sizes.

Making the firstlba (if present) part of the fixed size caused the problem to be fixed.

[Sebastian Roth]

Thanks, good to know! @Jim-Graczyk Would you mind posting the content of d1.partitions and d1.fixed_size_partitions (as text) here in the forum? I am trying to create a test framework for the partition resizing and this is definitely a good one we want to have in our test cases.

[Jim Graczyk]

Sebastian,

Here’s d1.partitions:

label: gpt
label-id: 6561AEE9-3184-4274-B8E2-359A32B76FD5
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 104857566

/dev/sda1 : start=        2048, size=      921600, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=3E77A64A-2E46-40EC-93D0-03CFD0BDDDC9, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/sda2 : start=      923648, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=2CF8BFD9-3B61-4FAD-A4DC-6FC2A1E6E134, name="EFI system partition", attrs="GUID:63"
/dev/sda3 : start=     1126400, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=1222537C-11F5-4B9F-9FB2-68AE743C5D79, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda4 : start=     1159168, size=   103696384, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=0C2EDC77-DB4B-45A1-BF2B-2BE3B844CF47, name="Basic data partition"

Here’s d1.fixed_size_partitions:

:2:3:1

Jim