From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: 37305@debbugs.gnu.org
Subject: [bug#37305] [PATCH] Allow booting from a Btrfs subvolume.
Date: Sun, 22 Sep 2019 23:43:03 +0200 [thread overview]
Message-ID: <87y2yg3t3s.fsf@gnu.org> (raw)
In-Reply-To: <87sgpby4p9.fsf@gmail.com> (Maxim Cournoyer's message of "Thu, 05 Sep 2019 09:20:02 +0900")
Hi!
Maxim Cournoyer <maxim.cournoyer@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@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@gmail.com>
> ;;; Copyright © 2017 Leo Famulari <leo@famulari.name>
> ;;; Copyright © 2017 Mathieu Othacehe <m.othacehe@gmail.com>
> +;;; Copyright © 2019 Maxim Cournoyer <maxim.cournoyer@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@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@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@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’.
next prev parent reply other threads:[~2019-09-22 21:44 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 0:20 [bug#37305] [PATCH] Allow booting from a Btrfs subvolume Maxim Cournoyer
2019-09-08 16:10 ` Christopher Baines
2019-09-22 21:43 ` Ludovic Courtès [this message]
2020-02-12 8:47 ` Maxim Cournoyer
2020-02-13 20:27 ` [bug#37305] [PATCH V2] " Maxim Cournoyer
2020-02-14 17:22 ` Ludovic Courtès
2020-02-16 5:36 ` Maxim Cournoyer
2020-02-16 11:11 ` [bug#37305] Making system installation tests faster Ludovic Courtès
2020-02-18 13:37 ` Maxim Cournoyer
2020-02-18 21:27 ` Maxim Cournoyer
2020-03-07 4:01 ` Maxim Cournoyer
2020-02-24 16:02 ` [bug#37305] [PATCH V2] Allow booting from a Btrfs subvolume Ludovic Courtès
2020-03-03 5:00 ` Maxim Cournoyer
2020-02-24 14:23 ` [bug#37305] [PATCH V3] " Maxim Cournoyer
2020-02-19 2:52 ` [bug#37305] Allow booting from a Btrfs subvolume [review part 2] Maxim Cournoyer
2020-02-20 9:55 ` Ludovic Courtès
2020-03-18 15:27 ` maxim.cournoyer
2020-05-17 13:29 ` Pierre Neidhardt
2020-05-17 16:13 ` [bug#37305] [PATCH v3] Allow booting from a Btrfs subvolume Maxim Cournoyer
2020-05-17 16:37 ` Pierre Neidhardt
2020-05-17 19:05 ` Pierre Neidhardt
2020-05-17 19:09 ` Pierre Neidhardt
2020-05-17 19:48 ` Pierre Neidhardt
2020-05-18 1:16 ` Maxim Cournoyer
2020-05-18 8:54 ` Pierre Neidhardt
2020-05-17 20:22 ` Pierre Neidhardt
2020-05-18 0:49 ` Maxim Cournoyer
2020-05-18 21:55 ` Ludovic Courtès
2020-05-20 12:44 ` Maxim Cournoyer
2020-05-20 12:44 ` bug#37305: " Maxim Cournoyer
2020-05-20 13:29 ` [bug#37305] " Pierre Neidhardt
2020-05-20 22:03 ` Ludovic Courtès
2020-05-21 6:58 ` Pierre Neidhardt
2020-05-28 4:30 ` Maxim Cournoyer
2020-05-28 8:26 ` Pierre Neidhardt
2020-05-29 21:14 ` Maxim Cournoyer
2020-05-28 12:30 ` Ludovic Courtès
2020-05-30 2:00 ` Maxim Cournoyer
2020-05-30 7:32 ` Pierre Neidhardt
2020-05-30 7:32 ` Pierre Neidhardt
2020-05-31 2:44 ` Maxim Cournoyer
2020-05-31 7:32 ` Pierre Neidhardt
2020-05-17 14:03 ` [bug#37305] Allow booting from a Btrfs subvolume [review part 2] Pierre Neidhardt
2020-05-17 16:16 ` Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y2yg3t3s.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=37305@debbugs.gnu.org \
--cc=maxim.cournoyer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).