Package: guix-patches;
Reported by: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Date: Thu, 5 Sep 2019 00:21:01 UTC
Severity: normal
Tags: patch
Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37305 in the body.
You can then email your comments to 37305 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Thu, 05 Sep 2019 00:21:01 GMT) Full text and rfc822 format available.Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:guix-patches <at> gnu.org.
(Thu, 05 Sep 2019 00:21:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: guix-patches <guix-patches <at> gnu.org> Subject: [PATCH] Allow booting from a Btrfs subvolume. Date: Thu, 05 Sep 2019 09:20:02 +0900
[Message part 1 (text/plain, inline)]
Hello! I'm sending this patch series to add support for booting off Btrfs subvolumes. There was some interested shown on #guix, so hopefully someone can test it on their system :-) Before this change, it wasn't possible to pass the required options to the Linux kernel as our init script would ignore them. I'm not including system tests yet, as this will take a bit more time and is starting to be a big change in itself.
[0001-bootloader-grub-Allow-booting-from-a-Btrfs-subvolume.patch (text/x-patch, attachment)]
[0002-build-initrd-Fix-write-cpio-archive-return-value.patch (text/x-patch, attachment)]
[0003-linux-boot-Fix-typo.patch (text/x-patch, attachment)]
[0004-linux-boot-Honor-rootflags-kernel-argument.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 08 Sep 2019 16:11:01 GMT) Full text and rfc822 format available.Message #8 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Christopher Baines <mail <at> cbaines.net> To: maxim.cournoyer <at> gmail.com Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH] Allow booting from a Btrfs subvolume. Date: Sun, 08 Sep 2019 17:10:11 +0100
[Message part 1 (text/plain, inline)]
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes: > Hello! > > I'm sending this patch series to add support for booting off Btrfs > subvolumes. There was some interested shown on #guix, so hopefully > someone can test it on their system :-) > > Before this change, it wasn't possible to pass the required options to > the Linux kernel as our init script would ignore them. > > I'm not including system tests yet, as this will take a bit more time > and is starting to be a big change in itself. Hey, I haven't got around to looking at this yet, but I did write a system test when I reported this bug [1], it's in the 0001-WIP-Btrfs-store-subvolume-test.patch file in the initial message [2]. Maybe you could see if that passes with your changes here? 1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33517 2: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33517#5 Chris
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 22 Sep 2019 21:44:01 GMT) Full text and rfc822 format available.Message #11 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH] Allow booting from a Btrfs subvolume. Date: Sun, 22 Sep 2019 23:43:03 +0200
Hi!
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
> I'm sending this patch series to add support for booting off Btrfs
> subvolumes. There was some interested shown on #guix, so hopefully
> someone can test it on their system :-)
>
> Before this change, it wasn't possible to pass the required options to
> the Linux kernel as our init script would ignore them.
>
> I'm not including system tests yet, as this will take a bit more time
> and is starting to be a big change in itself.
Did you have a chance to look at the system test that Chris mentioned?
> From 6858efa540d89c54ce377bfa6a6882e551cd2e56 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Sun, 14 Jul 2019 20:50:23 +0900
> Subject: [PATCH 1/4] bootloader: grub: Allow booting from a Btrfs subvolume.
>
> * gnu/bootloader/grub.scm (prepend-subvol, arguments->subvol): New procedures.
> (grub-configuration-file): Use ARGUMENTS->SUBVOL to extract the subvolume name
> from the kernel arguments, and prepend it to the kernel and initrd paths using
> the PREPEND-SUBVOL procedure.
> * tests/grub.scm: Add tests for the "arguments->subvol" procedure.
> * doc/guix.texi (File Systems, (Bootloader Configuration): Document the use of
> Btrfs subvolumes.
[...]
> +@cindex rootflags, Grub
> +@cindex Btrfs root subvolume, Grub
> +To allow using a Btrfs @emph{subvolume} for the root partition, the Grub-based
Nitpick: s/Grub/GRUB/
> --- a/gnu/bootloader/grub.scm
> +++ b/gnu/bootloader/grub.scm
> @@ -3,6 +3,7 @@
> ;;; Copyright © 2016 Chris Marusich <cmmarusich <at> gmail.com>
> ;;; Copyright © 2017 Leo Famulari <leo <at> famulari.name>
> ;;; Copyright © 2017 Mathieu Othacehe <m.othacehe <at> gmail.com>
> +;;; Copyright © 2019 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> @@ -25,6 +26,8 @@
> #:use-module (guix gexp)
> #:use-module (gnu artwork)
> #:use-module (gnu bootloader)
> + #:use-module ((gnu build linux-modules) #:select (%not-comma))
‘%not-comma’ is not a great API and not quite related to linux-modules
:-), so it’s one of the rare cases where I’d rather keep it private and
duplicate it if needed.
> +(define (arguments->subvol arguments)
> + "Return any \"subvol\" value given as an option to the \"rootflags\"
> +argument, or #f on failure."
> + (let* ((rootflags (find-long-option "rootflags" arguments))
> + (rootflags-options (and=> rootflags (cut string-tokenize <> %not-comma))))
> + (and=> rootflags-options (cut find-long-option "subvol" <>))))
Maybe rename ‘arguments->subvol’ to ‘linux-arguments-btrfs-subvolume’ or
similar?
Is “rootflags” the commonly-used name here?
> + (let* ((device (menu-entry-device entry))
> + (device-mount-point (menu-entry-device-mount-point entry))
> + (label (menu-entry-label entry))
> + (kernel (menu-entry-linux entry))
> + (arguments (menu-entry-linux-arguments entry))
> + (subvol (arguments->subvol arguments))
> + (initrd (menu-entry-initrd entry)))
> ;; Here DEVICE is the store and DEVICE-MOUNT-POINT is its mount point.
> ;; 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)))
> +
> + ;; Also, in case a subvolume name could be extracted from the "subvol"
> + ;; option given to the "rootflags" argument of the kernel, it is
> + ;; prepended to the kernel and initrd paths, to allow booting from
> + ;; a Btrfs subvolume.
> + (let ((kernel (prepend-subvol subvol (strip-mount-point
> + device-mount-point kernel)))
> + (initrd (prepend-subvol subvol (strip-mount-point
> + device-mount-point initrd))))
It might be clearer to have an explicit:
(if subvolume
#~(string-append #$subvolume …)
(strip-mount-point …))
than to hide the ‘if’ in ‘prepend-subvol’.
Regarding the interface, it’s the only time where we extract info from
the user-provided ‘kernel-arguments’ list. Usually it’s the other way
around: we have ‘file-systems’, and from that we build up the list of
kernel arguments.
Do you think it could be made to work similarly? (I’m not familiar with
Btrfs though.) That way, we wouldn’t have to parse the kernel
arguments, the user wouldn’t have to fiddle explicitly with kernel
arguments, and the end result might more easily work with all the
bootloaders.
> (define (find-long-option option arguments)
> "Find OPTION among ARGUMENTS, where OPTION is something like \"--load\".
> -Return the value associated with OPTION, or #f on failure."
> +Return the value associated with OPTION, or #f on failure. Any non-string
> +arguments are ignored."
> (let ((opt (string-append option "=")))
> - (and=> (find (cut string-prefix? opt <>)
> + (and=> (find (lambda (arg)
> + (and (string? arg)
> + (string-prefix? opt arg)))
> arguments)
> (lambda (arg)
> (substring arg (+ 1 (string-index arg #\=)))))))
Ignoring non-strings makes for a weird API IMO. :-)
I understand this is because, when using it on the host side, you may
now pass it gexps instead of strings. But perhaps that calls for a new
procedure?
> From 3a628d1e731b2857a4c964484213cce980cb596f Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Tue, 16 Jul 2019 18:09:38 +0900
> Subject: [PATCH 2/4] build: initrd: Fix "write-cpio-archive" return value.
>
> * gnu/build/linux-initrd.scm (write-cpio-archive): Really return OUTPUT on
> success, even when compression is disabled.
Good catch, go for it!
> From 49ffe9a2645252bb708995169a9f1749f3982385 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Thu, 18 Jul 2019 07:23:48 +0900
> Subject: [PATCH 3/4] linux-boot: Fix typo.
>
> * gnu/build/linux-boot.scm (mount-root-file-system): Fix typo.
LGTM!
> From b56aea9c62b015c8a8b48827f9587b1578c83af3 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Thu, 18 Jul 2019 04:59:25 +0900
> Subject: [PATCH 4/4] linux-boot: Honor "rootflags" kernel argument.
>
> * gnu/build/linux-boot.scm (mount-root-file-system): Add the optional FLAGS
> and OPTIONS arguments; and document them. Pass those to the `mount' calls.
> (boot-system): Parse the "rootflags" kernel argument, and use it when calling
> `mount-root-file-system'.
> * doc/guix.texi (Initial RAM Disk): Document the use of the "rootflags"
> argument.
We’ll have to wait for patch #1, but in the final patch set, it should
probably come before patch #1, no?
Thank you!
Ludo’.
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Wed, 12 Feb 2020 08:48:02 GMT) Full text and rfc822 format available.Message #14 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH] Allow booting from a Btrfs subvolume. Date: Wed, 12 Feb 2020 03:47:40 -0500
[Message part 1 (text/plain, inline)]
Hello Ludovic! My much delayed answer to your review are the attached, much improved patches. The new test passes and I'm already using this on one of my system successfully. Thanks for your patience, Maxim
[0001-gnu-tests-Reduce-the-time-required-to-run-the-system.patch (text/x-patch, attachment)]
[0002-gnu-linux-boot-Ensure-volatile-root-is-mounted-read-.patch (text/x-patch, attachment)]
[0003-file-systems-Add-a-file-system-device-string-procedu.patch (text/x-patch, attachment)]
[0004-gnu-linux-boot-Refactor-boot-system.patch (text/x-patch, attachment)]
[0005-file-systems-Represent-the-file-system-options-as-an.patch (text/x-patch, attachment)]
[0006-gnu-linux-boot-Honor-the-root-options-kernel-argumen.patch (text/x-patch, attachment)]
[0007-gnu-linux-boot-Filter-out-file-system-independent-op.patch (text/x-patch, attachment)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Thu, 13 Feb 2020 20:28:02 GMT) Full text and rfc822 format available.Message #17 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH V2] Allow booting from a Btrfs subvolume. Date: Thu, 13 Feb 2020 15:27:15 -0500
[Message part 1 (text/plain, inline)]
I've fixed a few problems I've found with more extensive testing. Attached is the version 2 of the patch series.
[0001-gnu-tests-Reduce-the-time-required-to-run-the-system.patch (text/x-patch, attachment)]
[0002-gnu-linux-boot-Ensure-volatile-root-is-mounted-read-.patch (text/x-patch, attachment)]
[0003-file-systems-Add-a-file-system-device-string-procedu.patch (text/x-patch, attachment)]
[0004-gnu-linux-boot-Refactor-boot-system.patch (text/x-patch, attachment)]
[0005-file-systems-Represent-the-file-system-options-as-an.patch (text/x-patch, attachment)]
[0006-gnu-linux-boot-Honor-the-root-options-kernel-argumen.patch (text/x-patch, attachment)]
[0007-gnu-linux-boot-Filter-out-file-system-independent-op.patch (text/x-patch, attachment)]
[0008-bootloader-grub-Allow-booting-from-a-Btrfs-subvolume.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Fri, 14 Feb 2020 17:23:02 GMT) Full text and rfc822 format available.Message #20 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH V2] Allow booting from a Btrfs subvolume. Date: Fri, 14 Feb 2020 18:22:26 +0100
Hi Maxim!
Great to see Btrfs support improving; many people will love that!
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
> From 3640bea548826e1c1ec9b766da1fdfe4791d7452 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Sun, 17 Nov 2019 06:01:00 +0900
> Subject: [PATCH 1/9] gnu: tests: Reduce the time required to run the system
> tests.
>
> When setting the GUIX_DEV_HACKS environment variable, the Guix package used
> inside the instrumented VMs recycles the binaries already found in the Guix
> checkout of the developer instead of rebuilding Guix from scratch. This
> brings the time required for this component from 20+ minutes down to 2-3
> minutes on an X200 machine.
>
> * gnu/packages/package-management.scm (current-guix/pre-built): New procedure.
> * build-aux/run-system-tests.scm (tests-for-channel-instance): Use it, when
> GUIX_DEV_HACKS is defined.
I understand the need, but I’d really like to avoid that; it’s too
fragile IMO.
But I have good news! First, commit
887fd835a7c90f720d36a211478012547feaead0 really improved things by
avoiding the full ‘guix’ package rebuild (and we’re only talking about
the installation tests; other tests are just fine.) Second, there are
improvements to Guile that will appear in 3.0.1/2.2.7 that make
compilation of big files roughly twice as fast.
There’s still room for improvement, but I’d rather work in those
directions. WDYT?
> From 97d8a635eba34c7cf0708e99bf77ef9bad1344bf Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Tue, 11 Feb 2020 12:57:29 -0500
> Subject: [PATCH 2/9] gnu: linux-boot: Ensure volatile root is mounted
> read-only.
>
> * gnu/build/linux-boot.scm (mount-root-file-system): Ensure MS_RDONLY is
> present among the root file system flags when VOLATILE-ROOT? is #t.
(You can drop the “gnu:” prefix.)
OK!
> From e8d6642d3597207657842c9ca4849f8660d06638 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Tue, 11 Feb 2020 23:56:45 -0500
> Subject: [PATCH 3/9] file-systems: Add a 'file-system-device->string'
> procedure.
>
> * gnu/system/file-systems.scm (file-system-device->string): New procedure.
> * gnu/system.scm (bootable-kernel-arguments): Use it.
> * gnu/system/vm.scm (operating-system-uuid): Likewise.
> * guix/scripts/system.scm (display-system-generation): Likewise.
OK!
> From 4f6e3955957beb5287e9d5a5d33b74725836e1ac Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Tue, 11 Feb 2020 14:00:06 -0500
> Subject: [PATCH 4/9] gnu: linux-boot: Refactor boot-system.
>
> The --root option can now be omitted, and inferred from the root file system
> declaration instead.
>
> * gnu/build/linux-boot.scm (boot-system): Remove nested definitions for
> root-fs-type, root-fs-flags and root-fs-options, and bind those inside the
> let* instead. Make "--root" take precendence over the device field string
> representation of the root file system.
> * doc/guix.texi (Initial RAM Disk): Document that "--root" can be left
> unspecified.
[...]
> @item --root=@var{root}
> -Mount @var{root} as the root file system. @var{root} can be a
> -device name like @code{/dev/sda1}, a file system label, or a file system
> -UUID.
> +Mount @var{root} as the root file system. @var{root} can be a device
> +name like @code{/dev/sda1}, a file system label, or a file system UUID.
> +When unspecified, the device name from the root file system of the
> +operating system declaration is used.
Oh! Does it always work? That makes me wonder why we’ve been carrying
‘--root’ and I’m not sure if I’m forgetting a good reason to do it that
way.
> (mount-essential-file-systems)
> (let* ((args (linux-command-line))
> (to-load (find-long-option "--load" args))
> - (root (find-long-option "--root" args)))
> + (root-fs (find root-mount-point? mounts))
> + (root-fs-type (or (and=> root-fs file-system-type)
> + "ext4"))
> + (root-device (and=> root-fs file-system-device))
> + (root-device-str (and=> root-device file-system-device->string))
> + ;; --root takes precedence over the 'device' field of the root
> + ;; <file-system> record.
> + (root (or (find-long-option "--root" args)
> + root-device-str))
> + (root-fs-flags (mount-flags->bit-mask
> + (or (and=> root-fs file-system-flags)
> + '())))
> + (root-fs-options (if root-fs
> + (file-system-options root-fs)
> + '()))
> + (root-options (if (null? root-fs-options)
> + #f
> + (file-system-options->str
> + root-fs-options))))
Since ‘file-system-device->string’ is lossy, I think we should do it the
other way around: convert the ‘--root’ string to a <file-system>.
Perhaps that bit can be moved to a separate procedure, like
‘root-string->file-system’.
Also, the (or … "ext4") bit doesn’t sound great, but perhaps it’ll be
unnecessary if we do with something as outlined above?
> From af61745d8b686755a5d9deb9e21c9eac624fb43e Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Wed, 25 Sep 2019 22:43:41 +0900
> Subject: [PATCH 5/9] file-systems: Represent the file system options as an
> alist.
>
> This allows accessing the parameter values easily, without having to parse a
> string.
>
> * gnu/system/file-systems.scm (<file-system>): Update the default value of the
> OPTIONS field, doc.
> (%file-system-options): Field accessor renamed from `file-system-options'.
> (file-system-options, file-system-options->string): New procedures.
> * gnu/build/file-systems.scm (mount-file-system): Adapt.
> * gnu/services/base.scm (file-system->fstab-entry): Likewise.
> * tests/file-systems.scm: New tests.
> * doc/guix.texi (File Systems): Document the modified default value of the
> 'file-system-options' field.
The main issue I see with this change is that mount(2) takes raw strings
for the options. There’s a convention to have those strings look like
“KEY1=VALUE1,KEY2=VALUE2”, but it’s just a convention.
As a rule of thumb, I’d rather have our interface be as close as
possible to the actual mount(2) interface, which means taking strings.
Now, we can surely add helper procedures to parse options that follow
the above conventions.
WDYT?
> + ;; Support the deprecated options format (a string).
> + (define (options-string->options-list str)
> + (let ((option-list (string-split str #\,)))
> + (map (lambda (param)
> + (if (string-contains param "=")
> + (apply cons (string-split param #\=))
> + param))
> + option-list)))
I think we’d want to split only on the first ‘=’ sign, meaning we should
use ‘string-index’ etc. instead of ‘string-split’.
> From 67135c925b07f2e077b4cd852e07178691a10164 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Tue, 11 Feb 2020 14:14:36 -0500
> Subject: [PATCH 6/9] gnu: linux-boot: Honor the "--root-options" kernel
> argument.
>
> * gnu/build/linux-boot.scm (boot-system): Parse the "--root-options" kernel
> argument, and use it when calling `mount-root-file-system'. Update doc.
> * doc/guix.texi (Initial RAM Disk): Document the use of the "--root-options"
> argument.
Hmm do we really need this extra option? :-)
(Also, in hindsight, I think it was a mistake to call them
‘--something’. Following the common naming convention, we should rather
call these options ‘gnu.something’.)
> From cb060af5ea56427e1fd63ced5f9c9edd3ae61f76 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Tue, 11 Feb 2020 14:27:19 -0500
> Subject: [PATCH 7/9] gnu: linux-boot: Filter out file system independent
> options.
>
> This fixes an issue where options such as "defaults", which are understood by
> the command line program "mount", are not understood by the system call of the
> same name, which is used in the initial RAM disk.
>
> * gnu/system/file-systems.scm (%file-system-independent-mount-options): New variable.
> (file-system-independent-mount-option?): New predicate.
> * gnu/build/linux-boot.scm (boot-system): Use the above predicate to filter
> out system independent mount options.
[...]
> +(define %file-system-independent-mount-options
> + ;; Taken from 'man 8 mount'.
> + '("async" "atime" "auto" "noatime" "noauto" "context" "defaults" "dev" "nodev"
> + "diratime" "nodiratime" "dirsync" "exec" "noexec" "group" "iversion"
> + "noiversion" "mand" "nomand" "_netdev" "nofail" "relatime" "norelatime"
> + "strictatime" "nostrictatime" "lazytime" "nolazytime" "suid" "nosuid"
> + "silent" "loud" "owner" "remount" "ro" "rw" "sync" "user" "nouser" "users"))
I’d rather avoid it. In general, as much as possible, I think we should
pass options to the kernel without trying to be “smart”. It’s often the
safe strategy.
WDYT?
> From 6cf2ece21683e98544f8f46675aef58d5a7231fd Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Sun, 14 Jul 2019 20:50:23 +0900
> Subject: [PATCH 8/9] bootloader: grub: Allow booting from a Btrfs subvolume.
>
> * gnu/bootloader/grub.scm (grub-configuration-file) [btrfs-subvolume-path]:
> New parameter. When it is defined, prepend its value to the kernel and
> initrd file paths.
> * gnu/bootloader/depthcharge.scm (depthcharge-configuration-file): Adapt.
> * gnu/bootloader/extlinux.scm (extlinux-configuration-file): Likewise.
> * gnu/system/file-systems.scm (btrfs-subvolume?)
> (btrfs-store-subvolume-path): New procedures.
> * gnu/system.scm (operating-system-bootcfg): Specify the Btrfs subvolume path
> of the GNU store to the `operating-system-bootcfg' procedure, using the new
> BTRFS-SUBVOLUME-PATH argument.
> * doc/guix.texi (File Systems): Add a Btrfs subsection to document the use of
> subvolumes. Document the new `properties' field of the `<file-system>'
> record.
> * gnu/tests/install.scm: Add test "btrfs-root-on-subvolume-os".
Neat!
> (define* (grub-configuration-file config entries
> #:key
> (system (%current-system))
> - (old-entries '()))
> + (old-entries '())
> + btrfs-subvolume-path)
> "Return the GRUB configuration file corresponding to CONFIG, a
> <bootloader-configuration> object, and where the store is available at
> STORE-FS, a <file-system> object. OLD-ENTRIES is taken to be a list of menu
> -entries corresponding to old generations of the system."
> +entries corresponding to old generations of the system. BTRFS-SUBVOLUME-PATH
> +may be used to specify on which subvolume a Btrfs root file system resides."
(Nitpick: s/path/file name/ :-))
It’s a bit problematic that (1) GRUB needs explicit Btrfs support, and
(2) other bootloaders will silently ignore the option, due to
#:allow-other-keys.
I don’t have a better idea, but it’d be great if Btrfs support could be
made bootloader-independent, and if it could be somewhat
not-too-btrfs-specific, if that is possible at all.
Thoughts?
> + (properties file-system-properties ; list of name-value pairs
> + (default '()))
> (location file-system-location
> (default (current-source-location))
> (innate)))
> @@ -582,4 +589,48 @@ system has the given TYPE."
> (or (string-prefix-ci? "x-" option-name)
> (member option-name %file-system-independent-mount-options))))
>
> +(define (btrfs-subvolume? fs)
> + "Predicate to check if FS, a file-system object, is a Btrfs subvolume."
> + (and-let* ((btrfs-file-system? (string= "btrfs" (file-system-type fs)))
> + (option-keys (map (match-lambda
> + ((key . value) key)
> + (key key))
> + (file-system-options fs))))
> + (find (cut string-prefix? "subvol" <>) option-keys)))
I wonder if we can avoid special support in the <file-system> API for
Btrfs.
> + (error "The store is on a Btrfs subvolume, but the \
> +subvolume name is unknown.
> +Hint: Define the \"btrfs-subvolume-path\" file system property or
> +use the \"subvol\" Btrfs file system option."))))
Rather use ‘raise’ with ‘&message’ and ‘&fix-hint’ conditions.
Pheeew, that was a long patch series!
Perhaps we can split the continuation of this thread in sizable chunks!
Thanks for working on this,
Ludo’.
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 16 Feb 2020 05:37:02 GMT) Full text and rfc822 format available.Message #23 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH V2] Allow booting from a Btrfs subvolume. Date: Sun, 16 Feb 2020 00:36:28 -0500
Hello!
Thanks for the prompt feedback.
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hi Maxim!
>
> Great to see Btrfs support improving; many people will love that!
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> From 3640bea548826e1c1ec9b766da1fdfe4791d7452 Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Date: Sun, 17 Nov 2019 06:01:00 +0900
>> Subject: [PATCH 1/9] gnu: tests: Reduce the time required to run the system
>> tests.
>>
>> When setting the GUIX_DEV_HACKS environment variable, the Guix package used
>> inside the instrumented VMs recycles the binaries already found in the Guix
>> checkout of the developer instead of rebuilding Guix from scratch. This
>> brings the time required for this component from 20+ minutes down to 2-3
>> minutes on an X200 machine.
>>
>> * gnu/packages/package-management.scm (current-guix/pre-built): New procedure.
>> * build-aux/run-system-tests.scm (tests-for-channel-instance): Use it, when
>> GUIX_DEV_HACKS is defined.
>
> I understand the need, but I’d really like to avoid that; it’s too
> fragile IMO.
>
> But I have good news! First, commit
> 887fd835a7c90f720d36a211478012547feaead0 really improved things by
> avoiding the full ‘guix’ package rebuild (and we’re only talking about
> the installation tests; other tests are just fine.) Second, there are
> improvements to Guile that will appear in 3.0.1/2.2.7 that make
> compilation of big files roughly twice as fast.
>
> There’s still room for improvement, but I’d rather work in those
> directions. WDYT?
With a little bit more love (inheriting from the Guix package from the
inferior captured at build time), I don't see the hack being any less
fragile than the Guix checkout compiled and ran with ./pre-inst-env.
There's no arguing that it *is* a hack, but:
1) Being labeled as such (GUIX_DEV_HACKS)
2) Being undocumented
3) Only being enabled explicitly (through that GUIX_DEV_HACKS
environment variable)
4) Can be reverted easily in the future when the default, clean implementation is
fast enough to obsolete it.
To me means its targeted to developers who understand the nature of the
hack and is provided without any warranty.
And while it's exciting that Guile's compilation time is going to be
improved, no compiler's going to be as efficient as "no compilation"
;-).
>> From 97d8a635eba34c7cf0708e99bf77ef9bad1344bf Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Date: Tue, 11 Feb 2020 12:57:29 -0500
>> Subject: [PATCH 2/9] gnu: linux-boot: Ensure volatile root is mounted
>> read-only.
>>
>> * gnu/build/linux-boot.scm (mount-root-file-system): Ensure MS_RDONLY is
>> present among the root file system flags when VOLATILE-ROOT? is #t.
>
> (You can drop the “gnu:” prefix.)
Done.
I never know before looking at past logs (and then sometimes it's a
mixed bag). Is there any mechanical process for selecting the right
commit prefix? :-)
> OK!
>
>> From e8d6642d3597207657842c9ca4849f8660d06638 Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Date: Tue, 11 Feb 2020 23:56:45 -0500
>> Subject: [PATCH 3/9] file-systems: Add a 'file-system-device->string'
>> procedure.
>>
>> * gnu/system/file-systems.scm (file-system-device->string): New procedure.
>> * gnu/system.scm (bootable-kernel-arguments): Use it.
>> * gnu/system/vm.scm (operating-system-uuid): Likewise.
>> * guix/scripts/system.scm (display-system-generation): Likewise.
>
> OK!
>
>> From 4f6e3955957beb5287e9d5a5d33b74725836e1ac Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Date: Tue, 11 Feb 2020 14:00:06 -0500
>> Subject: [PATCH 4/9] gnu: linux-boot: Refactor boot-system.
>>
>> The --root option can now be omitted, and inferred from the root file system
>> declaration instead.
>>
>> * gnu/build/linux-boot.scm (boot-system): Remove nested definitions for
>> root-fs-type, root-fs-flags and root-fs-options, and bind those inside the
>> let* instead. Make "--root" take precendence over the device field string
>> representation of the root file system.
>> * doc/guix.texi (Initial RAM Disk): Document that "--root" can be left
>> unspecified.
>
> [...]
>
>> @item --root=@var{root}
>> -Mount @var{root} as the root file system. @var{root} can be a
>> -device name like @code{/dev/sda1}, a file system label, or a file system
>> -UUID.
>> +Mount @var{root} as the root file system. @var{root} can be a device
>> +name like @code{/dev/sda1}, a file system label, or a file system UUID.
>> +When unspecified, the device name from the root file system of the
>> +operating system declaration is used.
>
> Oh! Does it always work? That makes me wonder why we’ve been carrying
> ‘--root’ and I’m not sure if I’m forgetting a good reason to do it that
> way.
If the documentation is accurate, it should :-), given that --root gets
written as a string to the GRUB configuration file, and that the doc
says it's possible to give it as a device name, label or UUID.
About why providing options such as --root or --root-options in the
first place; I pondered about this as well, especially after making the
file systems from operating system able to be mounted with all their
(file system independent -- more on that later) options. A reason I
came up with was that it allows to experiment at the GRUB command line
and change the root device, or perhaps the root options. One use case
would be debugging the right options to pass to a file system driver in
case of a mistake in the operating system declaration.
>
>> (mount-essential-file-systems)
>> (let* ((args (linux-command-line))
>> (to-load (find-long-option "--load" args))
>> - (root (find-long-option "--root" args)))
>> + (root-fs (find root-mount-point? mounts))
>> + (root-fs-type (or (and=> root-fs file-system-type)
>> + "ext4"))
>> + (root-device (and=> root-fs file-system-device))
>> + (root-device-str (and=> root-device file-system-device->string))
>> + ;; --root takes precedence over the 'device' field of the root
>> + ;; <file-system> record.
>> + (root (or (find-long-option "--root" args)
>> + root-device-str))
>> + (root-fs-flags (mount-flags->bit-mask
>> + (or (and=> root-fs file-system-flags)
>> + '())))
>> + (root-fs-options (if root-fs
>> + (file-system-options root-fs)
>> + '()))
>> + (root-options (if (null? root-fs-options)
>> + #f
>> + (file-system-options->str
>> + root-fs-options))))
>
> Since ‘file-system-device->string’ is lossy, I think we should do it the
> other way around: convert the ‘--root’ string to a <file-system>.
> Perhaps that bit can be moved to a separate procedure, like
> ‘root-string->file-system’.
Done!
> Also, the (or … "ext4") bit doesn’t sound great, but perhaps it’ll be
> unnecessary if we do with something as outlined above?
That bit was already there; it exists because we allow an operating
system definition to be made without any root file system (for use with
the 'guix system container' or 'guix system vm' commands IIRC). What
could be simpler would be to always require such information to be
embedded in the operating system declaration: when an interactive user
command would need to modify the root file system, it could create a new
operating-system object, inheriting from the original one.
>> From af61745d8b686755a5d9deb9e21c9eac624fb43e Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Date: Wed, 25 Sep 2019 22:43:41 +0900
>> Subject: [PATCH 5/9] file-systems: Represent the file system options as an
>> alist.
>>
>> This allows accessing the parameter values easily, without having to parse a
>> string.
>>
>> * gnu/system/file-systems.scm (<file-system>): Update the default value of the
>> OPTIONS field, doc.
>> (%file-system-options): Field accessor renamed from `file-system-options'.
>> (file-system-options, file-system-options->string): New procedures.
>> * gnu/build/file-systems.scm (mount-file-system): Adapt.
>> * gnu/services/base.scm (file-system->fstab-entry): Likewise.
>> * tests/file-systems.scm: New tests.
>> * doc/guix.texi (File Systems): Document the modified default value of the
>> 'file-system-options' field.
>
> The main issue I see with this change is that mount(2) takes raw strings
> for the options. There’s a convention to have those strings look like
> “KEY1=VALUE1,KEY2=VALUE2”, but it’s just a convention.
>
> As a rule of thumb, I’d rather have our interface be as close as
> possible to the actual mount(2) interface, which means taking strings.
>
> Now, we can surely add helper procedures to parse options that follow
> the above conventions.
>
> WDYT?
To me, it's an implementation detail that I'd rather abstract away (or
make optional, like in this patch). Just like we provide a higher level
configuration for services instead of requiring the user to input the
configuration in the native format of the tool (or allowing for both).
The idea for this format was taken from a discussion here:
http://issues.guix.info/issue/33517#3.
Are we really targeting mount(2)? The commit
9d3053819dfd834a1c29a03427c41d8524b8a7d5 (which you co-authored :-))
mentions 'man 8 mount' for the file system options. This should be
stressed in the manual, as someone attempting to pass file system
independent options (perhaps taking their options line from a previous
/etc/fstab config), could prevent the system from booting.
I mistakenly was under the impression that mount(8) was targeted, since
the main interaction I observed between a file system object and my
system was the /etc/fstab file getting produced.
Doesn't targeting mount(2) mean that it becomes impossible to give all
the options someone would possibly want to produce their /etc/fstab
file? Suppose you want the 'ro' option for one of your partition in
/etc/fstab; that wouldn't fly currently, unless I'm missing something.
It seems to me we should target mount(8), and internally translate the
file system independent mount(8) options into mount(2) flags or
vice-versa but targeting the higher level and going down makes more
sense to me.
>> + ;; Support the deprecated options format (a string).
>> + (define (options-string->options-list str)
>> + (let ((option-list (string-split str #\,)))
>> + (map (lambda (param)
>> + (if (string-contains param "=")
>> + (apply cons (string-split param #\=))
>> + param))
>> + option-list)))
>
> I think we’d want to split only on the first ‘=’ sign, meaning we should
> use ‘string-index’ etc. instead of ‘string-split’.
Good catch!
>> From 67135c925b07f2e077b4cd852e07178691a10164 Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Date: Tue, 11 Feb 2020 14:14:36 -0500
>> Subject: [PATCH 6/9] gnu: linux-boot: Honor the "--root-options" kernel
>> argument.
>>
>> * gnu/build/linux-boot.scm (boot-system): Parse the "--root-options" kernel
>> argument, and use it when calling `mount-root-file-system'. Update doc.
>> * doc/guix.texi (Initial RAM Disk): Document the use of the "--root-options"
>> argument.
>
> Hmm do we really need this extra option? :-)
It is not strictly needed but allows the user to experiment/troubleshoot
with the init RAM disk from GRUB as discussed earlier for --root. Do
you think it has enough value to be kept?
> (Also, in hindsight, I think it was a mistake to call them
> ‘--something’. Following the common naming convention, we should rather
> call these options ‘gnu.something’.)
Is this convention detailed somewhere? I haven't found it in 'Standards'.
>> From cb060af5ea56427e1fd63ced5f9c9edd3ae61f76 Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Date: Tue, 11 Feb 2020 14:27:19 -0500
>> Subject: [PATCH 7/9] gnu: linux-boot: Filter out file system independent
>> options.
>>
>> This fixes an issue where options such as "defaults", which are understood by
>> the command line program "mount", are not understood by the system call of the
>> same name, which is used in the initial RAM disk.
>>
>> * gnu/system/file-systems.scm (%file-system-independent-mount-options): New variable.
>> (file-system-independent-mount-option?): New predicate.
>> * gnu/build/linux-boot.scm (boot-system): Use the above predicate to filter
>> out system independent mount options.
>
> [...]
>
>> +(define %file-system-independent-mount-options
>> + ;; Taken from 'man 8 mount'.
>> + '("async" "atime" "auto" "noatime" "noauto" "context" "defaults" "dev" "nodev"
>> + "diratime" "nodiratime" "dirsync" "exec" "noexec" "group" "iversion"
>> + "noiversion" "mand" "nomand" "_netdev" "nofail" "relatime" "norelatime"
>> + "strictatime" "nostrictatime" "lazytime" "nolazytime" "suid" "nosuid"
>> + "silent" "loud" "owner" "remount" "ro" "rw" "sync" "user" "nouser" "users"))
>
> I’d rather avoid it. In general, as much as possible, I think we should
> pass options to the kernel without trying to be “smart”. It’s often the
> safe strategy.
Let's revisit this topic after we've sorted the mount(8) vs mount(2)
problem above.
I'll address the rest in a part 2.
Thank you for your time and patience!
Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 16 Feb 2020 11:12:01 GMT) Full text and rfc822 format available.Message #26 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: 37305 <at> debbugs.gnu.org Subject: Making system installation tests faster Date: Sun, 16 Feb 2020 12:11:47 +0100
Hi Maxim, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis: > Ludovic Courtès <ludo <at> gnu.org> writes: > >> Hi Maxim! >> >> Great to see Btrfs support improving; many people will love that! >> >> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis: >> >>> From 3640bea548826e1c1ec9b766da1fdfe4791d7452 Mon Sep 17 00:00:00 2001 >>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> >>> Date: Sun, 17 Nov 2019 06:01:00 +0900 >>> Subject: [PATCH 1/9] gnu: tests: Reduce the time required to run the system >>> tests. >>> >>> When setting the GUIX_DEV_HACKS environment variable, the Guix package used >>> inside the instrumented VMs recycles the binaries already found in the Guix >>> checkout of the developer instead of rebuilding Guix from scratch. This >>> brings the time required for this component from 20+ minutes down to 2-3 >>> minutes on an X200 machine. >>> >>> * gnu/packages/package-management.scm (current-guix/pre-built): New procedure. >>> * build-aux/run-system-tests.scm (tests-for-channel-instance): Use it, when >>> GUIX_DEV_HACKS is defined. >> >> I understand the need, but I’d really like to avoid that; it’s too >> fragile IMO. >> >> But I have good news! First, commit >> 887fd835a7c90f720d36a211478012547feaead0 really improved things by >> avoiding the full ‘guix’ package rebuild (and we’re only talking about >> the installation tests; other tests are just fine.) Second, there are >> improvements to Guile that will appear in 3.0.1/2.2.7 that make >> compilation of big files roughly twice as fast. >> >> There’s still room for improvement, but I’d rather work in those >> directions. WDYT? > > With a little bit more love (inheriting from the Guix package from the > inferior captured at build time), I don't see the hack being any less > fragile than the Guix checkout compiled and ran with ./pre-inst-env. It’s grabbing files from the working tree, with heuristics to minimize the changes in incorporating files that shouldn’t be there; I think it’s fragile. :-) It also breaks that idea that things compiled by Guix are well under control. > There's no arguing that it *is* a hack, but: > > 1) Being labeled as such (GUIX_DEV_HACKS) > 2) Being undocumented > 3) Only being enabled explicitly (through that GUIX_DEV_HACKS > environment variable) > 4) Can be reverted easily in the future when the default, clean implementation is > fast enough to obsolete it. > > To me means its targeted to developers who understand the nature of the > hack and is provided without any warranty. > > And while it's exciting that Guile's compilation time is going to be > improved, no compiler's going to be as efficient as "no compilation" > ;-). True! But still, we’d have to maintain that in the meantime and deal with any “surprising” effects it has for those using it. FWIW, when testing (gnu installer tests), I only have to rebuild “guix-system-tests.drv”, which is fast. And in fact, I can also not rebuild anything by doing: (define operating-system-with-current-guix identity) because in this particular case, I know it’s not necessary to have the current ‘guix’ package. I suppose this would also be an option in your case, when testing the Btrfs changes, no? Perhaps we should make this case more easily accessible through an environment variable? Thanks, Ludo’.
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Tue, 18 Feb 2020 13:39:02 GMT) Full text and rfc822 format available.Message #29 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 37305 <at> debbugs.gnu.org Subject: Re: Making system installation tests faster Date: Tue, 18 Feb 2020 08:37:52 -0500
Hi Ludovic,
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> Ludovic Courtès <ludo <at> gnu.org> writes:
>>
>>> Hi Maxim!
>>>
>>> Great to see Btrfs support improving; many people will love that!
>>>
>>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>>>
>>>> From 3640bea548826e1c1ec9b766da1fdfe4791d7452 Mon Sep 17 00:00:00 2001
>>>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>>>> Date: Sun, 17 Nov 2019 06:01:00 +0900
>>>> Subject: [PATCH 1/9] gnu: tests: Reduce the time required to run the system
>>>> tests.
>>>>
>>>> When setting the GUIX_DEV_HACKS environment variable, the Guix package used
>>>> inside the instrumented VMs recycles the binaries already found in the Guix
>>>> checkout of the developer instead of rebuilding Guix from scratch. This
>>>> brings the time required for this component from 20+ minutes down to 2-3
>>>> minutes on an X200 machine.
>>>>
>>>> * gnu/packages/package-management.scm (current-guix/pre-built): New procedure.
>>>> * build-aux/run-system-tests.scm (tests-for-channel-instance): Use it, when
>>>> GUIX_DEV_HACKS is defined.
>>>
>>> I understand the need, but I’d really like to avoid that; it’s too
>>> fragile IMO.
>>>
>>> But I have good news! First, commit
>>> 887fd835a7c90f720d36a211478012547feaead0 really improved things by
>>> avoiding the full ‘guix’ package rebuild (and we’re only talking about
>>> the installation tests; other tests are just fine.) Second, there are
>>> improvements to Guile that will appear in 3.0.1/2.2.7 that make
>>> compilation of big files roughly twice as fast.
>>>
>>> There’s still room for improvement, but I’d rather work in those
>>> directions. WDYT?
>>
>> With a little bit more love (inheriting from the Guix package from the
>> inferior captured at build time), I don't see the hack being any less
>> fragile than the Guix checkout compiled and ran with ./pre-inst-env.
>
> It’s grabbing files from the working tree, with heuristics to minimize
> the changes in incorporating files that shouldn’t be there; I think it’s
> fragile. :-)
Fragile or not, it's helped me getting this change tested much faster
than I could have had otherwise, which is the point of that hack :-).
Benchmarks below.
> It also breaks that idea that things compiled by Guix are well under
> control.
>
>> There's no arguing that it *is* a hack, but:
>>
>> 1) Being labeled as such (GUIX_DEV_HACKS)
>> 2) Being undocumented
>> 3) Only being enabled explicitly (through that GUIX_DEV_HACKS
>> environment variable)
>> 4) Can be reverted easily in the future when the default, clean implementation is
>> fast enough to obsolete it.
>>
>> To me means its targeted to developers who understand the nature of the
>> hack and is provided without any warranty.
>>
>> And while it's exciting that Guile's compilation time is going to be
>> improved, no compiler's going to be as efficient as "no compilation"
>> ;-).
>
> True! But still, we’d have to maintain that in the meantime and deal
> with any “surprising” effects it has for those using it.
Yeah.
> FWIW, when testing (gnu installer tests), I only have to rebuild
> “guix-system-tests.drv”, which is fast. And in fact, I can also not
> rebuild anything by doing:
>
> (define operating-system-with-current-guix identity)
>
> because in this particular case, I know it’s not necessary to have the
> current ‘guix’ package.
>
> I suppose this would also be an option in your case, when testing the
> Btrfs changes, no?
I think it is important that the 'installer' image corresponds to the
'current-guix' in my case, because it has to generate the correct GRUB
configuration file at 'guix system init' time.
Below are some analysis of the derivations triggered in different scenarios.
Without the hack:
--8<---------------cut here---------------start------------->8---
./pre-inst-env make check-system TESTS=btrfs-root-on-subvolume-os
Compiling Scheme modules...
random seed for tests: 1581852580
Computing Guix derivation for 'x86_64-linux'... \
Running 1 system tests...
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
/gnu/store/3g9bawa6c876lml0318g2knqdcv2ahv9-btrfs-root-on-subvolume-os.drv
/gnu/store/vswbrzp8ab5wz0fyzrj9j72mqcbd6c4a-installation.drv
/gnu/store/nf1wd5bgminylzvwq4mjs5293hpr1mmi-disk-image.drv
/gnu/store/45334hsl3hs5yx13x7qz1b1sc83vkbzj-module-import-compiled.drv
/gnu/store/dmi03i3jv9wwkw10fm57g7fq97kwlscf-module-import.drv
/gnu/store/4cp5pqyn554rdmv9l4vfhnw7lgasv18q-raw-initrd.drv
/gnu/store/vx147spsmrxkiy0qcmvxn341fpz4fmrv-init.drv
/gnu/store/d6ri0lh953vaksiz5h8jx681h3i35vvm-module-import-compiled.drv
/gnu/store/b0gv94llsbvrlzkxs3naz7crcv1glxy1-grub.cfg.drv
/gnu/store/gcslrfymsqsp6kqckla41zkyaa7fy9in-raw-initrd.drv
/gnu/store/m8bbfcdn1irn7a41syy9arl1yz34hbln-init.drv
/gnu/store/hbfgqnralir92slqr9hhfw8cxqrlgv06-system.drv
/gnu/store/0v4aq6yprk8az183rpdjx90jnxw3w838-parameters.drv
/gnu/store/8daaamb92bbkpdwz96a19r81f7vnk40k-gc-roots.drv
/gnu/store/f48dwgib52ciaq1nh06nhks6g7gvy7bx-system.drv
/gnu/store/4ll7vvq5wxq8c2xl8qw5dbim7nrz0yda-raw-initrd.drv
/gnu/store/mxdfkkfyy3ld6656a01z0lw7gxgjns25-init.drv
/gnu/store/72fjlv3kp75629as4bc49yp9hgf80pv7-boot.drv
/gnu/store/xra5iv1ayyiml1kvpcjg5rkrgjbzy6lb-activate.scm.drv
/gnu/store/xww4xc7rpc1bw1xk9sn6vy3hazjk1gcq-module-import-compiled.drv
/gnu/store/y8hd9wzr9ypn2pfcl5al0dckijzw36x6-shepherd.conf.drv
/gnu/store/14mdcbdyqrihnl7x8lqygncxdbsvmhv0-shepherd-file-system--home.go.drv
/gnu/store/clv6h5sxwgchw1kkf9cnafgvd5ms4p4r-shepherd-file-system--home.scm.drv
/gnu/store/zc84ngrjdvbc4kibdvzipf9sxjj50rgz-module-import-compiled.drv
/gnu/store/6cca3yng6k4zl812ysdgmj5lyw8lmwln-shepherd-file-system--gnu-store.go.drv
/gnu/store/rplp3l38j9jm0fism0ka1iqbfhx7h3ir-shepherd-file-system--gnu-store.scm.drv
/gnu/store/729f2ranwr6klr90rvrx5pfka30iwazr-shepherd-user-homes.go.drv
/gnu/store/2cadf4viazfvzlazj996vmbpq3cw1hbr-shepherd-user-homes.scm.drv
/gnu/store/7j784x4jpxqlcisikn8cin4s0n1vv7z7-shepherd-term-auto.go.drv
/gnu/store/zgz6p1mss3jwra7d4vzh1dxy9b4llnlg-shepherd-term-auto.scm.drv
/gnu/store/7n6y2ljl0gp4s568wqbj5iwdkw5hrhk6-shepherd-file-system--dev-shm.go.drv
/gnu/store/apsplfgbzzq38b5q7p06jxjn37kx74b2-shepherd-file-system--dev-shm.scm.drv
/gnu/store/qj459c7mlrls9imm1nw98lw9fgqh4yyy-shepherd-udev.go.drv
/gnu/store/78klph6xipr232a938qjhm8v4qviacvd-shepherd-udev.scm.drv
/gnu/store/z103dcbbvz3inx6ax7s966zxmy1s38hn-shepherd-file-system--dev-pts.go.drv
/gnu/store/5ss1d8nwn4dv9vb69h1iyw884b61y487-shepherd-file-system--dev-pts.scm.drv
/gnu/store/z1f6a7gfxxszaa0lm68xfl9hbglz48cw-parameters.drv
/gnu/store/vvg05l3pgkyz1rky6f2cn0d1r2i1b6yr-system.drv
/gnu/store/1k5k3kd11l3wabcc8sci8m04nvc6wllw-raw-initrd.drv
/gnu/store/51ay1gi0ajsbrgm7wy6j1njyy6pcjlzb-init.drv
/gnu/store/jjhnm39rqckl6r0jf7l43000nlydb2vj-parameters.drv
/gnu/store/wdm0acks0pzl3hiam7knffl7n6xmyvrm-boot.drv
/gnu/store/59mhndnjhsq6yspag4miv4b71rb8v683-activate.scm.drv
/gnu/store/z0ik75q9nshaik97jsigd69vriyjijgp-shepherd.conf.drv
/gnu/store/6pxsd37k5nl5viqadd57n0hah53nzcp7-shepherd-user-homes.go.drv
/gnu/store/y9rj23r1xmyb5b4fwrh75pb5yr61clvp-shepherd-user-homes.scm.drv
/gnu/store/h0xbdk4hw1i4byy8xnrnaqmlwnfgrswz-profile.drv
/gnu/store/sxdgmvfjakapmbyqmxjgvarsaaxc2mw7-profile.drv
/gnu/store/hxcadzr771dzl99kylz64d9qz2qai8wd-guix-000000000.drv
/gnu/store/95lcx1xx41p4vcwqlwli7phny6hpp8b0-guix-manual.drv
/gnu/store/9yz0spp1h158zdh8wmg2r7sspnkm0qfc-guix-translated-texinfo.drv
/gnu/store/g6ggidnpaahws37qgx15mvkhfll0ns06-guix-daemon.drv
/gnu/store/jpb2jfk00q5nh5fg3k3cf6hcyw49zz84-guix-command.drv
/gnu/store/14zcma6hkqszaab37hda736i24r41rv4-guix-module-union.drv
/gnu/store/sfzd86425cl744lr58yh877i7z5qbd68-guix-000000000-modules.drv
/gnu/store/71a40hzi2d2wdn1vjl5amfq00caqlh3m-guix-system-tests-modules.drv
/gnu/store/kc3zg69yabaglvllj4l7hzgs72v9mk26-guix-system-tests.drv
/gnu/store/5zhgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv
/gnu/store/d7df7qw5allqcm2qn75dn60wz1dg50cq-guix-system.drv
/gnu/store/ily3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv
/gnu/store/xgpy1v810xi76w8ivpfi7gg5h7vg0ska-guix-cli.drv
/gnu/store/7ih7cmbhz1p7a4m7yrgy0s2jawqc666n-guix-packages-base-modules.drv
/gnu/store/j15kzs5m07pq3nmgqr5rr47cryq8arfs-guix-system-modules.drv
/gnu/store/rhk9cknm5wbk30slzzrr52app8mfn4a2-guix-packages-modules.drv
/gnu/store/x05mz632h3ph0k9n3s5y14m51qy3k929-guix-cli-modules.drv
/gnu/store/fs2g9iin23iq4505jsxjnrjaxnxp1wzl-inferior-script.scm.drv
/gnu/store/y4hv2s267zjz2gzja3cj428a7z1dln98-profile.drv
/gnu/store/kx5h4kxkz28gahlgkxni02i0rf8558vd-boot.drv
/gnu/store/nhi2s5zcyd5frjqag4jnp7fvhzbx6kd6-activate.scm.drv
/gnu/store/qnchikcfqx8hn0a7cn45f0pnf664s0jk-shepherd.conf.drv
/gnu/store/7n4cqlsbn7hywlwssxvax6j6b57gm1q4-shepherd-user-homes.go.drv
/gnu/store/dl333r3dshzi5nb4qqrvcsp2hmk3hd9p-shepherd-user-homes.scm.drv
/gnu/store/i96lsb7shixcczc62bfadbg1g73qp38l-shepherd-udev.go.drv
/gnu/store/yv3maqmnqqpiqj2jk5ss574pzvgh9jin-shepherd-udev.scm.drv
/gnu/store/s5w901l6zl0ql800bc9cndnskqdhnsxm-shepherd-file-system--tmp.go.drv
/gnu/store/a5nb6vhs86g76ww5bmpphi398pggnga7-shepherd-file-system--tmp.scm.drv
/gnu/store/sjn7zb56x72lh6i7arkh6gpd639g7d17-shepherd-guix-daemon.go.drv
/gnu/store/rww6z6m3nz6s7h54xklwj3plylg1f0yc-shepherd-guix-daemon.scm.drv
/gnu/store/lmbja82mymwsn3kmxwfy8g7s46xac443-linux-vm-loader.drv
/gnu/store/z8y0v374himjlig4qwjisv1xa7rk7r0l-builder-in-linux-vm.drv
/gnu/store/14bw0x4dq0g262vk4pjh3dlha6x3gz0s-module-import-compiled.drv
/gnu/store/nbkfy5wjpia5y7hj1p9j5hmbv42j4zp5-module-import.drv
The following grafts will be made:
/gnu/store/qn8j1cqp2lfvghiv4sy5rps4kv2hz02y-guile3.0-git-0.3.0.drv
/gnu/store/dnl877iincgcw7lw493h5nd4llxqjw7a-libgit2-0.28.4.drv
The following profile hooks will be built:
/gnu/store/96274clz8449s7s18a91sa31d1ilmi0p-fonts-dir.drv
/gnu/store/30lvdbci7v9zqgn3nqjy1vgbpv5k4b98-ca-certificate-bundle.drv
/gnu/store/b5dspr8576n0j3vl2cjsr7zrfdp380cw-guix-package-cache.drv
/gnu/store/chjdvqjbrnb7cqla43n5rvqia5d4f4mg-fonts-dir.drv
/gnu/store/kh7wixk3i5db2ym48ddyrdbggw8ccxp8-info-dir.drv
/gnu/store/x3bp2acfy04w9r9l11w30l9z0hpsii5a-manual-database.drv
/gnu/store/bhla9fihy35pgc3bwszfxvsfjir71v88-glib-schemas.drv
/gnu/store/isb4444058amfr4sipqmffcrgisx75gs-ca-certificate-bundle.drv
/gnu/store/l8qgqaxq1xcb8jk3lqmzzrfiv8hzpna1-xdg-desktop-database.drv
/gnu/store/x0vhd98kg66pzfwffbi45f76126by816-xdg-mime-database.drv
/gnu/store/xs4k7nmrpbjsy0a5k6lsbdxc2n4i23g4-info-dir.drv
/gnu/store/zffqfc9w73sy815av7hwincbqpl7hbkr-manual-database.drv
building /gnu/store/dmi03i3jv9wwkw10fm57g7fq97kwlscf-module-import.drv...
successfully built /gnu/store/dmi03i3jv9wwkw10fm57g7fq97kwlscf-module-import.drv
building /gnu/store/9yz0spp1h158zdh8wmg2r7sspnkm0qfc-guix-translated-texinfo.drv...
^Cmake: *** [Makefile:5711: check-system] Interrupt
--8<---------------cut here---------------end--------------->8---
With the hack:
--8<---------------cut here---------------start------------->8---
./pre-inst-env make check-system TESTS=btrfs-root-on-subvolume-os GUIX_DEV_HACKS=1
Compiling Scheme modules...
random seed for tests: 1581851372
Running 1 system tests...
The following derivations will be built:
/gnu/store/l4z1363klr8a58qmm3pjzy2y5bxsr6bd-btrfs-root-on-subvolume-os.drv
/gnu/store/zlg6gxml4awbkbs2s6n1b0z3ysrqvy0h-installation.drv
/gnu/store/89vdpn33f47y0510im604snwfmbpswmm-disk-image.drv
/gnu/store/45334hsl3hs5yx13x7qz1b1sc83vkbzj-module-import-compiled.drv
/gnu/store/4cp5pqyn554rdmv9l4vfhnw7lgasv18q-raw-initrd.drv
/gnu/store/vx147spsmrxkiy0qcmvxn341fpz4fmrv-init.drv
/gnu/store/d6ri0lh953vaksiz5h8jx681h3i35vvm-module-import-compiled.drv
/gnu/store/58912rdjjk4jdv767svb2axp0llmn8ch-linux-vm-loader.drv
/gnu/store/hvcm9abi0br38plwpngqlvw1l0060fni-builder-in-linux-vm.drv
/gnu/store/14bw0x4dq0g262vk4pjh3dlha6x3gz0s-module-import-compiled.drv
/gnu/store/nbkfy5wjpia5y7hj1p9j5hmbv42j4zp5-module-import.drv
/gnu/store/shc8hzzqi40pdpip0773i2g9x2apnn0h-grub.cfg.drv
/gnu/store/gcslrfymsqsp6kqckla41zkyaa7fy9in-raw-initrd.drv
/gnu/store/m8bbfcdn1irn7a41syy9arl1yz34hbln-init.drv
/gnu/store/zifmvsbiw6x4gs15k29l1nvyzxkszafw-system.drv
/gnu/store/0v4aq6yprk8az183rpdjx90jnxw3w838-parameters.drv
/gnu/store/8daaamb92bbkpdwz96a19r81f7vnk40k-gc-roots.drv
/gnu/store/f48dwgib52ciaq1nh06nhks6g7gvy7bx-system.drv
/gnu/store/4ll7vvq5wxq8c2xl8qw5dbim7nrz0yda-raw-initrd.drv
/gnu/store/mxdfkkfyy3ld6656a01z0lw7gxgjns25-init.drv
/gnu/store/72fjlv3kp75629as4bc49yp9hgf80pv7-boot.drv
/gnu/store/xra5iv1ayyiml1kvpcjg5rkrgjbzy6lb-activate.scm.drv
/gnu/store/xww4xc7rpc1bw1xk9sn6vy3hazjk1gcq-module-import-compiled.drv
/gnu/store/y8hd9wzr9ypn2pfcl5al0dckijzw36x6-shepherd.conf.drv
/gnu/store/14mdcbdyqrihnl7x8lqygncxdbsvmhv0-shepherd-file-system--home.go.drv
/gnu/store/clv6h5sxwgchw1kkf9cnafgvd5ms4p4r-shepherd-file-system--home.scm.drv
/gnu/store/zc84ngrjdvbc4kibdvzipf9sxjj50rgz-module-import-compiled.drv
/gnu/store/6cca3yng6k4zl812ysdgmj5lyw8lmwln-shepherd-file-system--gnu-store.go.drv
/gnu/store/rplp3l38j9jm0fism0ka1iqbfhx7h3ir-shepherd-file-system--gnu-store.scm.drv
/gnu/store/729f2ranwr6klr90rvrx5pfka30iwazr-shepherd-user-homes.go.drv
/gnu/store/2cadf4viazfvzlazj996vmbpq3cw1hbr-shepherd-user-homes.scm.drv
/gnu/store/7j784x4jpxqlcisikn8cin4s0n1vv7z7-shepherd-term-auto.go.drv
/gnu/store/zgz6p1mss3jwra7d4vzh1dxy9b4llnlg-shepherd-term-auto.scm.drv
/gnu/store/7n6y2ljl0gp4s568wqbj5iwdkw5hrhk6-shepherd-file-system--dev-shm.go.drv
/gnu/store/apsplfgbzzq38b5q7p06jxjn37kx74b2-shepherd-file-system--dev-shm.scm.drv
/gnu/store/qj459c7mlrls9imm1nw98lw9fgqh4yyy-shepherd-udev.go.drv
/gnu/store/78klph6xipr232a938qjhm8v4qviacvd-shepherd-udev.scm.drv
/gnu/store/z103dcbbvz3inx6ax7s966zxmy1s38hn-shepherd-file-system--dev-pts.go.drv
/gnu/store/5ss1d8nwn4dv9vb69h1iyw884b61y487-shepherd-file-system--dev-pts.scm.drv
/gnu/store/z1f6a7gfxxszaa0lm68xfl9hbglz48cw-parameters.drv
/gnu/store/vvg05l3pgkyz1rky6f2cn0d1r2i1b6yr-system.drv
/gnu/store/1k5k3kd11l3wabcc8sci8m04nvc6wllw-raw-initrd.drv
/gnu/store/51ay1gi0ajsbrgm7wy6j1njyy6pcjlzb-init.drv
/gnu/store/jjhnm39rqckl6r0jf7l43000nlydb2vj-parameters.drv
/gnu/store/wdm0acks0pzl3hiam7knffl7n6xmyvrm-boot.drv
/gnu/store/59mhndnjhsq6yspag4miv4b71rb8v683-activate.scm.drv
/gnu/store/z0ik75q9nshaik97jsigd69vriyjijgp-shepherd.conf.drv
/gnu/store/6pxsd37k5nl5viqadd57n0hah53nzcp7-shepherd-user-homes.go.drv
/gnu/store/y9rj23r1xmyb5b4fwrh75pb5yr61clvp-shepherd-user-homes.scm.drv
/gnu/store/kammkm5z0ihjqalg0ijn69ffhdyzki47-profile.drv
/gnu/store/07kxlp8a99mvx2zidnlz6rm4ak2az8d0-guix-1.0.1-13.50299ad+.drv
/gnu/store/m9783fc7m360dk582b3mv2wgrsdz6amk-boot.drv
/gnu/store/3v1whxi5qkp9cyfc3vjpvziwc9ms7y7k-shepherd.conf.drv
/gnu/store/50halfax0zbiwpy47z6374ybh1mq1d5r-shepherd-guix-daemon.go.drv
/gnu/store/g4m4mqiz9z4yd2iwzmb6f81vidw0k4bg-shepherd-guix-daemon.scm.drv
/gnu/store/7n4cqlsbn7hywlwssxvax6j6b57gm1q4-shepherd-user-homes.go.drv
/gnu/store/dl333r3dshzi5nb4qqrvcsp2hmk3hd9p-shepherd-user-homes.scm.drv
/gnu/store/i96lsb7shixcczc62bfadbg1g73qp38l-shepherd-udev.go.drv
/gnu/store/yv3maqmnqqpiqj2jk5ss574pzvgh9jin-shepherd-udev.scm.drv
/gnu/store/s5w901l6zl0ql800bc9cndnskqdhnsxm-shepherd-file-system--tmp.go.drv
/gnu/store/a5nb6vhs86g76ww5bmpphi398pggnga7-shepherd-file-system--tmp.scm.drv
/gnu/store/nhi2s5zcyd5frjqag4jnp7fvhzbx6kd6-activate.scm.drv
The following profile hooks will be built:
/gnu/store/4j2hrilvx5rfycqs1sccd39jy5yjhxy0-xdg-mime-database.drv
/gnu/store/4rdg1bi6xxn85zq5cjqc3bdfksx14913-info-dir.drv
/gnu/store/c59p1krnc51qlbr5vnxjx6bg3rrixca4-glib-schemas.drv
/gnu/store/drf1pi6m91b6qra3p6hrknfzh7gcd51z-fonts-dir.drv
/gnu/store/fwal8vsrjzpbwljnihvv66k9ikkfx2ma-xdg-desktop-database.drv
/gnu/store/jzp4ps09ipy0kcc6ybx5967vi3xlq7aa-manual-database.drv
/gnu/store/m7yl2xvk07l37l19wp2hfbvhzl3583ji-ca-certificate-bundle.drv
building /gnu/store/45334hsl3hs5yx13x7qz1b1sc83vkbzj-module-import-compiled.drv...
process 21756 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 0.0 (normalized: 0.0)
building /gnu/store/07kxlp8a99mvx2zidnlz6rm4ak2az8d0-guix-1.0.1-13.50299ad+.drv...
^Cmake: *** [Makefile:5711: check-system] Interrupt
--8<---------------cut here---------------end--------------->8---
The diff between those two looks like:
--8<---------------cut here---------------start------------->8---
--- /tmp/ediffD0RQCf 2020-02-16 12:10:53.643411325 -0500
+++ /tmp/ediffKmWrdZ 2020-02-16 12:10:53.647411377 -0500
@@ -1,15 +1,18 @@
- /gnu/store/3g9bawa6c876lml0318g2knqdcv2ahv9-btrfs-root-on-subvolume-os.drv
- /gnu/store/vswbrzp8ab5wz0fyzrj9j72mqcbd6c4a-installation.drv
- /gnu/store/nf1wd5bgminylzvwq4mjs5293hpr1mmi-disk-image.drv
+ /gnu/store/l4z1363klr8a58qmm3pjzy2y5bxsr6bd-btrfs-root-on-subvolume-os.drv
+ /gnu/store/zlg6gxml4awbkbs2s6n1b0z3ysrqvy0h-installation.drv
+ /gnu/store/89vdpn33f47y0510im604snwfmbpswmm-disk-image.drv
/gnu/store/45334hsl3hs5yx13x7qz1b1sc83vkbzj-module-import-compiled.drv
- /gnu/store/dmi03i3jv9wwkw10fm57g7fq97kwlscf-module-import.drv
/gnu/store/4cp5pqyn554rdmv9l4vfhnw7lgasv18q-raw-initrd.drv
/gnu/store/vx147spsmrxkiy0qcmvxn341fpz4fmrv-init.drv
/gnu/store/d6ri0lh953vaksiz5h8jx681h3i35vvm-module-import-compiled.drv
- /gnu/store/b0gv94llsbvrlzkxs3naz7crcv1glxy1-grub.cfg.drv
+ /gnu/store/58912rdjjk4jdv767svb2axp0llmn8ch-linux-vm-loader.drv
+ /gnu/store/hvcm9abi0br38plwpngqlvw1l0060fni-builder-in-linux-vm.drv
+ /gnu/store/14bw0x4dq0g262vk4pjh3dlha6x3gz0s-module-import-compiled.drv
+ /gnu/store/nbkfy5wjpia5y7hj1p9j5hmbv42j4zp5-module-import.drv
+ /gnu/store/shc8hzzqi40pdpip0773i2g9x2apnn0h-grub.cfg.drv
/gnu/store/gcslrfymsqsp6kqckla41zkyaa7fy9in-raw-initrd.drv
/gnu/store/m8bbfcdn1irn7a41syy9arl1yz34hbln-init.drv
- /gnu/store/hbfgqnralir92slqr9hhfw8cxqrlgv06-system.drv
+ /gnu/store/zifmvsbiw6x4gs15k29l1nvyzxkszafw-system.drv
/gnu/store/0v4aq6yprk8az183rpdjx90jnxw3w838-parameters.drv
/gnu/store/8daaamb92bbkpdwz96a19r81f7vnk40k-gc-roots.drv
/gnu/store/f48dwgib52ciaq1nh06nhks6g7gvy7bx-system.drv
@@ -44,56 +47,24 @@
/gnu/store/z0ik75q9nshaik97jsigd69vriyjijgp-shepherd.conf.drv
/gnu/store/6pxsd37k5nl5viqadd57n0hah53nzcp7-shepherd-user-homes.go.drv
/gnu/store/y9rj23r1xmyb5b4fwrh75pb5yr61clvp-shepherd-user-homes.scm.drv
- /gnu/store/h0xbdk4hw1i4byy8xnrnaqmlwnfgrswz-profile.drv
- /gnu/store/sxdgmvfjakapmbyqmxjgvarsaaxc2mw7-profile.drv
- /gnu/store/hxcadzr771dzl99kylz64d9qz2qai8wd-guix-000000000.drv
- /gnu/store/95lcx1xx41p4vcwqlwli7phny6hpp8b0-guix-manual.drv
- /gnu/store/9yz0spp1h158zdh8wmg2r7sspnkm0qfc-guix-translated-texinfo.drv
- /gnu/store/g6ggidnpaahws37qgx15mvkhfll0ns06-guix-daemon.drv
- /gnu/store/jpb2jfk00q5nh5fg3k3cf6hcyw49zz84-guix-command.drv
- /gnu/store/14zcma6hkqszaab37hda736i24r41rv4-guix-module-union.drv
- /gnu/store/sfzd86425cl744lr58yh877i7z5qbd68-guix-000000000-modules.drv
- /gnu/store/71a40hzi2d2wdn1vjl5amfq00caqlh3m-guix-system-tests-modules.drv
- /gnu/store/kc3zg69yabaglvllj4l7hzgs72v9mk26-guix-system-tests.drv
- /gnu/store/5zhgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv
- /gnu/store/d7df7qw5allqcm2qn75dn60wz1dg50cq-guix-system.drv
- /gnu/store/ily3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv
- /gnu/store/xgpy1v810xi76w8ivpfi7gg5h7vg0ska-guix-cli.drv
- /gnu/store/7ih7cmbhz1p7a4m7yrgy0s2jawqc666n-guix-packages-base-modules.drv
- /gnu/store/j15kzs5m07pq3nmgqr5rr47cryq8arfs-guix-system-modules.drv
- /gnu/store/rhk9cknm5wbk30slzzrr52app8mfn4a2-guix-packages-modules.drv
- /gnu/store/x05mz632h3ph0k9n3s5y14m51qy3k929-guix-cli-modules.drv
- /gnu/store/fs2g9iin23iq4505jsxjnrjaxnxp1wzl-inferior-script.scm.drv
- /gnu/store/y4hv2s267zjz2gzja3cj428a7z1dln98-profile.drv
- /gnu/store/kx5h4kxkz28gahlgkxni02i0rf8558vd-boot.drv
- /gnu/store/nhi2s5zcyd5frjqag4jnp7fvhzbx6kd6-activate.scm.drv
- /gnu/store/qnchikcfqx8hn0a7cn45f0pnf664s0jk-shepherd.conf.drv
+ /gnu/store/kammkm5z0ihjqalg0ijn69ffhdyzki47-profile.drv
+ /gnu/store/07kxlp8a99mvx2zidnlz6rm4ak2az8d0-guix-1.0.1-13.50299ad+.drv
+ /gnu/store/m9783fc7m360dk582b3mv2wgrsdz6amk-boot.drv
+ /gnu/store/3v1whxi5qkp9cyfc3vjpvziwc9ms7y7k-shepherd.conf.drv
+ /gnu/store/50halfax0zbiwpy47z6374ybh1mq1d5r-shepherd-guix-daemon.go.drv
+ /gnu/store/g4m4mqiz9z4yd2iwzmb6f81vidw0k4bg-shepherd-guix-daemon.scm.drv
/gnu/store/7n4cqlsbn7hywlwssxvax6j6b57gm1q4-shepherd-user-homes.go.drv
/gnu/store/dl333r3dshzi5nb4qqrvcsp2hmk3hd9p-shepherd-user-homes.scm.drv
/gnu/store/i96lsb7shixcczc62bfadbg1g73qp38l-shepherd-udev.go.drv
/gnu/store/yv3maqmnqqpiqj2jk5ss574pzvgh9jin-shepherd-udev.scm.drv
/gnu/store/s5w901l6zl0ql800bc9cndnskqdhnsxm-shepherd-file-system--tmp.go.drv
/gnu/store/a5nb6vhs86g76ww5bmpphi398pggnga7-shepherd-file-system--tmp.scm.drv
- /gnu/store/sjn7zb56x72lh6i7arkh6gpd639g7d17-shepherd-guix-daemon.go.drv
- /gnu/store/rww6z6m3nz6s7h54xklwj3plylg1f0yc-shepherd-guix-daemon.scm.drv
- /gnu/store/lmbja82mymwsn3kmxwfy8g7s46xac443-linux-vm-loader.drv
- /gnu/store/z8y0v374himjlig4qwjisv1xa7rk7r0l-builder-in-linux-vm.drv
- /gnu/store/14bw0x4dq0g262vk4pjh3dlha6x3gz0s-module-import-compiled.drv
- /gnu/store/nbkfy5wjpia5y7hj1p9j5hmbv42j4zp5-module-import.drv
-The following grafts will be made:
- /gnu/store/qn8j1cqp2lfvghiv4sy5rps4kv2hz02y-guile3.0-git-0.3.0.drv
- /gnu/store/dnl877iincgcw7lw493h5nd4llxqjw7a-libgit2-0.28.4.drv
+ /gnu/store/nhi2s5zcyd5frjqag4jnp7fvhzbx6kd6-activate.scm.drv
The following profile hooks will be built:
- /gnu/store/96274clz8449s7s18a91sa31d1ilmi0p-fonts-dir.drv
- /gnu/store/30lvdbci7v9zqgn3nqjy1vgbpv5k4b98-ca-certificate-bundle.drv
- /gnu/store/b5dspr8576n0j3vl2cjsr7zrfdp380cw-guix-package-cache.drv
- /gnu/store/chjdvqjbrnb7cqla43n5rvqia5d4f4mg-fonts-dir.drv
- /gnu/store/kh7wixk3i5db2ym48ddyrdbggw8ccxp8-info-dir.drv
- /gnu/store/x3bp2acfy04w9r9l11w30l9z0hpsii5a-manual-database.drv
- /gnu/store/bhla9fihy35pgc3bwszfxvsfjir71v88-glib-schemas.drv
- /gnu/store/isb4444058amfr4sipqmffcrgisx75gs-ca-certificate-bundle.drv
- /gnu/store/l8qgqaxq1xcb8jk3lqmzzrfiv8hzpna1-xdg-desktop-database.drv
- /gnu/store/x0vhd98kg66pzfwffbi45f76126by816-xdg-mime-database.drv
- /gnu/store/xs4k7nmrpbjsy0a5k6lsbdxc2n4i23g4-info-dir.drv
- /gnu/store/zffqfc9w73sy815av7hwincbqpl7hbkr-manual-database.drv
-building /gnu/store/dmi03i3jv9wwkw10fm57g7fq97kwlscf-module-import.drv...
+ /gnu/store/4j2hrilvx5rfycqs1sccd39jy5yjhxy0-xdg-mime-database.drv
+ /gnu/store/4rdg1bi6xxn85zq5cjqc3bdfksx14913-info-dir.drv
+ /gnu/store/c59p1krnc51qlbr5vnxjx6bg3rrixca4-glib-schemas.drv
+ /gnu/store/drf1pi6m91b6qra3p6hrknfzh7gcd51z-fonts-dir.drv
+ /gnu/store/fwal8vsrjzpbwljnihvv66k9ikkfx2ma-xdg-desktop-database.drv
+ /gnu/store/jzp4ps09ipy0kcc6ybx5967vi3xlq7aa-manual-database.drv
+ /gnu/store/m7yl2xvk07l37l19wp2hfbvhzl3583ji-ca-certificate-bundle.drv
--8<---------------cut here---------------end--------------->8---
So, we can see there would me many guix-* things to build without the
hack.
Just building the OS using guix-current/pre-built, vs old
guix-current', vs the modern guix-current used for system tests:
guix-current/pre-built:
--8<---------------cut here---------------start------------->8---
time ./pre-inst-env guix system build -e '(begin (use-modules (gnu packages package-management)) (parameterize ((current-guix-package (current-guix/pre-built))) ((@@ (gnu tests install) operating-system-with-current-guix) (@@ (gnu tests install) %btrfs-root-on-subvolume-os))))'
[...]
real 12m23.259s
user 0m9.124s
sys 0m0.986s
--8<---------------cut here---------------end--------------->8---
old guix-current:
--8<---------------cut here---------------start------------->8---
time ./pre-inst-env guix system build -e '(begin (use-modules (gnu packages package-management)) (parameterize ((current-guix-package (current-guix))) ((@@ (gnu tests install) operating-system-with-current-guix) (@@ (gnu tests install) %btrfs-root-on-subvolume-os))))'
[...]
real 45m45.572s
user 0m10.428s
sys 0m1.279s
--8<---------------cut here---------------end--------------->8---
And with the new "guix-current", computed with (guix self):
--8<---------------cut here---------------start------------->8---
time ./pre-inst-env guix system build -e '(begin
> (use-modules ((gnu ci) #:select (channel-instance->package))
> (guix monads)
> (guix channels)
> (guix store)
> ((guix status) #:select (with-status-verbosity))
> ((guix git-download) #:select (git-predicate))
> (guix utils)
> (gnu packages package-management))
> (with-store store
> (with-status-verbosity 2
> (run-with-store store
> (mlet* %store-monad
> ((source-dir -> "/home/maxim/src/guix")
> (source (interned-file source-dir
> "guix-source"
> #:recursive? #t
> #:select? (or (git-predicate
> source-dir)
> (const #t))))
> (instance -> (checkout->channel-instance source))
> (new-guix-current -> (channel-instance->package instance)))
> (return (parameterize ((current-guix-package new-guix-current))
> ((@@ (gnu tests install) operating-system-with-current-guix)
> (@@ (gnu tests install) %btrfs-root-on-subvolume-os)))))))))'
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
The following file will be downloaded:
/gnu/store/7r7lbghps6qcl10qb6m321a3bgpr72fi-compute-guix-derivation
substituting /gnu/store/7r7lbghps6qcl10qb6m321a3bgpr72fi-compute-guix-derivation...
downloading from http://10.42.0.199/nar/gzip/7r7lbghps6qcl10qb6m321a3bgpr72fi-compute-guix-derivation...
compute-guix-derivation 124KiB/s 00:00 | 881B transferred
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
\
substitute: updating substitutes from 'http://10.42.0.199:80'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
/gnu/store/1kmbdnkdip0xbdi4h09jj44nccmpmxh6-system.drv
/gnu/store/a2dl48yn635qqbga72gwkqnypd45lxaf-profile.drv
/gnu/store/3rqfd301xgwlaacwppswdxshlc13ky7p-profile.drv
/gnu/store/2hd5a6klgq8zz22rsm3jd4wqw6cbcmbq-profile.drv
/gnu/store/hb87zw934jkgxwkgbbfykwaq55p6pzlq-guix-000000000.drv
/gnu/store/65dva2y1zq173i93z57xzffn34rmfbgw-guix-daemon.drv
/gnu/store/cjzvm56h61zhwd56g1ksi91spq567b4b-guix-command.drv
/gnu/store/flii6im368mj1mlwb1xmnvwhibll0acg-guix-module-union.drv
/gnu/store/mx5kd00k1axs9xrgwn5hibiidbxshy3g-guix-000000000-modules.drv
/gnu/store/7ih7cmbhz1p7a4m7yrgy0s2jawqc666n-guix-packages-base-modules.drv
/gnu/store/5zhgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv
/gnu/store/rhk9cknm5wbk30slzzrr52app8mfn4a2-guix-packages-modules.drv
/gnu/store/ily3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv
/gnu/store/ybxk6d3bccnz52d2s55gcang7795cy3l-guix-cli-modules.drv
/gnu/store/6mdpdsflpz3axdlifw7mqfdmzhnpzvvc-guix-cli.drv
/gnu/store/ifqlhiq9mlbcq7cy05r2da7yr2c03whl-guix-system.drv
/gnu/store/ysr4d2bqhs4c4viwyk9pvcjcnwv4pnr8-guix-system-tests-modules.drv
/gnu/store/fwr4jlsgxjxkiqn6l4dr1hfl684irmp0-guix-system-tests.drv
/gnu/store/z3mzdfm2x2jrab7g3yhcg06lrgpq2ijz-guix-system-modules.drv
/gnu/store/95lcx1xx41p4vcwqlwli7phny6hpp8b0-guix-manual.drv
/gnu/store/9yz0spp1h158zdh8wmg2r7sspnkm0qfc-guix-translated-texinfo.drv
/gnu/store/zdqspx48gmwa9xv2ibn993qfswq9zgkf-inferior-script.scm.drv
/gnu/store/ixk9m5hqwj42kdzh88vwy06alk9bw811-boot.drv
/gnu/store/jp62bqlvch38sqcqkxk3ddwih84qz8ka-shepherd.conf.drv
/gnu/store/7wkb1al9lxp5k84k9b1i5v7h69x9p3wr-shepherd-guix-daemon.go.drv
/gnu/store/5688khnjjabnh8bnn4hc41j05h1larh9-shepherd-guix-daemon.scm.drv
The following grafts will be made:
/gnu/store/qn8j1cqp2lfvghiv4sy5rps4kv2hz02y-guile3.0-git-0.3.0.drv
/gnu/store/dnl877iincgcw7lw493h5nd4llxqjw7a-libgit2-0.28.4.drv
The following profile hooks will be built:
/gnu/store/1li6nkn0p7zikf5y36ljir2n53rf81cg-fonts-dir.drv
/gnu/store/841rih0j6iskwdxvay7cm94l3vn4idl7-guix-package-cache.drv
/gnu/store/8k7vn4fbwqvlmhsv604v7zkgils5j0f4-manual-database.drv
/gnu/store/qc53qlnzwxlhlm01fxp45ppdnrzw0lfz-info-dir.drv
/gnu/store/qpcnvr43c5rl6bgpsj7l3m38r6xndz7j-ca-certificate-bundle.drv
/gnu/store/scm0rsny7n5kmryffp081hdh6rh2659l-fonts-dir.drv
/gnu/store/44wi6c2lq0mpkmx940wsi56fmxr8fjh4-ca-certificate-bundle.drv
/gnu/store/d80j7mvj59m6h33m3c72mwfckb9xrn7r-info-dir.drv
/gnu/store/x1cfgs17hpiw33fpq8gj51ldykf8wd25-manual-database.drv
building /gnu/store/9yz0spp1h158zdh8wmg2r7sspnkm0qfc-guix-translated-texinfo.drv...
Your input po file ./guix-manual.de.po seems outdated (The amount of entries differ between files: 7994 is not 8473
). Please consider running po4a-updatepo to refresh it.
Your input po file ./guix-manual.de.po seems outdated (The amount of entries differ between files: 7994 is not 281
). Please consider running po4a-updatepo to refresh it.
Your input po file ./guix-manual.es.po seems outdated (The amount of entries differ between files: 7994 is not 8473
). Please consider running po4a-updatepo to refresh it.
Your input po file ./guix-manual.es.po seems outdated (The amount of entries differ between files: 7994 is not 281
). Please consider running po4a-updatepo to refresh it.
Your input po file ./guix-manual.fr.po seems outdated (The amount of entries differ between files: 7994 is not 8473
). Please consider running po4a-updatepo to refresh it.
Your input po file ./guix-manual.fr.po seems outdated (The amount of entries differ between files: 7994 is not 281
). Please consider running po4a-updatepo to refresh it.
Your input po file ./guix-manual.ru.po seems outdated (The amount of entries differ between files: 7994 is not 8473
). Please consider running po4a-updatepo to refresh it.
Your input po file ./guix-manual.ru.po seems outdated (The amount of entries differ between files: 7994 is not 281
). Please consider running po4a-updatepo to refresh it.
Your input po file ./guix-manual.zh_CN.po seems outdated (The amount of entries differ between files: 7994 is not 8473
). Please consider running po4a-updatepo to refresh it.
Your input po file ./guix-manual.zh_CN.po seems outdated (The amount of entries differ between files: 7994 is not 281
). Please consider running po4a-updatepo to refresh it.
successfully built /gnu/store/9yz0spp1h158zdh8wmg2r7sspnkm0qfc-guix-translated-texinfo.drv
applying 2 grafts for /gnu/store/dnl877iincgcw7lw493h5nd4llxqjw7a-libgit2-0.28.4.drv...
grafting '/gnu/store/mqlwm1gfp1wz7i74z2rifv51hscl2201-libgit2-0.28.4' -> '/gnu/store/7ymrcgnz6v4x1krljh60za1fx0wz57ny-libgit2-0.28.4'...
successfully built /gnu/store/dnl877iincgcw7lw493h5nd4llxqjw7a-libgit2-0.28.4.drv
building /gnu/store/95lcx1xx41p4vcwqlwli7phny6hpp8b0-guix-manual.drv...
./guix.de.texi:2286: warning: @node name should not contain `,': Tastaturbelegung, Netzwerkanbindung und Partitionierung
./guix.de.texi:29751: warning: @node name should not contain `,': Vorbereitung, um die Bootstrap-Bin�rdateien zu verwenden
./guix.ru.texi:932: warning: accent command `@,' must not be followed by whitespace
Wide character in warn at /gnu/store/irj21yhgls637jhhkb5yr79s76c96maq-texinfo-6.6/bin/makeinfo line 656.
./guix.ru.texi:3977: warning: `.' or `,' must follow @xref, not д
successfully built /gnu/store/95lcx1xx41p4vcwqlwli7phny6hpp8b0-guix-manual.drv
applying 1 graft for /gnu/store/qn8j1cqp2lfvghiv4sy5rps4kv2hz02y-guile3.0-git-0.3.0.drv...
grafting '/gnu/store/qi80syzn4dhxbwwwlqlww5v042kfkmx3-guile3.0-git-0.3.0' -> '/gnu/store/1hapil0ym1k3cii3j95pmabgnxi7c9m0-guile3.0-git-0.3.0'...
successfully built /gnu/store/qn8j1cqp2lfvghiv4sy5rps4kv2hz02y-guile3.0-git-0.3.0.drv
process 5055 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 0.0 (normalized: 0.0)
building /gnu/store/5zhgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv...
sending 23 store items (54 MiB) to '10.42.0.199'...
exporting path `/gnu/store/c2mxnc0dvi88dq5iacq78xchlcp6f2d2-guix-packages-base-source'
exporting path `/gnu/store/d3s80rm5pyggyqk71mwrsqzqahjc8jqr-guix-packages-base-builder'
exporting path `/gnu/store/4rjdijy36w6zx99bgqlb40nawipcm4w1-libgit2-0.28.4-guile-builder'
exporting path `/gnu/store/w7xwnvv15b6s062jfaqkwnry7padw936-http-parser-2.9.3-checkout.drv'
exporting path `/gnu/store/v6p9i2alpmsldsbjnq2g46rrnn2kwvvg-http-parser-2.9.3.drv'
exporting path `/gnu/store/29l03448v04pniv0rjlmclag9ga66yj6-libgit2-0.28.4.drv'
exporting path `/gnu/store/j823iyw1c851wmmlfbb8vxyy4hcvqcdz-libgit2-0.28.4-guile-builder'
exporting path `/gnu/store/dnl877iincgcw7lw493h5nd4llxqjw7a-libgit2-0.28.4.drv'
exporting path `/gnu/store/i63fzcsg2qrzkj53ri3jglzg1jqxcg6q-guile3.0-git-0.3.0-guile-builder'
exporting path `/gnu/store/ls7zbcnzl4khfqb64nm9nd9yri1x4mwi-guile3.0-git-0.3.0-guile-builder'
exporting path `/gnu/store/rp09b776n1a98fbpy1cbw6v7np66x3b6-guile3.0-git-0.3.0.drv'
exporting path `/gnu/store/qn8j1cqp2lfvghiv4sy5rps4kv2hz02y-guile3.0-git-0.3.0.drv'
exporting path `/gnu/store/rsc33ni89kzqbjwv2drm1w7qyyqzvw8g-guix-extra-source'
exporting path `/gnu/store/0szskn0spa0gkf36p9fkrl9b4r7x67vc-guix-extra-builder'
exporting path `/gnu/store/vg4zq88aw4y1skaljyd092yricg0krj0-guix-extra.drv'
exporting path `/gnu/store/5zhgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv'
exporting path `/gnu/store/7ymrcgnz6v4x1krljh60za1fx0wz57ny-libgit2-0.28.4'
exporting path `/gnu/store/1hapil0ym1k3cii3j95pmabgnxi7c9m0-guile3.0-git-0.3.0'
exporting path `/gnu/store/32569wrdn5wfq864iz889fv3hrz0a35c-guix-extra'
exporting path `/gnu/store/bgwcdqnrb3zqs91hgm4vsxprqmnxb6z0-guix-core'
exporting path `/gnu/store/gdkb4vs4i1pbaifihdnkgvw3bklcdafq-config.scm'
exporting path `/gnu/store/grfziyz24rkbal06ba8kb6d47zhv5m8i-guix-core-source'
offloading '/gnu/store/5zhgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv' to '10.42.0.199'...
offloading build of /gnu/store/5zhgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv to '10.42.0.199'
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
@ build-started /gnu/store/5zhgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv - x86_64-linux /var/log/guix/drvs/5z//hgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv.bz2 12591
[546/546] compiling... 100.0% of 273 files
@ build-succeeded /gnu/store/5zhgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv -
retrieving 1 store item from '10.42.0.199'...
importing file or directory '/gnu/store/60yrpv6cfzl9pzw4sgawfw0b8bx679js-guix-packages-base'...
found valid signature for '/gnu/store/60yrpv6cfzl9pzw4sgawfw0b8bx679js-guix-packages-base'
done with offloaded '/gnu/store/5zhgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv'
successfully built /gnu/store/5zhgzvnyswm8g50aha95rvdx6dpmw329-guix-packages-base.drv
building /gnu/store/7ih7cmbhz1p7a4m7yrgy0s2jawqc666n-guix-packages-base-modules.drv...
process 5174 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.24 (normalized: 2.24)
waiting for locks or build slots...
successfully built /gnu/store/7ih7cmbhz1p7a4m7yrgy0s2jawqc666n-guix-packages-base-modules.drv
process 5174 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 1.97 (normalized: 1.97)
building /gnu/store/ily3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv...
sending 4 store items (5 MiB) to '10.42.0.199'...
exporting path `/gnu/store/37ljzr1akxh64fbwf7rhn5qdsxs62zh5-guix-packages-builder'
exporting path `/gnu/store/qymkn55sgl7ln68cmkp60xx4h6kckg7p-guix-packages-source'
exporting path `/gnu/store/ily3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv'
offloading '/gnu/store/ily3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv' to '10.42.0.199'...
offloading build of /gnu/store/ily3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv to '10.42.0.199'
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
@ build-started /gnu/store/ily3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv - x86_64-linux /var/log/guix/drvs/il//y3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv.bz2 12691
[422/422] compiling... 100.0% of 211 files
@ build-succeeded /gnu/store/ily3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv -
retrieving 1 store item from '10.42.0.199'...
importing file or directory '/gnu/store/d5bz30n1r7fg8xybqip2prrxmfy07jz1-guix-packages'...
found valid signature for '/gnu/store/d5bz30n1r7fg8xybqip2prrxmfy07jz1-guix-packages'
done with offloaded '/gnu/store/ily3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv'
successfully built /gnu/store/ily3pqqvfkjz5622fxz6mxg31jbiqb21-guix-packages.drv
building /gnu/store/rhk9cknm5wbk30slzzrr52app8mfn4a2-guix-packages-modules.drv...
process 5205 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.73 (normalized: 2.73)
waiting for locks or build slots...
successfully built /gnu/store/rhk9cknm5wbk30slzzrr52app8mfn4a2-guix-packages-modules.drv
process 5205 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.52 (normalized: 2.52)
process 5205 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.31 (normalized: 2.31)
process 5205 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.13 (normalized: 2.13)
process 5205 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 1.96 (normalized: 1.96)
building /gnu/store/ifqlhiq9mlbcq7cy05r2da7yr2c03whl-guix-system.drv...
sending 4 store items (2 MiB) to '10.42.0.199'...
exporting path `/gnu/store/c5f1649rxrhfdb5vfr4s6i7yb4yqhidr-guix-system-source'
exporting path `/gnu/store/nw9kr3wkgfks44wrf8zw9y0l50bnzg77-guix-system-builder'
exporting path `/gnu/store/ifqlhiq9mlbcq7cy05r2da7yr2c03whl-guix-system.drv'
offloading '/gnu/store/ifqlhiq9mlbcq7cy05r2da7yr2c03whl-guix-system.drv' to '10.42.0.199'...
offloading build of /gnu/store/ifqlhiq9mlbcq7cy05r2da7yr2c03whl-guix-system.drv to '10.42.0.199'
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
@ build-started /gnu/store/ifqlhiq9mlbcq7cy05r2da7yr2c03whl-guix-system.drv - x86_64-linux /var/log/guix/drvs/if//qlhiq9mlbcq7cy05r2da7yr2c03whl-guix-system.drv.bz2 12805
[156/156] compiling... 100.0% of 78 files
@ build-succeeded /gnu/store/ifqlhiq9mlbcq7cy05r2da7yr2c03whl-guix-system.drv -
retrieving 1 store item from '10.42.0.199'...
importing file or directory '/gnu/store/6swg1fk14gw145ihh0ml1549cdqvq9n1-guix-system'...
found valid signature for '/gnu/store/6swg1fk14gw145ihh0ml1549cdqvq9n1-guix-system'
done with offloaded '/gnu/store/ifqlhiq9mlbcq7cy05r2da7yr2c03whl-guix-system.drv'
successfully built /gnu/store/ifqlhiq9mlbcq7cy05r2da7yr2c03whl-guix-system.drv
process 5266 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 3.05 (normalized: 3.05)
building /gnu/store/z3mzdfm2x2jrab7g3yhcg06lrgpq2ijz-guix-system-modules.drv...
waiting for locks or build slots...
successfully built /gnu/store/z3mzdfm2x2jrab7g3yhcg06lrgpq2ijz-guix-system-modules.drv
process 5266 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.81 (normalized: 2.81)
process 5266 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.58 (normalized: 2.58)
process 5266 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.37 (normalized: 2.37)
process 5266 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.18 (normalized: 2.18)
process 5266 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.01 (normalized: 2.01)
process 5266 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 1.85 (normalized: 1.85)
building /gnu/store/6mdpdsflpz3axdlifw7mqfdmzhnpzvvc-guix-cli.drv...
sending 4 store items (1 MiB) to '10.42.0.199'...
exporting path `/gnu/store/nlrwldyvnmbih5qzcv8xhby5jcnnr5gn-guix-cli-source'
exporting path `/gnu/store/z8dgrdv8vqxwn2p8480q6x5fwiyc9f0q-guix-cli-builder'
exporting path `/gnu/store/6mdpdsflpz3axdlifw7mqfdmzhnpzvvc-guix-cli.drv'
offloading '/gnu/store/6mdpdsflpz3axdlifw7mqfdmzhnpzvvc-guix-cli.drv' to '10.42.0.199'...
offloading build of /gnu/store/6mdpdsflpz3axdlifw7mqfdmzhnpzvvc-guix-cli.drv to '10.42.0.199'
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
@ build-started /gnu/store/6mdpdsflpz3axdlifw7mqfdmzhnpzvvc-guix-cli.drv - x86_64-linux /var/log/guix/drvs/6m//dpdsflpz3axdlifw7mqfdmzhnpzvvc-guix-cli.drv.bz2 12943
[106/106] compiling... 100.0% of 53 files
@ build-succeeded /gnu/store/6mdpdsflpz3axdlifw7mqfdmzhnpzvvc-guix-cli.drv -
retrieving 1 store item from '10.42.0.199'...
importing file or directory '/gnu/store/7gh81jn54ak2qw3ahq4nb9dc0zzn0h4v-guix-cli'...
found valid signature for '/gnu/store/7gh81jn54ak2qw3ahq4nb9dc0zzn0h4v-guix-cli'
done with offloaded '/gnu/store/6mdpdsflpz3axdlifw7mqfdmzhnpzvvc-guix-cli.drv'
successfully built /gnu/store/6mdpdsflpz3axdlifw7mqfdmzhnpzvvc-guix-cli.drv
building /gnu/store/ybxk6d3bccnz52d2s55gcang7795cy3l-guix-cli-modules.drv...
process 5300 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.28 (normalized: 2.28)
waiting for locks or build slots...
successfully built /gnu/store/ybxk6d3bccnz52d2s55gcang7795cy3l-guix-cli-modules.drv
process 5300 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 2.1 (normalized: 2.1)
process 5300 acquired build slot '/var/guix/offload/10.42.0.199:22/0'
load on machine '10.42.0.199' is 1.93 (normalized: 1.93)
building /gnu/store/fwr4jlsgxjxkiqn6l4dr1hfl684irmp0-guix-system-tests.drv...
sending 4 store items (0 MiB) to '10.42.0.199'...
exporting path `/gnu/store/k4vp8f9prcfc29lqmzpygrsx8qxmmzs3-guix-system-tests-builder'
exporting path `/gnu/store/sbrl1022yphyzdcjilpabfgq102rxxkc-guix-system-tests-source'
exporting path `/gnu/store/fwr4jlsgxjxkiqn6l4dr1hfl684irmp0-guix-system-tests.drv'
offloading '/gnu/store/fwr4jlsgxjxkiqn6l4dr1hfl684irmp0-guix-system-tests.drv' to '10.42.0.199'...
offloading build of /gnu/store/fwr4jlsgxjxkiqn6l4dr1hfl684irmp0-guix-system-tests.drv to '10.42.0.199'
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
@ build-started /gnu/store/fwr4jlsgxjxkiqn6l4dr1hfl684irmp0-guix-system-tests.drv - x86_64-linux /var/log/guix/drvs/fw//r4jlsgxjxkiqn6l4dr1hfl684irmp0-guix-system-tests.drv.bz2 13042
[ 5/ 46] loading... 21.7% of 23 filesrandom seed for tests: 1582005862
[ 46/ 46] compiling... 100.0% of 23 files
@ build-succeeded /gnu/store/fwr4jlsgxjxkiqn6l4dr1hfl684irmp0-guix-system-tests.drv -
retrieving 1 store item from '10.42.0.199'...
importing file or directory '/gnu/store/c98xnkcbm1bd3j69k08kr3d8msm5zg94-guix-system-tests'...
found valid signature for '/gnu/store/c98xnkcbm1bd3j69k08kr3d8msm5zg94-guix-system-tests'
done with offloaded '/gnu/store/fwr4jlsgxjxkiqn6l4dr1hfl684irmp0-guix-system-tests.drv'
successfully built /gnu/store/fwr4jlsgxjxkiqn6l4dr1hfl684irmp0-guix-system-tests.drv
building /gnu/store/ysr4d2bqhs4c4viwyk9pvcjcnwv4pnr8-guix-system-tests-modules.drv...
successfully built /gnu/store/ysr4d2bqhs4c4viwyk9pvcjcnwv4pnr8-guix-system-tests-modules.drv
building /gnu/store/mx5kd00k1axs9xrgwn5hibiidbxshy3g-guix-000000000-modules.drv...
successfully built /gnu/store/mx5kd00k1axs9xrgwn5hibiidbxshy3g-guix-000000000-modules.drv
building /gnu/store/flii6im368mj1mlwb1xmnvwhibll0acg-guix-module-union.drv...
successfully built /gnu/store/flii6im368mj1mlwb1xmnvwhibll0acg-guix-module-union.drv
building /gnu/store/cjzvm56h61zhwd56g1ksi91spq567b4b-guix-command.drv...
successfully built /gnu/store/cjzvm56h61zhwd56g1ksi91spq567b4b-guix-command.drv
building /gnu/store/65dva2y1zq173i93z57xzffn34rmfbgw-guix-daemon.drv...
successfully built /gnu/store/65dva2y1zq173i93z57xzffn34rmfbgw-guix-daemon.drv
building /gnu/store/hb87zw934jkgxwkgbbfykwaq55p6pzlq-guix-000000000.drv...
successfully built /gnu/store/hb87zw934jkgxwkgbbfykwaq55p6pzlq-guix-000000000.drv
building CA certificate bundle...
successfully built /gnu/store/qpcnvr43c5rl6bgpsj7l3m38r6xndz7j-ca-certificate-bundle.drv
building fonts directory...
successfully built /gnu/store/scm0rsny7n5kmryffp081hdh6rh2659l-fonts-dir.drv
building directory of Info manuals...
successfully built /gnu/store/qc53qlnzwxlhlm01fxp45ppdnrzw0lfz-info-dir.drv
building database for manual pages...
Creating manual page database...
[ 1/ 1] building list of man-db entries...
0 entries processed in 0.0 s
successfully built /gnu/store/8k7vn4fbwqvlmhsv604v7zkgils5j0f4-manual-database.drv
building /gnu/store/2hd5a6klgq8zz22rsm3jd4wqw6cbcmbq-profile.drv...
successfully built /gnu/store/2hd5a6klgq8zz22rsm3jd4wqw6cbcmbq-profile.drv
building /gnu/store/zdqspx48gmwa9xv2ibn993qfswq9zgkf-inferior-script.scm.drv...
successfully built /gnu/store/zdqspx48gmwa9xv2ibn993qfswq9zgkf-inferior-script.scm.drv
building package cache...
(repl-version 0 0)
Generating package cache for '/gnu/store/lxl90crn49lgnmxd13ljka6w6dz6vm9p-profile'...
(values (value "/gnu/store/ckyfrrsk8fdx9lzkiwvf0a3p79ll2gfg-guix-package-cache/lib/guix/package.cache"))
successfully built /gnu/store/841rih0j6iskwdxvay7cm94l3vn4idl7-guix-package-cache.drv
building /gnu/store/3rqfd301xgwlaacwppswdxshlc13ky7p-profile.drv...
successfully built /gnu/store/3rqfd301xgwlaacwppswdxshlc13ky7p-profile.drv
building CA certificate bundle...
successfully built /gnu/store/44wi6c2lq0mpkmx940wsi56fmxr8fjh4-ca-certificate-bundle.drv
building fonts directory...
successfully built /gnu/store/1li6nkn0p7zikf5y36ljir2n53rf81cg-fonts-dir.drv
building directory of Info manuals...
successfully built /gnu/store/d80j7mvj59m6h33m3c72mwfckb9xrn7r-info-dir.drv
building database for manual pages...
Creating manual page database...
[ 45/ 45] building list of man-db entries...
1039 entries processed in 3.2 s
successfully built /gnu/store/x1cfgs17hpiw33fpq8gj51ldykf8wd25-manual-database.drv
building /gnu/store/5688khnjjabnh8bnn4hc41j05h1larh9-shepherd-guix-daemon.scm.drv...
successfully built /gnu/store/5688khnjjabnh8bnn4hc41j05h1larh9-shepherd-guix-daemon.scm.drv
building /gnu/store/a2dl48yn635qqbga72gwkqnypd45lxaf-profile.drv...
warning: collision encountered:
/gnu/store/zg26g1i42sfn26ll4k5i3wb20zmwmpah-info-dir/share/info/dir
/gnu/store/ma7ccwpzsypkxp88j2jlr4vq1gad06vd-profile/share/info/dir
warning: choosing /gnu/store/zg26g1i42sfn26ll4k5i3wb20zmwmpah-info-dir/share/info/dir
warning: collision encountered:
/gnu/store/5al8wjz7522q8rqzyfmz46mlbzm70jzj-manual-database/share/man/index.db
/gnu/store/ma7ccwpzsypkxp88j2jlr4vq1gad06vd-profile/share/man/index.db
warning: choosing /gnu/store/5al8wjz7522q8rqzyfmz46mlbzm70jzj-manual-database/share/man/index.db
successfully built /gnu/store/a2dl48yn635qqbga72gwkqnypd45lxaf-profile.drv
building /gnu/store/7wkb1al9lxp5k84k9b1i5v7h69x9p3wr-shepherd-guix-daemon.go.drv...
successfully built /gnu/store/7wkb1al9lxp5k84k9b1i5v7h69x9p3wr-shepherd-guix-daemon.go.drv
building /gnu/store/jp62bqlvch38sqcqkxk3ddwih84qz8ka-shepherd.conf.drv...
successfully built /gnu/store/jp62bqlvch38sqcqkxk3ddwih84qz8ka-shepherd.conf.drv
building /gnu/store/ixk9m5hqwj42kdzh88vwy06alk9bw811-boot.drv...
successfully built /gnu/store/ixk9m5hqwj42kdzh88vwy06alk9bw811-boot.drv
building /gnu/store/1kmbdnkdip0xbdi4h09jj44nccmpmxh6-system.drv...
successfully built /gnu/store/1kmbdnkdip0xbdi4h09jj44nccmpmxh6-system.drv
/gnu/store/mv1c4cv6c1wws712zi4wz8l6ab8gwn85-system
--8<---------------cut here---------------end--------------->8---
real 58m19.825s
user 3m42.533s
sys 0m1.936s
I've left the full log because it did most poorly, at nearly an hour.
Next I'll try to verify if this long build is triggered amongst the
commits of this change set.
Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Tue, 18 Feb 2020 21:28:02 GMT) Full text and rfc822 format available.Message #32 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 37305 <at> debbugs.gnu.org Subject: Re: Making system installation tests faster Date: Tue, 18 Feb 2020 16:27:25 -0500
Hello Ludovic!
I have more benchmark results. Not to be compared with the previous
results, as these were executed on a much faster machine (24 cores vs 4
cores), with an SSD instead of a rotative disk.
Commands used:
current-guix/pre-built:
--8<---------------cut here---------------start------------->8---
time ./pre-inst-env guix system build -e \
'(begin
(use-modules
(gnu packages package-management))
(parameterize
((current-guix-package
(current-guix/pre-built)))
((@@
(gnu tests install)
operating-system-with-current-guix)
(@@
(gnu tests install)
%btrfs-root-os))))'
--8<---------------cut here---------------end--------------->8---
current-guix (old fashionned):
--8<---------------cut here---------------start------------->8---
time ./pre-inst-env guix system build -e \
'(begin
(use-modules
(gnu packages package-management))
(parameterize
((current-guix-package
(current-guix)))
((@@
(gnu tests install)
operating-system-with-current-guix)
(@@
(gnu tests install)
%btrfs-root-os))))'
--8<---------------cut here---------------end--------------->8---
new current-guix (guix self):
--8<---------------cut here---------------start------------->8---
time ./pre-inst-env guix system build -e \
'(begin
(use-modules ((gnu ci) #:select (channel-instance->package))
(guix monads)
(guix channels)
(guix store)
((guix status) #:select (with-status-verbosity))
((guix git-download) #:select (git-predicate))
(guix utils)
(gnu packages package-management))
(with-store store
(with-status-verbosity 2
(run-with-store store
(mlet* %store-monad
((source-dir -> "/home/mcournoyer/src/guix")
(source (interned-file source-dir
"guix-source"
#:recursive? #t
#:select? (or (git-predicate source-dir)
(const #t))))
(instance -> (checkout->channel-instance source))
(new-guix-current -> (channel-instance->package instance)))
(return (parameterize ((current-guix-package new-guix-current))
((@@ (gnu tests install) operating-system-with-current-guix)
(@@ (gnu tests install) %btrfs-root-os)))))))))'
--8<---------------cut here---------------end--------------->8---
Methodology:
1. Break at each commit of the current change set, run make, and run the three
above commands in the order they appear.
2. Record the "real" component of the time results of each
commit/command in the table below.
| Commit | current-guix/pre-built | old current-guix | new current-guix |
|--------------------------------------------------------------+------------------------+------------------+------------------|
| linux-boot: Ensure volatile root is mounted read-only. | 2m2.245s | 13m39.669s | 3m47.066s |
| file-systems: Add a 'file-system-device->string' procedure. | 2m12.576s | 13m42.906s | 3m43.212s |
| gnu: linux-boot: Refactor boot-system. | 1m53.928s | 13m48.825s | 9m53.133s |
| file-systems: Represent the file system options as an alist. | 2m12.530s | "" | 10m3.523s |
| gnu: linux-boot: Honor the "--root-options" kernel argument. | "" | "" | 11m10.448s |
| gnu: linux-boot: Filter out file system independent options. | "" | "" | 5m4.997s |
| bootloader: grub: Allow booting from a Btrfs subvolume. | 2m13.375s | 13m44.671s | 3m38.815s |
|--------------------------------------------------------------+------------------------+------------------+------------------|
This machine appears to be 5 times faster (at this task) than the
previous one used, to give an idea of the time someone would have to
wait just to build the operating system to test. An x200 would be even
slightly slower that than.
One of the things that seems costly is rebuilding the documentation.
Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Wed, 19 Feb 2020 19:27:02 GMT) Full text and rfc822 format available.Message #35 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] Allow booting from a Btrfs subvolume [review part 2] Date: Tue, 18 Feb 2020 21:52:24 -0500 (15 hours, 38 minutes, 5 seconds ago)
[Message part 1 (text/plain, inline)]
Hello Ludovic,
Here comes part 2!
Ludovic Courtès <ludo <at> gnu.org> writes:
>> From 6cf2ece21683e98544f8f46675aef58d5a7231fd Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Date: Sun, 14 Jul 2019 20:50:23 +0900
>> Subject: [PATCH 8/9] bootloader: grub: Allow booting from a Btrfs subvolume.
>>
>> * gnu/bootloader/grub.scm (grub-configuration-file) [btrfs-subvolume-path]:
>> New parameter. When it is defined, prepend its value to the kernel and
>> initrd file paths.
>> * gnu/bootloader/depthcharge.scm (depthcharge-configuration-file): Adapt.
>> * gnu/bootloader/extlinux.scm (extlinux-configuration-file): Likewise.
>> * gnu/system/file-systems.scm (btrfs-subvolume?)
>> (btrfs-store-subvolume-path): New procedures.
>> * gnu/system.scm (operating-system-bootcfg): Specify the Btrfs subvolume path
>> of the GNU store to the `operating-system-bootcfg' procedure, using the new
>> BTRFS-SUBVOLUME-PATH argument.
>> * doc/guix.texi (File Systems): Add a Btrfs subsection to document the use of
>> subvolumes. Document the new `properties' field of the `<file-system>'
>> record.
>> * gnu/tests/install.scm: Add test "btrfs-root-on-subvolume-os".
>
> Neat!
>
>> (define* (grub-configuration-file config entries
>> #:key
>> (system (%current-system))
>> - (old-entries '()))
>> + (old-entries '())
>> + btrfs-subvolume-path)
>> "Return the GRUB configuration file corresponding to CONFIG, a
>> <bootloader-configuration> object, and where the store is available at
>> STORE-FS, a <file-system> object. OLD-ENTRIES is taken to be a list of menu
>> -entries corresponding to old generations of the system."
>> +entries corresponding to old generations of the system. BTRFS-SUBVOLUME-PATH
>> +may be used to specify on which subvolume a Btrfs root file system resides."
>
> (Nitpick: s/path/file name/ :-))
I stand corrected! From '(Standards)GNU Manuals':
Please do not use the term "pathname" that is used in Unix
documentation; use "file name" (two words) instead. We use the term
"path" only for search paths, which are lists of directory names.
> It’s a bit problematic that (1) GRUB needs explicit Btrfs support, and
> (2) other bootloaders will silently ignore the option, due to
> #:allow-other-keys.
>
> I don’t have a better idea, but it’d be great if Btrfs support could be
> made bootloader-independent, and if it could be somewhat
> not-too-btrfs-specific, if that is possible at all.
>
> Thoughts?
I have no idea how Btrfs subvolumes are handled (if at all) on U-Boot or
other bootloaders than GRUB. All I know is that for GRUB they need to
handle subvolumes in a special manner in their own grub-mkconfig tool
(which we bypass).
Also, I'm afraid subvolumes are very Btrfs specific :-). It doesn't
exist in traditional file systems like EXT4. I think ZFS must have
something similar, though.
>> + (properties file-system-properties ; list of name-value pairs
>> + (default '()))
>> (location file-system-location
>> (default (current-source-location))
>> (innate)))
>> @@ -582,4 +589,48 @@ system has the given TYPE."
>> (or (string-prefix-ci? "x-" option-name)
>> (member option-name %file-system-independent-mount-options))))
>>
>> +(define (btrfs-subvolume? fs)
>> + "Predicate to check if FS, a file-system object, is a Btrfs subvolume."
>> + (and-let* ((btrfs-file-system? (string= "btrfs" (file-system-type fs)))
>> + (option-keys (map (match-lambda
>> + ((key . value) key)
>> + (key key))
>> + (file-system-options fs))))
>> + (find (cut string-prefix? "subvol" <>) option-keys)))
>
> I wonder if we can avoid special support in the <file-system> API for
> Btrfs.
>
>> + (error "The store is on a Btrfs subvolume, but the \
>> +subvolume name is unknown.
>> +Hint: Define the \"btrfs-subvolume-path\" file system property or
>> +use the \"subvol\" Btrfs file system option."))))
> Rather use ‘raise’ with ‘&message’ and ‘&fix-hint’ conditions.
I tried this, but importing (guix utils) to acces &fix-hint caused the init
RAM disk to fail mysteriously:
--8<---------------cut here---------------start------------->8---
[ 0.614503] Run /init as init process
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
GC Warning: Couldn't read /proc/stat
Backtrace:
In ice-9/boot-9.scm:
222:29 19 (map1 (((ice-9 match)) ((rnrs bytevectors)) ((srfi
222:29 18 (map1 (((rnrs bytevectors)) ((srfi srfi-1)) ((srfi
222:29 17 (map1 (((srfi srfi-1)) ((srfi srfi-2)) ((srfi #)) (#)
222:29 16 (map1 (((srfi srfi-2)) ((srfi srfi-9)) ((srfi #)) (#)
222:29 15 (map1 (((srfi srfi-9)) ((srfi srfi-26)) ((srfi #)) (#)
222:29 14 (map1 (((srfi srfi-26)) ((srfi srfi-35)) ((srfi # #))
222:29 13 (map1 (((srfi srfi-35)) ((srfi srfi-9 gnu)) ((guix
))[ 0.657578] random: fast init done
222:29 12 (map1 (((srfi srfi-9 gnu)) ((guix records)) ((guix
222:29 11 (map1 (((guix records)) ((guix utils)) ((gnu system
))))
222:17 10 (map1 (((guix utils)) ((gnu system uuid))))
2800:17 9 (resolve-interface (guix utils) #:select _ #:hide _ # _
In ice-9/threads.scm:
390:8 8 (_ _)
In ice-9/boot-9.scm:
2726:13 7 (_)
In ice-9/threads.scm:
390:8 6 (_ _)
In ice-9/boot-9.scm:
2994:20 5 (_)
2312:4 4 (save-module-excursion #<procedure 7f455b6d48d0 at ice-
3014:26 3 (_)
In unknown file:
2 (primitive-load-path "guix/utils" #<procedure 7f455b8fd
In guix/utils.scm:
508:24 1 (_)
In unknown file:
0 (dynamic-func "strverscmp" #<dynamic-object #f>)
ERROR: In procedure dynamic-func:
In procedure dynamic-pointer: Symbol not found: strverscmp
[ 0.697002] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[ 0.697894] CPU: 0 PID: 1 Comm: init Not tainted 5.4.18-gnu #1
[ 0.698592] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[ 0.699938] Call Trace:
[ 0.700240] dump_stack+0x6d/0x8d
[ 0.700640] panic+0x10b/0x2f4
[ 0.701010] do_exit+0x7e2/0xb80
[ 0.701398] ? wake_up_state+0x1f/0x30
[ 0.701847] ? signal_wake_up_state+0x24/0x40
[ 0.702374] do_group_exit+0x44/0xa0
[ 0.702805] __x64_sys_exit_group+0x1c/0x20
[ 0.703306] do_syscall_64+0x5a/0x190
[ 0.703748] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 0.704347] RIP: 0033:0x5df9c6
[ 0.704716] Code: 00 00 00 be 3c 00 00 00 eb 19 66 2e 0f 1f 84 00 00 00 00 00 89 d7 89 f0 0f 05 48 3d 00 f0 ff ff 77 22 f4 89 d7 44 89 c0 0f 05 <48> 3d 00 f0 ff ff 76 e2 f7 d8 64 41 89 01 eb da 66 2e 0f 1f 84 00
[ 0.706919] RSP: 002b:00007ffd9fa65228 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[ 0.707808] RAX: ffffffffffffffda RBX: 00000000007c51f0 RCX: 00000000005df9c6
[ 0.708643] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
[ 0.709482] RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffb0
[ 0.710328] R10: 0000000000436340 R11: 0000000000000246 R12: 00000000007c51f0
[ 0.711166] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000003
[ 0.712026] Kernel Offset: 0x13000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 0.713288] Rebooting in 1 seconds..
file-size: /gnu/store/zfi66vny0h10d180xajgm4pq2vnvmc2z-nss-certs-3.49.1/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem: No such file or directory
file-size: /gnu/store/04xpkgf9zlhcngyr6gnhl4rb8g6v6i1i-profile/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem: No such file or directory
--8<---------------cut here---------------end--------------->8---
The exception I had refactored to use with &fix-hint looked like:
--8<---------------cut here---------------start------------->8---
(raise (condition
(&message
(message "The store is on a Btrfs subvolume, \
but the subvolume name is unknown."))
(&fix-hint
(hint "Define the \"btrfs-subvolume-file-name\" \
file system property or use the \"subvol\" Btrfs file system
option."))))
--8<---------------cut here---------------end--------------->8---
So, I ended up using just a &message condition with the hint embedded in it.
The attached patch (v3) incorporate the agreed changes so far.
The btrfs-root-on-subvolume-os test still passes.
Thank you for your patience,
Maxim
[0001-gnu-tests-Reduce-the-time-required-to-run-the-system.patch (text/x-patch, attachment)]
[0002-linux-boot-Ensure-volatile-root-is-mounted-read-only.patch (text/x-patch, attachment)]
[0003-file-systems-Add-a-file-system-device-string-procedu.patch (text/x-patch, attachment)]
[0004-linux-boot-Refactor-boot-system.patch (text/x-patch, attachment)]
[0005-file-systems-Represent-the-file-system-options-as-an.patch (text/x-patch, attachment)]
[0006-linux-boot-Honor-the-root-options-kernel-argument.patch (text/x-patch, attachment)]
[0007-linux-boot-Filter-out-file-system-independent-option.patch (text/x-patch, attachment)]
[0008-bootloader-grub-Allow-booting-from-a-Btrfs-subvolume.patch (text/x-patch, attachment)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Thu, 20 Feb 2020 09:56:02 GMT) Full text and rfc822 format available.Message #38 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] Allow booting from a Btrfs subvolume [review part 2] Date: Thu, 20 Feb 2020 10:55:05 +0100
Hi Maxim, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis: >>> + (error "The store is on a Btrfs subvolume, but the \ >>> +subvolume name is unknown. >>> +Hint: Define the \"btrfs-subvolume-path\" file system property or >>> +use the \"subvol\" Btrfs file system option.")))) > >> Rather use ‘raise’ with ‘&message’ and ‘&fix-hint’ conditions. > > I tried this, but importing (guix utils) to acces &fix-hint caused the init > RAM disk to fail mysteriously: Oh, my bad. We should move ‘&fix-hint’ to (guix diagnostics) eventually. In the meantime, I’d say just raise a ‘&message’ and leave the hint as a comment (it’s not supposed to be a user-facing interface). Or maybe you could define a specific error condition type for this? Thanks, Ludo’. PS: I’ll comment on the other bits ASAP!
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Mon, 24 Feb 2020 14:24:02 GMT) Full text and rfc822 format available.Message #41 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH V3] Allow booting from a Btrfs subvolume. Date: Mon, 24 Feb 2020 09:23:18 -0500
[Message part 1 (text/plain, inline)]
I've added a `normalize-file' procedure to the attached patch, which simplify producing correct store references in the GRUB configuration file generated. This fixed the GRUB video mode issues reported in a another issue. Thanks! Maxim
[0001-bootloader-grub-Allow-booting-from-a-Btrfs-subvolume.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Mon, 24 Feb 2020 16:04:01 GMT) Full text and rfc822 format available.Message #44 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH V2] Allow booting from a Btrfs subvolume. Date: Mon, 24 Feb 2020 17:02:49 +0100
Hi Maxim,
Resuming review of this series… Sorry for the delay!
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>>> From 97d8a635eba34c7cf0708e99bf77ef9bad1344bf Mon Sep 17 00:00:00 2001
>>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>>> Date: Tue, 11 Feb 2020 12:57:29 -0500
>>> Subject: [PATCH 2/9] gnu: linux-boot: Ensure volatile root is mounted
>>> read-only.
>>>
>>> * gnu/build/linux-boot.scm (mount-root-file-system): Ensure MS_RDONLY is
>>> present among the root file system flags when VOLATILE-ROOT? is #t.
>>
>> (You can drop the “gnu:” prefix.)
>
> Done.
>
> I never know before looking at past logs (and then sometimes it's a
> mixed bag). Is there any mechanical process for selecting the right
> commit prefix? :-)
“gnu:” is for changes to (gnu packages). The idea is that the prefix
should reflect what subsystem the commit is modifying. But yeah,
looking at ‘git log’ can be inspiring. :-)
>>> @item --root=@var{root}
>>> -Mount @var{root} as the root file system. @var{root} can be a
>>> -device name like @code{/dev/sda1}, a file system label, or a file system
>>> -UUID.
>>> +Mount @var{root} as the root file system. @var{root} can be a device
>>> +name like @code{/dev/sda1}, a file system label, or a file system UUID.
>>> +When unspecified, the device name from the root file system of the
>>> +operating system declaration is used.
>>
>> Oh! Does it always work? That makes me wonder why we’ve been carrying
>> ‘--root’ and I’m not sure if I’m forgetting a good reason to do it that
>> way.
>
> If the documentation is accurate, it should :-), given that --root gets
> written as a string to the GRUB configuration file, and that the doc
> says it's possible to give it as a device name, label or UUID.
Yes, ‘--root’ can resolve labels and UUIDs; my question was more about
why we have it in the first place.
> About why providing options such as --root or --root-options in the
> first place; I pondered about this as well, especially after making the
> file systems from operating system able to be mounted with all their
> (file system independent -- more on that later) options. A reason I
> came up with was that it allows to experiment at the GRUB command line
> and change the root device, or perhaps the root options. One use case
> would be debugging the right options to pass to a file system driver in
> case of a mistake in the operating system declaration.
Yes, that makes sense. It’s certainly useful to have ‘--root’ at least
as an option.
>> The main issue I see with this change is that mount(2) takes raw strings
>> for the options. There’s a convention to have those strings look like
>> “KEY1=VALUE1,KEY2=VALUE2”, but it’s just a convention.
>>
>> As a rule of thumb, I’d rather have our interface be as close as
>> possible to the actual mount(2) interface, which means taking strings.
>>
>> Now, we can surely add helper procedures to parse options that follow
>> the above conventions.
>>
>> WDYT?
>
> To me, it's an implementation detail that I'd rather abstract away (or
> make optional, like in this patch). Just like we provide a higher level
> configuration for services instead of requiring the user to input the
> configuration in the native format of the tool (or allowing for both).
> The idea for this format was taken from a discussion here:
> http://issues.guix.info/issue/33517#3.
>
> Are we really targeting mount(2)? The commit
> 9d3053819dfd834a1c29a03427c41d8524b8a7d5 (which you co-authored :-))
> mentions 'man 8 mount' for the file system options.
Right, mount(8) documents file system options that can be passed to
mount(2).
What does it mean to target mount(8) vs. mount(2)? To me, mount(8) is a
CLI to mount(2) that provides additional features to make the CLI more
convenient: the “defaults” option, a way to pass mount(2) flags as
options (like “ro”, “remount”, “bind”), /etc/fstab handling, etc.
Guix System handles /etc/fstab differently and “defaults” makes little
sense in our API (one can just use leave the default value of the
‘options’ field.)
I think mount(8) is actually a good illustration of what not to do. It
ends up mixing things that are separate in the mount(2) API, and that
doesn’t improve clarity and future-proof-ness (what if a file system has
a “bind” option, etc.).
But again, I think the helper procedures that you propose to move back
and forth between the string and the alist representations are very
welcome. I just wouldn’t hard-code that directly in our API.
WDYT?
>>> From 67135c925b07f2e077b4cd852e07178691a10164 Mon Sep 17 00:00:00 2001
>>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>>> Date: Tue, 11 Feb 2020 14:14:36 -0500
>>> Subject: [PATCH 6/9] gnu: linux-boot: Honor the "--root-options" kernel
>>> argument.
>>>
>>> * gnu/build/linux-boot.scm (boot-system): Parse the "--root-options" kernel
>>> argument, and use it when calling `mount-root-file-system'. Update doc.
>>> * doc/guix.texi (Initial RAM Disk): Document the use of the "--root-options"
>>> argument.
>>
>> Hmm do we really need this extra option? :-)
>
> It is not strictly needed but allows the user to experiment/troubleshoot
> with the init RAM disk from GRUB as discussed earlier for --root. Do
> you think it has enough value to be kept?
I’d rather avoid it for now. Less code is better. :-)
>> (Also, in hindsight, I think it was a mistake to call them
>> ‘--something’. Following the common naming convention, we should rather
>> call these options ‘gnu.something’.)
>
> Is this convention detailed somewhere? I haven't found it in 'Standards'.
It’s a convention of the Linux kernel, I don’t know if it’s documented.
That’s it!
Ludo’.
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Tue, 03 Mar 2020 05:01:02 GMT) Full text and rfc822 format available.Message #47 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH V2] Allow booting from a Btrfs subvolume. Date: Tue, 03 Mar 2020 00:00:05 -0500
Hello Ludovic! Resuming review; I hope I'll be able to bring this series to completion this time. [...] > “gnu:” is for changes to (gnu packages). The idea is that the prefix > should reflect what subsystem the commit is modifying. But yeah, > looking at ‘git log’ can be inspiring. :-) OK. Makes sense. Thanks for taking the time to explain! [...] >> About why providing options such as --root or --root-options in the >> first place; I pondered about this as well, especially after making the >> file systems from operating system able to be mounted with all their >> (file system independent -- more on that later) options. A reason I >> came up with was that it allows to experiment at the GRUB command line >> and change the root device, or perhaps the root options. One use case >> would be debugging the right options to pass to a file system driver in >> case of a mistake in the operating system declaration. > > Yes, that makes sense. It’s certainly useful to have ‘--root’ at least > as an option. > >>> The main issue I see with this change is that mount(2) takes raw strings >>> for the options. There’s a convention to have those strings look like >>> “KEY1=VALUE1,KEY2=VALUE2”, but it’s just a convention. >>> >>> As a rule of thumb, I’d rather have our interface be as close as >>> possible to the actual mount(2) interface, which means taking strings. >>> >>> Now, we can surely add helper procedures to parse options that follow >>> the above conventions. >>> >>> WDYT? I don't feel too strongly about it, so I will adapt to your preference. [...] >> Are we really targeting mount(2)? The commit >> 9d3053819dfd834a1c29a03427c41d8524b8a7d5 (which you co-authored :-)) >> mentions 'man 8 mount' for the file system options. > > Right, mount(8) documents file system options that can be passed to > mount(2). > > What does it mean to target mount(8) vs. mount(2)? To me, mount(8) is a > CLI to mount(2) that provides additional features to make the CLI more > convenient: the “defaults” option, a way to pass mount(2) flags as > options (like “ro”, “remount”, “bind”), /etc/fstab handling, etc. > > Guix System handles /etc/fstab differently and “defaults” makes little > sense in our API (one can just use leave the default value of the > ‘options’ field.) > > I think mount(8) is actually a good illustration of what not to do. It > ends up mixing things that are separate in the mount(2) API, and that > doesn’t improve clarity and future-proof-ness (what if a file system has > a “bind” option, etc.). I think I agree. It may be cleaner to use the API of mount(2), while mapping the low level stuff (binary flags?) to saner symbols, like it's already done. > But again, I think the helper procedures that you propose to move back > and forth between the string and the alist representations are very > welcome. I just wouldn’t hard-code that directly in our API. Okay. I'll keep them around in (gnu system file-systems); they're handy when we need to check the presence of an option in the option string. > WDYT? > >>>> From 67135c925b07f2e077b4cd852e07178691a10164 Mon Sep 17 00:00:00 2001 >>>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> >>>> Date: Tue, 11 Feb 2020 14:14:36 -0500 >>>> Subject: [PATCH 6/9] gnu: linux-boot: Honor the "--root-options" kernel >>>> argument. >>>> >>>> * gnu/build/linux-boot.scm (boot-system): Parse the "--root-options" kernel >>>> argument, and use it when calling `mount-root-file-system'. Update doc. >>>> * doc/guix.texi (Initial RAM Disk): Document the use of the "--root-options" >>>> argument. >>> >>> Hmm do we really need this extra option? :-) >> >> It is not strictly needed but allows the user to experiment/troubleshoot >> with the init RAM disk from GRUB as discussed earlier for --root. Do >> you think it has enough value to be kept? > > I’d rather avoid it for now. Less code is better. :-) Done! >>> (Also, in hindsight, I think it was a mistake to call them >>> ‘--something’. Following the common naming convention, we should rather >>> call these options ‘gnu.something’.) >> >> Is this convention detailed somewhere? I haven't found it in 'Standards'. > > It’s a convention of the Linux kernel, I don’t know if it’s documented. Well, with Hurd support coming, perhaps the standards used for a particular kernel are not too relevant? :-) One last thing that I'll try to understand before considering this finished: I think adding a special properties field to the file system record might not be necessary, as it seems that the subvol option can take an absolute path as well as a relative path (I thought it only accepted subvolume *names*.) Will send the 3rd revision soon. Thank you! Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sat, 07 Mar 2020 04:02:02 GMT) Full text and rfc822 format available.Message #50 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] Making system installation tests faster Date: Fri, 06 Mar 2020 23:01:14 -0500
Hello, this is a small update, to reflect recent changes to the code
base.
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> Hello Ludovic!
>
> I have more benchmark results. Not to be compared with the previous
> results, as these were executed on a much faster machine (24 cores vs 4
> cores), with an SSD instead of a rotative disk.
>
>
> Commands used:
>
> current-guix/pre-built:
>
> time ./pre-inst-env guix system build -e \
> '(begin
> (use-modules
> (gnu packages package-management))
> (parameterize
> ((current-guix-package
> (current-guix/pre-built)))
> ((@@
> (gnu tests install)
> operating-system-with-current-guix)
> (@@
> (gnu tests install)
> %btrfs-root-os))))'
>
>
> current-guix (old fashionned):
>
> time ./pre-inst-env guix system build -e \
> '(begin
> (use-modules
> (gnu packages package-management))
> (parameterize
> ((current-guix-package
> (current-guix)))
> ((@@
> (gnu tests install)
> operating-system-with-current-guix)
> (@@
> (gnu tests install)
> %btrfs-root-os))))'
>
>
> new current-guix (guix self):
>
> time ./pre-inst-env guix system build -e \
> '(begin
> (use-modules ((gnu ci) #:select (channel-instance->package))
> (guix monads)
> (guix channels)
> (guix store)
> ((guix status) #:select (with-status-verbosity))
> ((guix git-download) #:select (git-predicate))
> (guix utils)
> (gnu packages package-management))
> (with-store store
> (with-status-verbosity 2
> (run-with-store store
> (mlet* %store-monad
> ((source-dir -> "/home/mcournoyer/src/guix")
> (source (interned-file source-dir
> "guix-source"
> #:recursive? #t
> #:select? (or (git-predicate source-dir)
> (const #t))))
> (instance -> (checkout->channel-instance source))
> (new-guix-current -> (channel-instance->package instance)))
> (return (parameterize ((current-guix-package new-guix-current))
> ((@@ (gnu tests install) operating-system-with-current-guix)
> (@@ (gnu tests install) %btrfs-root-os)))))))))'
There have been some changes made to the modules used in the benchmark code
above. Here's an updated version:
--8<---------------cut here---------------start------------->8---
time ./pre-inst-env guix system build -e \
'(begin
(use-modules ((gnu ci) #:select (channel-source->package))
(guix monads)
(guix channels)
(guix store)
((guix status) #:select (with-status-verbosity))
((guix git-download) #:select (git-predicate))
(guix utils)
(gnu packages package-management))
(with-store store
(with-status-verbosity 2
(run-with-store store
(mlet* %store-monad
((source-dir -> "/home/mcournoyer/src/guix")
(source (interned-file source-dir
"guix-source"
#:recursive? #t
#:select? (or (git-predicate source-dir)
(const #t))))
(instance -> (checkout->channel-instance source))
(new-guix-current -> (channel-source->package instance)))
(return (parameterize ((current-guix-package new-guix-current))
((@@ (gnu tests install) operating-system-with-current-guix)
(@@ (gnu tests install) %btrfs-root-os)))))))))'
--8<---------------cut here---------------end--------------->8---
Time taken:
real 7m39.912s
user 0m57.129s
sys 0m0.499s
Compared to recycling the Guix development copy from the work tree:
real 0m48.297s
user 0m2.516s
sys 0m0.229s
Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Wed, 18 Mar 2020 15:29:01 GMT) Full text and rfc822 format available.Message #53 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: maxim.cournoyer <at> gmail.com To: Ludovic Courtès <ludo <at> gnu.org> Cc: 37305 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Subject: Re: [bug#37305] Allow booting from a Btrfs subvolume [review part 2] Date: Wed, 18 Mar 2020 11:27:58 -0400
[Message part 1 (text/plain, inline)]
Hi Ludovic, Ludovic Courtès <ludo <at> gnu.org> writes: > Hi Maxim, > > Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis: > >>>> + (error "The store is on a Btrfs subvolume, but the \ >>>> +subvolume name is unknown. >>>> +Hint: Define the \"btrfs-subvolume-path\" file system property or >>>> +use the \"subvol\" Btrfs file system option.")))) >> >>> Rather use ‘raise’ with ‘&message’ and ‘&fix-hint’ conditions. >> >> I tried this, but importing (guix utils) to acces &fix-hint caused the init >> RAM disk to fail mysteriously: > > Oh, my bad. We should move ‘&fix-hint’ to (guix diagnostics) > eventually. > > In the meantime, I’d say just raise a ‘&message’ and leave the hint as a > comment (it’s not supposed to be a user-facing interface). Or maybe you > could define a specific error condition type for this? > > Thanks, > Ludo’. > > PS: I’ll comment on the other bits ASAP! The remaining, reworked patches for this series are attached below. If you don't want to merge the 0001 for now (speeding up tests), I don't mind too much (though it still provides value to me, when using old hardware). Thanks for your patience :-) Maxim
[0001-gnu-tests-Reduce-the-time-required-to-run-the-system.patch (text/x-patch, attachment)]
[0002-linux-boot-Refactor-boot-system.patch (text/x-patch, attachment)]
[0003-file-systems-Add-helpers-for-parsing-the-options-str.patch (text/x-patch, attachment)]
[0004-bootloader-grub-Allow-booting-from-a-Btrfs-subvolume.patch (text/x-patch, attachment)]
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
to control <at> debbugs.gnu.org.
(Tue, 31 Mar 2020 01:28:02 GMT) Full text and rfc822 format available.guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 17 May 2020 13:30:03 GMT) Full text and rfc822 format available.Message #58 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: maxim.cournoyer <at> gmail.com Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] Allow booting from a Btrfs subvolume [review part 2] Date: Sun, 17 May 2020 15:29:05 +0200
[Message part 1 (text/plain, inline)]
I'll try to test this patch, possibly today. Is the patch from the 18th of March the right one? The patch says it has 5 components but the last patch is --8<---------------cut here---------------start------------->8--- [PATCH 4/5] bootloader: grub: Allow booting from a Btrfs subvolume. --8<---------------cut here---------------end--------------->8--- Is the fifth patch missing? -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 17 May 2020 14:04:02 GMT) Full text and rfc822 format available.Message #61 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: maxim.cournoyer <at> gmail.com Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] Allow booting from a Btrfs subvolume [review part 2] Date: Sun, 17 May 2020 16:03:41 +0200
[Message part 1 (text/plain, inline)]
Hi Maxim!
maxim.cournoyer <at> gmail.com writes:
> +@lisp
> +(file-system
> + (device (file-system-label "btrfs-pool-1"))
> + (mount-point "/gnu/store")
> + (type "btrfs")
> + (options "subvol=root-snapshots/root-current/guix-store"
> + ("compress" . "zstd")))
> +@end lisp
[Message part 2 (text/plain, inline)]
Is this ("compress" . "zstd") intentional? It does not match the first example.
--
Pierre Neidhardt
https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 17 May 2020 16:14:01 GMT) Full text and rfc822 format available.Message #64 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Pierre Neidhardt <mail <at> ambrevar.xyz> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [PATCH v3] Allow booting from a Btrfs subvolume Date: Sun, 17 May 2020 12:13:34 -0400
[Message part 1 (text/plain, inline)]
Hi Pierre! Pierre Neidhardt <mail <at> ambrevar.xyz> writes: > I'll try to test this patch, possibly today. > > Is the patch from the 18th of March the right one? > The patch says it has 5 components but the last patch is > > [PATCH 4/5] bootloader: grub: Allow booting from a Btrfs subvolume. > > Is the fifth patch missing? As I send my patches as attachments rather than with git send-email, I simply forgot to update the subject line counter. There are four patches in total, although the hack in 0001 was controversial so is included as a curiosity only. I've rebased the 4 patches on current master, and fixed some conflict that arose in the initrd code.
[0001-gnu-tests-Reduce-the-time-required-to-run-the-system.patch (text/x-patch, attachment)]
[0002-linux-boot-Refactor-boot-system.patch (text/x-patch, attachment)]
[0003-file-systems-Add-helpers-for-parsing-the-options-str.patch (text/x-patch, attachment)]
[0004-bootloader-grub-Allow-booting-from-a-Btrfs-subvolume.patch (text/x-patch, attachment)]
[Message part 6 (text/plain, inline)]
I'll test those rebased patches as well. The automated system tests no longer pass -- although it might not be specific to this change (I'll try running the "installed-os" test to see if all the install tests are broken or just this new "btrfs-root-on-subvolume-os" one.). In case you are not familiar with system tests, a single system test can be run with: make check-system TESTS="btrfs-root-on-subvolume-os" The install tests are defined under (gnu tests install) and are *very* expensive to run (mostly in time, but they require some disk space as well). Hence the hack in 0001, but I'm not sure if it brings as much benefits as when I made it (given Ludovic keeps improving the way Guix gets built :-)). A fresh benchmark could be interesting if you have lots of time on your hands. Thank you for looking at this! Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 17 May 2020 16:17:02 GMT) Full text and rfc822 format available.Message #67 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Pierre Neidhardt <mail <at> ambrevar.xyz> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] Allow booting from a Btrfs subvolume [review part 2] Date: Sun, 17 May 2020 12:16:07 -0400
Hello Pierre!
Pierre Neidhardt <mail <at> ambrevar.xyz> writes:
> Hi Maxim!
>
> maxim.cournoyer <at> gmail.com writes:
>
>> +@lisp
>> +(file-system
>> + (device (file-system-label "btrfs-pool-1"))
>> + (mount-point "/gnu/store")
>> + (type "btrfs")
>> + (options "subvol=root-snapshots/root-current/guix-store"
>> + ("compress" . "zstd")))
>> +@end lisp
>
>
> Is this ("compress" . "zstd") intentional? It does not match the first example.
Good catch! This pair syntax was removed, based on feedback from
previous reviews. It can still be used with the helper procedures, but
not directly like that. It should be fixed in the patch series I just
sent in the previous email.
Thank you,
Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 17 May 2020 16:38:02 GMT) Full text and rfc822 format available.Message #70 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [PATCH v3] Allow booting from a Btrfs subvolume Date: Sun, 17 May 2020 18:37:04 +0200
[Message part 1 (text/plain, inline)]
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes: > I'll test those rebased patches as well. The automated system tests no > longer pass -- although it might not be specific to this change (I'll > try running the "installed-os" test to see if all the install tests are > broken or just this new "btrfs-root-on-subvolume-os" one.). In case you > are not familiar with system tests, a single system test can be run > with: > > make check-system TESTS="btrfs-root-on-subvolume-os" OK. Do you want me to try something here? > The install tests are defined under (gnu tests install) and are *very* > expensive to run (mostly in time, but they require some disk space as > well). Hence the hack in 0001, but I'm not sure if it brings as much > benefits as when I made it (given Ludovic keeps improving the way Guix > gets built :-)). > > A fresh benchmark could be interesting if you have lots of time on your > hands. Sorry, I don't think I'll be able to do that :) Cheers! -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 17 May 2020 19:06:02 GMT) Full text and rfc822 format available.Message #73 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [PATCH v3] Allow booting from a Btrfs subvolume Date: Sun, 17 May 2020 21:05:51 +0200
[Message part 1 (text/plain, inline)]
Finally "system reconfigure"d with your patch.
The first entry fails to boot with:
--8<---------------cut here---------------start------------->8---
loading kernel modules...
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure string-prefix?: Wrong type argument in position 2
(expecting string): #<file-system-label "guix">
--8<---------------cut here---------------end--------------->8---
Funny thing is, the previous generation boots properly!
My config.scm's filesystem layout:
--8<---------------cut here---------------start------------->8---
(file-systems (cons* (file-system
(device (file-system-label "guix"))
(mount-point "/")
(type "btrfs")
(options "subvol=rootfs,compress=zstd"))
(file-system
(device (file-system-label "data"))
(mount-point "/media/data")
(type "ext4"))
(file-system
(mount-point "/tmp")
(device "none")
(type "tmpfs")
(check? #f))
%base-file-systems))
--8<---------------cut here---------------end--------------->8---
--
Pierre Neidhardt
https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 17 May 2020 19:10:02 GMT) Full text and rfc822 format available.Message #76 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [PATCH v3] Allow booting from a Btrfs subvolume Date: Sun, 17 May 2020 21:09:13 +0200
[Message part 1 (text/plain, inline)]
The first (failing) generation was generated from today (or yesterday) Guix master. The second (working) generation was generated from a 2 month old Guix. Let me know if you want the precise commits. -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 17 May 2020 19:49:02 GMT) Full text and rfc822 format available.Message #79 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [PATCH v3] Allow booting from a Btrfs subvolume Date: Sun, 17 May 2020 21:48:16 +0200
[Message part 1 (text/plain, inline)]
False alarm, I had mis-merged your (old) patch. After applying your patch from today, everything works. I won't have access to this computer in 24 hours. Let me know if there is anything else you'd like me to test before then! :) Cheers! -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 17 May 2020 20:23:02 GMT) Full text and rfc822 format available.Message #82 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [PATCH v3] Allow booting from a Btrfs subvolume Date: Sun, 17 May 2020 22:22:13 +0200
[Message part 1 (text/plain, inline)]
About the patch: maybe some of it could be generalized to other filesystems that support subvolumes (like ZFS). But this is probably premature and it could be long before someone tests all this with ZFS, thus it's probably wiser to first merge this and generalize later. By the way, can Guix with installed on a ZFS root? -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Mon, 18 May 2020 00:50:01 GMT) Full text and rfc822 format available.Message #85 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Pierre Neidhardt <mail <at> ambrevar.xyz> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [PATCH v3] Allow booting from a Btrfs subvolume Date: Sun, 17 May 2020 20:49:38 -0400
Hi Pierre, Pierre Neidhardt <mail <at> ambrevar.xyz> writes: > About the patch: maybe some of it could be generalized to other > filesystems that support subvolumes (like ZFS). But this is probably > premature and it could be long before someone tests all this with ZFS, > thus it's probably wiser to first merge this and generalize later. > By the way, can Guix with installed on a ZFS root? I'm sorry, but I know nothing about ZFS, except that its license is incompatible with the GPL. Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Mon, 18 May 2020 01:17:01 GMT) Full text and rfc822 format available.Message #88 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Pierre Neidhardt <mail <at> ambrevar.xyz> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [PATCH v3] Allow booting from a Btrfs subvolume Date: Sun, 17 May 2020 21:16:17 -0400
Hello Pierre! Pierre Neidhardt <mail <at> ambrevar.xyz> writes: > False alarm, I had mis-merged your (old) patch. > After applying your patch from today, everything works. Woohoo! Thank you for testing! > I won't have access to this computer in 24 hours. Let me know if there > is anything else you'd like me to test before then! :) Any comments above the implementation (code) or documentation? Was something unclear/missing? If everything looks OK, I'll give this another 2 weeks period from now to allow for more comments then merge the three non-controversial (i.e., all except the hack to speed installation tests) to the master branch. Thank you! Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Mon, 18 May 2020 08:55:02 GMT) Full text and rfc822 format available.Message #91 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305 <at> debbugs.gnu.org Subject: Re: [PATCH v3] Allow booting from a Btrfs subvolume Date: Mon, 18 May 2020 10:54:46 +0200
[Message part 1 (text/plain, inline)]
Hi Maxim! >> I won't have access to this computer in 24 hours. Let me know if there >> is anything else you'd like me to test before then! :) > > Any comments above the implementation (code) or documentation? Was > something unclear/missing? I had a cursory look. The code looks good to me as far as I can tell (which is little, considering my limited knowledge of the file system code). The documentation examples are good. The paragraphs are a little bit harder to grasp for me, but I am not sure how to make it clearer; besides, the examples really help clarifying everything, so it's good enough. Thanks! -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Mon, 18 May 2020 21:57:02 GMT) Full text and rfc822 format available.Message #94 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Pierre Neidhardt <mail <at> ambrevar.xyz>, 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Mon, 18 May 2020 23:55:50 +0200
Hi Maxim, Sorry for dropping the ball for sooo long. Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis: >>From b03a574ad565b34bbe8a7d3d0322591850984dc6 Mon Sep 17 00:00:00 2001 > From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> > Date: Tue, 11 Feb 2020 14:00:06 -0500 > Subject: [PATCH 2/4] linux-boot: Refactor boot-system. > > The --root option can now be omitted, and inferred from the root file system > declaration instead. > > * gnu/build/file-systems.scm (canonicalize-device-spec): Extend to support NFS > directly, and... > * gnu/build/linux-boot.scm (boot-system): ...remove NFS special casing from > here. Remove nested definitions for root-fs-type, root-fs-flags and > root-fs-options, and bind those inside the let* instead. Make "--root" take > precedence over the device field string representation of the root file > system. > * doc/guix.texi (Initial RAM Disk): Document that "--root" can be left [...] > +++ b/gnu/build/linux-boot.scm > @@ -498,25 +498,13 @@ upon error." > (define (root-mount-point? fs) > (string=? (file-system-mount-point fs) "/")) > > - (define root-fs-type > - (or (any (lambda (fs) > - (and (root-mount-point? fs) > - (file-system-type fs))) > - mounts) > - "ext4")) > - > - (define root-fs-flags > - (mount-flags->bit-mask (or (any (lambda (fs) > - (and (root-mount-point? fs) > - (file-system-flags fs))) > - mounts) > - '()))) > - > - (define root-fs-options > - (any (lambda (fs) > - (and (root-mount-point? fs) > - (file-system-options fs))) > - mounts)) [...] > + (root-fs (find root-mount-point? mounts)) > + (root-fs-type (or (and=> root-fs file-system-type) > + "ext4")) > + (root-fs-device (and=> root-fs file-system-device)) > + (root-fs-flags (mount-flags->bit-mask > + (or (and=> root-fs file-system-flags) > + '()))) > + (root-options (if root-fs > + (file-system-options root-fs) > + #f)) I would tend to keep these as defines to make the ‘let*’ less intimidating, but it’s a detail. > + ;; XXX: Importing (guix utils) and using &fix-hint causes the > + ;; following error when booting the init RAM disk: "ERROR: In > + ;; procedure dynamic-func:\nIn procedure dynamic-pointer: Symbol not > + ;; found: strverscmp", so we just embed the hint in the message. I think it should just be “FIXME: Use &fix-hint once it no longer pulls in (guix utils).” >>From 082934db68964890ebd2a2118fb44d66911844d3 Mon Sep 17 00:00:00 2001 > From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> > Date: Sun, 14 Jul 2019 20:50:23 +0900 > Subject: [PATCH 4/4] bootloader: grub: Allow booting from a Btrfs subvolume. > > * gnu/bootloader/grub.scm (strip-mount-point): Remove procedure. > (normalize-file): Add procedure. > (grub-configuration-file): New BTRFS-SUBVOLUME-FILE-NAME parameter. When > defined, prepend its value to the kernel and initrd file names, using the > NORMALIZE-FILE procedure. Adjust the call to EYE-CANDY to pass the > BTRFS-SUBVOLUME-FILE-NAME argument. Normalize the KEYMAP file as well. > (eye-candy): Add a BTRFS-SUBVOLUME-FILE-NAME parameter, and use it, along with > the NORMALIZE-FILE procedure, to normalize the FONT-FILE and IMAGE nested > variables. Adjust doc. > * gnu/bootloader/depthcharge.scm (depthcharge-configuration-file): Adapt. > * gnu/bootloader/extlinux.scm (extlinux-configuration-file): Likewise. > * gnu/system/file-systems.scm (btrfs-subvolume?) > (btrfs-store-subvolume-file-name): New procedures. > * gnu/system.scm (operating-system-bootcfg): Specify the Btrfs > subvolume file name the store resides on to the > `operating-system-bootcfg' procedure, using the new > BTRFS-SUBVOLUME-FILE-NAME argument. > * doc/guix.texi (File Systems): Add a Btrfs subsection to document the use of > subvolumes. > * gnu/tests/install.scm: Add test "btrfs-root-on-subvolume-os". Please list the entities added to ‘install.scm’. > (define* (eye-candy config store-device store-mount-point > + btrfs-store-subvolume-file-name > #:key system port) I think ‘btrfs-store-subvolume-file-name’ should be a keyword argument. > (define* (grub-configuration-file config entries > #:key > (system (%current-system)) > - (old-entries '())) > + (old-entries '()) > + btrfs-subvolume-file-name) I wonder if we should just call it ‘store-directory-prefix’ or similar since, after all, it’s just about prepending a prefix, which could perhaps be useful for file systems other than Btrfs. Thoughts? Anyway, that’s great work, so I’ll be happy to finally see it committed in the coming days! Ludo’.
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Wed, 20 May 2020 12:45:01 GMT) Full text and rfc822 format available.Message #97 received at 37305 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Pierre Neidhardt <mail <at> ambrevar.xyz>, 37305 <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Wed, 20 May 2020 08:44:02 -0400
Hi Ludovic! Ludovic Courtès <ludo <at> gnu.org> writes: > Hi Maxim, > > Sorry for dropping the ball for sooo long. No worries :-) > Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis: [...] >> +++ b/gnu/build/linux-boot.scm >> @@ -498,25 +498,13 @@ upon error." >> (define (root-mount-point? fs) >> (string=? (file-system-mount-point fs) "/")) >> >> - (define root-fs-type >> - (or (any (lambda (fs) >> - (and (root-mount-point? fs) >> - (file-system-type fs))) >> - mounts) >> - "ext4")) >> - >> - (define root-fs-flags >> - (mount-flags->bit-mask (or (any (lambda (fs) >> - (and (root-mount-point? fs) >> - (file-system-flags fs))) >> - mounts) >> - '()))) >> - >> - (define root-fs-options >> - (any (lambda (fs) >> - (and (root-mount-point? fs) >> - (file-system-options fs))) >> - mounts)) > > [...] > >> + (root-fs (find root-mount-point? mounts)) >> + (root-fs-type (or (and=> root-fs file-system-type) >> + "ext4")) >> + (root-fs-device (and=> root-fs file-system-device)) >> + (root-fs-flags (mount-flags->bit-mask >> + (or (and=> root-fs file-system-flags) >> + '()))) >> + (root-options (if root-fs >> + (file-system-options root-fs) >> + #f)) > > I would tend to keep these as defines to make the ‘let*’ less > intimidating, but it’s a detail. It would only *appear* less intimidating ;-). I personally prefer the let* versions as the logic is more succinctly expressed (there is no need for 'any' + lambdas, for example). >> + ;; XXX: Importing (guix utils) and using &fix-hint causes the >> + ;; following error when booting the init RAM disk: "ERROR: In >> + ;; procedure dynamic-func:\nIn procedure dynamic-pointer: Symbol not >> + ;; found: strverscmp", so we just embed the hint in the message. > > I think it should just be “FIXME: Use &fix-hint once it no longer pulls > in (guix utils).” Done! >>>From 082934db68964890ebd2a2118fb44d66911844d3 Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> >> Date: Sun, 14 Jul 2019 20:50:23 +0900 >> Subject: [PATCH 4/4] bootloader: grub: Allow booting from a Btrfs subvolume. >> >> * gnu/bootloader/grub.scm (strip-mount-point): Remove procedure. >> (normalize-file): Add procedure. >> (grub-configuration-file): New BTRFS-SUBVOLUME-FILE-NAME parameter. When >> defined, prepend its value to the kernel and initrd file names, using the >> NORMALIZE-FILE procedure. Adjust the call to EYE-CANDY to pass the >> BTRFS-SUBVOLUME-FILE-NAME argument. Normalize the KEYMAP file as well. >> (eye-candy): Add a BTRFS-SUBVOLUME-FILE-NAME parameter, and use it, along with >> the NORMALIZE-FILE procedure, to normalize the FONT-FILE and IMAGE nested >> variables. Adjust doc. >> * gnu/bootloader/depthcharge.scm (depthcharge-configuration-file): Adapt. >> * gnu/bootloader/extlinux.scm (extlinux-configuration-file): Likewise. >> * gnu/system/file-systems.scm (btrfs-subvolume?) >> (btrfs-store-subvolume-file-name): New procedures. >> * gnu/system.scm (operating-system-bootcfg): Specify the Btrfs >> subvolume file name the store resides on to the >> `operating-system-bootcfg' procedure, using the new >> BTRFS-SUBVOLUME-FILE-NAME argument. >> * doc/guix.texi (File Systems): Add a Btrfs subsection to document the use of >> subvolumes. >> * gnu/tests/install.scm: Add test "btrfs-root-on-subvolume-os". > > Please list the entities added to ‘install.scm’. Done! >> (define* (eye-candy config store-device store-mount-point >> + btrfs-store-subvolume-file-name >> #:key system port) > > I think ‘btrfs-store-subvolume-file-name’ should be a keyword argument. Done! >> (define* (grub-configuration-file config entries >> #:key >> (system (%current-system)) >> - (old-entries '())) >> + (old-entries '()) >> + btrfs-subvolume-file-name) > > I wonder if we should just call it ‘store-directory-prefix’ or similar > since, after all, it’s just about prepending a prefix, which could > perhaps be useful for file systems other than Btrfs. > > Thoughts? Perhaps, but given it's not yet clear whether another file system will require similar support from GRUB, I'd rather keep things as explicit as possible for now. > Anyway, that’s great work, so I’ll be happy to finally see it committed > in the coming days! Thanks for the great words and for having a last look :-). I've added a news entry and pushed to master as: --8<---------------cut here---------------start------------->8--- 489699c456 allow-booting-from-btrfs-subvolume news: Add entry for Btrfs subvolume boot support. b460ba7992 bootloader: grub: Allow booting from a Btrfs subvolume. fa35fb58c8 file-systems: Add helpers for parsing the options string into an alist. 281d80d8e5 linux-boot: Refactor boot-system. --8<---------------cut here---------------end--------------->8--- Closing! Thanks to Pierre and Ludovic for testing and reviewing. Maxim
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:Message #102 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Pierre Neidhardt <mail <at> ambrevar.xyz>, 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Wed, 20 May 2020 08:44:13 -0400
Hi Ludovic! Ludovic Courtès <ludo <at> gnu.org> writes: > Hi Maxim, > > Sorry for dropping the ball for sooo long. No worries :-) > Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis: [...] >> +++ b/gnu/build/linux-boot.scm >> @@ -498,25 +498,13 @@ upon error." >> (define (root-mount-point? fs) >> (string=? (file-system-mount-point fs) "/")) >> >> - (define root-fs-type >> - (or (any (lambda (fs) >> - (and (root-mount-point? fs) >> - (file-system-type fs))) >> - mounts) >> - "ext4")) >> - >> - (define root-fs-flags >> - (mount-flags->bit-mask (or (any (lambda (fs) >> - (and (root-mount-point? fs) >> - (file-system-flags fs))) >> - mounts) >> - '()))) >> - >> - (define root-fs-options >> - (any (lambda (fs) >> - (and (root-mount-point? fs) >> - (file-system-options fs))) >> - mounts)) > > [...] > >> + (root-fs (find root-mount-point? mounts)) >> + (root-fs-type (or (and=> root-fs file-system-type) >> + "ext4")) >> + (root-fs-device (and=> root-fs file-system-device)) >> + (root-fs-flags (mount-flags->bit-mask >> + (or (and=> root-fs file-system-flags) >> + '()))) >> + (root-options (if root-fs >> + (file-system-options root-fs) >> + #f)) > > I would tend to keep these as defines to make the ‘let*’ less > intimidating, but it’s a detail. It would only *appear* less intimidating ;-). I personally prefer the let* versions as the logic is more succinctly expressed (there is no need for 'any' + lambdas, for example). >> + ;; XXX: Importing (guix utils) and using &fix-hint causes the >> + ;; following error when booting the init RAM disk: "ERROR: In >> + ;; procedure dynamic-func:\nIn procedure dynamic-pointer: Symbol not >> + ;; found: strverscmp", so we just embed the hint in the message. > > I think it should just be “FIXME: Use &fix-hint once it no longer pulls > in (guix utils).” Done! >>>From 082934db68964890ebd2a2118fb44d66911844d3 Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> >> Date: Sun, 14 Jul 2019 20:50:23 +0900 >> Subject: [PATCH 4/4] bootloader: grub: Allow booting from a Btrfs subvolume. >> >> * gnu/bootloader/grub.scm (strip-mount-point): Remove procedure. >> (normalize-file): Add procedure. >> (grub-configuration-file): New BTRFS-SUBVOLUME-FILE-NAME parameter. When >> defined, prepend its value to the kernel and initrd file names, using the >> NORMALIZE-FILE procedure. Adjust the call to EYE-CANDY to pass the >> BTRFS-SUBVOLUME-FILE-NAME argument. Normalize the KEYMAP file as well. >> (eye-candy): Add a BTRFS-SUBVOLUME-FILE-NAME parameter, and use it, along with >> the NORMALIZE-FILE procedure, to normalize the FONT-FILE and IMAGE nested >> variables. Adjust doc. >> * gnu/bootloader/depthcharge.scm (depthcharge-configuration-file): Adapt. >> * gnu/bootloader/extlinux.scm (extlinux-configuration-file): Likewise. >> * gnu/system/file-systems.scm (btrfs-subvolume?) >> (btrfs-store-subvolume-file-name): New procedures. >> * gnu/system.scm (operating-system-bootcfg): Specify the Btrfs >> subvolume file name the store resides on to the >> `operating-system-bootcfg' procedure, using the new >> BTRFS-SUBVOLUME-FILE-NAME argument. >> * doc/guix.texi (File Systems): Add a Btrfs subsection to document the use of >> subvolumes. >> * gnu/tests/install.scm: Add test "btrfs-root-on-subvolume-os". > > Please list the entities added to ‘install.scm’. Done! >> (define* (eye-candy config store-device store-mount-point >> + btrfs-store-subvolume-file-name >> #:key system port) > > I think ‘btrfs-store-subvolume-file-name’ should be a keyword argument. Done! >> (define* (grub-configuration-file config entries >> #:key >> (system (%current-system)) >> - (old-entries '())) >> + (old-entries '()) >> + btrfs-subvolume-file-name) > > I wonder if we should just call it ‘store-directory-prefix’ or similar > since, after all, it’s just about prepending a prefix, which could > perhaps be useful for file systems other than Btrfs. > > Thoughts? Perhaps, but given it's not yet clear whether another file system will require similar support from GRUB, I'd rather keep things as explicit as possible for now. > Anyway, that’s great work, so I’ll be happy to finally see it committed > in the coming days! Thanks for the great words and for having a last look :-). I've added a news entry and pushed to master as: --8<---------------cut here---------------start------------->8--- 489699c456 allow-booting-from-btrfs-subvolume news: Add entry for Btrfs subvolume boot support. b460ba7992 bootloader: grub: Allow booting from a Btrfs subvolume. fa35fb58c8 file-systems: Add helpers for parsing the options string into an alist. 281d80d8e5 linux-boot: Refactor boot-system. --8<---------------cut here---------------end--------------->8--- Closing! Thanks to Pierre and Ludovic for testing and reviewing. Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Wed, 20 May 2020 13:30:01 GMT) Full text and rfc822 format available.Message #105 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Ludovic Courtès <ludo <at> gnu.org> Cc: 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Wed, 20 May 2020 15:29:34 +0200
[Message part 1 (text/plain, inline)]
Thanks a lot! This is a huge improvement to Guix in my opinion :) -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Wed, 20 May 2020 22:04:02 GMT) Full text and rfc822 format available.Message #108 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Pierre Neidhardt <mail <at> ambrevar.xyz>, 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Thu, 21 May 2020 00:03:47 +0200
Hi Maxim, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis: [...] >>> (define* (grub-configuration-file config entries >>> #:key >>> (system (%current-system)) >>> - (old-entries '())) >>> + (old-entries '()) >>> + btrfs-subvolume-file-name) >> >> I wonder if we should just call it ‘store-directory-prefix’ or similar >> since, after all, it’s just about prepending a prefix, which could >> perhaps be useful for file systems other than Btrfs. >> >> Thoughts? > > Perhaps, but given it's not yet clear whether another file system will > require similar support from GRUB, I'd rather keep things as explicit as > possible for now. To me, another consideration is familiarity with Btrfs for those who’ll touch the code: to someone not familiar with it, the code may be viewed as “read-only” because it says “btrfs”. Whereas if it clearly states that it’s just about prepending a directory name or similar, it’s easy to reason about it. >> Anyway, that’s great work, so I’ll be happy to finally see it committed >> in the coming days! > > Thanks for the great words and for having a last look :-). > > I've added a news entry and pushed to master as: > > 489699c456 allow-booting-from-btrfs-subvolume news: Add entry for Btrfs subvolume boot support. > b460ba7992 bootloader: grub: Allow booting from a Btrfs subvolume. > fa35fb58c8 file-systems: Add helpers for parsing the options string into an alist. > 281d80d8e5 linux-boot: Refactor boot-system. > > Closing! Thanks to Pierre and Ludovic for testing and reviewing. That’s great news, thanks a lot for your work… and for your patience! Ludo’.
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Thu, 21 May 2020 06:59:02 GMT) Full text and rfc822 format available.Message #111 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Ludovic Courtès <ludo <at> gnu.org>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Thu, 21 May 2020 08:58:30 +0200
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes: > To me, another consideration is familiarity with Btrfs for those who’ll > touch the code: to someone not familiar with it, the code may be viewed > as “read-only” because it says “btrfs”. Whereas if it clearly states > that it’s just about prepending a directory name or similar, it’s easy > to reason about it. Agreed, this is where I was going to with my comment on ZFS. Maybe the "btrfs" part of the symbols can be left out to make it more general and understandable. -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Thu, 28 May 2020 04:31:01 GMT) Full text and rfc822 format available.Message #114 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Pierre Neidhardt <mail <at> ambrevar.xyz> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Thu, 28 May 2020 00:30:17 -0400
[Message part 1 (text/plain, inline)]
Hello, Pierre Neidhardt <mail <at> ambrevar.xyz> writes: > Ludovic Courtès <ludo <at> gnu.org> writes: > >> To me, another consideration is familiarity with Btrfs for those who’ll >> touch the code: to someone not familiar with it, the code may be viewed >> as “read-only” because it says “btrfs”. Whereas if it clearly states >> that it’s just about prepending a directory name or similar, it’s easy >> to reason about it. > > Agreed, this is where I was going to with my comment on ZFS. > Maybe the "btrfs" part of the symbols can be left out to make it more > general and understandable. I've adapted with the naming suggested earlier by Ludovic. Does the patch below fit the bill? Thanks, Maxim
[0001-bootloader-grub-Rename-the-btrfs-subvolume-file-name.patch (text/x-patch, attachment)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Thu, 28 May 2020 08:27:01 GMT) Full text and rfc822 format available.Message #117 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Thu, 28 May 2020 10:26:49 +0200
[Message part 1 (text/plain, inline)]
Looks good to me, but: > (btrfs-store-subvolume-file-name file-systems)))) I haven't looked at the context, but is this procedure really Btrfs-only? -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Thu, 28 May 2020 12:31:01 GMT) Full text and rfc822 format available.Message #120 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Pierre Neidhardt <mail <at> ambrevar.xyz>, 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Thu, 28 May 2020 14:30:14 +0200
Hello! Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis: > From ee23cc391cce7b8dcdcb5146d4b84a55881a5cb9 Mon Sep 17 00:00:00 2001 > From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> > Date: Wed, 27 May 2020 22:44:28 -0400 > Subject: [PATCH] bootloader: grub: Rename the btrfs-subvolume-file-name > parameter. > > Following discussion in <https://issues.guix.gnu.org/37305>, it seems more > appropriate to give the parameter a more generic name that better describes > what it does. > > * gnu/bootloader/grub.scm (normalize-file): Rename the > btrfs-subvolume-file-name parameter to store-directory-prefix. > (eye-candy): Likewise. > (grub-configuration-file): Likewise. > * gnu/system.scm (operating-system-bootcfg): Adapt. [...] > (define* (eye-candy config store-device store-mount-point > - #:key btrfs-store-subvolume-file-name system port) > + #:key store-directory-prefix system port) > "Return a gexp that writes to PORT (a port-valued gexp) the 'grub.cfg' part > concerned with graphics mode, background images, colors, and all that. > STORE-DEVICE designates the device holding the store, and STORE-MOUNT-POINT is > its mount point; these are used to determine where the background image and > fonts must be searched for. SYSTEM must be the target system string---e.g., > -\"x86_64-linux\". BTRFS-STORE-SUBVOLUME-FILE-NAME is the file name of the > -Btrfs subvolume, to be prepended to any store path, if any." > +\"x86_64-linux\". STORE-DIRECTORY-PREFIX is a directory prefix to prepend to > +any store path." s/path/file name/ :-) Maybe you can have ‘store-directory-prefix’ default to "" and adjust users accordingly. Otherwise LGTM. Thanks for taking the time to work on this patch! Ludo’.
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Fri, 29 May 2020 21:15:02 GMT) Full text and rfc822 format available.Message #123 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Pierre Neidhardt <mail <at> ambrevar.xyz> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Fri, 29 May 2020 17:14:36 -0400
Pierre Neidhardt <mail <at> ambrevar.xyz> writes: > Looks good to me, but: > >> (btrfs-store-subvolume-file-name file-systems)))) > > I haven't looked at the context, but is this procedure really Btrfs-only? Yes! It takes a list of file-system objects, filter the Btrfs ones using the "subvol" option and returns their subvolume file name, if the store is mounted on such subvolume.
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sat, 30 May 2020 02:01:01 GMT) Full text and rfc822 format available.Message #126 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Pierre Neidhardt <mail <at> ambrevar.xyz>, 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Fri, 29 May 2020 22:00:17 -0400
Hello, Ludovic Courtès <ludo <at> gnu.org> writes: [...] >> +\"x86_64-linux\". STORE-DIRECTORY-PREFIX is a directory prefix to prepend to >> +any store path." > > s/path/file name/ :-) Done! > Maybe you can have ‘store-directory-prefix’ default to "" and adjust > users accordingly. I tried adapting it, but my test failed, because I had failed to adapt one of the users. I find that using #f to denote the absence of a prefix more accurate than "" (after all, "" is a valid prefix) and composes better (should we want to 'or' a couple of prefix seeking procedures together). > Otherwise LGTM. > > Thanks for taking the time to work on this patch! No problem :-) Pushed as commit e7b86a0d88. Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sat, 30 May 2020 07:33:02 GMT) Full text and rfc822 format available.Message #129 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Ludovic Courtès <ludo <at> gnu.org> Cc: 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Sat, 30 May 2020 09:32:39 +0200
[Message part 1 (text/plain, inline)]
Hooray! -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sat, 30 May 2020 07:34:01 GMT) Full text and rfc822 format available.Message #132 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Ludovic Courtès <ludo <at> gnu.org> Cc: 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Sat, 30 May 2020 09:32:56 +0200
[Message part 1 (text/plain, inline)]
Maybe this would warrant a blog post! :) -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 31 May 2020 02:45:02 GMT) Full text and rfc822 format available.Message #135 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Pierre Neidhardt <mail <at> ambrevar.xyz> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Sat, 30 May 2020 22:44:00 -0400
Hello Pierre! Pierre Neidhardt <mail <at> ambrevar.xyz> writes: > Maybe this would warrant a blog post! :) Eh, I'm not sure. It's kind of a basic thing that other systems already support (through grub-mkconfig). We've just caught up :-). Maxim
guix-patches <at> gnu.org:bug#37305; Package guix-patches.
(Sun, 31 May 2020 07:34:02 GMT) Full text and rfc822 format available.Message #138 received at 37305-done <at> debbugs.gnu.org (full text, mbox):
From: Pierre Neidhardt <mail <at> ambrevar.xyz> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 37305-done <at> debbugs.gnu.org Subject: Re: [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Date: Sun, 31 May 2020 09:32:59 +0200
[Message part 1 (text/plain, inline)]
Sure, but I don't know how popular Btrfs is, plus compression is a very welcome addition to Guix (for all those SSD users with little space :p). Granted, this is not very Guix specific... -- Pierre Neidhardt https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Sun, 28 Jun 2020 11:24:04 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.