dual EFI entries after GPT conversion

Anonymous

For reasons too lengthy to detail here, I was unable to use MBR2GPT for converting my current boot disk. Instead, I used Hasleo Disk Clone to clone the disk to another SSD while also converting it to GPT. This worked fine and the new drive correctly shows up as GPT with the shiny new MSR and EFI partitions. However, it left the protected/system EFI directory intact on the drive. My UEFI has been set to UEFI only with CSM=Disabled and yet I can still see entries for both EFI instances. Booting to the GPT partition works fine, but booting to the EFI directory fails. Is it possible (and safe) to either archive/rename or delete the EFI directory on C:\ so that it is no longer detected by the UEFI and disappears from the boot menu? I'm loathe to take any of the additional steps towards a Win11 upgrade without sorting this out first.

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

Answer accepted by question author

Anonymous

(1) Even looking at the log, I'm unsure what's up with /SetREImage. But I think it is unnecessary. We'll revisit it if necessary.

(2) It looks like /Disable followed by /Enable would get the job done all by themselves. /Disable moved WinRE.wim from partition 3 into the staging area, namely C:\Windows\system32\Recovery....

2023-03-06 17:24:41, Info [ReAgentc.exe] winreCopyWIMBack moved WIM file from \?\GLOBALROOT\device\harddisk3\partition3\Recovery\WindowsRE\ to C:\Windows\system32\Recovery\Winre.wim successfully!

Then /Enable wanted to move it into partition 4, which it did recognize to be the Recovery partition. But it found that partition to be too small...

2023-03-06 17:24:49, Info [ReAgentc.exe] Checking partition at offset 497942528000, partition number: 4

2023-03-06 17:24:49, Info [ReAgentc.exe] MeetPartitionRequirements Partition details: {Offset: 497942528000, Free space: 467849216, Total space: 487256064}

2023-03-06 17:24:49, Info [ReAgentc.exe] MeetPartitionRequirements WinRE WIM size: 423565200

2023-03-06 17:24:49, Info [ReAgentc.exe] MeetPartitionRequirements Required free space: 478091152

2023-03-06 17:24:49, Warning [ReAgentc.exe] MeetPartitionRequirements Not enough free space req = 478091152 avail = 467849216 offset = 497942528000

2023-03-06 17:24:49, Info [ReAgentc.exe] skip partition because it does not meet WinRE requirements

(3) So, let's make it bigger. Mine is 848 MB. Your Disk Management (DM) shows the Recovery partition of 465 MB is followed by 1.56 GB of unallocated space...

Unfortunately, DM won't let you make it larger because it is a system partition. Can you easily add 383 MB to it using AOMEI Partition Assistant? If not, we can try this...

DiskPart <<<Enter DiskPart

Select Disk 3 <<<Focus on the EVO 970

List Part <<<Show its partitions

Select Part 4 <<<Focus on its Recovery partition

Detail Part <<<Show it has the Recovery type code

SET ID=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 Override <<<Basic Data Partition

Detail Part <<<Show the new type code

Exit <<<Leave DiskPart

The 2nd Detail Part should show the new type. It is now a Basic Data Partition. Reboot to be sure the whole system knows. Then open Disk Management, right-click what was the Recovery partition, & see whether you can extend volume to 848 MB. Then make it a Recovery partition again this way...

DiskPart <<<Enter DiskPart

Select Disk 3 <<<Focus on the EVO 970

List Part <<<Show its partitions

Select Part 4 <<<Focus on what was its Recovery partition

Detail Part <<<Show it has the Basic type code

SET ID=de94bba4-06d1-4d40-a16a-bfd50179d6ac Override <<<Recovery Partition

Detail Part <<<Show the new type code

Exit <<<Leave DiskPart

I would Reboot again. Then, try...

ReagentC /Disable

ReagentC /Enable

ReagentC /Info

I hope that will do it. Good luck.

0 comments

Answer accepted by question author

Anonymous

(1) This should move {bootmgr} back to the top of DisplayOrder...

BCDEdit /Set {FWBootMGR} DisplayOrder {BootMGR} /Addfirst

That is where it belongs. I don't know how it got to the bottom. Do a full reboot for it to register in BIOS. Then, show us a new BCDEdit /Enum All.

That's nasty that BIOS adds one back after you have deleted it.

(2) The order of the GUIDs in DisplayOrder does not have to be the same as they are in the body of the BCD. In the body, they are in the order the boot entry was created. Moving one to the top of DisplayOrder should also move it to the top in BIOS Setup (after a full reboot). It then becomes the one that will boot by default. That is, it's the one that boots unless you chose another by using the one-time BIOS Boot Options menu. I think in your Asrock that is invoked with F11. (And DEL or F2 goes to BIOS Setup).

(3) I'm confused about your BIOS. I don't have one that complex.

(a) I don't know why it's got 4 Boot Options.

(b) Are you sure it is Boot Option #1 that is executing? Maybe disable ...#2 to be sure.

(d) What is that item that is disabled within ...#1?

