Image Deployment: Can FOG create partitions with GPT layout instead of MBR?
I used FOG to capture an image from a computer with a GPT-layout disk (GPT is needed to support UEFI boot).
I applied the image to seven computers using multicast, but after the deployment was done, the computers’ disks were all set up in MBR layout, instead of GPT. Consequently, I was unable to UEFI-boot these computers. Once I turned on Legacy Boot in the BIOS settings, the computers booted to Windows fine.
I booted the target computers to WinPE and used Mbr2Gpt to convert the disks to GPT layout:
mbr2gpt /validate /disk:0 mbr2gpt /convert /disk:0
Once that was done, I was able to UEFI-boot the target computers to Windows.
I assumed the disk image would include the disk layout (GPT or MBR) of the original disk, but it appears that is not the case.
Is there a way to get FOG to partition the disks with GPT layout instead of MBR layout so I don’t have to manually convert to GPT after deploying the image?
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.
CreatePartitions-UEFI.txtputs 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
@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.mbrto an empty test VM disk and looking at it with
gdiskI 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…
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.
Thanks so much for your help!
@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.minimum.partitions(only when image is of type resizable) and
d1.mbrfile to re-create and adjust the partition layout. The contents of
d1.partitionsyou posted clearly show a GPT style partition layout and I suspect
d1.minimum.partitionsto be the same! I reckon the
d1.mbrfile 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.mbrfile (it’s binary, upload to a file share and post a link here) and see if we can help you fixing it.
@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.
I’ll try running
diskpart /s HideRecoveryPartitions-UEFI.txt(link) on the source machine and see if that prevents FOG from getting confused.
Prior to using FOG, we imaged computers individually from a USB drive. We booted to Win PE and ran
diskpart /s CreatePartitions-UEFI.txtand
We used that process when setting up the source computer.
Here are the contents of
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 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.
Thank you for the response.
Here are the contents of
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 -
@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.partitionsthis 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.