How to recover if MBR-to-GPT conversion fails?
I have 3 computers with MBR drives booted with UEFI using CSM. (Hopefully I've used correct terminology there.) I am planning to convert the drives to GPT and boot with full UEFI support but want to make sure I can recover if (when) I mess up the procedure. I've never dug very deeply into either BIOS vs UEFU functions or MBR vs GTP drive formats so I'm way out of my comfort zone here.
I've done numerous recoveries using the MVP Custom Build recovery media for two of the computers so have no problem with the actual recovery process itself, and I will take backups right before the conversion process. Then I will run MBR2GPT.
Now the questions:
- If something goes wrong and the conversion fails, do I simply boot the recovery medium in CSM mode and run a recovery? Or do I need to reformat the drive to get it back to MBR?
- If the conversion succeeds, do I need to take another backup or can the backup of the MBR drive be used to recover to a GPT drive if I use the recovery medium's UEFI boot? (I vaguely remember there is something different about the recovery partition. Placement? Size?)
- Once I have converted, do I need to create a new backup task or otherwise force the creation of a full backup rather than create another incremental backup?
- Once I have a backup of the GTP drive, can I use that backup if I need to go back to MBR or do I have to use a backup of the old MBR drive?
Thank you. Very helpful information.
Simply put, booting recovery media in UEFI mode and recovering a backup image file will, if necessary, convert that image to a UEFI/GPT bootable disk.
Booting recovery media in Legacy/CSM mode and recovering an image will if necessary, convert that image to a Legacy/CSM bootable disk.
That was what I was hoping (and probably had read without understanding). I knew I had to boot Legacy/CSM or UEFI depending on the desired result, but I could not tell whether the conversion was automatic or if I had to take some other action outside of the recovery environment. I'm very relieved to see that the conversion will automatically happen.
Actually, it sounds like I could to do my desired MBR-to-GPT conversion just by booting the recovery medium in UEFI mode and doing a recovery ... but I still think I will run MBR2GPT.
Patrick O'Keefe wrote:Actually, it sounds like I could to do my desired MBR-to-GPT conversion just by booting the recovery medium in UEFI mode and doing a recovery ... but I still think I will run MBR2GPT.
Yes you could, but running MBR2GPT is the safest option. I did this with two systems about 6 months ago (a third system refused to convert for reasons I could not be bothered sorting out). To keep things simple I would create new backup tasks for the converted disks - that is what I did; new cloud backup, new backup to NAS and new backup to USB drive/local HDD.
Ian
Yes, the MBR2GPT tool works well but is only found on Windows 10 versions 1703 and later.
Tip: If you want to check your disk for compatibility from an admin command prompt type “mbr2gpt /validate /disk:0” without the quotes.
Do not run the tool if Bitlocker is in use on the disk. It will fail if you do.
If you meet failure with the tool the information below may help:
MBR2GPT failed with return codes
According to Microsoft documents, MBR2GPT has following return codes and each code has its corresponding description. From below chart, we can easily find out what results in conversion fail and what to do to fix the error.
Thanks for the info. I'm on Win 10 1803 and don't use Bitlocker so I should be OK but that's get information for others contemplating doing this conversion.
Edit:
Some typos - such as a half a sentence missing - have been fixed (I hope) in the following description.
I succeeded on my test PC but not without a peculiar problem.
First, the validation failed:
MBR2GPT: Attempting to validate disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
Disk layout validation failed for disk 0
Not much information there, but Disk manager shows I have 2 Recovery partitions - 4 partitions in all. MBR2GPT doc say the conversion requires there be 3 or fewer partitions. I deleted the unused Recovery partition and the validation worked so I proceeded with the conversion which took just a few seconds.
I then cloned my old backup task, gave it a new name and ran it. It failed claiming no room for the backup on the target drive (that had 2.3TB unused space before the conversion). Looking at my F drive I saw everything I expected plus something named "Reserved", and looking under This PC (in Windows) I did not see an F: drive at all.
Disk manager showed the problem. Something in the conversion process had mapped the System Reserved partition to F: and had given GT: to my external drive. And somehow the desktop shortcut for the F: drive was combining the old and new contents in a single display.
I unmapped the System Reserved partition, remapped my external drive back to F:, rebooted (just in case), and am now happily backing up my new GPT drive.
So a warning to all doing this conversion: check your drive mapping after the conversion.
Patrick,
Wow, glad you found the problem. Tough to say what occurred there. Maybe some metadata problem in updating.
I believe it would be wise to recommend that all storage drives on a system be detached during the conversion process which should avoid the issue.
I just checked and can confirm this issue you experienced has happened to others. The recommendation to avoid it is, detach all other storage drives on the system prior to conversion. :)
Thanks for posting.
Stumbling block #2:
MBR2GPT failed on one of my "production" computers because it could not shrink the OS partition. Disk Management confirms this - shrink space of 0. I assume this means I have something allocated right at the end of the partition. Do I have to do a clean reinstall of Windows to fix this, or can I resize and then do a recovery?
I should probably be asking this question on a Windows forum, but I'm hoping ATI can somehow get me around this problem.
Patrick, try using a partition manager such as MiniTool Partition Wizard which is better at that type of task than Windows Disk Management is at shrinking partitions!
I'll give it a try. When I shrink the partition should I make room for bother the EFI partition and a recovery partition?
I would focus on mainly resizing the OS partition rather on others that may be created later by the conversion tool.
Steve Smith wrote:I would focus on mainly resizing the OS partition rather on others that may be created later by the conversion tool.
Hmm. I'm not sure what to do, then. The only reason I'm resizing the OS partition is because the conversion tool could not. I think it needs 100MB for the EFI partition.
Do I assume that's all it needs, or should I leave more open space on the disk? I don't know what Recovery partitions are actually for but I've done several ATI recoveries of this system so I know ATI does not make use of the partition so I assume I can continue getting along without one.
Stumbling block #2:
MBR2GPT failed on one of my "production" computers because it could not shrink the OS partition. Disk Management confirms this - shrink space of 0.
Patrick, my suggestion here was purely related to the issue you mentioned above that the conversion tool could not shrink your OS partition. I have never used the MBR2GPT tool so have no experience of how it works.
The Recovery partitions are created by Windows when major Updates are installed, such as the late October 2018 one. There can also be a manufacturer Factory recovery partition on some systems to allow returning the system to its initial shipped state. I would expect the MBR2GPT tool to recognise what any partitions are and deal with them as needed.
How much frees space is there in the OS partition? It could be as simple as defragging the OS partition to cause it to be shrinkable.
I've got 107GB out of 237GB free but it's an SSD. I shouldn't need to defrag should I?
Here are some steps you can take that might fix the issue:
The reason why Windows won’t let you shrink the volume is as the message shown in Disk Management suggested, because there are immovable system files at the very end of the volume, as this screenshot from utility shows us. there are multiple things you could try to work this around.
Run the Disk Cleanup Wizard, making sure to remove the hibernation file and all restore points.
- Run the Disk Cleanup Wizard, making sure to remove the hibernation file and all restore points.
- Disable System Restore
- Disable the pagefile ( Open up System in Control Panel, then Advanced System Settings \ Advanced \ Performance \ Advanced \ Change \ No Paging File.
- Disable kernel memory dump. In the same Advanced Settings, go to Startup and Recovery \ Settings and then change the Write debugging information drop-down to “None” to disable the kernel memory dump.
- Disable Hibernation mode in your power options \ advanced power options screen.
Reboot the machine, and then delete your c:\pagefile.sys file
Somehow it finally worked. The only thing I did in Windows was disable hibernation (which I thought I had done eons ago) and rebooted. The did nothing right away and neither did my two attempts at running Partition Wizard. But later on Disk Manager showed shrink space so I tried MBR2GPT again and it worked.
I would love to attribute the success to my carefully laid out plan (but there wasn't one) or to your suggestions (which I hadn't followed). I have no idea what did work but I won't argue with success.
Disabling the hibernation file had the same effect as running Disk Cleanup, the first suggestion I made, because that action deleted the hibernation file which freed up disk space at the end of the OS partition.
Glad you had success.