Our goal is to have you boot to the EVO that has Windows on it. So, that is the drive that needs to be at the top of the Boot Order in your Boot Option #1. Is it...?...

The way to know that it is the correct Windows partition that is booted is that your C: partition will be 463 GB...

0 comments

Answer accepted by question author

Ramesh 181.8K Volunteer Moderator

Rebuilding the BCD should be enough, not the entire boot files, even though rebuilding the entire boot files doesn't do any harm.

And wondering why you're trying to create a Recovery drive with system files? Is it for backup/restore purposes or only for accessing WinRE? If it's for accessing WinRE, you can uncheck "Backup system files..." and create the media.

Regarding your question about C:\EFI folder, you can simply rename it. If Windows reboots correctly, that folder can be deleted. Do this only after creating the USB setup disk or Recovery drive.

0 comments

56 additional answers

Anonymous

2023-02-23T21:50:55+00:00

Folks, this was quite the team effort. I feel I owe everyone a recap/explanation. The original problem stemmed from a failed effort to execute MBR2GPT on my 970 boot disk. Something was wrong (likely with WinRE) and in spite of days of fiddling around with the BCD tools, ReagentC, etc. I could never get MBR2GPT to work. It's been a couple of months, but I'm pretty sure at some point I got the system partially hosed up and ran some variation of "bcdboot c:\windows" - which is how I ended up with a bootable \EFI directory on the C:\ partition.

When I ran the Hasleo Disk Clone utility, it faithfully cloned that to the empty 850 (and did the MBR conversion to GPT). Booting from the 850 was stable so after a few days, I took a deep breath and cloned BACK overwriting the 970 making it a GPT drive also. However, now I had 4 viable boot environments: an EFI partition and a primary partition with an EFI directory on each drive. Not surprisingly, the BCD had gotten a bit scrambled in the process. To put a cherry on top, I went into the BIOS and set it to UEFI only with CSM disabled. Now I had 4 boot entries, but 2 of them didn't work and the working vs non-working copies on each drive were indistinguishable within the BIOS. To top it off, the ordering of the entries in BCD and in the BIOS did not agree and efforts to delete the non-bootable entries failed as they were detected and added back after each boot!

By the time I read this, I'd already done as Ramesh suggested and moved the EFI folder into another directory and renamed it. That didn't impact the booting, so I did it on both drives. That reduced my entries to just 2 - an EFI partition on the 970 and the one on the 850. I then used the commands above to force {bootmgr} to the top of the list and be the default entry. After an initial reboot that seems to work as advertised - though it takes ~15sec instead of the 3sec that I've have set between POST and the start of Windows booting. I'm still baffled by this long wait time. Perhaps once I scrub the 850 it will just boot straight through.

Meanwhile, I was pretty sure that my Windows Recovery partition had not survived the double cloning. ReagentC confirmed this as did my effort to create a new Recovery Device. I dug around and extracted the recovery files (Winre.wim, ReAgent.xml and boot.sdi) from my media and placed them in \windows\system32\recovery. Now I could run "ReagentC /enable" and after rebooting I could build a new USB recovery drive (that I've since validated). I'm kind of bummed to gone this route instead of using the actual Recovery partition on the 970, but that's the way the dominoes fell.

Thank you all for your patience and contributions in helping me mostly resolve this. Other than the long POST delay noted above, I only have one remaining issue. I can't access the BIOS without pulling my GPU! I'm pretty sure that this issue started not after installing the GPU (I ran for a year on a Radeon 3400G with integrated graphics), but after swapping from a fixed refresh (60hz) monitor to a variable refresh (60-165hz). I've seen a few threads online about this, but no one seems to know why (though there are a few comments about BIOS makers moving from VGA to GOP drivers). I'll likely continue running on the 3400G for a few more days until I'm convinced that everything is completely stable, then plug the GPU back in and forget about the BIOS until I need to do a repair/recovery or Win11 upgrade (which was why I tried MBR2GPT in the first place!-) I'm a little spooked and will probably wait several months before attempting anything else!-)
Was this answer helpful?

0 comments No comments
Anonymous

2023-02-23T01:15:54+00:00

I read the article Ramesh linked more closely and feel that I'm not quite in such bad shape that I need to wipe out and rebuild the EFI partition (since I appear to be booting from it). However, I am intrigued by the "bcdboot E:\Windows /s Y: /f UEFI" command for rebuilding the BCD - even though it looks like it's simply overwriting the EFI partition BCD with information stored in Windows. That being the case, it's unlikely to help my issue of dual EFI data on both the original and current boot drives (post MBR->GPT).

My new thumbdrive just arrived, but when I attempted to create a recovery drive within Win10, it complained as follows. I suspect that this means that the Recovery partition on the boot drive is no longer valid after the cloning operation and that I need to rebuild it. I think I have notes somewhere on how to do that from my install media and will tackle it tomorrow. Once I am confident that I can recover the boot drive, I'll be more willing to start hacking around on the BCD or EFI files. For that same reason, I haven't wiped the original SSD since if I kill the NVME I'll still need some way to boot my only computer!-)
Was this answer helpful?

0 comments No comments