Announcement

**Qqmike** · Jul 28, 2015, 07:20 AM

No complaints here: the ASUS H97-Plus motherboard and firmware work great, imo. But it does show how these things (the workings of the UEFI firmware) may throw off some unexpected's. In fact, I've had the [crazy] idea lately that as part of a routine maintenance plan, perhaps you should clear the CMOS memory once or twice a year ( ! ). I've had to do it once--it resets all your UEFI firmware settings including the BootOrder NVRAM variables.

The phenomenon is interesting (to those of us with nothing else to do), and so I'm only posting this as I say, as an fyi.

**Rod J** · Jul 28, 2015, 10:46 PM

Hi Mike,

Well, I had a very similar experience just recently too. I've got the same motherboard (ASUS H97-Plus).

I noticed that my ReFind menu wasn't popping up any more. I had it set to always appear on bootup (even though I only have one OS installed on the bare metal) and it was in the first position in the UEFI boot order. But, after I noticed that ReFind wasn't appearing I checked and the boot order had changed in a similar way to yours (except the original order was ReFind, then Ubuntu, etc).

This is my boot order now (back to the original order):
rod@Core-i5:~$ sudo efibootmgr
[sudo] password for rod:
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000,0005,0001,0002
Boot0000* ubuntu
Boot0001* Hard Drive
Boot0002* CD/DVD Drive
Boot0003* rEFInd Boot Manager
Boot0005* ubuntu

I have speculated on what changed the order. I thought it might be a kernel update in 14.04 but I have updated the kernel a couple of times without any change in the boot order since. ReFind was updated the other day but that didn't make any change either.

I'm as baffled as you I think.

**Qqmike** · Jul 29, 2015, 05:36 AM

Hi Rod J

You may have hit on something: what updates/events could cause a switch in the 1st and 2nd entries in BootOrder?

7/27/15: there was a refind upgrade listed in Muon View > Show history.
I noticed it at the time. That could have caused rEFInd to take over position #1 and bump my ubuntu down to position #2.

For you: how did your ubuntu get bumped up to position #1, and rEFInd down to #2?
That's the question.
Possibilities ? :
a re-install of GRUB which (I think) occurs when GRUB is updated; my Muon history shows a grub-efi update on 7/11/15.
what about certain kernel upgrades? --> an open question;
what about a linux firmware upgrade? --> an open question (it occurred 7/22/15)

I think you solved my dilemma. I'll have to watch more closely next time on exact timing, possibly run an immediate test right after the upgrade.

Related:

https://www.kubuntuforums.net/showth...l=1#post373269

a discrepancy between what the ASUS UEFI firmware boot menu showed me and what efibootmgr showed me;

Comment: Need, again, to watch the timing carefully, to check for interveining upgrades, changes, or even user actions (like sudo grub-install).

Thanks for your input.

EDIT:
I edited Post #1 to point at Post #4 on this "new" discussion on possibilities.

**otisklt** · Jul 29, 2015, 10:19 PM

What about an autoremove pass as a cause?
It seems to rebuild the grub list with each old kernel removed.

**SteveRiley** · Jul 29, 2015, 10:31 PM

It is quite likely that installing or updating a boot manager (rEFInd, GRUB, others) would include a step that places the boot manager's loader first in the list.

I'm checking out rEFInd now. The package's post installation script contains this:

Code:

# Remove any existing NVRAM entry for rEFInd, to avoid creating a duplicate.
ExistingEntry=`efibootmgr | grep "rEFInd Boot Manager" | cut -c 5-8`
if [[ -n $ExistingEntry ]] ; then
   efibootmgr --bootnum $ExistingEntry --delete-bootnum &> /dev/null
fi

As indicated in the comment, this removes any existing NVRAM entry for rEFInd.

The grunt work of installing rEFInd occurs via the script install.sh. Here's a relevant snippet:

Code:

AddBootEntry() {
   . . .
      if [[ $InstallIt == "1" ]] ; then
         echo "Installing it!"
         "$Efibootmgr" -c -l "$EfiEntryFilename" -L "rEFInd Boot Manager" -d $InstallDisk -p $PartNum &> /dev/null
         if [[ $? != 0 ]] ; then
            EfibootmgrProblems=1
            Problems=1
         fi
      fi
. . .
} # AddBootEntry()

The if [[ $InstallIt == "1" ]] ; then contains a call to efibootmgr using the standard parameters for creating a new boot entry. By default, efibootmgr places new boot entries at the front of the boot order list.

So yeah, installing or updating rEFInd would cause the behavior you're seeing. I can't duplicate it here because I don't have multiple boot managers installed.

**Qqmike** · Jul 30, 2015, 06:07 AM

SteveRiley:

It is quite likely that installing or updating a boot manager (rEFInd, GRUB, others) would include a step that places the boot manager's loader first in the list ... So yeah, installing or updating rEFInd would cause the behavior you're seeing. I can't duplicate it here because I don't have multiple boot managers installed.

Yes, exactly so -- IME. I don't know this by analyzing the install scripts as you have done. I know this by experimenting only and observing the end result, which is that the most recently installed bootloader/manager/OS(which installs its bootloader) will take over as #1 in the BootOrder and bump the existing list down one place (thus the previous #1 becomes #2 in the new BootOrder).

So the question becomes, as Rod J had the insight to question: What causes re-installations or new installations of bootloaders/boot managers. Thus, we should carefully watch the update/upgrades that occur in Muon/Synaptic (or by sudo apt-get [dist-]upgrade). Some are obvious: upgrades to grub-efi. But what about linux firmware upgrades? kernel upgrades (all or only certain ones)?, certain commands like autoremove?, and so on. Open questions.

(I guess we should note, for "new" users to this, that if the boot order (the NVRAM variable BootOrder) does change, you can easily change it back using efibootmgr with the -o option. See man efibootmgr and scroll down to see the examples at the end of the man page.)

Thanks, Steve, for your surgical report!

**Qqmike** · Jul 30, 2015, 08:13 AM

@otisklt, re sudo apt-get autoremove:

It looks like this only does the following:

Code:

Generating grub configuration file ...

and

Code:

Adding boot menu entry for EFI firmware configuration

and thus it affects only the file /boot/grub/grub.cfg (in the current OS from which you issued the autoremove command).

Thus, it does not (re-)install grub or change any NVRAM variable or the BootOrder.

**otisklt** · Jul 30, 2015, 06:04 PM

Was a thought, thanks for clarifying it further.

Announcement

Gremlins in the UEFI BootOrder

Gremlins in the UEFI BootOrder

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment