UEFI Shell bcfg: Add & Remove Boot Entries (Fix OpenCore Boot Recovery)

Older motherboards and some UEFI firmware can't create boot entries automatically even when a bootloader exists on the EFI System Partition. When OpenCore won't boot without the USB stick, or its entry disappears from the BIOS boot list, you can add the NVRAM boot entry directly with the bcfg command from a standalone UEFI Shell.

Revised and updated as of 2026.
The core commands from the original post still hold, but I've added map -r to re-scan the filesystems, path verification, reordering boot entries, and pre-flight precautions. I also fixed the path separator that looked like a won sign on screen to the actual UEFI backslash (\).

When to use this method

• The bootloader is on the EFI partition but doesn't appear in the BIOS boot list
• Removing the OpenCore USB stops the internal disk from booting
• You want to clean up duplicate Clover/OpenCore boot entries or change their order
• The motherboard setup screen has no option to select an EFI file directly

Caution: bcfg directly modifies Boot#### and BootOrder in the firmware NVRAM. Deleting the Windows Boot Manager or the entry you currently boot from by mistake may require a recovery USB. It's safer to first photograph the output of bcfg boot dump -v.

OpenShell.efi vs. a standalone UEFI Shell

The OpenShell.efi you run from OpenCore's Tools is also a UEFI Shell, but it runs after OpenCore's drivers and NVRAM-related settings have already been applied. If your goal is to repair the firmware's actual boot entries, prefer the motherboard's built-in Shell, or a standalone UEFI Shell booted directly from EFI\BOOT\BOOTX64.EFI on a FAT32 USB.

Especially in setups that use OpenCore options like RequestBootVarRouting, the boot variables visible inside OpenCore may behave differently from the values the firmware manages directly. Rather than the old post's phrasing of "communicating with a virtual BIOS," it's more accurate to understand that working in a Shell before OpenCore intervenes makes the results easier to verify.

What you'll need

USB	Format as FAT32 and place the UEFI Shell executable at EFI\BOOT\BOOTX64.EFI
Bootloader path	A typical OpenCore default bootstrap is EFI\BOOT\BOOTx64.efi
Firmware settings	Boot the USB in UEFI mode. If the Shell file isn't signed, you may need to temporarily disable Secure Boot
Recovery prep	Photograph the existing boot list and keep a known-good bootable USB on hand

If your motherboard has a built-in UEFI Shell, you can use that feature without a separate USB. If bcfg isn't recognized in the Shell, that Shell build simply doesn't include the command, so you'll need to prepare a UEFI Shell that supports bcfg.

Adding an OpenCore boot entry with bcfg

1. Refresh the filesystem mapping

   When the Shell starts, first re-scan the currently connected disks and partitions.

   map -r
   map

   Entries shown as FS0:, FS1: are filesystems the Shell can access. If you've reinserted the USB or changed the disk layout, always run map -r first.

2. Find the EFI System Partition

   Switch to each filesystem and check whether it has an EFI folder.

   FS0:
   ls
   
   FS1:
   ls

   On a partition where OpenCore is installed, you'll usually see both EFI\BOOT and EFI\OC folders. Here we'll assume FS1: is the internal disk's EFI partition as an example.

3. Verify the bootloader file actually exists

   ls FS1:\EFI\BOOT\BOOTx64.efi
   ls FS1:\EFI\OC\OpenCore.efi

   Don't register a guessed path — always confirm the file with ls. In OpenCore's official structure, BOOTx64.efi acts as the initial bootstrap and loads OpenCore.efi from the same EFI partition.

4. Check the current boot list

   bcfg boot dump -v

   Adding -v makes it easy to see the device paths too. Before inserting a new entry at position 0, also check whether the same OpenCore entry already exists.

5. Add the OpenCore entry

   bcfg boot add 0 FS1:\EFI\BOOT\BOOTx64.efi "OpenCore"

   0 means putting it at the very front of the BootOrder. If you want another OS to take priority, check the current list and use the appropriate position number. If you need a direct-launch configuration you can register FS1:\EFI\OC\OpenCore.efi, but for a typical install structure, using the default bootstrap path offers better compatibility.

6. Confirm the result and exit

   bcfg boot dump -v
   exit

   After rebooting, check whether OpenCore appears in the BIOS boot list.

Deleting duplicates and changing the order

Remove an unneeded boot entry

bcfg boot dump -v
bcfg boot rm 3

After rm, use the position number you confirmed in the list printed first. Don't just see a variable named Boot0003 and blindly type rm 3 — go by the order that the current bcfg boot dump shows.

Change the boot order

bcfg boot mv 3 0

This moves the entry at position 3 to position 0, i.e. to the front. You can adjust the order with mv without deleting and recreating it.

When it disappears again after registering

• The firmware may fail to save NVRAM boot variables, or it may remove an invalid entry on every boot.
• A CMOS reset, a BIOS update, or another OS's bootloader recovery can change the BootOrder.
• In that case, keeping the removable-media default path EFI\BOOT\BOOTx64.efi helps the firmware find the file even without a separate NVRAM entry.
• For OpenCore, it's good to also check the official docs' LauncherOption and the install structure.

Quick command summary

map -r
FS1:
ls FS1:\EFI\BOOT\BOOTx64.efi
bcfg boot dump -v
bcfg boot add 0 FS1:\EFI\BOOT\BOOTx64.efi "OpenCore"
bcfg boot dump -v
exit

Two things matter most.
First, don't treat a number like FS1: as a fixed value — verify the actual EFI partition every time. Second, always keep a verbose list before any deletion. Following just these two greatly reduces the risk of touching the wrong disk or the Windows Boot Manager.

Official references

• UEFI Forum Specifications — UEFI Shell Specification 2.2
• UEFI Shell Specification 2.2 PDF — reference for map and bcfg commands
• OpenCore Reference Manual — directory structure and bootstrap reference
• OpenCorePkg official releases