changes to the boot order made via efibootmgr are not sticking

[antagomir]

I installed Ubuntu 14.04 beta on my HP Elitebook Folio laptop. Fresh install, complete hard disk formatted. After successful installation I rebooted. The system tells me I am missing the OS. Then from BIOS menu F9 I could manually boot via EFI and got the system working. However I could not change bios settings such that the system would boot automatically via UEFI. After long trial and error with advice from several IRC colleagues I somehow managed to get the system boot via BIOS. But it seems that changes that are done to boot order, do not stay permanent.

I was told that my boot firmware "assumes that a drive without a "boot flag" on any of its primary partitions
in its msdos label cannot be booted via BIOS (again, only true with Windows).

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: grub-efi-amd64 (not installed)
ProcVersionSignature: Ubuntu 3.13.0-13.33-generic 3.13.5
Uname: Linux 3.13.0-13-generic x86_64
ApportVersion: 2.13.2-0ubuntu5
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Mar 1 00:10:27 2014
InstallationDate: Installed on 2014-02-28 (0 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140224)
SourcePackage: grub2
UpgradeStatus: No upgrade log present (probably fresh install)

[Phillip Susi (psusi)]

Please attach your /var/log/installer/syslog file.

[Phillip Susi (psusi)]

This seems to be the relevant error:

[ 760.222181] efivars: DataSize & Attributes must be valid!
Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1286388

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[antagomir (antagomir)]

Unfortunately I bumped into many other (i think unrelated) problems and finally had to reinstall the whole system. I can't run the required tests any more as they concern problems with the previous install.

[Phillip Susi (psusi)]

Bloody bot, I told you to stop nagging... syslog is already attached.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ubfan (ubfan1)]

BIOS Insyd 6.60
EFI version 2.31 by INSYDE
Firmware 6.10
Toshiba Satellite S955, UEFI with Secure boot disabled.
OS 64 bit Ubuntu 14.04.2, running kernel 3.19.8-992-generic
Dual boot with Windows 8.1

