[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33517: Problem booting when using btrfs subvolume for /gnu/store
From: |
Christopher Baines |
Subject: |
bug#33517: Problem booting when using btrfs subvolume for /gnu/store |
Date: |
Sat, 01 Dec 2018 17:48:04 +0000 |
User-agent: |
mu4e 1.0; emacs 26.1 |
Ludovic Courtès <address@hidden> writes:
> Hello,
>
> Christopher Baines <address@hidden> 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"))
I guess one approach for dealing with this would be to allow directly
configuring the stripping of the mount point somehow. Or maybe having
some btrfs-file-system record, which could store the subvol option in a
more machine readable way.
One thing that still makes me uncertian, is how grub actually is trying
to find files on the btrfs filesystem. I tried changing the default
subvolume to the one containing the store, but that didn't seem to
help. Looks like it might not be aware of subvolumes.
signature.asc
Description: PGP signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#33517: Problem booting when using btrfs subvolume for /gnu/store,
Christopher Baines <=