In my answer I will be refering to (U)EFI—the (Unified) Extensible Firmware Interface—simply as EFI.
Also, for all the commands an elevated command prompt should be used, i.e. run cmd.exe
(not PowerShell!) with administrator rights!
I was just looking for the same thing. I had the (temporary) problem that Linux couldn't access/change EFI NVRAM, including the boot sequence. (Which I eventually resolved.) During this time I looked into the Windows way of doing this, and found that bcdedit
actually does have the same set of functions, including a) creating a new EFI boot menu entry and b) changing the EFI boot sequence.
If a Linux boot loader is already configured, the sequence can be changed with bcdedit /enum firmware
should list it. Imporant is only the GUID of the boot loader object listed with the Linux boot loader, i.e. a string looking like {01234567-89AB-CDEF-0123-456789ABCDEF}
, and replace {<GUID>}
in the following examples with your actual GUID.
Any firmware boot loader can be set as the default EFI boot option with bcdedit /set {fwbootmgr} default {<GUID>}
.
To set a EFI boot loader entry as the first boot item in the list, bcdedit /set {fwbootmgr} displayorder {<GUID>} /addfirst
can be used.
Problematic is when you don't have a EFI boot loader entry for the Linux boot loader (maybe it got deleted somehow, or it wasn't set during installation). Important is only that the Linux boot loader is already configured, because that is something that has to be done in Linux. The standard nowadays is GRUB (the GRand Unified Bootloader, version 2). On EFI systems it should be installed on the ESP (EFI System Partition) in \EFI\<Distribution>\<bootloader>.efi
or similar. E.g. for Ubuntu it would be \EFI\Ubuntu\grubx64.efi
. For Arch Linux it could be \EFI\arch\grubx64.efi
or \EFI\GRUB\grubx64.efi
for x86-64 systems (and \EFI\arch\grub.efi
or \EFI\GRUB\grub.efi
for x86-32).
To find out which EFI boot loaders there are, the ESP has to be mounted on Windows first, which can be done with diskpart
.
DISKPART> select disk 0
DISKPART> list volume
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ------ ----- ---------- ------- --------- ------
...
Volume 2 FAT32 Partition 200 MB Healthy System
DISKPART> select volume 2
DISKPART> assign letter=S
DISKPART> exit
The above assumes that a) the ESP, shown as System
under the Info column, is volume 2 (replace it with the actual volume #), and that b) drive letter S is still available (unused) up to this moment, otherwise use any other free drive letter (from A to Z).
The ESP is now accessible as the assigned drive, in the example S:
. Look at this drive to see if there are any EFI boot loaders under \EFI
... This can be done e.g. using the Windows Explorer, or while still in an elevated command prompt:
s:
dir /s /q
Note that this drive letter assignment is not permanent, i.e. after a Windows reboot the ESP will no longer be mounted, which is as it should be.
Now bcdedit
can be used to add an EFI boot loader to the EFI boot menu, and set it as the new default, as follows (change paths and GUIDs accordingly):
bcdedit /set {bootmgr} path \efi\grub\grubx64.efi
bcdedit /enum {bootmgr}
bcdedit /set {fwbootmgr} displayorder {<GUID>} /addfirst
bcdedit /set {fwbootmgr} default {<GUID>}
Note that changing the displayorder
is entirely optional!
All these commands only work with cmd.exe
, as with PowerShell (which would also have to be an elevated shell, i.e. "run as administrator") additional quotes are required:
bcdedit /set '{bootmgr}' path \efi\grub\grubx64.efi
bcdedit /enum '{bootmgr}'
bcdedit /set '{fwbootmgr}' displayorder '{<GUID>}' /addfirst
bcdedit /set '{fwbootmgr}' default '{<GUID>}'
This worked for me, as it set the Linux EFI boot loader as the default from within Windows 10, permanently. IMHO bcdedit
is the equivalent of efibootmgr
on Windows, only with the additional layer of (in this case absolutely unnecessary) random GUIDs to refer to the individual EFI boot loaders...