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

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.

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

Thanks - SOLVED.

Jim

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

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,

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

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.

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