guix system disk-image -t raw fails with grub-efi-bootloader

  • Done
  • quality assurance status badge
Details
5 participants
  • Bengt Richter
  • Jesse Gibbons
  • Ludovic Courtès
  • Maxim Cournoyer
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Jesse Gibbons
Severity
normal
J
J
Jesse Gibbons wrote on 31 Oct 2020 17:47
(address . bug-guix@gnu.org)
1e589f3b-47f8-fd53-b750-d2beff8d91f5@gmail.com
To replicate:
cd to a git checkout of the source code, gnu/system/examples
The hash for my current checkout is
d7e033b9a153a9e60f52ff64f4eb355c1c3d0a6e which is also the hash for my
current version of guix.
guix system disk-image -t raw lightweight-desktop.tmpl

lightweight-desktop.tmpl defines an operating-system that uses
grub-efi-bootloader, and is embedded in the info pages as an example
operating system. Since it is lightweight, it doesn't take as long to
build as desktop.tmpl.

Expected results: guix builds the raw image just fine, and that image
can be copied to an SD card and run on a computer with an efi
bootloader, just like the counterpart with grub-bootloader. There is
nothing in the documentation suggesting that this should not work by design.

Actual results: guix fails, see attached log.

-Jesse
M
M
Maxim Cournoyer wrote on 7 Nov 2020 08:09
(name . Jesse Gibbons)(address . jgibbons2357@gmail.com)
87lffdtzh1.fsf@gmail.com
Hello!

Jesse Gibbons <jgibbons2357@gmail.com> writes:

Toggle quote (22 lines)
> To replicate:
> cd to a git checkout of the source code, gnu/system/examples
> The hash for my current checkout is
> d7e033b9a153a9e60f52ff64f4eb355c1c3d0a6e which is also the hash for my
> current version of guix.
> guix system disk-image -t raw lightweight-desktop.tmpl
>
> lightweight-desktop.tmpl defines an operating-system that uses
> grub-efi-bootloader, and is embedded in the info pages as an example
> operating system. Since it is lightweight, it doesn't take as long to
> build as desktop.tmpl.
>
> Expected results: guix builds the raw image just fine, and that image
> can be copied to an SD card and run on a computer with an efi
> bootloader, just like the counterpart with grub-bootloader. There is
> nothing in the documentation suggesting that this should not work by
> design.
>
> Actual results: guix fails, see attached log.
>
> -Jesse

Thank you for the report!

I'm CC'ing Mathieu as he knows this part of the code much better than I
do, having overhauled the generation of disk images recently!

Below are two patches I made while investigating this. Mathieu, does
that look like a proper fix? It allows images to be generated, but I'm
unsure whether they'd be bootable (I couldn't successfully boot either
EFI or MBR GRUB-based disk images in QEMU).

Anyway, attached are the patches.

Thank you!

Maxim
From 557a938633ed55c41aed8b41a0f93b6151f00943 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Fri, 6 Nov 2020 21:37:33 -0500
Subject: [PATCH 1/2] build: image: Ensure required arguments are present.

* gnu/build/image.scm (initialize-root-partition): Validate arguments.
[system-directory, references-graph]: Change from keyword to positional
arguments.
[doc]: Add space between sentences.
* gnu/system/image.scm (system-iso9660-image): Adjust.
---
gnu/build/image.scm | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)

