grub: Allow setting the boot root explicitly

[shlevy]

If /boot is a btrfs subvolume, it will be on a different device than / but not be
at the root from grub's perspective. This should be fixed in a nicer way by #2449,
but that won't make it into 14.04

[shlevy]

cc @edolstra

[edolstra]

Uh, isn't install-grub.pl supposed to discover this automatically already?

my $bootRoot = "/boot";
if (stat("/")->dev != stat("/boot")->dev) {
    $bootRoot = "";
    $copyKernels = 1;
} elsif (stat("/boot")->dev != stat("/nix/store")->dev) {
    $copyKernels = 1;
}

[shlevy]

As I said in the commit message, if /boot is on a subvolume it will have a different device than / but from grub's perspective its files won't be at the root of the device.

[edolstra]

I don't understand. Isn't that exactly what this code handle? It detects that /boot is on a different device than / and adjusts the root accordingly.

[shlevy]

It sets the root to "", which is wrong. For example, suppose /boot is a btrfs subvolume boot. The current script will see that /boot and / are on different devices and set the root to "" and thus for example say in the config that the kernels live in /kernels/whatever. But from grub's perspective, the files are actually at /boot/kernels/whatever (well technically (hd0)/boot/kernels/whatever) and so the system doesn't boot.

[shlevy]

Setting root to "" is the reasonable thing to do in a world without subvolumes, since if / and /boot are not the same device /boot must be a mount point.

Well I suppose bind-mounted /boot would have the same problem.

[edolstra]

I see. Still, install-grub should be able to figure this out automatically, right? I.e., see that /boot is a subvolume (or bind mount), and then take the absolute path on the parent volume.

[shlevy]

Sure, that's done by #2449 . If we're OK with backporting that to 14.04 that's fine, I just wanted to do the quickest thing that worked to avoid breakage.

[edolstra]

Well, we've never claimed that 14.04 supports having /boot on ZFS, so I don't think we should add ad-hoc options for that...

[shlevy]

Without this we can't use 14.04 for our systems as we've planned them, and install-grub is not practically overrideable. What exactly is the problem with adding features to the stable release if they're sure not to affect existing use cases?

[shlevy]

(setting aside that it isn't even released yet...)

[bluescreen303]

Eelco Dolstra notifications@github.com writes:

Well, we've never claimed that 14.04 supports having /boot on ZFS, so
I don't think we should add ad-hoc options for that...

This has nothing to do with ZFS. In-kernel btrfs has subvolumes too :)

---

Reply to this email directly or view it on GitHub:
#2456 (comment)

[edolstra]

Well, we never said we support booting from btrfs either ;-)

However, I guess we can merge this, since we can remove this option once #2449 is in.

[shlevy]

Fixed by e4630c1 in master, ccea12c in 14.04