Inserting Extended partitions - failed
-
-
@Tom-Elliott I am capturing again with RC-6 I will let you know how it goes.
-
@Tom-Elliott Inserting extended partitions is still failing on rc-6
-
This leads me to think it’s not a problem with FOG at this point then.
-
@Tom-Elliott It deploys fine to a similar sized hard drive as the one it was captured from. It is the smaller ones that are an issue. The image is not sysprepped if that helps.
-
@coop90 I’m going to test a theory.
-
I’m going to have the “Inserting Extended partitions” use the minimum partitions file instead of the original partitions file. With any luck, using this mechanism will help.
-
@coop90 FOG is agnostic towards the data. Your selections in the GUI help to define if the image is Linux, Mac, Windows, etc. FOG just does a clone of everything present on the drive, and all partitions if you have set the settings appropriately.
FOG Doesn’t care if the image is sysprepped or not, the OS might, but FOG does not. Sometime in the past there was limited understanding toward sysprep and a special tool was made to assist in making images deploy completely from the FOG server. But again this was to satisfy the OS, not FOG. The data was written to the drive, but the OS was not happy with registry values, and etc that were necessary for the OS to boot.
So I don’t think the fact that the image is not sysprepped is the problem, it could be, but it may not. You can attempt to sysprep one, upload it as a new image and try to deploy and report back. However, I am not certain this is where the issue lies.
What perplexes me is that the image deploys fine to a hard drive that is larger in size. But will not deploy to one smaller. This also bothers me. But THIS is exactly the reason I build my images on literally the smallest hard drive I can find.
I realize this doesn’t exactly answer your question, but It helps me get some thoughts out so I can get on the right track of finding a resolution for your issue. It also arms you with information that you may or may not have known.
-
Please re-run the installer. (You can pull too but it won’t help anything directly.) You should not need to re-capture the original image after this point.
I don’t know if it will make the image bootable though.
-
@Tom-Elliott I reran the installer without pulling and deployed the image again. It said “Inserting extended partitions (minimum) … failed)”
-
@coop90 then I can only guess this image is really captured improperly and possibly from an originally, but corrected for, gpt layout. The corrected for changed this abnormality to a proper MBR layout, though the MBR file you’re currently using is 1 MB in size. This normally happens for Linux style images.
I’m just throwing theories out though. As to what the exact problem is? I haven’t the slightest at this point sorry.
-
@Tom-Elliott Thanks for taking the time to help. In the next two weeks I will try to rebuild the image on a smaller hard drive.
-
@coop90 Sorry I can’t give you a fool-proof “here’s how to fix it”. I still imagine it’s slighly lying with the MBR file itself.
-
As a full informative piece, you’re not setting the ‘1’ in the d1.fixed_size_partitions file are you?
-
@Tom-Elliott I checked disk management on the image and it is set to mbr.
In d1.fixed_size_partitions there is only :3
This is what is in d1.minimum.partitions
-
@coop90 So the d1.minimum.partitions, and I suppose d1.partitions files both have ‘e’ as the the /dev/sda3?
That would lead me to think that the 3rd partition is REALLY odd.
-
@Tom-Elliott Yes. it is ‘e’ in d.partitions also. Let me try deleting that partition and recapturing as a new image.
-
I think that’s going to give you the best bet btw.
-
@Tom-Elliott As usual, you are a genius. It boots fine now! Thank you!
-
@coop90 Glad you got it sorted, sorry it took so long to get to the bottom of it!