Toggle diff (44 lines)
diff --git a/gnu/build/image.scm b/gnu/build/image.scm
index 640a784204..053972166b 100644
--- a/gnu/build/image.scm
+++ b/gnu/build/image.scm
@@ -5,6 +5,7 @@
;;; Copyright © 2017 Marius Bakke <mbakke@fastmail.com>
;;; Copyright © 2020 Tobias Geerinckx-Rice <me@tobias.gr>
;;; Copyright © 2020 Mathieu Othacehe <m.othacehe@gmail.com>
+;;; Copyright © 2020 Maxim Cournoyer <maxim.cournoyer@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -179,7 +180,7 @@ to call-with-database."
make-device-nodes
(wal-mode? #t)
#:allow-other-keys)
- "Initialize the given ROOT directory. Use BOOTCFG and BOOTCFG-LOCATION to
+ "Initialize the given ROOT directory. Use BOOTCFG and BOOTCFG-LOCATION to
install the bootloader configuration.
If REGISTER-CLOSURES? is true, register REFERENCES-GRAPHS in the store. If
@@ -187,6 +188,20 @@ DEDUPLICATE? is true, then also deduplicate files common to CLOSURES and the
rest of the store when registering the closures. SYSTEM-DIRECTORY is the name
of the directory of the 'system' derivation. Pass WAL-MODE? to
register-closure."
+
+ (define (validate-arguments)
+ (when bootcfg
+ (unless bootcfg-location
+ (error "Missing 'bootcfg-location' argument")))
+ (when bootloader-installer
+ (unless bootloader-package
+ (error "Missing 'bootloader-package' argument")))
+ (unless references-graphs
+ (error "Missing 'references-graphs' argument"))
+ (unless system-directory
+ (error "Missing 'system-directory' argument")))
+
+ (validate-arguments)
(populate-root-file-system system-directory root)
(populate-store references-graphs root)
--
2.28.0
From c642a6984d4961256f50ca5133d1eec5ca1af4e9 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Sat, 7 Nov 2020 00:20:49 -0500
Subject: [PATCH 2/2] image: Only attempt bootloader installation when
supported.


The initialize-root-partition in (guix build image) attempts to install a
bootloader when BOOTLOADER-INSTALLER is defined. Unfortunately, it relies on
a special #f value for the second argument (device), which only the
INSTALL-GRUB procedure from (gnu bootloader grub) supports.

* gnu/system/image.scm (system-disk-image): Only pass the bootloader installer
argument when the bootloader name is 'grub. Add comment.
---
gnu/system/image.scm | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

Toggle diff (24 lines)
diff --git a/gnu/system/image.scm b/gnu/system/image.scm
index 4075a26552..d4932466e5 100644
--- a/gnu/system/image.scm
+++ b/gnu/system/image.scm
@@ -345,8 +345,16 @@ used in the image."
#:grub-efi #+grub-efi
#:bootloader-package
#+(bootloader-package bootloader)
+ ;; Special case: most bootloaders can be copied
+ ;; directly at some fixed location on the image
+ ;; disk, but when installed to the master boot
+ ;; record (MBR), GRUB requires support files
+ ;; present under /boot/grub, which is handled by
+ ;; its 'installer' procedure.
#:bootloader-installer
- #+(bootloader-installer bootloader)
+ #+(if (eq? 'grub (bootloader-name bootloader))
+ (bootloader-installer bootloader)
+ #f)
#:bootcfg #$bootcfg
#:bootcfg-location
#$(bootloader-configuration-file bootloader))
--
2.28.0
M
M
Maxim Cournoyer wrote on 7 Nov 2020 08:09
control message for bug #44353
(address . control@debbugs.gnu.org)
87k0uxtzgu.fsf@gmail.com
tags 44353 + patch
quit
M
M
Mathieu Othacehe wrote on 7 Nov 2020 10:08
Re: bug#44353: guix system disk-image -t raw fails with grub-efi-bootloader
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
875z6hmt4b.fsf@gnu.org
Hello Maxim,

Thanks for your patch! It's hard to provide a reliable abstraction on
top of all the exotic bootloader installation methods existing.

Currently, each bootloader implements two methods:

* bootloader-installer
* bootloader-disk-image-installer

The first one is dedicated to the installation of the bootloader on a
mounted directory, while the second one is meant to work on a disk
device such as "/dev/sda" or directly on a disk-image.

When producing a disk-image with the "raw" type, we are always creating
and populating an ESP partition (see raw-image-type), regardless of the
selected bootloader. In fact, "raw" should be renamed to "hybrid-efi".

The produced image can work on machines with legacy mbr boot or with EFI
boot. Hence, calling "install-grub-efi" like it's done while building
the lightweight-desktop operating-system is useless and fails. The
attached patch fixes it.

You can test it with:

Toggle snippet (3 lines)
qemu-system-x86_64 -m 1024 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin -hda disk.img

Toggle quote (12 lines)
> + ;; Special case: most bootloaders can be copied
> + ;; directly at some fixed location on the image
> + ;; disk, but when installed to the master boot
> + ;; record (MBR), GRUB requires support files
> + ;; present under /boot/grub, which is handled by
> + ;; its 'installer' procedure.
> #:bootloader-installer
> - #+(bootloader-installer bootloader)
> + #+(if (eq? 'grub (bootloader-name bootloader))
> + (bootloader-installer bootloader)
> + #f)

That would prevent other bootloaders relying on this procedure to work,
such as extlinux.

Thanks,

Mathieu
From 2145fc40d3eb949885ce94883b09c7291c607be6 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <othacehe@gnu.org>
Date: Sat, 7 Nov 2020 10:03:53 +0100
Subject: [PATCH] bootloader: grub: Fix EFI installation.

When producing a disk-image, "install-grub-efi" will be called with EFI-DIR
set to false. The EFI bootloader is already installed by
"initialize-efi-partition". In that case, do not proceed to bootloader
installation.


* gnu/bootloader/grub.scm (install-grub-efi): Do not install the bootloader if
EFI-DIR is false.
---
gnu/bootloader/grub.scm | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)

Toggle diff (45 lines)
diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index 0899fab61f..3404456df9 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -574,20 +574,24 @@ fi~%"))))
(define install-grub-efi
#~(lambda (bootloader efi-dir mount-point)
;; Install GRUB onto the EFI partition mounted at EFI-DIR, for the
- ;; system whose root is mounted at MOUNT-POINT.
- (let ((grub-install (string-append bootloader "/sbin/grub-install"))
- (install-dir (string-append mount-point "/boot"))
- ;; When installing Guix, it's common to mount EFI-DIR below
- ;; MOUNT-POINT rather than /boot/efi on the live image.
- (target-esp (if (file-exists? (string-append mount-point efi-dir))
- (string-append mount-point efi-dir)
- efi-dir)))
- ;; Tell 'grub-install' that there might be a LUKS-encrypted /boot or
- ;; root partition.
- (setenv "GRUB_ENABLE_CRYPTODISK" "y")
- (invoke/quiet grub-install "--boot-directory" install-dir
- "--bootloader-id=Guix"
- "--efi-directory" target-esp))))
+ ;; system whose root is mounted at MOUNT-POINT. When producing a
+ ;; disk-image, EFI-DIR is false and the EFI bootloader is already
+ ;; installed using "initialize-efi-partition".
+ (when efi-dir
+ (let ((grub-install (string-append bootloader "/sbin/grub-install"))
+ (install-dir (string-append mount-point "/boot"))
+ ;; When installing Guix, it's common to mount EFI-DIR below
+ ;; MOUNT-POINT rather than /boot/efi on the live image.
+ (target-esp (if (file-exists?
+ (string-append mount-point efi-dir))
+ (string-append mount-point efi-dir)
+ efi-dir)))
+ ;; Tell 'grub-install' that there might be a LUKS-encrypted /boot or
+ ;; root partition.
+ (setenv "GRUB_ENABLE_CRYPTODISK" "y")
+ (invoke/quiet grub-install "--boot-directory" install-dir
+ "--bootloader-id=Guix"
+ "--efi-directory" target-esp)))))
(define (install-grub-efi-netboot subdir)
"Define a grub-efi-netboot bootloader installer for installation in SUBDIR,
--
2.29.2
B
B
Bengt Richter wrote on 7 Nov 2020 12:26
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
20201107112617.GA2716@LionPure
Hi Mathieu,

On +2020-11-07 10:08:36 +0100, Mathieu Othacehe wrote:
Toggle quote (49 lines)
>
> Hello Maxim,
>
> Thanks for your patch! It's hard to provide a reliable abstraction on
> top of all the exotic bootloader installation methods existing.
>
> Currently, each bootloader implements two methods:
>
> * bootloader-installer
> * bootloader-disk-image-installer
>
> The first one is dedicated to the installation of the bootloader on a
> mounted directory, while the second one is meant to work on a disk
> device such as "/dev/sda" or directly on a disk-image.
>
> When producing a disk-image with the "raw" type, we are always creating
> and populating an ESP partition (see raw-image-type), regardless of the
> selected bootloader. In fact, "raw" should be renamed to "hybrid-efi".
>
> The produced image can work on machines with legacy mbr boot or with EFI
> boot. Hence, calling "install-grub-efi" like it's done while building
> the lightweight-desktop operating-system is useless and fails. The
> attached patch fixes it.
>
> You can test it with:
>
> --8<---------------cut here---------------start------------->8---
> qemu-system-x86_64 -m 1024 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin -hda disk.img
> --8<---------------cut here---------------end--------------->8---
>
> > + ;; Special case: most bootloaders can be copied
> > + ;; directly at some fixed location on the image
> > + ;; disk, but when installed to the master boot
> > + ;; record (MBR), GRUB requires support files
> > + ;; present under /boot/grub, which is handled by
> > + ;; its 'installer' procedure.
> > #:bootloader-installer
> > - #+(bootloader-installer bootloader)
> > + #+(if (eq? 'grub (bootloader-name bootloader))
> > + (bootloader-installer bootloader)
> > + #f)
>
> That would prevent other bootloaders relying on this procedure to work,
> such as extlinux.
>
> Thanks,
>
> Mathieu

Given that writing to "raw" disks is something the dd command is often used for,
how much trouble would it be to provide an option for bootloader-disk-image-installer
to output a shell script with the necessary dd commands, instead of doing the raw writing itself?

I am imagining a tarball with separate binary block-sequence file images for the GPT or MBR
header blocks, the embedded boot loader or UEFI partition image, and root partition
etc..

I think the block-sequence images can be sliced out of the backing file of a loopback mount that
fdisk and mkfs.* can format as desired, unless I'm missing something.

I would like the script to use lsblk -o model,serial to identify the raw disk to write to,
so there is no shooting the wrong foot ;)

This is sketchy on the details, but ISTM a tarball like this would make it easy to prepare
a USB-accessible disk using any laptop that was in a state where it was trusted to do
sudo dd ... right.

If the laptop didn't have all the tools, perhaps a minimal static busybox could be included
in the tarball to guarantee existence of the dd and lsblk tools etc.

There might be some file content that needs to be written with file i/o after dd has written
the content-initialized monolith file system images. This could be interactive choices of alternate
hostname, passwords, or whatever.

Remember, this script is not burning a bootable installer (though it could), it is burning
the bootable system an installer would install.

The point of this is that it happens as the script with the dd commands executes on an arbitrary
laptop with a raw USB disk attached, not as initialization dialog on first boot of the system
whose image is being written to the USB disk.

Obviously all files should be verifiable one way or another.

Hopefully it would also make it easier to share/generate system images for raspberries or RISC-V ARM, etc.

I guess you could call this a shell-script derivation, meant to talk to bash/dd instead of the guix daemon.

Has anyone done this kind of factoring already?

TIA for comment :)
--
Regards,
Bengt Richter
M
M
Maxim Cournoyer wrote on 7 Nov 2020 21:32
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
877dqwucum.fsf@gmail.com
Hello Mathieu!

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (23 lines)
> Hello Maxim,
>
> Thanks for your patch! It's hard to provide a reliable abstraction on
> top of all the exotic bootloader installation methods existing.
>
> Currently, each bootloader implements two methods:
>
> * bootloader-installer
> * bootloader-disk-image-installer
>
> The first one is dedicated to the installation of the bootloader on a
> mounted directory, while the second one is meant to work on a disk
> device such as "/dev/sda" or directly on a disk-image.
>
> When producing a disk-image with the "raw" type, we are always creating
> and populating an ESP partition (see raw-image-type), regardless of the
> selected bootloader. In fact, "raw" should be renamed to "hybrid-efi".
>
> The produced image can work on machines with legacy mbr boot or with EFI
> boot. Hence, calling "install-grub-efi" like it's done while building
> the lightweight-desktop operating-system is useless and fails. The
> attached patch fixes it.

Thank you for the clarifications!

Toggle quote (5 lines)
> You can test it with:
>
> qemu-system-x86_64 -m 1024 -bios $(guix build
> ovmf)/share/firmware/ovmf_x64.bin -hda disk.img

Thank you! I hadn't realized that the default SeaBIOS BIOS used by QEMU
wasn't EFI-capable! The image now boots, but fails bringing up its file
systems for some reason. Perhaps I'm supposed to edit the file system
definitions of the template before use?

Here's how I tested it:

$ time ./pre-inst-env guix system disk-image
gnu/system/examples/lightweight-desktop.tmpl --verbosity=2 --no-offload

That took 38 minutes on my system and produced /gnu/store/...-disk-image.

$ cp /gnu/store/...-disk-image /tmp/lightweight-desktop.img

$ chmod +rw /tmp/lightweight-desktop.img

Then I tried running it with the suggested command:

$ qemu-system-x86_64 -m 1024 -bios $(guix build
ovmf)/share/firmware/ovmf_x64.bin -hda /tmp/lightweight-desktop.img

Toggle quote (15 lines)
>> + ;; Special case: most bootloaders can be copied
>> + ;; directly at some fixed location on the image
>> + ;; disk, but when installed to the master boot
>> + ;; record (MBR), GRUB requires support files
>> + ;; present under /boot/grub, which is handled by
>> + ;; its 'installer' procedure.
>> #:bootloader-installer
>> - #+(bootloader-installer bootloader)
>> + #+(if (eq? 'grub (bootloader-name bootloader))
>> + (bootloader-installer bootloader)
>> + #f)
>
> That would prevent other bootloaders relying on this procedure to work,
> such as extlinux.

I pondered about such solution, but when I verified the bootloaders
under gnu/bootloaders, it appeared that *only* the install-grub
procedure supported being passed #f as its mount point; the others would
fail because of the unexpected #f boolean value.

For example, the install-extlinux procedure from (gnu bootloaders
extlinux):

Toggle snippet (13 lines)
(define (install-extlinux mbr)
#~(lambda (bootloader device mount-point)
(let ((extlinux (string-append bootloader "/sbin/extlinux"))
(install-dir (string-append mount-point "/boot/extlinux"))
(syslinux-dir (string-append bootloader "/share/syslinux")))
(for-each (lambda (file)
(install-file file install-dir))
(find-files syslinux-dir "\\.c32$"))
(invoke/quiet extlinux "--install" install-dir)
(write-file-on-device (string-append syslinux-dir "/" #$mbr)
440 device 0))))

Would break if device was set to #f, as is done in (guix build image)'s
initialize-efi-partition:

Toggle snippet (5 lines)
(when bootloader-installer
(display "installing bootloader...\n")
(bootloader-installer bootloader-package #f root))

Is my analysis correct? If so, the patch I sent yesterday would fix the
problem more thoroughly.

Thank you,

Maxim
M
M
Mathieu Othacehe wrote on 8 Nov 2020 12:04
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87h7q0cdns.fsf@gnu.org
Hey,

Toggle quote (5 lines)
> $ time ./pre-inst-env guix system disk-image
> gnu/system/examples/lightweight-desktop.tmpl --verbosity=2 --no-offload
>
> That took 38 minutes on my system and produced /gnu/store/...-disk-image.

Strange, only 8 minutes for me. Does it include the time necessary to
fetch all substitutes? Are you using a SSD drive?

Toggle quote (3 lines)
> $ qemu-system-x86_64 -m 1024 -bios $(guix build
> ovmf)/share/firmware/ovmf_x64.bin -hda /tmp/lightweight-desktop.img

It tries to mount the EFI file-system with UUID "1234-ABCD" and
fails. You can remove this one for the lightweight-desktop configuration
to obtain a bootable system.

Toggle quote (10 lines)
> Would break if device was set to #f, as is done in (guix build image)'s
> initialize-efi-partition:
>
> (when bootloader-installer
> (display "installing bootloader...\n")
> (bootloader-installer bootloader-package #f root))
>
> Is my analysis correct? If so, the patch I sent yesterday would fix the
> problem more thoroughly.

Yes it is probably broken too. However, I would prefer not to introduce
bootloader specific stuff in (gnu system image).

I think the bootloaders should try to do their best with the DEVICE and
MOUNT-POINT arguments passed to bootloader-installer procedure. It
means, trying to install themselves using only MOUNT-POINT argument or
bailing out.

WDYT?

Thanks,

Mathieu
M
M
Maxim Cournoyer wrote on 12 Nov 2020 04:57
[PATCH version-1.2.0 v2 1/3] image: Remove conflicting user-provided EFI file system.
(address . 44353@debbugs.gnu.org)
20201112035713.3789-1-maxim.cournoyer@gmail.com
When the bootloader used is grub-efi-bootloader, an ESP partition and file
system is already added by the image generator. If a conflicting
user-provided EFI file system is provided, it will (likely) cause the boot to
fail, as happens for the lightweight-desktop.tmpl and desktop.tmpl templates
under gnu/system/examples.

* gnu/system/image.scm (operating-system-for-image): Also remove file systems
whose mount point is "/boot/efi".
---
gnu/system/image.scm | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

Toggle diff (17 lines)
diff --git a/gnu/system/image.scm b/gnu/system/image.scm
index 81152f0fc4..4972d9067b 100644
--- a/gnu/system/image.scm
+++ b/gnu/system/image.scm
@@ -576,7 +576,9 @@ it can be used for bootloading."
(file-systems-to-keep
(srfi-1:remove
(lambda (fs)
- (string=? (file-system-mount-point fs) "/"))
+ (let ((mount-point (file-system-mount-point fs)))
+ (or (string=? mount-point "/")
+ (string=? mount-point "/boot/efi"))))
(operating-system-file-systems base-os)))
(format (image-format image))
(os
--
2.28.0
M
M
Maxim Cournoyer wrote on 12 Nov 2020 04:57
[PATCH version-1.2.0 v2 3/3] doc: Detail which bootloader get used with disk-image or vm-image.
(address . 44353@debbugs.gnu.org)
20201112035713.3789-3-maxim.cournoyer@gmail.com
* doc/guix.texi (Invoking guix system): Extend doc.
---
doc/guix.texi | 31 ++++++++++++++++++++++++++-----
1 file changed, 26 insertions(+), 5 deletions(-)

Toggle diff (55 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index b7f1bc1f00..e15ee4092c 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -30909,11 +30909,25 @@ a value. Docker images are built to contain exactly what they need, so
the @option{--image-size} option is ignored in the case of
@code{docker-image}.
+@cindex disk-image, creating disk images
The @code{disk-image} command can produce various image types. The
image type can be selected using the @command{--image-type} option. It
-defaults to @code{raw}. When its value is @code{iso9660}, the
+defaults to @code{raw}. When its value is @code{iso9660}, the
@option{--label} option can be used to specify a volume ID with
-@code{disk-image}.
+@code{disk-image}. When using @code{disk-image}, the bootloader
+installed on the generated image is taken from the provided
+@code{operating-system} definition. The following example demonstrates
+how to generate an image that uses the @code{grub-efi-bootloader}
+bootloader and boot it with QEMU:
+
+@example
+image=$(guix system disk-image --image-type=qcow2 \
+ gnu/system/examples/lightweight-desktop.tmpl)
+cp $image /tmp/my-image.qcow2
+chmod +rw /tmp/my-image.qcow2
+qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000
+ -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin
+@end example
When using the @code{raw} image type, a raw disk image is produced; it
can be copied as is to a USB stick, for instance. Assuming
@@ -30927,10 +30941,17 @@ the image to it using the following command:
The @code{--list-image-types} command lists all the available image
types.
+@cindex vm-image, creating virtual machine images
When using @code{vm-image}, the returned image is in qcow2 format, which
-the QEMU emulator can efficiently use. @xref{Running Guix in a VM},
-for more information on how to run the image in a virtual machine.
-
+the QEMU emulator can efficiently use. @xref{Running Guix in a VM}, for
+more information on how to run the image in a virtual machine. The
+@code{grub-bootloader} bootloader is always used independently of what
+is declared in the @code{operating-system} file passed as argument.
+This is to make it easier to work with QEMU, which uses the SeaBIOS BIOS
+by default, expecting a bootloader to be installed in the Master Boot
+Record (MBR).
+
+@cindex docker-image, creating docker images
When using @code{docker-image}, a Docker image is produced. Guix builds
the image from scratch, not from a pre-existing Docker base image. As a
result, it contains @emph{exactly} what you define in the operating
--
2.28.0
M
M
Maxim Cournoyer wrote on 12 Nov 2020 04:57
[PATCH version-1.2.0 v2 2/3] bootloader: grub: Skip install-grub-efi when producing a disk image.
(address . 44353@debbugs.gnu.org)
20201112035713.3789-2-maxim.cournoyer@gmail.com

Every bootloader should try their best to install themselves using only the
MOUNT-POINT and otherwise do nothing. This requirement comes from the
necessity to call INSTALL-GRUB when installing the (non-EFI) GRUB bootloader,
which needs to populate the root file system with extra modules that cannot be
fit in the core.img file, limited in size to 491520 bytes (by the i386-pc
format required for legacy BIOS compatibility).

As introducing bootloader knowledge at the level of the image code is
undesirable, every bootloader should be adapted to support this fall-back for
their installation procedure (TODO).

* gnu/bootloader/grub.scm (install-grub-efi)[efi-dir]: Skip when the EFI-DIR
argument is set to #f.
---
gnu/bootloader/grub.scm | 33 ++++++++++++++++++---------------
1 file changed, 18 insertions(+), 15 deletions(-)

Toggle diff (46 lines)
diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index 0899fab61f..af7b7561ff 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -573,21 +573,24 @@ fi~%"))))
(define install-grub-efi
#~(lambda (bootloader efi-dir mount-point)
- ;; Install GRUB onto the EFI partition mounted at EFI-DIR, for the
- ;; system whose root is mounted at MOUNT-POINT.
- (let ((grub-install (string-append bootloader "/sbin/grub-install"))
- (install-dir (string-append mount-point "/boot"))
- ;; When installing Guix, it's common to mount EFI-DIR below
- ;; MOUNT-POINT rather than /boot/efi on the live image.
- (target-esp (if (file-exists? (string-append mount-point efi-dir))
- (string-append mount-point efi-dir)
- efi-dir)))
- ;; Tell 'grub-install' that there might be a LUKS-encrypted /boot or
- ;; root partition.
- (setenv "GRUB_ENABLE_CRYPTODISK" "y")
- (invoke/quiet grub-install "--boot-directory" install-dir
- "--bootloader-id=Guix"
- "--efi-directory" target-esp))))
+ ;; There is nothing useful to do when called in the context of a disk
+ ;; image generation.
+ (when efi-dir
+ ;; Install GRUB onto the EFI partition mounted at EFI-DIR, for the
+ ;; system whose root is mounted at MOUNT-POINT.
+ (let ((grub-install (string-append bootloader "/sbin/grub-install"))
+ (install-dir (string-append mount-point "/boot"))
+ ;; When installing Guix, it's common to mount EFI-DIR below
+ ;; MOUNT-POINT rather than /boot/efi on the live image.
+ (target-esp (if (file-exists? (string-append mount-point efi-dir))
+ (string-append mount-point efi-dir)
+ efi-dir)))
+ ;; Tell 'grub-install' that there might be a LUKS-encrypted /boot or
+ ;; root partition.
+ (setenv "GRUB_ENABLE_CRYPTODISK" "y")
+ (invoke/quiet grub-install "--boot-directory" install-dir
+ "--bootloader-id=Guix"
+ "--efi-directory" target-esp)))))
(define (install-grub-efi-netboot subdir)
"Define a grub-efi-netboot bootloader installer for installation in SUBDIR,
--
2.28.0
M
M
Maxim Cournoyer wrote on 12 Nov 2020 08:09
[PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.
(address . 44353@debbugs.gnu.org)
20201112070917.11794-1-maxim.cournoyer@gmail.com
* guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
(%default-options): Set its default value to #f.
(show-help): Add help doc.
* guix/scripts/system.scm (perform-action): Propagate option...
(system-derivation-for-action): ...here. Use it to set the volatile-root?
field of the image object passed to SYSTEM-IMAGE.
* doc/guix.texi (Invoking guix system): Document it.
---
doc/guix.texi | 18 ++++++++++++------
guix/scripts/system.scm | 21 +++++++++++++++++----
2 files changed, 29 insertions(+), 10 deletions(-)

Toggle diff (121 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index e15ee4092c..30efb7fc97 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -30911,14 +30911,20 @@ the @option{--image-size} option is ignored in the case of
@cindex disk-image, creating disk images
The @code{disk-image} command can produce various image types. The
-image type can be selected using the @command{--image-type} option. It
+image type can be selected using the @option{--image-type} option. It
defaults to @code{raw}. When its value is @code{iso9660}, the
@option{--label} option can be used to specify a volume ID with
-@code{disk-image}. When using @code{disk-image}, the bootloader
-installed on the generated image is taken from the provided
-@code{operating-system} definition. The following example demonstrates
-how to generate an image that uses the @code{grub-efi-bootloader}
-bootloader and boot it with QEMU:
+@code{disk-image}. By default, the root file system of a disk image is
+mounted volatile; the @option{--non-volatile} option can be used to make
+it persistent instead. The @option{--non-volatile} is useful to make
+use of extra disk space that can be obtained by using a larger value for
+the @option{--image-size} option; otherwise, the amount of physical
+memory available determines the capacity of the volatile file system
+overlay used for the root file system. When using @code{disk-image},
+the bootloader installed on the generated image is taken from the
+provided @code{operating-system} definition. The following example
+demonstrates how to generate an image that uses the
+@code{grub-efi-bootloader} bootloader and boot it with QEMU:
@example
image=$(guix system disk-image --image-type=qcow2 \
diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index ad998156c2..004f1c9739 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -674,7 +674,8 @@ checking this by themselves in their 'check' procedure."
(define* (system-derivation-for-action os action
#:key image-size image-type
full-boot? container-shared-network?
- mappings label)
+ mappings label
+ volatile-root?)
"Return as a monadic value the derivation for OS according to ACTION."
(mlet %store-monad ((target (current-target-system)))
(case action
@@ -706,7 +707,8 @@ checking this by themselves in their 'check' procedure."
base-image))
(target (or base-target target))
(size image-size)
- (operating-system os))))))
+ (operating-system os)
+ (volatile-root? volatile-root?))))))
((docker-image)
(system-docker-image os
#:shared-network? container-shared-network?)))))
@@ -761,6 +763,7 @@ and TARGET arguments."
dry-run? derivations-only?
use-substitutes? bootloader-target target
image-size image-type
+ volatile-root?
full-boot? label container-shared-network?
(mappings '())
(gc-root #f))
@@ -768,7 +771,8 @@ and TARGET arguments."
bootloader; BOOTLOADER-TAGET is the target for the bootloader; TARGET is the
target root directory; IMAGE-SIZE is the size of the image to be built, for
the 'vm-image' and 'disk-image' actions. IMAGE-TYPE is the type of image to
-be built.
+be built. When VOLATILE-ROOT? is #t, the root file system is mounted
+volatile.
FULL-BOOT? is used for the 'vm' action; it determines whether to
boot directly to the kernel or to the bootloader. CONTAINER-SHARED-NETWORK?
@@ -816,6 +820,7 @@ static checks."
#:label label
#:image-type image-type
#:image-size image-size
+ #:volatile-root? volatile-root?
#:full-boot? full-boot?
#:container-shared-network? container-shared-network?
#:mappings mappings))
@@ -974,6 +979,8 @@ Some ACTIONS support additional ARGS.\n"))
--image-size=SIZE for 'vm-image', produce an image of SIZE"))
(display (G_ "
--no-bootloader for 'init', do not install a bootloader"))
+ (display (G_ "
+ --non-volatile for 'disk-image', persist root file system changes"))
(display (G_ "
--label=LABEL for 'disk-image', label disk image with LABEL"))
(display (G_ "
@@ -1048,6 +1055,9 @@ Some ACTIONS support additional ARGS.\n"))
(option '("no-bootloader" "no-grub") #f #f
(lambda (opt name arg result)
(alist-cons 'install-bootloader? #f result)))
+ (option '("non-volatile") #f #f
+ (lambda (opt name arg result)
+ (alist-cons 'volatile-root? #f result)))
(option '("label") #t #f
(lambda (opt name arg result)
(alist-cons 'label arg result)))
@@ -1109,7 +1119,8 @@ Some ACTIONS support additional ARGS.\n"))
(image-type . raw)
(image-size . guess)
(install-bootloader? . #t)
- (label . #f)))
+ (label . #f)
+ (volatile-root? . #t)))
(define (verbosity-level opts)
"Return the verbosity level based on OPTS, the alist of parsed options."
@@ -1206,6 +1217,8 @@ resulting from command-line parsing."
#:image-type (lookup-image-type-by-name
(assoc-ref opts 'image-type))
#:image-size (assoc-ref opts 'image-size)
+ #:volatile-root?
+ (assoc-ref opts 'volatile-root?)
#:full-boot? (assoc-ref opts 'full-boot?)
#:container-shared-network?
(assoc-ref opts 'container-shared-network?)
--
2.28.0
M
M
Mathieu Othacehe wrote on 12 Nov 2020 09:36
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
877dqrvums.fsf@gnu.org
Hello Maxim,

Toggle quote (8 lines)
> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
> (%default-options): Set its default value to #f.
> (show-help): Add help doc.
> * guix/scripts/system.scm (perform-action): Propagate option...
> (system-derivation-for-action): ...here. Use it to set the volatile-root?
> field of the image object passed to SYSTEM-IMAGE.
> * doc/guix.texi (Invoking guix system): Document it.

This is a nice addition and it looks good to me.

Thanks,

Mathieu
M
M
Mathieu Othacehe wrote on 12 Nov 2020 09:39
Re: bug#44353: [PATCH version-1.2.0 v2 1/3] image: Remove conflicting user-provided EFI file system.
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87361fvui4.fsf@gnu.org
Hey Maxim,

Toggle quote (6 lines)
> When the bootloader used is grub-efi-bootloader, an ESP partition and file
> system is already added by the image generator. If a conflicting
> user-provided EFI file system is provided, it will (likely) cause the boot to
> fail, as happens for the lightweight-desktop.tmpl and desktop.tmpl templates
> under gnu/system/examples.

Nice one. I would just clarify in the commit message that the ESP
partition is added only when the selected image type is "raw".

Otherwise, it looks fine!

Thanks,

Mathieu
M
M
Mathieu Othacehe wrote on 12 Nov 2020 09:42
Re: bug#44353: [PATCH version-1.2.0 v2 2/3] bootloader: grub: Skip install-grub-efi when producing a disk image.
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87y2j7uftu.fsf@gnu.org
Hello Maxim,

Toggle quote (4 lines)
> As introducing bootloader knowledge at the level of the image code is
> undesirable, every bootloader should be adapted to support this fall-back for
> their installation procedure (TODO).

Or maybe find a way to remove the need to call "bootloader-installer"
when producing a disk-image as we discussed on IRC.

Looks fine!

Thanks,

Mathieu
M
M
Mathieu Othacehe wrote on 12 Nov 2020 09:45
Re: bug#44353: [PATCH version-1.2.0 v2 3/3] doc: Detail which bootloader get used with disk-image or vm-image.
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87tutvufns.fsf@gnu.org
Hey,

Toggle quote (9 lines)
> +@example
> +image=$(guix system disk-image --image-type=qcow2 \
> + gnu/system/examples/lightweight-desktop.tmpl)
> +cp $image /tmp/my-image.qcow2
> +chmod +rw /tmp/my-image.qcow2
> +qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000
> + -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin
> +@end example

This looks good! Note that I plan to remove the "vm-image" command and
rename "disk-image" command to "image" once the 1.2.0 is out.

Thanks,

Mathieu
M
M
Maxim Cournoyer wrote on 12 Nov 2020 15:59
Re: bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87h7pufwop.fsf@gmail.com
Hello Mathieu,

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (16 lines)
> Hello Maxim,
>
>> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
>> (%default-options): Set its default value to #f.
>> (show-help): Add help doc.
>> * guix/scripts/system.scm (perform-action): Propagate option...
>> (system-derivation-for-action): ...here. Use it to set the volatile-root?
>> field of the image object passed to SYSTEM-IMAGE.
>> * doc/guix.texi (Invoking guix system): Document it.
>
> This is a nice addition and it looks good to me.
>
> Thanks,
>
> Mathieu

One thing I wasn't sure was if it'd be better to implicitly derive
volatile-root? #f when image-type was specified (not (eq? 'guess)). The
rationale being that users specifying the image-size themselves probably
want to make use of extra space (assumption) but can't unless
volatile-root? is #t on the image.

If we choose the above it'd lead to less code and one less switch; on
the other hand it is not as explicit.

What do you think?

Maxim
M
M
Mathieu Othacehe wrote on 12 Nov 2020 18:06
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87r1oyjyhx.fsf@gnu.org
Hello Maxim,

Toggle quote (11 lines)
> One thing I wasn't sure was if it'd be better to implicitly derive
> volatile-root? #f when image-type was specified (not (eq? 'guess)). The
> rationale being that users specifying the image-size themselves probably
> want to make use of extra space (assumption) but can't unless
> volatile-root? is #t on the image.
>
> If we choose the above it'd lead to less code and one less switch; on
> the other hand it is not as explicit.
>
> What do you think?

When developing the image API, I hesitated keeping the default of using
volatile root file systems by default.

In most cases, I think that the user may prefer to have non volatile
images. They already have to copy the image from the store and make it
writable so that QEMU can use it with "-hda" argument.

Switching the default to non volatile could be an option I think. Doing
what you are proposing: setting volatile to false when image-size is
passed could also be a first step.

Thanks,

Mathieu
L
L
Ludovic Courtès wrote on 12 Nov 2020 22:16
Re: bug#44353: [PATCH version-1.2.0 v2 3/3] doc: Detail which bootloader get used with disk-image or vm-image.
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87r1oyff7b.fsf@gnu.org
Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (12 lines)
>> +@example
>> +image=$(guix system disk-image --image-type=qcow2 \
>> + gnu/system/examples/lightweight-desktop.tmpl)
>> +cp $image /tmp/my-image.qcow2
>> +chmod +rw /tmp/my-image.qcow2
>> +qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000
>> + -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin
>> +@end example
>
> This looks good! Note that I plan to remove the "vm-image" command and
> rename "disk-image" command to "image" once the 1.2.0 is out.

However note that the manual should not be change on ‘version-1.2.0’ at
this point, “the strings are frozen”, they say.

Ludo’.
L
L
Ludovic Courtès wrote on 12 Nov 2020 22:18
Re: bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87mtzmff4k.fsf@gnu.org
Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (10 lines)
>> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
>> (%default-options): Set its default value to #f.
>> (show-help): Add help doc.
>> * guix/scripts/system.scm (perform-action): Propagate option...
>> (system-derivation-for-action): ...here. Use it to set the volatile-root?
>> field of the image object passed to SYSTEM-IMAGE.
>> * doc/guix.texi (Invoking guix system): Document it.
>
> This is a nice addition and it looks good to me.

Can we keep it for ‘master’ only, notably because of the “string
freeze”?

Ludo’.
L
L
Ludovic Courtès wrote on 15 Nov 2020 22:45
Re: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
878sb25m6s.fsf@gnu.org
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Toggle quote (8 lines)
> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
> (%default-options): Set its default value to #f.
> (show-help): Add help doc.
> * guix/scripts/system.scm (perform-action): Propagate option...
> (system-derivation-for-action): ...here. Use it to set the volatile-root?
> field of the image object passed to SYSTEM-IMAGE.
> * doc/guix.texi (Invoking guix system): Document it.

Due notably to the “string freeze”, I think we shouldn’t apply it to
‘version-1.2.0’.

Some comments:

Toggle quote (3 lines)
> +@code{disk-image}. By default, the root file system of a disk image is
> +mounted volatile; the @option{--non-volatile} option can be used to make

That’s not generally the case, though in (gnu system image), only two
image types have it set to false.

Before the new image API though, ‘disk-image’ did not produce a volatile
root, IIRC. I’m tempted to think that we should set (volatile-root?
#f) on image types where it makes sense, which is maybe all of them
except ISO. (Then we need to make sure ‘guix system vm’ still gets a
volatile root.)

WDYT, Mathieu?

So apart from the sentence above, the patch LGTM for ‘master’!

Thanks,
Ludo’.
M
M
Maxim Cournoyer wrote on 16 Nov 2020 03:48
Re: bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.
(name . Ludovic Courtès)(address . ludo@gnu.org)
87r1oudnkt.fsf@gmail.com
Hey,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (15 lines)
> Mathieu Othacehe <othacehe@gnu.org> skribis:
>
>>> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
>>> (%default-options): Set its default value to #f.
>>> (show-help): Add help doc.
>>> * guix/scripts/system.scm (perform-action): Propagate option...
>>> (system-derivation-for-action): ...here. Use it to set the volatile-root?
>>> field of the image object passed to SYSTEM-IMAGE.
>>> * doc/guix.texi (Invoking guix system): Document it.
>>
>> This is a nice addition and it looks good to me.
>
> Can we keep it for ‘master’ only, notably because of the “string
> freeze”?

Sure, let's do that!

Maxim
M
M
Maxim Cournoyer wrote on 16 Nov 2020 04:47
(name . Ludovic Courtès)(address . ludo@gnu.org)
87mtzidku8.fsf@gmail.com
Hello,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (23 lines)
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
>> (%default-options): Set its default value to #f.
>> (show-help): Add help doc.
>> * guix/scripts/system.scm (perform-action): Propagate option...
>> (system-derivation-for-action): ...here. Use it to set the volatile-root?
>> field of the image object passed to SYSTEM-IMAGE.
>> * doc/guix.texi (Invoking guix system): Document it.
>
> Due notably to the “string freeze”, I think we shouldn’t apply it to
> ‘version-1.2.0’.
>
> Some comments:
>
>> +@code{disk-image}. By default, the root file system of a disk image is
>> +mounted volatile; the @option{--non-volatile} option can be used to make
>
> That’s not generally the case, though in (gnu system image), only two
> image types have it set to false.

Note that the only two images with volatile-root? #f are ARM, and not by
intent but as a workaround:

;; FIXME: Deleting and creating "/var/run" and "/tmp" on the overlayfs
;; fails.

Toggle quote (8 lines)
> Before the new image API though, ‘disk-image’ did not produce a volatile
> root, IIRC. I’m tempted to think that we should set (volatile-root?
> #f) on image types where it makes sense, which is maybe all of them
> except ISO. (Then we need to make sure ‘guix system vm’ still gets a
> volatile root.)
>
> WDYT, Mathieu?

Based on your comments and those of Mathieut, I've made volatile-root?
#f the default for 'guix system disk-image', with a '--volatile' option
to maintain the ability to have the rootfs mounted volatile, and
adjusted the doc accordingly.

Toggle quote (2 lines)
> So apart from the sentence above, the patch LGTM for ‘master’!

Thanks for the review!

Maxim
M
M
Mathieu Othacehe wrote on 16 Nov 2020 10:23
Re: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.
(name . Ludovic Courtès)(address . ludo@gnu.org)
87o8jxlkot.fsf@gnu.org
Hey Ludo,

Toggle quote (8 lines)
> Before the new image API though, ‘disk-image’ did not produce a volatile
> root, IIRC. I’m tempted to think that we should set (volatile-root?
> #f) on image types where it makes sense, which is maybe all of them
> except ISO. (Then we need to make sure ‘guix system vm’ still gets a
> volatile root.)
>
> WDYT, Mathieu?

That's also what I proposed to Maxim. Note that "guix system vm" is
still using the "old" VM based image production method and doesn't share
the new image API volatile default.

Thanks,

Mathieu
L
L
Ludovic Courtès wrote on 16 Nov 2020 14:09
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
874klpxxch.fsf@gnu.org
Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (12 lines)
>> Before the new image API though, ‘disk-image’ did not produce a volatile
>> root, IIRC. I’m tempted to think that we should set (volatile-root?
>> #f) on image types where it makes sense, which is maybe all of them
>> except ISO. (Then we need to make sure ‘guix system vm’ still gets a
>> volatile root.)
>>
>> WDYT, Mathieu?
>
> That's also what I proposed to Maxim. Note that "guix system vm" is
> still using the "old" VM based image production method and doesn't share
> the new image API volatile default.

Right.

Speaking of which, can we remove ‘system-disk-image-in-vm’? It has zero
users now.

Ludo’.
M
M
Mathieu Othacehe wrote on 16 Nov 2020 14:34
(name . Ludovic Courtès)(address . ludo@gnu.org)
87k0ull91k.fsf@gnu.org
Hey,

Toggle quote (3 lines)
> Speaking of which, can we remove ‘system-disk-image-in-vm’? It has zero
> users now.

Sure, I also need to find some time to route "vm-image", "vm" and
possibly "docker-image" commands to new image API.

Thanks,

Mathieu
M
M
Maxim Cournoyer wrote on 17 Nov 2020 15:44
Re: bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87tutoavq6.fsf@gmail.com
Hello Mathieu,

Mathieu Othacehe <othacehe@gnu.org> writes:


[...]

Toggle quote (11 lines)
> When developing the image API, I hesitated keeping the default of using
> volatile root file systems by default.
>
> In most cases, I think that the user may prefer to have non volatile
> images. They already have to copy the image from the store and make it
> writable so that QEMU can use it with "-hda" argument.
>
> Switching the default to non volatile could be an option I think. Doing
> what you are proposing: setting volatile to false when image-size is
> passed could also be a first step.

Hi Mathieu! As I mentioned in a reply to Ludovic and based from your
feedback I'll make the disk-image produced to be non-volatile by
default, with the switch to make them volatile becoming "--volatile".

Thanks!

Maxim
M
M
Maxim Cournoyer wrote on 17 Nov 2020 19:29
Re: bug#44353: [PATCH version-1.2.0 v2 2/3] bootloader: grub: Skip install-grub-efi when producing a disk image.
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
875z63albi.fsf@gmail.com
Hello,

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (9 lines)
> Hello Maxim,
>
>> As introducing bootloader knowledge at the level of the image code is
>> undesirable, every bootloader should be adapted to support this fall-back for
>> their installation procedure (TODO).
>
> Or maybe find a way to remove the need to call "bootloader-installer"
> when producing a disk-image as we discussed on IRC.

I looked into this option, using GPT + a 1 MiB boot partition, hoping to
produce a GRUB to put there with grub mkstandalone, but that is too big
to fit for the i386-pc format requirements, sadly.

Maxim
M
M
Maxim Cournoyer wrote on 17 Nov 2020 19:37
Re: bug#44353: [PATCH version-1.2.0 v2 1/3] image: Remove conflicting user-provided EFI file system.
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
871rgrakyh.fsf@gmail.com
Hello Mathieu!

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (11 lines)
> Hey Maxim,
>
>> When the bootloader used is grub-efi-bootloader, an ESP partition and file
>> system is already added by the image generator. If a conflicting
>> user-provided EFI file system is provided, it will (likely) cause the boot to
>> fail, as happens for the lightweight-desktop.tmpl and desktop.tmpl templates
>> under gnu/system/examples.
>
> Nice one. I would just clarify in the commit message that the ESP
> partition is added only when the selected image type is "raw".

Done, thank you!

Thank you!

Maxim
M
M
Maxim Cournoyer wrote on 17 Nov 2020 21:21
Re: bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87wnyj91k8.fsf@gmail.com
Hello,

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (5 lines)
> Hey,
>
>> Speaking of which, can we remove ‘system-disk-image-in-vm’? It has zero
>> users now.

Done!

This series has now been pushed to master. Closing.

Thank you,

Maxim
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 44353@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 44353
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch