Announcement

Collapse
No announcement yet.

Gremlins in the UEFI BootOrder

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Gremlins in the UEFI BootOrder

    EDIT, NEW: See Post #4 below on possibilities why this might occur.

    An fyi post for those following the issue of gremlins.

    Yesterday, this was my BootOrder as shown by efibootmgr (and it actually did work this way upon booting):

    I posted it in another thread discussion -->
    https://www.kubuntuforums.net/showth...l=1#post376893
    This:

    Code:
    sudo efibootmgr
    [sudo] password for mike: 
    BootCurrent: 0000
    Timeout: 1 seconds
    BootOrder: [B][COLOR=#ff0000]0000,0003[/COLOR][/B],0001,0004,000A,0005,0006,0002,000B,000C,0007,0008,0009
    Boot0000* [COLOR=#ff0000]ubuntu[/COLOR]
    Boot0001* debian
    Boot0002* grub_sda5K1504
    Boot0003* [COLOR=#ff0000]rEFInd[/COLOR] Boot Manager
    Boot0004* Mint_2
    Boot0005* Hard Drive 
    Boot0006* CD/DVD Drive 
    Boot0007* UEFI:CD/DVD Drive
    Boot0008* UEFI:Removable Device
    Boot0009* UEFI:Network Device
    Boot000A* Mint_1
    Boot000B* ubuntu
    Boot000C* ubuntu
    Last night, I shut down the computer.
    This morning, I powered up the computer, it booted to a different Boot order,
    I investigated all the boot menus in UEFI firmware to confirm that, indeed,
    the BootOrder had changed consistently throughout, I allowed the PC to boot using the new BootOrder, got into my Kubuntu here, ran efibootmgr thusly:

    Code:
    sudo efibootmgr
    [sudo] password for mike: 
    BootCurrent: 0003
    Timeout: 1 seconds
    BootOrder: [B][COLOR=#ff0000]0003,0000[/COLOR][/B],0001,0004,000A,0005,0006,0002,000B,000C
    Boot0000* [COLOR=#ff0000]ubuntu[/COLOR]
    Boot0001* debian
    Boot0002* grub_sda5K1504
    Boot0003* [COLOR=#ff0000]rEFInd[/COLOR] Boot Manager
    Boot0004* Mint_2
    Boot0005* Hard Drive 
    Boot0006* CD/DVD Drive 
    Boot000A* Mint_1
    Boot000B* ubuntu
    Boot000C* ubuntu
    And so, it flipped the first two entries ubuntu and refind; and it deleted the three at the end, 0007,0008,0009 (these are probably not anything important, cryptic duplicates or BIOS options, I'm sure).

    I did not take screen shots, I forgot how, but you can trust me on this!
    Last edited by Qqmike; Jul 29, 2015, 05:37 AM.
    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

    #2
    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.
    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

    Comment


      #3
      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.
      Desktop PC: Intel Core-i5-4670 3.40Ghz, 16Gb Crucial ram, Asus H97-Plus MB, 128Gb Crucial SSD + 2Tb Seagate Barracuda 7200.14 HDD running Kubuntu 18.04 LTS and Kubuntu 14.04 LTS (on SSD).
      Laptop: HP EliteBook 8460p Core-i5-2540M, 4Gb ram, Transcend 120Gb SSD, currently running Deepin 15.8 and Manjaro KDE 18.

      Comment


        #4
        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.
        Last edited by Qqmike; Jul 29, 2015, 05:38 AM.
        An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

        Comment


          #5
          What about an autoremove pass as a cause?
          It seems to rebuild the grub list with each old kernel removed.
          Kubuntu 18.04 on AMD

          Comment


            #6
            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.

            Comment


              #7
              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!
              An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

              Comment


                #8
                @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.
                An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

                Comment


                  #9
                  Was a thought, thanks for clarifying it further.
                  Kubuntu 18.04 on AMD

                  Comment

                  Working...
                  X