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

[Ludovic Courtès]

Hello,

Christopher Baines <address@hidden> skribis:

> I'm loosing track of this issue a bit, as I've been dealing with it for
> a while. I have a machine that I've setup where /gnu/store is a btrfs
> subvolume. I do this so that I can make flexible use of the space on
> that btrfs filesystem.
>
> Unfortunately, the grub configuration generated for this doesn't seem to
> account for this, and so it requires some tweaking to get it to boot.
>
> A long while back, I discovered I could make the following change, then
> the generated grub configuration would be fine.
>
>
> ---
>  gnu/bootloader/grub.scm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
> index 06856dd58c..c3ddc3e128 100644
> --- a/gnu/bootloader/grub.scm
> +++ b/gnu/bootloader/grub.scm
> @@ -320,8 +320,8 @@ entries corresponding to old generations of the system."
>        ;; Use the right file names for KERNEL and INITRD in case
>        ;; DEVICE-MOUNT-POINT is not "/", meaning that the store is on a
>        ;; separate partition.
> -      (let ((kernel  (strip-mount-point device-mount-point kernel))
> -            (initrd  (strip-mount-point device-mount-point initrd)))
> +      (let ((kernel kernel)
> +            (initrd initrd))
>          #~(format port "menuentry ~s {
>    ~a
>    linux ~a ~a
> --
> 2.19.2
>
>
>
> Unfortunately, it's not a proper solution, as it obviously breaks when
> you actually want to strip the mount point off so that grub can find the
> right files.

Is there a way ‘strip-mount-point’ or some higher-level code could
determine whether we actually need to strip the mount point?

Thanks,
Ludo’.