@plover was having trouble restoring a Win7 image from a previous system onto a new one, and the underlying cause turned out to be that the image was captured from a Legacy BIOS system and the new one was set up for UEFI booting. And in another recent thread, someone else was trying to restore a GPT disk from a UEFI system onto a new one that for some reason was configured for Legacy BIOS booting. I know this problem will eventually disappear organically as Legacy BIOS systems and Windows 7 are phased out, but in the meantime this seems to be catching users out, and I had some ideas for how Reflect might be able to provide some additional guidance.
I know there isn't an industry standard way to query a system's BIOS configuration, but I know it's possible for WinPE to identify whether it was booted under Legacy BIOS or UEFI mode. I'm therefore wondering if it would be possible for the Rescue environment to check this, and then if a user opts to restore a GPT disk when Rescue detected it had been booted in Legacy BIOS mode, or vice versa, Reflect could display a warning basically saying, "Hey, if you intend to BOOT from this disk you're restoring, you might
need to change your BIOS settings to make that happen, or better yet change them before proceeding with this so that the Fix Boot Problems function will work." The message could even suggest the specific BIOS changes, e.g. enabling UEFI mode when restoring a GPT disk in a Legacy BIOS environment, or switching to Legacy or at least keeping UEFI but enabling CSM/Legacy Option ROMs when restoring an MBR disk in a UEFI environment.
Better yet for the MBR disk to UEFI PC scenario might be some automation whereby Reflect performs manual target disk partitioning and post-restore steps outlined in this KB article
, thereby adapting the source disk/image to boot appropriately for the target system's current configuration rather than requiring the user to make BIOS configuration changes at all, although I know this would require more effort. Alternatively, once support for WinPE 10 1703 is implemented, if the MBR2GPT utility is included in PE, perhaps Reflect could call that as a post-restore task, although that would only work for this migration direction and for Rescue Media built with that PE version. For the GPT disk to BIOS PC scenario, the same automated target disk preparation from this KB article
could be implemented, but in that case I would recommend first displaying a warning that says, "If this system CAN be configured to boot in UEFI mode, that's usually preferable, but if not, you can choose either to have Reflect convert the source image to a format that will work in Legacy BIOS mode." And for both directions, the user should of course have the choice to skip the conversion and instead perform a normal restore, accepting the risk that it may result in an unbootable disk.
Lastly, if the Fix Boot Problems function doesn't already do this, perhaps it could be updated to check the disk partition layout type against the current boot environment mode, and if it finds this type of discrepancy, it could identify that as a likely cause for the disk of interest being unable to boot, with a message making the appropriate BIOS configuration change recommendations. It could further explain that even if the BIOS change alone doesn't resolve the boot issue, the change will need to be made anyway and the Rescue Media booted in the alternate fashion so that the Fix Boot Problems function will work properly against the unbootable disk of interest.