Trying to create a UEFI bootable rescue partition on an existing GPT hard drive (not flash drive).

I have tried a variety of things, both the drive doesn't boot.  Essentially the steps I've used are:

1. Create a standard FAT32 partition.
2. Copy my Macrium Rescue ISO contents to the FAT32 partition.
3. Run "bcdboot C:\Windows /s R: /f UEFI"   (R: is the new intended Rescue partition)
4. Change the partition ID to c12a7328-f81f-11d2-ba4b-00a0c93ec93b to make it an EFI partition.
5. Boot.

In the last step, the UEFI boot for the drive shows up in the BIOS menu, but the boot is not successful.

Not sure what else to try.  I should mention the drive is a 4TB drive, and the FAT32 part is at the physical end of the disk.  Wondering if I might do better to reposition it to the beginning of the drive.  Also hoping others might have some suggestions.

Certainly over my head but I did locate a post that talks about your issue.  See the 3rd post, 2nd paragraph.  Not sure this is helpful but thought I'd put it out there.

https://forum.macrium.com/40562/Rescue-Media-Unsupported-disk-and-gpt-format-not-supported

+x

 

capair45 - 13 October 2022 6:44 PM

Certainly over my head but I did locate a post that talks about your issue.  See the 3rd post, 2nd paragraph.  Not sure this is helpful but thought I'd put it out there.

https://forum.macrium.com/40562/Rescue-Media-Unsupported-disk-and-gpt-format-not-supported

Thanks.  I think I have followed those ideas closely but no success.  Still looking for other thoughts.

You'll get some answers soon.  Some of the experts will jump in, I'm sure.

If this is going to be a disk that's permanently installed, you would typically just enable the boot menu recovery option by using the "Windows Boot Menu" option in Rescue Media Builder.  But if you're trying to create it on a disk that will not always be attached, then you should not be performing Steps 3 and 4.  Your Step 3 command is telling Windows to put a copy of Windows Boot Manager onto that partition and create a BCD entry in that instance that will boot into your regular Windows environment, which is definitely not what you want for Rescue Media.  And Step 4 is unnecessary. First, Diskpart has a command that will create a properly configured EFI partition anyway ("create partition efi"), but a Rescue Media partition is not an EFI partition, nor should it be designated as such.  The purpose of an EFI partition is to be set up using a firmware-supported file system (e.g. FAT32) and store the bootloader files that the system firmware will read and that will then allow a full OS to be booted from a different partition that will typically use a file system that is NOT firmware-supported, such as ext4 (Linux) or NTFS, which is optional to support under the UEFI spec and thus not widely supported.  That's not what you're trying to do here.

All you need to do is create a FAT32 partition and copy the Rescue Media files to its root, but then you would boot from it when desired by invoking your system-level one-time boot menu.  Technically you could register the \EFI\Boot\Bootx64.efi bootloader file on that partition as a regular boot path into your system's UEFI firmware, but the much more common use case is to use one-time boot menus just as you would for a Rescue Media flash drive that you'd attached.

Note however that if your GPT hard disk is attached via USB, I've encountered some systems will not boot from USB "fixed disk class" devices like hard drives and SSDs, and will instead only boot from USB "removable storage class" devices like flash drives.  If you have such a system and that isn't resolvable with a firmware update, then you're out of luck.  If you have a properly populated FAT32 partition and have that disk connected at boot and you still don't see a new option in your one-time boot menu at that point, then that may be your issue.

I've also encountered some systems that will only boot from Partition 1 of storage devices initialized as GPT, even though they will happily boot from later partitions if that same device is re-initialized as MBR.

+x

 

jphughan - 14 October 2022 12:46 AM

