Ubuntu/Kubuntu dual boot with btrfs on EFI systems

[valmar]

Dear All,

I have a machine where I need to setup a dual boot between Ubuntu 13.10 and Kubuntu 14.04 beta1. Both are installed on btrfs file systems (the installation went perfectly for both). The problem comes in setting up dual boot between them. When I install grub, the two EFI boot entries overwrite each other, because they both use the bootloader_id 'ubuntu'. This is apparently by design:

https://bugs.launchpad.net/ubuntu/+s...2/+bug/1077643

There are two workarounds suggested in that bug report. The first is to use one grub to boot both systems. This is not possible for me because apparently grub does not detect kernels in a btrfs subvolume (and Ubuntu, when you install it on a btrfs system, creates two subvolumes called @ and @home and installs there). Is this a bug? This does not work even for Ubuntu 13.10

The second is to set GRUB_DISTRIBUTOR to something diffferent than 'ubuntu' and force the installation in a different EFI entry. I tried to to this in Kubuntu 14.04, by setting GRUB_DISTRIBUTOR to 'kubuntu'. This however, is ignored, and an entry called 'ubuntu', which overwrites the other one, is created. Is this normal or is it a bug for which I should file a report? In Ubuntu 13.10, the GRUB_DISTRIBUTOR value is respected...

Has anyone had a similar experience?

Valerio

[oshunluvr]

This is not possible for me because apparently grub does not detect kernels in a btrfs subvolume

This is untrue. I have six hard drives, five btrfs installs, using nested multiple grubs, in all which grub detects kernels just fine.

and Ubuntu, when you install it on a btrfs system, creates two subvolumes called @ and @home and installs there). Is this a bug?

No this is a feature, and in my view the bug is no other installers have this feature. Most experienced Linux users are in the habit of having a separate /home. Ubiquity (the Ubuntu installer) is doing this for you. I requested the ability from the developers to allow the user to control names of the subvolumes at installation, but they weren't interested.

Unfortunately I cannot speak to the EFI issue as I have no experience with it. Have you tried renaming the first EFI entriy before the second install?

[valmar]

This is untrue. I have six hard drives, five btrfs installs, using nested multiple grubs, in all which grub detects kernels just fine.

Well, this does not happen for me. I mean if this was a bug, not that the subvolumes are created. I agree that having separate root and home subvolumes is excellent.

I noticed that if I, say, am in Kubuntu and mount the subvolume containing the Ubuntu /boot folder, then Kubuntu detects the kernels, but does not add them correctly to the grub menu (it does not see that they are in a subvolume).

Could the fact that grub does not see kernels in subvolumes a bug in beta1 14.04?

Valerio

[oshunluvr]

Well, this does not happen for me. I mean if this was a bug, not that the subvolumes are created. I agree that having separate root and home subvolumes is excellent.

I noticed that if I, say, am in Kubuntu and mount the subvolume containing the Ubuntu /boot folder, then Kubuntu detects the kernels, but does not add them correctly to the grub menu (it does not see that they are in a subvolume).

Could the fact that grub does not see kernels in subvolumes a bug in beta1 14.04?

Valerio

Could be and that's a fine point. I'm using 13.10 without this problem; GRUB has the ability to read btrfs subvolumes. Could be they messed up the config in 14.04 and aren't aware of it yet. Or possibly the GRUB implementation of EFI is not able to parse the btrfs subvolumes. As I said, I have no dealings with EFI yet. Since your efi configs are being over-written by each other I would say they've done a poor job handling efi. Steve Riley recommends and wrote a nice how to on using an alternate boot manager - rEFInd. You might consider trying that.

Just to illustrate how non-efi GRUB works for me: I currently have 4 installs and 3 home subvolumes on a single btrfs dual drive filesystem and two more installs on other filesystems. Each install has it's own GRUB. The default boot install acts only as a GRUB host. It's menu has custom stanzas that point at the other three installs grub menu. Each install update it's own grub menu and the grub host it's own as well. Since I keep the grub menus separate, I turn off the linux probe function for each install, otherwise they scan the entire 5TB of drives (not a quick operation as you can imagine) and put all the installs in every grub menu, which I really don't need. This makes things faster, neater, and avoids unnecessary reboots.

The one accommodation I have to undertake manually is to rename the default subvolume names so that multiple installs can reside on the same btrfs filesystem. Kubuntu defaults to @ and @home, which I change to @Kubuntu_13_10 and @Kubuntu_13_10_home before doing the next install.

[apachelogger]

I tried to to this in Kubuntu 14.04, by setting GRUB_DISTRIBUTOR to 'kubuntu'.

I haven't read the entire thread, but I would like to point out that 'kubuntu' is an explicitly handled DISTRIBUTOR value that is mapped to ubuntu. So whether you set it to 'ubuntu' or 'kubuntu' GRUB will behave exactly the same. To get non-ubuntu behavior you have to set GRUB_DISTRIBUTOR to something entirely different from *buntu and probably also debian.

GRUB_DISTRIBUTOR="mylinux" should do the trick for example.

[valmar]

GRUB_DISTRIBUTOR="mylinux" should do the trick for example.

I tried but then grub does not work any more. It boots to grub console....

[valmar]

Is it possible that I am actually booting shim and that shim has hardcoded to boot the Ubuntu entry?

[valmar]

Dear apachelogger,

Your comment was very enlightening for me. However it would seem that the EFI bootloader installed from Kubuntu always looks for an 'Ubuntu' EFI entry. If it does not find it, it falls back to grub console. If it finds it, it will boot that and I end up with the Ubuntu grub. If you read the bug report I linked:

https://bugs.launchpad.net/ubuntu/+s...2/+bug/1077643

This is by design. The correct way seems to be to add the Kubuntu kernels to the Ubuntu grub menu. Unfortunately grub (or better os-prober, does not find for me kernels in other btrfs partitions, because they are in a subvolume...

I am kind of stuck and about to give up and install another KDE distro, but not before filing a grub/os-prober bug report...

Valerio

[valmar]

Ok I filed a bug here:

https://bugs.launchpad.net/ubuntu/+s...r/+bug/1294638

Valerio

[apachelogger]

Is it possible that I am actually booting shim and that shim has hardcoded to boot the Ubuntu entry?

FWIW, if you have/had secureboot active that is entirely possible. It is also the reason why kubuntu internally gets rewired to the actual ubuntu entry. For a loader to have a valid signature it needs to have a stable id, which in essence is the directory name. So while in theory you could simply copy /boot/EFI/ubuntu to /boot/EFI/kitty and create a uefi bm entry for kitty, it will in practise often not actually load anything because your firmware refuses to start the kitty loader because the signature is invalid (points to /ubuntu, but loader is /kitty). The other option is that the kitty loader actually gets started but now relative pathing is off because the signatured loader will attempt to load stuff from /ubuntu and thus fail (from the sound of it that is what you are encountering, as the defacto result of this is that grub will fall over dead and drop to a prompt).

But as already noted, short of getting the UEFI loaders aligned such that both can start it usually is best to simply get grub to handle the actual OS selection (i.e. as it would be on a BIOS system), so the os-proper bug report is indeed the best approach here.