No announcement yet.

How enable choice of Kubuntu and Mint in the Bios/NVRAM boot menu?

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

    How enable choice of Kubuntu and Mint in the Bios/NVRAM boot menu?

    On my PC I have 3 Linux systems on a GPT/UEFI disk: Kubuntu, Linux Mint and openSUSE. The Bios NVRAM bootmenu shows Windows Boot Manager, ubuntu and opensuse. Kubuntu and Linux Mint both install to the \EFI\ubuntu\ folder, which means I get the bootmenu of the last one installed of these two. I would like to be able to choose either of them, just like I now can choose the opensuse bootmenu. How?

    There are ways to do this. See my

    UEFI Simplified, a quicker version
    toward the end, these sections:
    Dual-booting: Summary of 5 options
    Separate EFI directories for your OSs
    Using more than one ESP
    Changing labels on UEFI Boot entries: sudo efibootmgr -L
    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski


      Thanks a lot! This seems to be what I asked for, though quite a lot to digest. Will report back, but probably not soon. Cheers!


        Yes, there was an enormous amount of information in your link, and I rather quickly decided that there was more than I would be capable of absorbing. Did notice your option 4 though, which was very similar to a previous failed attempt of mine. I had tried to create a new entry by copying /EFI/ubuntu and renaming the copy /EFI/mint and editing the grub.cfg to the mint UUID and partition number. No, it still booted /EFI/ubuntu which was the Kubuntu grub2 menu. The difference with your option 4 was that /EFI/mint had to be created. So I booted MInt and in a root terminal run this:

        grub-install --force --bootloader-id=mint --no-uefi-secure-boot /dev/sda2 (sda2 being my EFI partition), Got these messages:
        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
        (just like in my previous thread) but also the comment that it had executed without error.

        Rebooted, the "ubuntu" entry was gone from the NVRAM menu and no sign of a "mint" entry. Started EasyUEFI and recreated the"ubuntu" entry - now calling it "Kubuntu" with path \EFI\ubuntu\grubx64.efi , and created an entry for "Mint" with the path \EFI\mint\grubx64.efi. Yes the "mint" folder had been created and contained one file, grux64.efi. Copied over the grub.cfg and edited the UUID and partition number.

        Rebooted with optimism and the NVRAM menu contained both Kubuntu and Mint! Choose to boot Mint. Yes, there was the Mint menu, which I had not seen for a long time! Rebooted and chose Kubuntu, and there was the Mint menu again! Not goot! What to do now?

        Copied over grubx64.efi from yesterday's backup to \EFI\ubuntu\ and rebooted. Yes, now got the Kubuntu menu, and yes, can still get the Mint menu. Great! Thank you Qqmike again for pointing me in the right direction!


          Glad you got it, again, hallergard! I didn't follow you exactly (too detailed for me at the moment), but only scanned your post. What counts is that you understand it . I haven't actually experimented with all this lately, but one thing I remember getting me was this stuff in my Technical Note in that how to I linked to, this:

          Technical note Briefly: There is just one EFI subdirectory for Ubuntu-based OSs, /boot/efi/EFI/ubuntu. You can get around this by creating separate, clearly named subdirectories for Ubuntu-based OSs using -bootloader-id=some_name. Suppose you do this for Ubuntu-based LinuxX; thus, /boot/efi/EFI/<some_name_for_LinuxX> contains the GRUB files for LinuxX. Now boot from <some_name_for_LinuxX>. Instead of using the location of LinuxX's GRUB files pointed to by /boot/efi/EFI/<some_name_for_LinuxX>, the system may use the location pointed to by the default directory /boot/efi/EFI/ubuntu (by /boot/efi/EFI/ubuntu/grub.cfg). This happens because the location /boot/efi/EFI/ubuntu/grub.cfg is hard-coded into the GRUB executable grubx64.efi. (The location /boot/efi/EFI/ubuntu is populated by the MOST RECENT (K)Ubuntu-based OS installed (or from which grub-install (with no options) was run). To fix this, you must (1) disable secure booting in UEFI firmware, and (2) use --no-uefi-secure-boot in your grub-install command when setting up a dual-boot with Ubuntu-based OSs using separate EFI directories.
          I'm not sure if/how relevant it is to your work. What counts is that you somehow get a solution that works for your setup, right?
          An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski


            Yes it was relevant, Qqmike! May I ask you a related questio?: How does 30_os-prober know what to add to other systems kernel command line? Background for question here:


              It uses a program called "linux-boot-prober"

              From the manpage:

              NAME linux-boot-prober -- Determine boot characteristics of a specified device.

              linux-boot-prober <partition>

              The linux-boot-prober utility will try to work out how to boot the linux root partition
              specified by <partition>. If successful, it will outoput one or more lines of the form:

              <root partition>:<boot partition>:<label>:<kernel path>:<initrd path>:<kernel parameters>

              For example, for a system with a kernel at /boot/vmlinuz and an initramfs at /boot/ini-
              trd.gz, and with / on /dev/sda2 and /boot on /dev/sda1, the command "linux-boot-prober
              /dev/sda1" will display:


              Some partitions will not be displayed by linux-boot-prober. If a partition is mounted on /, /target, or /target/boot, it will be skipped.
              You can do cat /etc/grub.d/30_os-prober to see the script

              Please Read Me


                Thanks oshunluvr Have compared the Kubuntu and openSuse scripts. Not identical, but its above my level. If anyone can explain why the openSuse command line is not always picked up by debian systems, please let me know on the above thread!