bug#33517: Problem booting when using btrfs subvolume for /gnu/store

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello,

"Svante v. Erichsen" <Svante.v.Erichsen@web.de> writes:

> The subvolume and the mount point are independent issues.
>
> For example, I have a subvolume named @ as root volume:
>
> (file-system
>   (device "/dev/mapper/hd")
>   (mount-point "/")
>   (type "btrfs")
>   (options "compress=lzo,ssd,subvol=@"))
>
> It also appears that the subvolume name must be prepended to the path as if it
> just was an ordinary directory (grub.cfg):
>
> …
>   linux /@/gnu/store/…
> …
>
> I could not yet confirm this from documentation, but it works like that for me.
> (I semi-manually edit the generated grub.cfg currently.)
>
> So, additionally to stripping the mount point, the subvolume needs to be
> prepended (grub.scm):
>
>   (let ((kernel (prepend-subvol device-subvol
>                                 (strip-mount-point device-mount-point
>                                                    kernel)))
>         (initrd (prepend-subvol device-subvol
>                                 (strip-mount-point device-mount-point
>                                                    initrd))))
>     …)
>
> This would mean that the menu-entry structure needs the subvol information.
> However, I wouldn't want to parse this from the options field in the file-system
> entry, so I'd propose allowing a list there, maybe like this:
>
> (file-system
>   (device "/dev/mapper/hd")
>   (mount-point "/")
>   (type "btrfs")
>   (options '(("compress" . "lzo")
>              "ssd"
>              ("subvol" . "@"))))
>
> On the other hand, it might be surprising that declaring the options like this
> would work for subvols, while using a string doesn't, especially when some older
> documentation/blogs/gists is still hanging around on the internet, so maybe it
> would be necessary to parse the options anyway (to this list structure).
>
> I'm lacking experience in guix and guile, so making this work and submit a patch
> will take me some time.
>
> Do you think this is sensible?

I had not seen this issue before implementing the solution, but it seems
we've reached the same conclusion in that the entries of initrd and
kernel of the Grub configuration need to be prepended with the subvolume
name in order for Grub to successfully boot from a subvolume.

My implementation differs a bit in that the subvolume name to be used in
the Grub config is parsed from the kernel argument "rootflags=" value;
the reasoning being that you'd have to specify it there anyway for the
kernel to mount the root partition correctly (for non-root partitions,
fstab (file-system fields) can take care of it alone).

If anyone wants to give it a try, it's available to review here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37305.

Maxim