Image Deployment: Can FOG create partitions with GPT layout instead of MBR?

[george1421]

@browlry In general I can say that FOG should only recreate the disk partitions as they were on the source disk. So your situation is a bit unique.

Will you provide the output of this command cat d1.partitions this must be executed on the FOG host server in the image directory. On my FOG server, I can’t “visually” tell the difference between a gpt and mbr image (other than the content of the d1.partitions and the number of partitions). So the FOS engine must detect the image format via some other methods.

I can tell you from my experience both MBR and GPT images deploy correctly and we NEVER have to mess with the disks to get them to boot. My intuition kind of tells me there may be something a bit abnormal with your master image that is confusing the FOS engine when it either captures the image or as its deploying. We’ll have to get the fog developers to take a look at the output of the d1.partitions file to see if anything jumps out at them.

[browlry]

Thank you for the response.

Here are the contents of /images/Win10v1909/d1.partitions:

label: gpt
label-id: FF49A6C2-3C34-40F5-8F80-D56539F0A596
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 500118158

/dev/sda1 : start=        2048, size=      614400, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=0AB00D6D-C20F-4585-A4A8-0E38EB2D9A49, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/sda2 : start=      616448, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=549668CE-D282-4FFD-9681-949F2CE71769, name="EFI system partition", attrs="GUID:63"
/dev/sda3 : start=      821248, size=      262144, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=9DA83316-BE94-44B9-8FBF-785A19055ED1, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda4 : start=     1083392, size=   468314112, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=F517EAB8-B856-4F95-9B98-77C985D2A4C1, name="Basic data partition"
/dev/sda5 : start=   469397504, size=    30720000, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=402020BF-E7B1-47AD-8B19-CBCF229B0331, name="Basic data partition", attrs="RequiredPartition GUID:63"

For what it’s worth, I’m using Fog version 1.5.8.

Here are the settings I used for the image:

Setting	Value
Image Name	Win10v1909
Operating System	Windows 10 - (9)
Image Path	/images/Win10v1909
Image Type	Single Disk - Resizable (1)
Partition	Everything - (1)
Protected	False
Image Enabled	True
Replicate?	True
Compression	6
Image Manager	Partclone Zstd

Here are the settings I used for the target computers (“Hosts”):

Setting	Value
Host Product Key	[blank]
Host Image	Win10v1909 - (1)
Host Kernel	[blank]
Host Kernel Arguments	[blank]
Host Init	[blank]
Host Primary Disk	[blank]
Host Bios Exit Type	- Please Select an option -
Host EFI Exit Type	- Please Select an option -

[george1421]

@browlry That first partition is suspect. Normally that first partition on the disk is the efi boot partition. Are you using some kind of third party disk encryption system (not bitlocker)? It could also be an OEM repair partition too, but its surely suspect.

Its possible since its not an efi partition the fog code is getting confused. The rest of the disk structure looks OK.

[browlry]

Prior to using FOG, we imaged computers individually from a USB drive. We booted to Win PE and ran diskpart /s CreatePartitions-UEFI.txt and ApplyImage-UEFI.bat Win10v1909.wim (source).

We used that process when setting up the source computer.

Here are the contents of CreatePartitions-UEFI.txt:

rem == CreatePartitions-UEFI.txt ==
rem == These commands are used with DiskPart to
rem    set up the drive and ecreate five partitions
rem    for a UEFI/GPT-based PC.
rem    Adjust the partition sizes to fill the drive
rem    as necessary. ==
select disk 0
clean
convert gpt
rem == 1. Windows RE tools partition ===============
create partition primary size=300
format quick fs=ntfs label="Windows RE tools"
assign letter="T"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
rem == 2. System partition =========================
create partition efi size=100
rem ** NOTE: For Advanced Format 4Kn drives,
rem          change this value to size = 260 **
format quick fs=fat32 label="System"
assign letter="S"
rem == 3. Microsoft Reserved (MSR) partition =======
create partition msr size=128
rem == 4. Windows partition ========================
rem ==    a. Create the Windows partition ==========
create partition primary 
rem ==    b. Create space for the recovery image ===
shrink minimum=15000
rem ==    c. Prepare the Windows partition ========= 
format quick fs=ntfs label="Windows"
assign letter="C"
rem === 5. Recovery image partition ================
create partition primary
format quick fs=ntfs label="Recovery image"
assign letter="R"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
list volume
exit

