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

[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