I add, that it resets on reboot to order, that I see in EFI control utility (BIOS) in boot priority list. When I change order here, it really changes and Linux boots first. But changing it by efibootmgr does no effect, as on reboot it resets to order in BIOS.
IIRC version 0.7.0 changed boot order properly (but there was another problems with booting Windows then).

What is the brand and model of your system and the date + version of your EFI control utility?

Asking because changing the boot order with efibootmgr 0.11.0 works fine on a
ThinkPad L530 with
UEFI BIOS version G3ETAWW(2.61) of April 23rd 2014.

I have following configuration:

Laptop: Acer Aspire V5-552G
BIOS version: 2.07
BIOS vendor: Insyde Corp.
efibootmgr version: 0.11.0

Apparently Acer customizes Insyde's firmware after they take delivery, and they've (maybe) got another variable they're keeping the boot order in, and regenerating it each time during boot.

This is completely nonstandard behavior, but if we can identify what they're doing, we may still be able to make efibootmgr support it.

Same problem on Acer Aspire VN7-591G and BIOS Insyde V1.10.
Had to resort to this ugly hack (concealing the Windows boot manager), after which configured boot order is fully respected.

Now efibootmgr -v looks like this after reboot and is not being overwritten (see how there's no Boot0000 anymore but a new Boot0006 instead):

BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0006,2001,2002,2003
Boot0002* Fedora    HD(2,12c800,96000,2d46ad0b-592f-483a-aeee-d787e26d5378)File(\EFI\fedora\shim.efi)
Boot0006* Windows   HD(2,12c800,96000,2d46ad0b-592f-483a-aeee-d787e26d5378)File(\EFI\1Microsoft\Boot\bootmgfw.efi)
Boot2001* EFI USB Device    RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC

Same issue on Lenovo Thinkstation p300

Perhaps not quite the same issue?
Supermicro server with NO MS Windows installed. (AMI BIOS)
Ubuntu 14.04 trusty with two ESP partitions. Either ESP will boot to root file system (RAID1 on partition 2 of each disk)
Setting the BootOrder with efibootmgr appears to work (second run of efibootmgr reports correct settings) but the system ignores any changes on next boot.
I can add/remove boot entries and BootNext works as expected.

Ubuntu 14.04 trusty - fully updated
Kernel 3.13.0-65-generic

Tried:
Stock Ubuntu 14.04 (no efivar module):-
efibootmgr_0.5.4-7ubuntu1.2 - stock Ubuntu 14.04
From Ubuntu repos for later releases:-
efibootmgr_0.7.0-2ubuntu0.14.10.1 with libefivar0_0.10-5 and efivar_0.10-5
efibootmgr_0.11.0-3 with libefivar0_0.15-3 and efivar_0.15-3
efibootmgr_0.12-4 with libefivar0_0.21-1 and efivar_0.21-1

The later versions were also using the stock Ubuntu kernel with no efivar module

Should I be talking to Supermicro about this?

I'm wondering if any of these issues are related to a problem I had recently with an "Acer Aspire E15 Start" laptop.
With Secure Boot OFF the laptop always just showed a screen saying "No Bootable Device". Even after re-installing grub2 to the HD and checking that mageia was first in the boot order, it failed to boot and on re-checking the boot order, mageia had been removed from the boot order by the boot attempt.
It had a clean install of Mageia 5 on the drive which was fine and could be booted via a SuperGrub2 CD.
The problem turned out to be a buggy UEFI BIOS whereby it required grubx64.efi to be set as "trusted" even when Secure Boot was not being used.
The solution was to enter a password and set Secure Boot ON, then set the mageia/grubx64.efi as trusted. The machine then booted correctly with or without Secure Boot enabled and with or without a Secure Boot password set.
This seems to be a common issue with some Acer laptops, maybe it affects other manufacturers.

Follow up on my post above:
In our case, efibootmgr is behaving correctly as per the UEFI spec. (thank you, vathpela and others!) The issue lies with Supermicro who have not implemented the UEFI spec correctly on these systems. The firmware ignores the UEFI BootOrder variable completely on boot. Supermicro tech support say that this is due to their "standard" BIOS boot menu system and will not fix it.
I am not aware of any workaround for this issue.

I've got the same issue on my new laptop, and I just found a (kind of unstable) workaround, that is to make it run 'efibootmgr -n NNNN' every time it boots. I would like somebody to hack this lame BIOS if possible!

Laptop : Acer Aspire V-13, V3-372-P5E5
BIOS version : 1.05
BIOS name : InsydeH2O Setup Utility Rev. 5.0
efibootmgr version : 0.12

a funny thing is that I have to connect a UEFI bootable USB flashdrive to get it booted lol. or else it just shows a cute image and text says 'no bootable drive' found(I'm not sure about the exact word, it could be 'media' instead of 'drive') 'No Bootable Device'

@wind0204 Have you found a permanent workaround? I'm in the same situation here. Also on an Acer Aspire V 13. Edit: well it's not a particularly good workaround but I've got a startup script to set the next boot entry.

@wind0204 I figured it out! You need to enable secure boot and register systemd with secure boot. However, then it complained that vm-linuz wasn't registered so I disabled secure boot again. It kept Linux on the boot menu though, so I moved it up to first and everything worked out. I might look into getting secure boot working with a chain efi loader though.

@PlasmaPower Thanx for sharing :) I still don't know what's going on in this stupid motherboard in V3-372 but anyway, now I've somehow managed to get it to boot without an efi bootable drive plugged in, I don't know how it works though.

I still use the udev rule for running 'efibootmgr -n NNNN' but this time I've got the stupid motherboard to register my linux kernel by renaming the kernel to ?????.efi and then registering the hash in the BIOS setup utility(holding down the key F2 when it's doing a POST)->'Security'->'Select AN UEFI file as trusted for executing'->browse and choose the kernel I just renamed.-I'd tried ArchISO's Hashtool but it wouldn't stop the BIOS printing cute image and text of security check failure- After the registration in BIOS setup utility, this motherboard had got the efi variable and it appeared on the boot priority configuration screen but since it didn't have the kernel parameters (root, resume, resume_offset, initrd) it just panicked.