[browlry]

I’ll try running diskpart /s HideRecoveryPartitions-UEFI.txt (link) on the source machine and see if that prevents FOG from getting confused.

[george1421]

@browlry Ah so your recovery partition is the first partition and is marked as primary.

While this is a philosophical question, but is a recovery partition even necessary (today) if you have an imaging solution in place? It talks less time to image with FOG than it does to even begin the recovery process. Its very rare that a recovery partition is the very first partition on the disk, even M$ recommends the uefi boot partition to be disk 1 partition 1 position. I’m not saying its wrong only abnormal.

[Sebastian Roth]

@browlry Looking at the information provided I also find it surprising that you seem to be left with an MBR partition layout on the destinations machines! FOG uses the information in d1.partitions, d1.minimum.partitions (only when image is of type resizable) and d1.mbr file to re-create and adjust the partition layout. The contents of d1.partitions you posted clearly show a GPT style partition layout and I suspect d1.minimum.partitions to be the same! I reckon the d1.mbr file to still have some old style MBR information in it that is confusing FOS.

Possibly it’s those commands from your scripts that create the “mess” but I am not sure.

select disk 0
clean
convert gpt

Why do you actually need to convert to GPT at all I wonder? Make sure the disk is being properly cleaned (I don’t know if MS diskpart is doing a good job) and create a fresh new GPT partition layout from scratch. George is right about the first partition being “abnormal”. I would not think this is causing the issue as described but that’s just me guessing.

If you don’t want to mess with your master image we can still take a look at the d1.mbr file (it’s binary, upload to a file share and post a link here) and see if we can help you fixing it.

[browlry]

@george1421 said:

While this is a philosophical question, but is a recovery partition even necessary (today) if you have an imaging solution in place?

Unfortunately, yes. We ship the computers to people working remotely, and sometimes we need the recovery partition to resolve issues in the field without them having to ship the computer back to us.

I noticed that Microsoft’s scripts that we’re using have been updated since I last looked at them 5+ years ago, so I’ll try creating an image with the new scripts and see if that makes a difference.

@Sebastian-Roth, here’s a download link for d1.mbr.

Thanks so much for your help!

[Sebastian Roth]

@browlry I have not seen such a “crippled” partition layout before. No offense here, just saying that I am confused by this. Deploying the d1.mbr to an empty test VM disk and looking at it with gdisk I get a lot of warnings and so on:

Even if I let it correct things and re-write the partition table I still get the warnings when re-opening. This must be something very special from the MS world…

[browlry]

I set up a new virtual machine using Microsoft’s new scripts.

Then I captured an image from the virtual machine with FOG and multicast it to four computers, and they all UEFI booted fine.

The new CreatePartitions-UEFI.txt puts the system partition first, instead of the recovery tools partition. This supports @george1421’s theory that FOG was confused when it found the recovery tools in the first partition, instead of the EFI (“System”) partition.

Thank you for your help!

rem == CreatePartitions-UEFI.txt ==
rem == These commands are used with DiskPart to
rem    create four partitions
rem    for a UEFI/GPT-based PC.
rem    Adjust the partition sizes to fill the drive
rem    as necessary. ==
select disk 0
clean
convert gpt
rem == 1. System partition =========================
create partition efi size=100
rem    ** NOTE: For Advanced Format 4Kn drives,
rem               change this value to size = 260 ** 
format quick fs=fat32 label="System"
assign letter="S"
rem == 2. Microsoft Reserved (MSR) partition =======
create partition msr size=16
rem == 3. Windows partition ========================
rem ==    a. Create the Windows partition ==========
create partition primary 
rem ==    b. Create space for the recovery tools ===
rem       ** Update this size to match the size of
rem          the recovery tools (winre.wim)
rem          plus some free space.
shrink minimum=500
rem ==    c. Prepare the Windows partition ========= 
format quick fs=ntfs label="Windows"
assign letter="W"
rem === 4. Recovery partition ======================
create partition primary
format quick fs=ntfs label="Recovery"
assign letter="R"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
list volume
exit