If this is going to be a disk that's permanently installed, you would typically just enable the boot menu recovery option by using the "Windows Boot Menu" option in Rescue Media Builder.  But if you're trying to create it on a disk that will not always be attached, then you should not be performing Steps 3 and 4.  Your Step 3 command is telling Windows to put a copy of Windows Boot Manager onto that partition and create a BCD entry in that instance that will boot into your regular Windows environment, which is definitely not what you want for Rescue Media.  And Step 4 is unnecessary. First, Diskpart has a command that will create a properly configured EFI partition anyway ("create partition efi"), but a Rescue Media partition is not an EFI partition, nor should it be designated as such.  The purpose of an EFI partition is to be set up using a firmware-supported file system (e.g. FAT32) and store the bootloader files that the system firmware will read and that will then allow a full OS to be booted from a different partition that will typically use a file system that is NOT firmware-supported, such as ext4 (Linux) or NTFS, which is optional to support under the UEFI spec and thus not widely supported.  That's not what you're trying to do here.

All you need to do is create a FAT32 partition and copy the Rescue Media files to its root, but then you would boot from it when desired by invoking your system-level one-time boot menu.  Technically you could register the \EFI\Boot\Bootx64.efi bootloader file on that partition as a regular boot path into your system's UEFI firmware, but the much more common use case is to use one-time boot menus just as you would for a Rescue Media flash drive that you'd attached.

Note however that if your GPT hard disk is attached via USB, I've encountered some systems will not boot from USB "fixed disk class" devices like hard drives and SSDs, and will instead only boot from USB "removable storage class" devices like flash drives.  If you have such a system and that isn't resolvable with a firmware update, then you're out of luck.  If you have a properly populated FAT32 partition and have that disk connected at boot and you still don't see a new option in your one-time boot menu at that point, then that may be your issue.

I've also encountered some systems that will only boot from Partition 1 of storage devices initialized as GPT, even though they will happily boot from later partitions if that same device is re-initialized as MBR.

Thank you.  I did get a USB hard drive to work with UEFI (not the one I wanted).  Your simple advice to just create a FAT32 partition and nothing more did the trick.

I have a pretty old machine and the BIOS that my testing shows has many issues with UEFI boot (won't UEFI boot from ESATA, seems not to want to boot from a my 4TB drive even when USB connected).  So my original goal of being able to boot from my large backup drive seems unachievable.  But I learned how to get it working (when possible) thanks to you. 

Happy to help, and glad to hear you made some headway, even if you may be blocked from your ideal goal by some system limitations.

+x

 

jphughan - 14 October 2022 11:00 PM

Happy to help, and glad to hear you made some headway, even if you may be blocked from your ideal goal by some system limitations.

Just an update.  I DID get my BIOS to boot a Macrium rescue partition from my backup drive in UEFI mode.  It was more involved than I'd like.  I mentioned the problems in an earlier post.

The solution also came from you:  add an entry to the UEFI boot menu.  This required a tool to do that: I used DiskGenius.  Unfortunately DiskGenius had to be hosted in a UEFI version of Windows (mine was not) to make the changes, so I had to create a new W10 installation just for that purpose.

Certainly be interested to know about a good bootable UEFI manager (ideally free), but I wanted to post this update in case it might help others.

+x

 

Larry - 16 October 2022 3:07 PM

+x

 

jphughan - 14 October 2022 11:00 PM

Happy to help, and glad to hear you made some headway, even if you may be blocked from your ideal goal by some system limitations.

Just an update.  I DID get my BIOS to boot a Macrium rescue partition from my backup drive in UEFI mode.  It was more involved than I'd like.  I mentioned the problems in an earlier post.

The solution also came from you:  add an entry to the UEFI boot menu.  This required a tool to do that: I used DiskGenius.  Unfortunately DiskGenius had to be hosted in a UEFI version of Windows (mine was not) to make the changes, so I had to create a new W10 installation just for that purpose.

Certainly be interested to know about a good bootable UEFI manager (ideally free), but I wanted to post this update in case it might help others.

I add boot entries using the following batch file from an admin command prompt (not powershell)
I just copy the files from the Rescue iso to a fat32 partition (2GB is plenty of size)
First is for UEFI pcs, and second for MBR pcs.
(note - always make an image backup before using these just in case something goes wrong - never has but always good to err on side of caution).


UEFI PCs




MBR PCs

Using the Code block feature would have been ideal for that batch file post.