the next step is build a kernel with built-in kernel parameters and get rid of the udev rule. sigh

@wind0204 I'm not using the EFI stub, as whenever linux updates the hash changes I think. Instead, I'm using systemd-boot (you should try that, the menu is optional).

@PlasmaPower it works so well, I appreciate it. :)

@wind0204 Glad I could help!

Not sure if it helps anyone else ( @biggreenogre ? ) but I noticed that my SuperMicro X10SDV-F-O had a boot mode option in the BIOS boot config screen. It had the options "Legacy", "UEFI" and I think the last (and default) was something like "Hybrid".

Switched it to UEFI and it follows the boot order set in efibootmgr.

Thanks for the heads-up!

I downloaded and installed the latest BIOS for our systems (SS1028u-4+), X10DRU6.721, dated July of this year. Unfortunately, it seems that the UEFI Bootorder is still broken by their weird BIOS boot order menus.

Hopefully they have listened and fixed it on new systems going forward.

On 05/08/16, bobobo1618 notifications@github.com wrote:

Not sure if it helps anyone else ( @biggreenogre(https://github.com/biggreenogre) ? ) but I noticed that my SuperMicro X10SDV-F-O had a boot mode option in the BIOS boot config screen. It had the options "Legacy", "UEFI" and I think the last (and default) was something like "Hybrid".

Switched it to UEFI and it follows the boot order set in efibootmgr.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub(#19 (comment)), or mute the thread(https://github.com/notifications/unsubscribe-auth/ADzaYzMZXbYgiHfX6P7kTCsha5UA36WKks5qcsNcgaJpZM4Cybus).

I noticed something that hasn't been mentionned.

In the following commands, I change the boot order to put Ubuntu (Grub) before Windows Boot Manager.

$ efibootmgr 
BootCurrent: 0002
Timeout: 10 seconds
BootOrder: 0000,0002,0001
Boot0000* Windows Boot Manager
Boot0001  Hard Drive
Boot0002* ubuntu

$ sudo efibootmgr -o 0002,0000,0001
BootCurrent: 0002
Timeout: 10 seconds
BootOrder: 0002,0000,0001
Boot0000* Windows Boot Manager
Boot0001  Hard Drive
Boot0002* ubuntu

$ efibootmgr
BootCurrent: 0002
Timeout: 10 seconds
show_boot_order(): Permission denied
Boot0000* Windows Boot Manager
Boot0001  Hard Drive
Boot0002* ubuntu

$ sudo efibootmgr 
BootCurrent: 0002
Timeout: 10 seconds
BootOrder: 0002,0000,0001
Boot0000* Windows Boot Manager
Boot0001  Hard Drive
Boot0002* ubuntu

Before the update, the boot order is visible without sudo. After the update, the boot order is only visible with sudo. Without sudo, you get show_boot_order(): Permission denied. More generally, everything modified with sudo will be invisible without sudo, BootOrder has a special permission denied message, but this is the case for Timeout and BootNext too.

Maybe efibootmgr is changing the reading rights and after the reboot, as the BIOS cannot read the boot order, it resets it to default.

Anyway, there is something weird with the way efibootmgr works.

I am surprised that this issue isn't more discussed. Are all people using a dual boot based on GPT/UEFI affected, or only some manufacturers ?

Motherboard MSI Z170A
Win10 and Ubuntu 16.04
efibootmgr version 0.12

And for those who want the dirty workaround, here is it.

sudo gedit /etc/rc.local and add efibootmgr -n XXXX (without sudo) before the wait 0. In my case, it looks like this:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

efibootmgr -n 0002

exit 0

After the reboot from Linux it will launch Grub. After using another OS, like Windows in my case, you have to call the boot menu manually to get back to Grub. So you can loop on Linux (with a Grub call) or Windows (default, no Grub), but after using Windows you need to call the boot menu manually to get back to Linux.

This isn't very pretty but it works.

I can confirm the same behavior here. After I updated the order, only sudo efibootmgr is able to read it, as @MarCnu mentions. Has anyone come up with a more permanent solution?

Laptop HP 250 G4
Motherboard HP 80C1
Windows 10 and Ubuntu 16.04
efibootmgr 0.12-4

@MarCnu for me even without lists the correct order, but still doesn't work, probably bios related, if I try to change the order in bios a window with the options opens, but if I press enter the window flashes, but stays open

For me (using T460 Thinkpad) the boot option doesn't even show up in EFI boot selection menu and the boot order is always reset to default after reboot, however setting bootnext works

Huh, turns out I overlooked “Lock Boot Order” setting in setup menu. Disabling it allows to create new boot entries

@mlen in bios?

@ForsakenHarmony yep

@PlasmaPower , thanks, your solution works well on my acer travel mate.

I experienced this on a laptop with AMI firmware. I would remove a boot entry with efibootmgr -B -b 0000 (Fedora), and confirm they happened with efibootmgr -v. But then when I rebooted, I'd see that Boot0000 (Fedora) was back like I never did anything.

Then I noticed that the following variables existed:

• FastBootOption - Hexdump showed shim.efi, but not "Fedora"
• FBO_SavedBootOrder - (0, 3)
• FBO_SavedBoot0000 - Looked just like the original Boot0000

I deleted these variables (rm /sys/firmware/efi/efivars/...) and then the system acted like I expected.

Greetings. Experienced this issue on acer laptop.
I'm using arch linux.
'Fixed' by replacing /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi with /boot/efi/EFI/arch/grubx64.efi
Having renamed that file allowed to boot straight to grub without breaking Windows entry there and playing around with efibootmgr

Fixed it on an Acer notebook (StackExchane - AskUbuntu):

Set supervisor password from Security menu option.
Set BootMode to 'UEFI' from Boot menu option.
Enable SecureBoot from Boot menu option.
From Security menu option - Select 'UEFI file as trusted for
executing' press Enter then 'HDD0' appears press Enter then 'EFI'
appears press Enter then select 'ubuntu' option from the list (only
listed if you have ubuntu installed already) press Enter then choose 'shimx64.efi' (In my case it's the third entry) press Enter give it a name and press Enter.
Go back to Boot menu option and under Boot priority goto
'ubuntu' item in the list and press F6 until it become top most item in the list. Repeat same for 'Windows Boot manager' until it becomes second top most item in the list.
Press F10 to save changes and exit.

I'm having much the same problem, though it seems to have f**ked me over a tad more.

I'm running dual booted Windows 10 and Manjaro Linux. In order to boot into grub after installation, I booted into windows and used bcdedit to modify the bootmgr path to point at the GRUB binary.

When I wanted to get rid of windows 10, I was told to use efibootmgr to modify the boot order to boot Manjaro first. When I did that and rebooted, I booted into Windows directly.

I managed to get back into Manjaro through my f12 boot menu, and efibootmgr output shows 2 Windows boot manager entries, one at 0000 and one at 0005, with 0000 being the first to boot. it seems this phantom WBM is also completely ignoring bcdedit, and choosing to boot directly to windows.

I reallllly need to get this fixed, so if anyone has any ideas I'd be glad to try them

I'm using an Acer V3-575T. efibootmgr version 15, according to efibootmgr -V.
I can look for the BIOS version and vendor if that's needed

@Redrield It sounds like the firmware is automatically creating an entry for Windows after finding the Windows EFI binary on the ESP (EFI System Partition), and placing it at the top of the list. This is unfortunately very common and utterly broken behaviour, but it's implemented in the firmware before any EFI binaries are run, so it's not something that efibootmgr can do anything about.

If you never want to boot Windows again on this machine, you could mount the ESP from under Linux and just remove the Microsoft/Windows directories from the ESP, then clean up efibootmgr entries. If you do want Windows to boot but not be the default, I think the safest thing to do is try and use the firmware settings to change the boot order to place Linux first, and then never touch it again from efibootmgr/bcdedit - that's most likely to "stick".

@ramcq If you mean in the configuration options that I get when I use f2 at boot, i can't. The only options in the boot order there are to generically boot from my HDD, boot from windows boot manager, or net boot and other external boot sources.

Solved on my Acer Spin 5 SP513-51-54F6 in a similar way as @RigDillinger: by making a backup of /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi, then changing it with the grubx64.efi executable, and than making a new entry in grub for windows that points to the backup of bootmgfw.efi.

@RigDillinger Thanks resolved for me.

@RigDillinger 's fix worked for me also. I'm using an Acer Aspire E5-575-33BM.

I wanted a linux-only boot system. I moved my .efi file from its linux-specific path to /EFI/Microsoft/Boot/bootmgfw.efi , on the efi partition. I didn't need to add the boot option using efibootmgr, the entry was there automatically on start. It shows up as "Windows Boot Manager".

I am on a Dell XPS 9343 (bios A14) and I experience a similar problem: I can manage with boot entries, boot order, timeout with efibootmgr but when I reboot, settings are resetted to their original values.

I have only Arch Linux installed on my disk.

HP Spectre has started ignoring BootOrder recently. I suspect a recent firmware update is what broke it. DMI: HP HP Spectre Notebook/81A0, BIOS F.40 02/26/2018

I've tried minimal regression testing kernel 4.14.18, 4.15.14, and 4.16.2 with efibootmgr-15-3 and 15-6 and it's all the same. BootNext works, but changing either the BootOrder variable with efibootmgr --bootorder or PhysicalBootOrder per this bug's advice https://bugzilla.redhat.com/show_bug.cgi?id=1343559#c5 does not work.

I do before and after hexdump -C for each of the variables, if that is a reliable check of whether the change is really written to NVRAM, then that means on reboot the firmware is somehow resetting those variables - but I don't understand what BootOrder can use as a template. In such a case I'd expect it to revert to Windows, but I'm trying to get the BootOrder to make Window first, but instead I'm always getting GRUB (the Fedora entry).

Edit: OK so I fixed it but I don't know why this worked. I went into firmware setup > system configuration>boot options>os boot manager and toggled Fedora/Windows, F10 twice to save. And now Windows boots by default. And now efibootmgr --bootorder works again for either OS. I have a file listing of /sys/firmware/efi/efivars from the "stuck" state where --bootorder would not work, and after. There are two new entries in the current state that weren't there in the "stuck" state.

-rw-r--r--. 1 root root   94 Apr 19 14:43 Boot3002-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r--. 1 root root   90 Apr 19 14:43 TargetHddDevPath-59d1c24f-50f1-401a-b101-f33e0daed443

And efibootmgr reflects this extra entry

$ efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002,2001,2002,2004
Boot0001* Fedora
Boot0002* Windows Boot Manager
Boot2001* EFI USB Device
Boot3001* Internal Hard Disk or Solid State Disk
Boot3002* Internal Hard Disk or Solid State Disk
$ hexdump -C /sys/firmware/efi/efivars/TargetHddDevPath-59d1c24f-50f1-401a-b101-f33e0daed443
00000000  07 00 00 00 02 01 0c 00  d0 41 03 0a 00 00 00 00  |.........A......|
00000010  01 01 06 00 00 1d 01 01  06 00 00 00 03 17 10 00  |................|
00000020  01 00 00 00 00 25 38 44  61 b5 7d f2 04 01 2a 00  |.....%8Da.}...*.|
00000030  02 00 00 00 00 18 0e 00  00 00 00 00 00 18 03 00  |................|
00000040  00 00 00 00 8a 6b ff c2  67 0b 1a 4d 89 53 0f 00  |.....k..g..M.S..|
00000050  b0 54 2b 63 02 02 7f ff  04 00                    |.T+c......|
0000005a
$ 

Anyway, I guess letting the firmware change the boot order, in effect cleared up the problem.

I have a similar problem with my Shuttle Barebone XPC Cube SH170R6 1151. I have Lubuntu 18.10 running and added a Win10. It all works fine except Win10 is booting as default. I can change via F7/boot menu to Ubuntu. I have secure boot deactivated. I tried to use rEFInd as bootmanager and found that after I setup the entry with efibootmgr and sudo it gets deactivated on reboot. Did not try and workarounds yet.

Same behavior on an msi x470 motherboard

Same behavior observed on a Microsoft surface go.

Any idea what exact chip and which vendor is to blame here?
I do not believe this is directly an issue with Microsoft.

Asrock X470 Taichi Ultimate- also braindead.
Oh, and Asrock apparently "Only support Windows OS" (haven't heard that one in a while!)

Asus X370-F. Cannot remove EFI entries. Can create new ones, but existing EFI entries cannot be removed.

Greetings. Experienced this issue on acer laptop.
I'm using arch linux.
'Fixed' by replacing /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi with /boot/efi/EFI/arch/grubx64.efi
Having renamed that file allowed to boot straight to grub without breaking Windows entry there and playing around with efibootmgr

It works, thank you very much!!

also happens with a Asus PRIME a320m-a even after I updated the BIOS

For every Supermicro X10 (X11 should be the same) user which can't set the uefi boot order from linux with efibootmgr:

It' not your fault - it's Supermicro's fault -> [1]. They prohibit the change of the boot order from non-windows or non-signed-kernel systems. They offer an option to set the boot order via SUM (Supermicro Update Manager) -> [2] but this is way to complicated.

Easy way via BIOS:

1. Enter BIOS
2. Go to Boot
3. Select Add new boot option
4. Select Add boot option
5. Give the boot option a meaningful name
6. Select Path for boot option
7. Select the drive/volume the efi image is located
8. Then there is a "popup" titled Select a File to Boot which leads you through the directory tree of the drive/volume until you reach the efi image. At the end select the appropriate efi image - e.x. grubx64.efi
9. Select Create to finish which should verify the successful process with the "popup" Boot Option Created Successfully
10. Now go to Save & Exit and select Save Changes and Reset
11. After reset enter the BIOS again
12. Go to Boot
13. Select UEFI Hard Disk Drive BBS Priorities
14. Select UEFI Boot Order # 1 and select your newly created boot option
15. Now go to Save & Exit and select Save Changes and Reset and it should boot your selected OS.

I attached a slideshow-style screencast so the youth can follow my directions. If anybody want to put this on his/her blog/instagram/whateverIsCoolToday - feel free - but please link to this comment.

[1] https://www.supermicro.com/support/faqs/faq.cfm?faq=27004
[2] https://www.supermicro.com/SwDownload/UserInfo.aspx?sw=0&cat=SUM

I don't have an 'issue' with efibootmgr either - as per above posts this is about the odd removal of my boot entries after a lengthy shutdown. I found the above comments very helpful, as having been about to re-flash my bios it hadn't occurred to me to actually enable secure boot!

Reason I mention this is because having done so (and it's too early to tell yet whether settings will persist. I'll know tomorrow morning) I wasn't asked for any passwords or to confirm or accept anything as 'trusted' or 'secure' ?

I might point out that when installing on this ex Windows 8.1 box I deleted all the partition information. This is a single system, single user machine, with Arch linux on it. I began afresh with new GPT table, and then entries and formatting accordingly.

I've just started booting via efistub, having ditched grub2 because why do I need another bootloader? Had same issues when using grub i.e. settings lost overnight. I've tried CSM support both on and off, as per other answers elsewhere, but same difference.

I have no problem editing boot entries, or creating a new one in efibootmgr but obviously it's a complete pain in the **s having to rewrite that every morning!

After several HOURS I managed to write the entry manually with bcfg: https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#bcfg

1. map
   my SSD was FS1:
   found out via FS1: + ls => has EFI directory (don't get confused with arch iso live CD!!!)
2. bcfg boot add 3 FS1:\EFI\refind\refind_x64.efi "rEFInd Boot Manager"
3. bcfg boot mv 3 0
4. profit $$$

Issue still present on Asus prime z370-p with the latest bios. The boot order just disappears.

Just want to comment that on my Acer aspire vn7-591g this issue occurs .

Not using windows , just linux but as soon as I plug a bootable usb (linux one for example) automatically boots ftom that and the infamous boot0000 appears at the first place on boot order.

Using UEFI with secure boot enable, didn't try the legacy mode.

After upgrading bios firmware, all linux boot order has gone But windows's still alive. How can we keep it after upgrading bios firmware?

There are a lot of comments about broken EFI firmware behavior in this issue, but none of the problems are related to efibootmgr. So I'm closing this.

Some observations I had on a B550 motherboard, might help others in this thread:

1. During boot, firmware starts reading entries in order
2. If it finds an entry with a duplicate name but with the same path and params, it skips and deletes it.
3. If it finds an entry with an invalid path or params, it skips and deletes it.
4. If an entry exists but is not a part of the boot order, it skips but does not delete it.