Announcement

Collapse
No announcement yet.

Cannot get 'ubuntu' in the Bios NVRAM bootmenu

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

    Cannot get 'ubuntu' in the Bios NVRAM bootmenu

    Used to have three entries in the firmware (Bios) "UEFI Only" bootmenu (NVRAM): ubuntu (default), opensuse-secureboot and Windows Boot Manager.

    Had an accident and had to restore the EFI partition, and have managed to get back opensuse-secureboot and Windows Boot Manager - but not ubuntu. My Kubuntu 16.10 works fine, but I have to boot it from the opensuse Grub2 bootmenu. Have tried the following:
    1. Reinstalling Kubuntu 16.10
    2. Boot-Repair
    3. efibootmgr -c -L {ubuntu} -l \EFI\ubuntu\grubx64.efi
    efibootmgr: Could not set variable Boot0001: No such file or directory
    efibootmgr: Could not prepare boot variable: No such file or directory
    4. grub-install --force /dev/sda2
    Installing for x86_64-efi platform.
    efibootmgr: Could not set variable Boot0001: No such file or directory
    efibootmgr: Could not prepare boot variable: No such file or directory
    5. bcdedit /set {ubuntu} path \EFI\ubuntu\grubx64.efi
    The element data type specified is not recognized, or does not apply to the specified entry.

    None of the above works (and I do have the correct files in /dev/sda2/EFI/ubuntu/). Help would be very much appreciated!

    #2
    Hmmm ... just to double check what you've done ...

    You may have re-created the ESP? If so, in GParted you should set the boot flag on the ESP partition, which looks like it is /dev/sda2. However, your other two OSs are booting OK using that ESP, so it should be OK.

    Clearing up notation:
    The ESP files would be in
    /boot/efi/EFI/ubuntu
    right?

    ... where the ESP partition /dev/sda2 is mounted at /boot/efi.

    When you boot into your ubuntu, you can check to see if it recognizes your ESP using this command:

    df /boot/efi

    which would return /dev/sda2 if your ESP is sda2.

    So you tried to reset GRUB, but you don't need any arguments (though they may just be ignored anyway).
    When you get booted into ubuntu, try again to re-set GRUB by doing (no arguments):
    sudo grub-install
    sudo update-grub

    And you can check the status of your disk sda (to see a valid GPT and so on) using:
    sudo gdisk -l /dev/sda
    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

    Comment


      #3
      And just to throw out something else for you to play with, your statement:
      efibootmgr -c -L {ubuntu} -l \EFI\ubuntu\grubx64.efi
      I'm not sure the braces work {}, not sure they won't; but in any case, you need to specify a partition for the ESP you wish to use; like this, for example:
      sudo efibootmgr -c -d /dev/sda -p 2 -l '\EFI\ubuntu\grubx64.efi' -L 'ubuntu'
      which uses sda2 as the ESP (disk d, partition p, bootloader l, label L); and note my use of the single quote marks '.
      An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

      Comment


        #4
        Thanks Qqmike, have done all the checks you mention and can confirm that everything is as you say it should be (except the same error message as before with 'sudo grub-install')

        Comment


          #5
          Sometimes, having Secure Boot turned on (in your UEFI/BIOS firmware menu) can mess up the grub-install, with the message you got.

          Make sure CSM and Legacy Boot options are turned off in the UEFI/BIOS setup menus.

          BUT ... if I read it correctly, your "opensuse-secureboot" is using Secure Boot (as well as your Windows)?
          If so, you can't turn Secure Boot off then.
          An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

          Comment


            #6
            If you've tried everything else, I may as well throw this out , too: Could the UEFI firmware/efibootmgr be damaged? This issue seems to pop up around the Internet. For example, see Rod Smith's answer here:

            http://askubuntu.com/questions/71900...-for-dual-boot

            It starts with this:

            Here's the problem, from lines 1220-1221 in your Boot Repair log:

            efibootmgr: Could not set variable Boot0002: No such file or directory
            efibootmgr: Could not prepare boot variable: No such file or directory
            Translated to English, the efibootmgr utility (a key part of installing an EFI boot loader from Linux) tried to create a new variable (Boot0002), but when it tried to set that variable as the default, it had disappeared from the firmware's memory. Basically, this indicates a bug in the firmware (or possibly in efibootmgr), or at least some sort of firmware glitch or misconfiguration. There are several possible solutions and workarounds, such as:
            An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

            Comment


              #7
              I'll add a tidbit of my own: Once, I had to reset my ASUS UEFI firmware. Doing that by turning the PC off, unplugged from wall, and playing with the CMOS-clear jumper. This is kind of a major thing, as you could end up all messed up, unable to boot and so on ...
              An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

              Comment


                #8
                I had actually already tried with the single quote ' instead of the braces {} but forgot to correct it in my post. Trying sudo efibootmgr -c -d /dev/sda -p 2 -l '\EFI\ubuntu\grubx64.efi' -L 'ubuntu' gave the same error messages as before. I don't have a Secure boot in the Bios, but I can choose between "UEFI mode Only" or "Legacy and UEFI mode". Have used "UEFI mode Only", but believe opensuse tries to install as secure-boot regardless whether it can or not. Yes, I already tried clearing the CMOS by taking the battery out for a minute. Will try to study what Rod Smith has to say on the subject. Thank you very much for your suggestions!

                Comment


                  #9
                  Qqmike Thank you for pointing me in the right direction. Rod Smith gave three alternatives: bcdedit did not work, EFI shell I did not get around to test, because EasyUEFI did work!

                  Comment


                    #10
                    Glad you got it, hallengard. If you are using Windows, the EasyUEFI looks very useful. First time I had heard of it. As for the EFI shell, it is my impression that it is somewhat advanced and requires some start-up time and effort to learn it. I've never used it, but our member Steve Riley had gained some expertise with it.
                    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

                    Comment

                    Working...
                    X