Group: Forum Members
If the original disk was GPT, then after the restore operation before you do anything else, the destination disk should have been GPT, even if the destination was MBR prior to you restoring onto it. Neither ReDeploy nor Fix Boot Problems would have converted back to MBR, so if after the restore operation your destination disk's partition layout scheme and/or partition layout didn't match the source you restored from, then the focus should have been on fixing that right away rather than accepting that disparity and then trying to find a way to manually convert it back to what you had in the first place. But fyi whenever you run Fix Boot Problems, it's important to boot the Rescue Media itself the same way that you would boot the OS you're trying to fix. Since you've got a GPT disk (or should), your OS is booting in UEFI mode, which means that you should make sure to boot your Rescue Media in UEFI mode, not Legacy BIOS mode. You can check how your Rescue Media was booted by looking at the Reflect application title bar along the very top of the Rescue interface. If it says "[UEFI]" at the end, it was booted in UEFI mode. If it doesn't, it was booted in Legacy mode. The way Rescue was booted will determine the types of fixes that the Fix Boot Problems routine attempts, and you don't want to attempt Legacy BIOS fixes on a disk that's meant to be booted in UEFI mode, or vice versa
If you've already gone through a clean install, I'm not sure you'd want to keep troubleshooting this, but if you do, it would probably help to post screenshots of what happens in Rescue Media. With Reflect 7.2 Rescue Media you can do that by pressing PrintScreen in the Rescue environment, which will pop up a dialog box asking where to save the screenshot file. If you have a flash drive or external hard drive, that's usually easiest. The very latest release of 7.2 adds a button to capture a screenshot into the taskbar for convenience, but the keyboard shortcut still works.
EDIT: Just saw your note that your source disk was a dynamic disk. That indeed might have been a complication. I've never worked with dynamic disks, but I believe that even in that case, you could have used something like diskpart within the Rescue Media Command Prompt environment to manually set up your target disk as GPT with the desired partition layout and then restored each partition from the source disk into the "shell" partitions you manually created on the destination.