Problem booting when using btrfs subvolume for /gnu/store

DoneSubmitted by Christopher Baines.
Details
5 participants
  • Svante v. Erichsen
  • david.larsson
  • Ludovic Courtès
  • Christopher Baines
  • Maxim Cournoyer
Owner
unassigned
Severity
normal
C
C
Christopher Baines wrote on 26 Nov 2018 21:27
(address . bug-guix@gnu.org)
87mupva8j5.fsf@cbaines.net
I'm loosing track of this issue a bit, as I've been dealing with it fora while. I have a machine that I've setup where /gnu/store is a btrfssubvolume. I do this so that I can make flexible use of the space onthat btrfs filesystem.
Unfortunately, the grub configuration generated for this doesn't seem toaccount 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, thenthe generated grub configuration would be fine.
--- gnu/bootloader/grub.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Toggle diff (15 lines)diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scmindex 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 whenyou actually want to strip the mount point off so that grub can find theright files.
I'm creating a bug for this, as I think it would be good to track theissue. I've also written a system test that I believe reproduced theissue.
From 7eee5685f95d0b6baeb97f5fdd947fe5223a61c9 Mon Sep 17 00:00:00 2001From: Christopher Baines <mail@cbaines.net>Date: Fri, 26 Oct 2018 18:48:32 +0100Subject: [PATCH] WIP Btrfs store subvolume test
--- gnu/tests/install.scm | 91 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 90 insertions(+), 1 deletion(-)
Toggle diff (109 lines)diff --git a/gnu/tests/install.scm b/gnu/tests/install.scmindex 4764ffffde..cfa071187c 100644--- a/gnu/tests/install.scm+++ b/gnu/tests/install.scm@@ -43,7 +43,8 @@ %test-separate-home-os %test-raid-root-os %test-encrypted-os- %test-btrfs-root-os))+ %test-btrfs-root-os+ %test-btrfs-root-with-store-subvolume-os)) ;;; Commentary: ;;;@@ -826,4 +827,92 @@ build (current-guix) and then store a couple of full system images.") (command (qemu-command/writable-image image))) (run-basic-test %btrfs-root-os command "btrfs-root-os"))))) + +;;;+;;; Btrfs root file system with store subvolume.+;;;++(define-os-with-source (%btrfs-root-with-store-subvolume-os+ %btrfs-root-with-store-subvolume-os-source)+ ;; The OS we want to install.+ (use-modules (gnu) (gnu tests) (srfi srfi-1))++ (operating-system+ (host-name "liberigilo")+ (timezone "Europe/Paris")+ (locale "en_US.UTF-8")++ (bootloader (bootloader-configuration+ (bootloader grub-bootloader)+ (target "/dev/vdb")))+ (kernel-arguments '("console=ttyS0"))+ (file-systems (cons* (file-system+ (device (file-system-label "my-root"))+ (mount-point "/")+ (type "btrfs"))+ (file-system+ (device (file-system-label "my-root"))+ (mount-point "/gnu/store")+ (type "btrfs")+ (options "subvol=/gnu/store"))+ %base-file-systems))+ (users (cons (user-account+ (name "charlie")+ (group "users")+ (home-directory "/home/charlie")+ (supplementary-groups '("wheel" "audio" "video")))+ %base-user-accounts))+ (services (cons (service marionette-service-type+ (marionette-configuration+ (imported-modules '((gnu services herd)+ (guix combinators)))))+ %base-services))))++(define %btrfs-root-with-store-subvolume-installation-script+ ;; Shell script of a simple installation.+ "\+. /etc/profile+set -e -x+guix --version++export GUIX_BUILD_OPTIONS=--no-grafts+ls -l /run/current-system/gc-roots+parted --script /dev/vdb mklabel gpt \\+ mkpart primary ext2 1M 3M \\+ mkpart primary ext2 3M 2G \\+ set 1 boot on \\+ set 1 bios_grub on+mkfs.btrfs -L my-root /dev/vdb2+mount /dev/vdb2 /mnt+btrfs subvolume create /mnt/home+mkdir /mnt/gnu+btrfs subvolume create /mnt/gnu/store+herd start cow-store /mnt+mkdir /mnt/etc+cp /etc/target-config.scm /mnt/etc/config.scm+guix system build /mnt/etc/config.scm+guix system init /mnt/etc/config.scm /mnt --no-substitutes+sync+reboot\n")++(define %test-btrfs-root-with-store-subvolume-os+ (system-test+ (name "btrfs-root-with-store-subvolume-os")+ (description+ "Test basic functionality of an OS installed like one would do by hand.+This test is expensive in terms of CPU and storage usage since we need to+build (current-guix) and then store a couple of full system images.")+ (value+ (mlet* %store-monad+ ((image (run-install+ %btrfs-root-with-store-subvolume-os+ %btrfs-root-with-store-subvolume-os-source+ #:script+ %btrfs-root-with-store-subvolume-installation-script))++ (command (qemu-command/writable-image image)))+ (run-basic-test %btrfs-root-with-store-subvolume-os+ command+ "btrfs-root-with-store-subvolume-os")))))+ ;;; install.scm ends here-- 2.19.2
It would be good if a way could be found to make this "just work". Ijust don't know whether the best way to do that is tweaking the way Guixgenerates the grub configuration to be aware of the odd mounting, orsomehow making grub find things in the subvolume, or something else.
Thanks,
Chris
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAlv8V05fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE9Xdlog//WFBd/LdzhI11lOnfHmS4uVxoAGC5MzZJ6nvThjzrZLxmPVbezYTOnU271ye73COsNLFD9I+YO30PcTxXz5fJbe0oOELrHIbb/dfk4tJ3vpR6M3kiWu6DRs2eNr4+g6KS65oPAgyTp2O3t3NPAWC0pLlSx644ABu1IoGr7/EgsPuZ4F536nNw51zOWXvgGFgRtKsYjTR6AWS3AJF1zxcVW2H6Kr5U6cSSUXjZ5CspgKi9QbAH5ftew/Rc15wxdrrO8z5F+wR5LVnoTDL5r/0LmHHlNoqvIz4cA/R33SpJkSWiscXGg9gwzfQJFDMGv/szhIYBXgknAvZSvJJl1NtA+UrmjG4dYXmPPabljyR1giJJhmh4VD6uuspALXpzTQi9jH6+Mc2FGxFcQ+WdRFuAq9tc9awv2NJKXIufQnOLTLgNbJspP1/jcGEUPfCjC4iCQcYvAJha1jkxfV9U4uVO7wNLZtM1UtXV4Gy47uFH+R2BruTTFqsNB5Tmq6aUkCRtF/hYZiL/bs5IvK9V43vodpKM8Hf7jxyMmipb+dXaNsCAZgxKzBFmVb8bU7oYe40Md0cd3SrlZVju0B61KZPe3i0DW9qh0TVODscKUVd3GCGAOOyNXk3rlyZbKqNX05l3HFAR1QsSZkLYdkz5vrCuLkqjKKjxVB7ZwI7Xz4Wdt7g==wgZK-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 28 Nov 2018 14:21
(name . Christopher Baines)(address . mail@cbaines.net)(address . 33517@debbugs.gnu.org)
87zhtt49sk.fsf@gnu.org
Hello,
Christopher Baines <mail@cbaines.net> skribis:
Toggle quote (40 lines)> 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 coulddetermine whether we actually need to strip the mount point?
Thanks,Ludo’.
C
C
Christopher Baines wrote on 1 Dec 2018 18:48
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 33517@debbugs.gnu.org)
875zwdqgtn.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (11 lines)> Hello,>> Christopher Baines <mail@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 thestore. 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 directlyconfiguring the stripping of the mount point somehow. Or maybe havingsome btrfs-file-system record, which could store the subvol option in amore machine readable way.
One thing that still makes me uncertian, is how grub actually is tryingto find files on the btrfs filesystem. I tried changing the defaultsubvolume to the one containing the store, but that didn't seem tohelp. Looks like it might not be aware of subvolumes.
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAlwCyVRfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE9XcZHBAAsQblOAw+xOoJP7tJhh1e+Zjf+Ky1lCIhNN7OMrgMmam3ziBhX2fi5XZi2TiyoNrqnPouQ+aigRVT51HONe84nrw/9Yu/56s2FVHhmAoUlS1Dw9AOc0agH6D2GDQVty51NSh3C0yYcInPxvb5TAuk+QmzLb7A2iqJRiHI7h8THCUrB8SjdwBcC0YcqeNkG5JVokAHXmymgiTHTRQjvtfV9uE+QGYHeRV7lB4Vxn/YUWQtJPoWiajFvH3ighO0Xcwryl9WjGUbHogKsKhqdhcfrpLKg87svzpU8GUDjzG2w35FC8fDkKJonF+dxnkAgGq8jDCryMAb7qwNxKRXAkVaqmQmtHenMxt9/Xfuo24/kz1fXLcOE9M92dKt4uVFQ2quPyFJdxd1VZewe1vR9HEhiIwboCvgV0T1yGitGapJ1qXjJJKi+hNbg0P8HHhDLUYsfPiB+AGkjaIle2ylDuy6M4y5wBfUcJgvnOXBouT78cEHU+38AVmFPM8ljgaccJ4hTySkjH/yORKSakpu+3wWAv6FRxwRyVkLw8uC4fsmRfNXqQWTKlvlHmYf23aWrPtIse5U8ej9afkUFcLDjN+GVBPKZAl6XKO1q7KZfd0bDnNZJdRTXqWTEhVVIY84LTVryYnpF86nAtWfFG+yUQlJARVXyk1utlDRTUxQHrBieqc==LD+E-----END PGP SIGNATURE-----
S
S
Svante v. Erichsen wrote on 27 Jan 2019 00:59
Problem booting when using btrfs subvolume for /gnu/store
(address . 33517@debbugs.gnu.org)
20190126235945.GP9163@krustig.localdomain
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 itjust 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 beprepended (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-systementry, 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 thiswould work for subvols, while using a string doesn't, especially when some olderdocumentation/blogs/gists is still hanging around on the internet, so maybe itwould 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 patchwill take me some time.
Do you think this is sensible?

-- Svante von Erichsen
GPG fingerprint: A78A D4FB 762F A922 A495 57E8 2649 9081 6E61 20DE
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEp4rU+3YvqSKklVfoJkmQgW5hIN4FAlxM9GsACgkQJkmQgW5hIN40jA//U1RLVPOBXIhvNKUTs5R313VDa1KwPooWyBHjkoHnw8eZ9+/BsPiKIcoQPaEseDK66NpctxjBW8TMHV3xVfVF6kloNJuMLvDnfCXUCTfIGzaqH+4VoHSn6TnVqBNOsfeP3misebz8tySrJq44NzD/qy1fVZ+D8HUiei9QBkor/x8VbBF7WuDFiAAu2QJlHGsrIGi8aPGZX4suEynDQKvPMUMaALpKE7WveH1ilS9mkWNv7TV/rFngLfaneXPbb82AHMKvmT5PIZ1gfgxhLMXGxFbwCfmqSIpBHPsZg3bHrVGEHVVNgvBzSlGjAWc64QdTXVX38HcDG5DCnyXD4GY7gon0OQ1VzKKY6wMrkrXnJsXQ4fPRbjIHRtiEkQ81BpjjRu4mwxoApLGAbONkEPYy5tp8ea9FUBfaMqHHjFjWv1o9wfnm1hNrL/sgj5bfreAUURFHYnOaM/B0/aGgxXjZU2kT4oEuwGpncd0lH1CsyQtJydSVK0aA+isEqKN+ZFHV+DpFJR/4hxWp2+Zf/q2GSIrlkn8DFU6ZIg7FZSeUQWOARumtDO328Kiac4OpPunm26+JG11rbRIHJkno/yKto+mOAJg+KhFeoFcrcod/Gt3/M8EgmOF0gF2xJWOM1W+vdojp2kXofTNyT8+pxAstQEl8xYiuXNZvmJ2ChhjqttE==ksF0-----END PGP SIGNATURE-----

D
D
david.larsson wrote on 3 Feb 2019 15:41
(name . Svante v. Erichsen)(address . Svante.v.Erichsen@web.de)
alpine.DEB.2.21.1902031541340.55299@Librem13v3
I also lack the experience with guile but it sounds very sensible tome. I can confirm that just fixing the grub-menu entries with thesubvol path works. I have been invoking guix system reconfigure with abash script that in the end calls a grubfix function below with thepath to each newly generated grub.cfg:
In my case the subvol is located at /snap2_rwfunction grubfix(){ sudo sed -i "s/linux\ \/gnu/linux\ \/snap2_rw\/gnu/g" "$1" sudo sed -i "s/initrd\ \/gnu/initrd\ \/snap2_rw\/gnu/g" "$1" sudo sed -i "s/--set\ \/gnu/--set\ \/snap2_rw\/gnu/g" "$1"}
Your suggestion to do this directly in config.scm sounds great.
Best regads,David L
On Sun, 27 Jan 2019, Svante v. Erichsen wrote:
Toggle quote (59 lines)> 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?>>> -- > Svante von Erichsen>> GPG fingerprint: A78A D4FB 762F A922 A495 57E8 2649 9081 6E61 20DE>
M
M
Maxim Cournoyer wrote on 6 Sep 2019 03:16
(name . Svante v. Erichsen)(address . Svante.v.Erichsen@web.de)(address . 33517@debbugs.gnu.org)
878sr2xm05.fsf@gmail.com
Hello,
"Svante v. Erichsen" <Svante.v.Erichsen@web.de> writes:
Toggle quote (53 lines)> 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 seemswe've reached the same conclusion in that the entries of initrd andkernel of the Grub configuration need to be prepended with the subvolumename in order for Grub to successfully boot from a subvolume.
My implementation differs a bit in that the subvolume name to be used inthe Grub config is parsed from the kernel argument "rootflags=" value;the reasoning being that you'd have to specify it there anyway for thekernel 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
M
M
Maxim Cournoyer wrote on 26 Sep 2019 10:04
(name . Christopher Baines)(address . mail@cbaines.net)
87ef03eb5j.fsf@gmail.com
Hi Christopher,
Christopher Baines <mail@cbaines.net> writes:
Toggle quote (24 lines)> Ludovic Courtès <ludo@gnu.org> writes:>>> Hello,>>>> Christopher Baines <mail@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 wasconfused at first why such fix should work.
Grub mounts the Btrfs partition at its 'top level'. In Btrfs, thesubvolume names appear as directories under the top level, so in yourcase not striping the mount-point amounts to prepending the subvolumename to the "real" file path location (as it has the same value as themount-point).
That means that your fix only works when mount-point == subvol.
Maxim
M
M
Maxim Cournoyer wrote on 20 May 15:31 +0200
(name . Christopher Baines)(address . mail@cbaines.net)(address . 33517-done@debbugs.gnu.org)
87h7wapwaq.fsf@gmail.com
Hello,
Christopher Baines <mail@cbaines.net> writes:
Toggle quote (8 lines)> 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.
[...]
This issue is now resolved as of commit12df6684b983507b2a73e14f45d28a71cddfb3b1 on master.
Closing!
Maxim
Closed
C
C
Christopher Baines wrote on 20 May 21:46 +0200
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 33517-done@debbugs.gnu.org)
87d06yjsnv.fsf@cbaines.net
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
Toggle quote (17 lines)> Hello,>> Christopher Baines <mail@cbaines.net> writes:>>> 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.>> [...]>> This issue is now resolved as of commit> 12df6684b983507b2a73e14f45d28a71cddfb3b1 on master.
Thanks Maxim, I'm guessing the commit that fixes this isb460ba7992a0b4af2ddb5927dcf062784539ef7b.
Chris
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAl7FiSRfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE9XeK7w/+L3Jzqs7WUpQdBJ4sNdPWKQlInAR/1djvGjLLaNTgjF7lNVYsKoZLtfPL8qgWrgUCAHY9W1J63B9f+ngpfoXKkp15qqQpbzbrE4fReZrx9503/d2+LlKdwKR7BkaPAOv6LOmZ+G8a/10R9KACpC725+d2hCuY4f7RgzCll58f3TcSB7WbXLwCog1p455+xMbvJKqL/wYYV8k0tER3abwp2k2YxRe5iSUg68CZGNbZ1XzcE+YiXYOTBhIwbXaTXJmitCU8m86dYe1a7vwuwzipc5a0kDsMkgmsRkI40lnh/rZ2q5lkq6S+VwrCjHwxYxWsEWS1eXNLDJfhaHyTznnI5f3C50uGI5fRQdzyCkptE/PQmekvN2tjrmpErU8oSnJBT5LWaMWopX4gtlVtj+0lRw9yN4HI0kRBq1L7tvXqUASa6Y4glgXQbVPGy9TUFwrNlj9QiKOMOmRyWheM6FAlVAGAcUFMTTELk03ml8i11fDuQMZQFe7QoOS1HnlLjV0I8tp4r0YFL+CTdI2cNV1EPrC61TB0n6rqlCyalVcxth8ytlnWMBsNiBDrSIw42+HdETBY9giTWXrrdEO8ln05411EhQb1tmjDajGXsmUXqrEPEHfWdyVzFnydW/viIlY/YM0JUPwuc/kbhmlcr2/xTsE3tvMt8wbYNS/Z9VKVDR4==swZi-----END PGP SIGNATURE-----
Closed
M
M
Maxim Cournoyer wrote on 21 May 03:34 +0200
(name . Christopher Baines)(address . mail@cbaines.net)(address . 33517-done@debbugs.gnu.org)
87d06yoyul.fsf@gmail.com
Hi Christopher,
Christopher Baines <mail@cbaines.net> writes:
Toggle quote (24 lines)> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:>>> Hello,>>>> Christopher Baines <mail@cbaines.net> writes:>>>>> 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.>>>> [...]>>>> This issue is now resolved as of commit>> 12df6684b983507b2a73e14f45d28a71cddfb3b1 on master.>> Thanks Maxim, I'm guessing the commit that fixes this is> b460ba7992a0b4af2ddb5927dcf062784539ef7b.>> Chris
Yes (and the two supporting commits right before this one). The one Ipointed to includes a news entry.
Maxim
Closed
?