After a Windows 8.1 update 7/8/2015 (two important updates, all optional (2) ignored, the EFI boot order is for each boot, always returned to the default order with Windows first. This machine has been running 14.04 for a year, and I have successfully changed the boot order before.
Ubuntu may still be selected at boot time (F12, select hdd, then select ubuntu) and it successfully boots., efibootmgr can still alter the boot order to put ubuntu first, and reorder the USB/Net entries:
(ubuntu, windows, USB, DVD, Net).
 Checking the order with another "efibootmgr -v" shows the new order, but a reboot will have the origial EFI order restored:
 Windows,Ubuntu,Network,USB,DVD
The EFI Settings order was unchanged from USB, DVD, HDD, NET. The ubuntu entry had the name "ubuntu", and that still works
when selected from the EFI device/os selection (F12).
  Looks like some nvram entry was changed by Windows to force the order reset at each boot. The efibootmgr reordering only
changes the "Boot Order" variable (as named by "fwts uefidump".
There are other variables, like Physical Boot Order, which might need changing to make the boot order permanent.

I am examining the differences on the fwts uefi outputs from before the problem and now, but at first pass, nothing obvious
turned up.

[Ubfan (ubfan1)]

After the Software Updater run of 7/9/2015, a new 3.13.0-57 kernel (signed and unsigned) was added, and something added the "Boot0000, ubuntu, shim" bootloader entry again, at the first position (where it originally was). I did nothing explicit to add this shim entry, and the machine is running with secure boot disabled. Attached is the efibootmgr output and the diff of fwts outputs. My Ubuntu boot default was restored, but something seems wrong with the update process changing nvram.

$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0004,0003,2003,2001,2002
Boot0000* ubuntu HD(2,e1800,82000,04b9edc2-fc48-11e1-8ec1-e7137b3aaf29)File(\EFI\ubuntu\shimx64.efi)
Boot0001* EFI Network 0 for IPv6 (00-8C-FA-3B-27-AA) ACPI(a0341d0,0)PCI(1c,0)PCI(0,0)MAC(008cfa3b27aa,0)030d3c000000$
Boot0002* EFI Network 0 for IPv4 (00-8C-FA-3B-27-AA) ACPI(a0341d0,0)PCI(1c,0)PCI(0,0)MAC(008cfa3b27aa,0)IPv4(0.0.0.0$
Boot0003* Ubuntu HD(2,e1800,82000,04b9edc2-fc48-11e1-8ec1-e7137b3aaf29)File(\EFI\ubuntu\grubx64.efi)RC
Boot0004* Windows Boot Manager HD(2,e1800,82000,04b9edc2-fc48-11e1-8ec1-e7137b3aaf29)File(\EFI\Microsoft\Boot\bootmgfw$
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RC

$ diff results.log fwtwuefidumpnewdefault.log
6c6
< This test run on 09/07/15 at 21:55:03 on host Linux tosi 3.19.8-992-generic
---
> This test run on 09/07/15 at 13:27:54 on host Linux tosi 3.19.8-992-generic
51,57d50
< Name: Boot0000.
< GUID: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
< Attr: 0x7 (NonVolatile,BootServ,RunTime).
< Active: Yes
< Info: ubuntu
< Path: \HARDDRIVE(2,e1800,82000,c2edb90448fce111,8e,c1)\FILE('\EFI\ubuntu\shimx64.efi').
<
110c103
< BootCurrent: 0x0000.
---
> BootCurrent: 0x0003.
115c108
< Boot Order: 0x0000,0x0004,0x0003,0x2003,0x2001,0x2002.
---
> Boot Order: 0x0004,0x0003,0x2003,0x2001,0x2002.
121c114
< Data: 0000: 00 00 ..
---
> Data: 0000: 03 00 ..
133c126
< Data: 0060: 5c 00 73 00 68 00 69 00 6d 00 78 00 36 00 34 00 \.s.h.i.m.x.6.4.
---
> Data: 0060: 5c 00 67 00 72 00 75 00 62 00 78 00 36 00 34 00 \.g.r.u.b.x.6.4.
1119,1120c1112,1113
< Size: 10 bytes of data.
< Data: 0000: 00 00 04 00 03 00 02 00 01 00 ..........
---
> Size: 8 bytes of data.
> Data: 0000: 04 00 03 00 02 00 01 00 ........

[David Cary (dcary)]

I have recently had a similar problem with a fresh install of Ubuntu Server, versions 14.04.1, 14.04.3, and 15.04 on an HP Pavilion 15-f039wv laptop. I have a factory pre-installed version of Windows 8.1 that should be dual booting under UEFI with Ubuntu Server from the same hard disk. However once the install is complete, the machine only boots to Windows, unless I first intervene by pressing F9 to get an UEFI "Boot Option Menu" that offers three options of:
    OS boot Manager (UEFI) - Windows Boot Manager (ST500LT012-1DG142)
    OS boot Manager (UEFI) - ubuntu (ST500LT012-1DG142)
    Boot From EFI File

With the second option, I can boot to a Gnu Grub screen and then to Ubuntu Server.

In Ubuntu server, I can use efibootmgr to display its firmware parameters. I can set a next boot number and have it take effect for the next boot, but as expected, only for the next boot, and I can set the timeout value and have it persist across multiple boots. However while I can change the BootOrder and display it with both efibootmgr and in the /proc file system, the change to the BootOrder is reverted to the original version (Windows Boot Manager first) if I reboot, even if I reboot directly back to Ubuntu using the F9 intervention.

I have seen numerous postings in forums addressing this kind of problem and which often that attribute the problem to aggressive, nonstandard UEFI behavior from the system vendors (HP in my case). At least one, http://askubuntu.com/questions/221835/installing-ubuntu-on-a-pre-installed-windows-with-uefi, has a popular answer that claims in a recent edit that the problem is fixed in Ubuntu 15.04. It is not fixed in Ubuntu Server 15.04, at least not in my case.

This is particularly a problem in my case because the current behavior requiring an F9 intervention to select a boot manager, prevents remote or other unattended rebooting of the Ubuntu server, for example when using SSH for maintenance.

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Marcus Tomlinson (marcustomlinson)]

This issue has sat incomplete for more than 60 days now. I'm going to close it as invalid. Please feel free re-open if this is still an issue for you. Thank you.