Multiple Distributions with UEFI

[Bings]

If you install more than one distro, does each one create it's own UEFI entry in the BIOS?

I currently have Kubuntu and Windows 10 on a dual boot. Each has it's own UEFI entries which I can move around in the BIOS. I want to install more distros but I use BTRFS file system, so (as I understand from other threads on here) it's not simply a case of refreshing Grub to get it in the menu. So I want to know if I am able to switch the UEFI order to get to each individual OS until I can manually put an entry in a grub menu.

[Qqmike]

If you install more than one distro, does each one create it's own UEFI entry in the BIOS?

Yes. Each has its own boot files in the ESP and also each is registered (listed) in the UEFI-BIOS firmware.

However ... Ubuntu derivative distros (Ubuntu, Kubuntu, Mint, etc.) all get the same name or label! Namely, the label "ubuntu" (whereas, for example, Debian may get the label debian). So, in your UEFI-BIOS boot lists, you might see several entries, each labeled ubuntu. Which is which? Not clear, but you can find out by experimenting. To cut to the quick here, there are some ways to deal with dual-booting multiple "Ubuntu" distros, as explained here in my how-to (pay attention to the subject of "Labels"):

UEFI Simplified -- A Quicker Version
https://www.kubuntuforums.net/showth...l=1#post379977


(Btw, I know nothing about BTRFS, so keep that in mind. I get the impression that dealing with GRUB may have some things to know about in BTRFS.)

[Qqmike]

