Adding UEFI firmware boot entry using bcdedit

22.7k views Asked by At

How to add a new UEFI firmware boot menu entry(in NVRAM) using bcdedit. For e.g. I tried the following steps but boot entry is not getting added.

bcdedit /create /d "LinuxLoader" /application osloader 

this will return a new guid (say newguid)

bcdedit /set {newguid} device partition=S:
bcdedit /set {newguid} path \boot\efi\bootx64.efi
bcdedit /set {fwbootmgr} displayorder {newguid} /addfirst

Thanks in advance.

1

There are 1 answers

1
AntoineL On

You cannot use applications of type OSLOADER to boot Linux: this kind is for Windows loaders, such application are boot applications (not the same as EFI applications), they are signed by Microsoft exclusively and launched by Windows Boot Manager (see the first slides of this UEFI document for a good description of the process.)

On the other hand, what should be possible is to add another boot manager along with Windows', and register it within UEFI (in NVRAM storage); the steps are much the same as you wrote, just use

bcdedit /create /d "LinuxLoader" {bootmgr}

as first operation. The theory of operation of bcdedit (bcdsrv really) is that, that at the last step, the entry should be copied to the NVRAM as well; so your UEFI manager will now have at least two options to choose from, with Windows Boot Manager probably still being the default one. This means in practice that you may have to use some magic key to bring this menu (the UEFI boot manager) up. To change the default entry, you can try

bcdedit /set {fwbootmgr} default $newguid

which would update the BootCurrent variable in NVRAM, so the UEFI firmware should then select the Linux loader in preference to Windows; no guarantee though, I believe there are out there UEFI firmwares which are badly programmed on this issue; according to this question, it even seems to be standard behaviour of Windows 8 boot process to revert such a change :-(

Also, additionally I would make another entry, distinct from the standard place (ESP)\EFI\BootX64.efi, as a provision in the {fwbootmgr} list: such an entry would survive when some (ill-advised) tool would decide to restore the correct value and flatly erase the standard place with Microsoft's bootmgfw.efi...