GNU bug report logs - #33517
Problem booting when using btrfs subvolume for /gnu/store

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Christopher Baines <mail <at> cbaines.net>
Cc: 33517 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: bug#33517: Problem booting when using btrfs subvolume for /gnu/store
Date: Thu, 26 Sep 2019 17:04:24 +0900

Hi Christopher,

Christopher Baines <mail <at> cbaines.net> writes:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hello,
>>
>> Christopher Baines <mail <at> cbaines.net> skribis:
>>
>>> 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?
>
> So, this is the file-system value that I'm using currently for the
> store. The information about subvolume is in the options value.
>
> (file-system
>   (device (uuid "84fc6b78-d7ff-45df-8659-bef44b5bf0ea"))
>   (type "btrfs")
>   (title 'uuid)
>   (mount-point "/gnu/store")
>   (needed-for-boot? #t)
>   (options "subvol=/gnu/store"))

Ah, that subvolume name explains why your fix would work.  I was
confused at first why such fix should work.

Grub mounts the Btrfs partition at its 'top level'.  In Btrfs, the
subvolume names appear as directories under the top level, so in your
case not striping the mount-point amounts to prepending the subvolume
name to the "real" file path location (as it has the same value as the
mount-point).

That means that your fix only works when mount-point == subvol.

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.