To clarify something, as you install multiple Ubuntu distros in succession, the one you are installing last gets the ubuntu label (folder) in the ESP. IOW, its GRUB takes over the booting (and boots your other Ubuntu's using the GRUB boot menu). You only need one ESP in your system, even if you have many disks and many OSs. But let's say you did create a separate ESP for each of your Ubuntu distro's. In each of those ESPs, the Ubuntu distro would get the ubuntu label and folder (in the ESP). And in your firmware's boot menus, each one of the Ubuntu distros would be labeled the same--each would be labeled "ubuntu." That how-to link explains all this and more.

[Bings]

Thanks. I have a problem with changing the efi boot entries though. I can run the commands in your tutorial and it all looks fine but then when I reboot all the changes are wiped. I don't know whether it's linked to another issue that when I update grub, I need to select another entry in the bios to boot it too.

[Qqmike]

Re-booting after making changes to the UEFI boot list is the right thing to do, so that is good.

And you can make changes to the UEFI-firmware boot settings can be done in two ways: (1) Using efibootmgr commands (as you have done), and (2) entering UEFI-BIOS and making changes (edits) directly to the UEFI boot order or boot list (if your UEFI (motherboard) firmware accommodates you in this task).

I do not know anything about how BTRFS might come into play here or make any difference. Can you access your ESP partition and see what is actually in there? See the folders and their contents? Do you have a clear ESP partition (you know, 200-500 MB, FAT32, set the boot flag on the ESP partition, it can be any partition but for convenience is often sda1, etc.).

Finally, there is the ever-present issue of HOW your motherboard maker has implemented the UEFI standards, and how good it has been done. I have always used ASUS, for example, and ASUS has implemented UEFI firmware and UEFI menus in a super-excellent way--you can use mouse control and/or keyboard in the UEFI-BIOS, the UEFI-BIOS menus are real clean, clear, and helpful, etc. I will tell you, though, that on occasion, gremlins have entered my computer, and I have encountered what you are dealing with: making changes to UEFI-BIOS boot settings (directly in the UEFI-BIOS or by using efibootmgr commands), re-booting, and they are gone and/or changed the wrong way! So I change again and re-boot again, etc.

[jlittle]

...install more distros... I use BTRFS...

If your installed distros come and go, problems booting can easily happen because installers, release upgrades, and grub do things behind the scenes.

Firstly,

I can run the commands in your tutorial and it all looks fine but then when I reboot all the changes are wiped.

What commands are those? In Linux the efibootmgr command is the easiest to work with; you may have to install it. Using the UEFI firmware to manipulate the ESP is slow, and can be buggy, especially for motherboards made soon after the transition to UEFI. (My 2015-ish Gigabyte UEFI is such.) If you are using efibootmgr, and the UEFI is overwriting what you set up, that sucks. Maybe there's a security setting in the UEFI for that. If you have secure boot on because you need to boot windows 10 I'd expect this kind of trouble.

...when I update grub...

The last time I looked carefully, earlier this year, the update-grub command doesn't do anything to the ESP, it just builds a new /boot/grub/grub.cfg. It's grub-install that puts entries in the ESP. grub-install is run at install time, but also behind the scenes by package managers if a new version or bug fix to grub arrives. If you've got, say, 3 installs you keep updated, and there's a security fix for grub, each install will update the ESP.

I suggest that taking control away from the installs is the way to stop various installation and package manager scripts mucking around with your boot. Also, getting some BTRFS flexibility is good. (I assume here that you're familiar with BTRFS, and how to set up multiple installs in the same BTRFS.) Here's what I do, with secure boot turned off:

• Mount the top level of the BTRFS somewhere. I use /mnt/top. I find this generally useful, and have an /etc/fstab entry in my main install to do this, but a simple sudo mount is quick to type, with no subvol option. Also mount the ESP, if it's not already; *buntus normally do this on /boot/efi.
• Make a separate subvolume just for grub, and install grub to it:

  $ sudo btrfs su cr /mnt/top/@grub
  $ sudo grub-install --boot-directory=/mnt/top/@grub/boot --efi-directory=/boot/efi

  (I manually maintain the grub.cfg there, it's much simpler than the generated one, but that's not necessary, I can copy a new grub.cfg to @grub/boot if it's changed.) Then, I can snapshot and backup grub, and other BTRFS goodness.
• Make my own copy of the EFI executable, and set up a boot entry for it (sdc is my main OS drive):

  $ cd /boot/efi/EFI/ubuntu
  $ sudo cp grubx64.efi mygrubx64.efi
  $ sudo efibootmgr -c -d /dev/sdc -l '\EFI\ubuntu\mygrubx64.efi' -L mine

  That makes "mine" the default entry. On my system it is Boot0001, or 1 for short. Now the installs can update grubx64.efi all they like.
• Sometimes, a grub update in some install will change the default entry, but I can still see "mine" in the UEFI boot list, and after booting I can use efibootmgr to reset the default back to "mine":

  $ sudo efibootmgr -o 1,0

[Bings]

I do not know anything about how BTRFS might come into play here or make any difference. Can you access your ESP partition and see what is actually in there? See the folders and their contents? Do you have a clear ESP partition (you know, 200-500 MB, FAT32, set the boot flag on the ESP partition, it can be any partition but for convenience is often sda1, etc.).

I can't access my ESP, no but here's the disk where it is.

sdc      8:32   0 465.8G  0 disk 
├─sdc1   8:33   0    34M  0 part /boot/efi
├─sdc2   8:34   0   200G  0 part /home
└─sdc3   8:35   0 265.7G  0 part

I'll have a go at repeated tries on the efibootmgr.

What commands are those? In Linux the efibootmgr command is the easiest to work with; you may have to install it. Using the UEFI firmware to manipulate the ESP is slow, and can be buggy, especially for motherboards made soon after the transition to UEFI. (My 2015-ish Gigabyte UEFI is such.) If you are using efibootmgr, and the UEFI is overwriting what you set up, that sucks. Maybe there's a security setting in the UEFI for that. If you have secure boot on because you need to boot windows 10 I'd expect this kind of trouble.

I tried to make a new entry for my Kubuntu as a test using

sudo efibootmgr -c -d /dev/sdg1 -p 10 -L Kubuntu -l \\EFI\\ubuntu\\grubx64.efi

It added it into the list properly when I typed to list the entries but it was gone after reboot. I then found a Windows program to do it and that worked so I guess that it's a permission problem of some sort. I do have secure boot on for Windows 10 yes.

The last time I looked carefully, earlier this year, the update-grub command doesn't do anything to the ESP, it just builds a new /boot/grub/grub.cfg. It's grub-install that puts entries in the ESP. grub-install is run at install time, but also behind the scenes by package managers if a new version or bug fix to grub arrives. If you've got, say, 3 installs you keep updated, and there's a security fix for grub, each install will update the ESP.

It's odd, when there is an update that needs to change grub (like kernels) it just goes black at the grub screen next restart and I have to change around the ubuntu entries in the bios. I also can't edit the bios and now i think of that, this is going to throw a spanner in my adding btrfs OS to the menu.

I suggest that taking control away from the installs is the way to stop various installation and package manager scripts mucking around with your boot. Also, getting some BTRFS flexibility is good. (I assume here that you're familiar with BTRFS, and how to set up multiple installs in the same BTRFS.) Here's what I do, with secure boot turned off:

I know that it's possibly to have multiple installs in the same partition, thanks to Oshunlvr's tutorials but I've not done it in practice. All I know is that BTRFS doesn't come up in Os-prober so I need to add the grub entry manually. Which is fine, if I can do it but now I am not sure whether I am going to be able to without figuring out what the problem is.

[jlittle]

I can't access my ESP...

That suggests it's not mounted. Maybe it's moved or changed since Kubuntu was installed; usually the install sets up an entry in /etc/fstab looking something like this:

# /boot/efi was on /dev/sdc1 during installation
UUID=ACA6-B7BC                              /boot/efi   vfat    umask=0000                           0       1

You could run sudo blkid and check the UUID for /dev/sdc1. Or, when you want to access it, sudo mount -o umask=0000 /dev/sdc1 /boot/efi

BTW, I dislike UUIDs, I find them confusing and error-prone; maybe your system has met with some error. I use labels, and my fstab entry for the ESP is

LABEL=EFI      /boot/efi   vfat    umask=000,noauto,noatime,user        0       1

Of course, with labels one has to make sure devices have suitable labels, and setting them can be obscure.

I do have secure boot on for Windows 10 yes

That has consequences for grub that I'm not familiar with, and how grub copes has changed over the years. I expect my methods would struggle.

[Bings]

sudo mount -o umask=0000 /dev/sdc1 /boot/efi
mount: /boot/efi: /dev/sdc1 already mounted on /boot/efi.
cd /boot/efi
bash: cd: /boot/efi: Permission denied

It's a permission issue rather than a mount issue

I can access it with midnight commander though.

[jlittle]

Maybe the ESP partition has been mounted without the umask=0000 option, or /boot has restrictive permissions. If I recall correctly (I'm not sure because I don't hesitate to change things), a vanilla install has 755, rwxr-xr-x permission on /boot, allowing anyone to access /boot/efi, and umask=0000 in /etc/fstab for the ESP mount, allowing anyone to access and change the ESP.
You could run

$ ls -ld /boot 
$ mount | grep sdc1

to see what the permissions are. IMO the first should say something like "drwxr-xr-x 1 root root 538 Mar 24 22:27 /boot" and the second something like "/dev/sdc1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,io charset=iso8859-1,shortname=mixed,errors=remount-ro)".

If the /boot permissions say rwx------ you could fix that with sudo chmod ugo+rx /boot.

If the mount of /dev/sdc1 has something like fmask=0777,dmask=0077 you could fix that (temporarily) with

$ sudo umount /dev/sdc1
$ sudo mount /dev/sdc1 /boot/efi -o umask=0000

then you should be able to navigate in the ESP. To change the mount after the next boot, you'd need to edit the /etc/fstab entry.

HTH, and that it's relevant to your system.