Deploying to Hyper-V UEFI VMs w/v1.5.0 RC-6 Working Branch
-
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
-
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.
-
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 -
@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
andd1.fixed_size_partitions
of this particular image here in the forum. Maybe we see something that is wrong with those. -
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.
-
-
Can we remote please?
-
Tom - I tested this on several Gen2 VMs and they all extended to the fill disk size.
Thanks - SOLVED.
Jim
-
@Jim-Graczyk @Tom-Elliott Can you please let us know how you were able to fix this?
-
@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.
-
Thanks, good to know! @Jim-Graczyk Would you mind posting the content of
d1.partitions
andd1.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. -
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