bug#44511: guix system vm-image fails when using grub-efi-bootleader

[Maxim Cournoyer]

Hello,

Attempting to build the lightweight-desktop.tpml image configuration using:

$ guix system vm-image gnu/system/examples/lightweight-desktop.tmpl 
--verbosity=10 --no-offload

ends up crashing with:

--8<---cut here---start->8---
populating...
creating FAT partition...
mkfs.fat 4.1 (2017-01-24)
mounting root partition...
[ 2314.084305] EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: 
(null)
installing bootloader...
Backtrace:
   1 (primitive-load "/gnu/store/8v2p9vi8249z31f8gsvrdf3c0b4
In ./gnu/build/vm.scm:
485:6  0 (initialize-hard-disk "/dev/vda" #:bootloader-package _ 
./gnu/build/vm.scm:485:6: In procedure initialize-hard-disk:
ERROR:
  1. : 
"'/gnu/store/8jf4yz2vb77d7ww1q42x3hqr5bd6nwl3-grub-efi-2.04/sbin/grub-install 
--boot-directory /fs/boot --bootloader-id=Guix --efi-directory /fs/dev/vda' 
exited with status 1; output follows:\n\n "
[ 2315.563173] reboot: Restarting system
[ 2315.569476] reboot: machine restart
file-size: 
/gnu/store/0llx3y194278l5ksr4xh9kc64mh8nn8d-nss-certs-3.52.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/8i7j0d7hwz56hkzd83cwbdfnir2d1g68-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
Backtrace:
   1 (primitive-load "/gnu/store/wjnqppa67w1cql169d1z5dmcldj?")
In ./gnu/build/vm.scm:
   198:12  0 (load-in-linux-vm _ #:output _ #:qemu _ #:memory-size _ ?)
./gnu/build/vm.scm:198:12: In procedure load-in-linux-vm:
guest VM code exited with a non-zero status 256
--8<---cut here---end--->8---

The value of the --efi-directory argument (/fs/dev/vda) of the grub-install
command seems suspicious to me.

Thanks,

Maxim

bug#43752: emacs-racer fails to install

[Nicolas Goaziou]

Hello,

Tomás Ortín Fernández via Bug reports for GNU Guix 
writes:

> I get the same error. It seems this is an issue in upstream with Emacs 27.1:
>
> https://github.com/racer-rust/emacs-racer/issues/136

I applied a workaround, waiting for upstream to fix it properly.

Thank you for the report.

Regards,
-- 
Nicolas Goaziou

bug#44508: Found a bug in compute-guix-derivation

[Marius Bakke]

Josh Marshall  writes:

> Hello all,
>
> When pulling I came across the following which told me to send a report in:
>
> ```
> anadon@goodadvicemallard:~$ guix pull
> Updating channel 'guix' from Git repository at '
> https://git.savannah.gnu.org/git/guix.git'...

[...]

> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> @ substituter-started
> /gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2

[...]

> gzip: stdin: unexpected end of file
> guix substitute: error: corrupt input while restoring
> '/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2/bin/git'
> from #{read pipe}#
> @ substituter-failed
> /gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2 256 fetching
> path `/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2'
> failed with exit code 1

[...]

> ./guix/store.scm:1368:15: ERROR:
>   1. :
>   message: "some substitutes for the outputs of derivation
> `/gnu/store/6kd94qkd2hnkri5hc44vfjvh8b0i5ynl-git-minimal-2.29.2.drv' failed
> (usually happens due to networking issues); try `--fallback' to build
> derivation from source "

Probably this was a transient (network) failure, or is the error
consistent?

And for something completely different:

> /gnu/store/ncknl03pkmamrxg7q9nxi1rn1qhvwbi9-guix-1.0.1/libexec/guix/substitute

Consider updating the 'root' user Guix (or reconfigure, if you are on
Guix System), to get the latest version of guix-daemon.


signature.asc
Description: PGP signature

bug#44508: Found a bug in compute-guix-derivation

[Josh Marshall]

Hello all,

When pulling I came across the following which told me to send a report in:

```
anadon@goodadvicemallard:~$ guix pull
Updating channel 'guix' from Git repository at '
https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to f900045 (533 new
commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git f900045
substitute:
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
substitute:
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
downloading from
https://ci.guix.gnu.org/nar/gzip/808xr7v3h004s0mafxw0v0ibmgpmam3i-module-import
...
 module-import  2KiB   539KiB/s 00:00
[##] 100.0%

/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
downloading from
https://ci.guix.gnu.org/nar/gzip/izn00974y4pfs39dch1a5lcxc00wscl0-module-import-compiled
...
 module-import-compiled  2.4MiB 61KiB/s 00:41
[##] 100.0%

/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
downloading from
https://ci.guix.gnu.org/nar/gzip/58yx23vgfvx4m1426v0b6xjn8hnnx245-compute-guix-derivation
...
 compute-guix-derivation  860B 286KiB/s 00:00
[##] 100.0%

substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
@ substituter-started
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
/gnu/store/ncknl03pkmamrxg7q9nxi1rn1qhvwbi9-guix-1.0.1/libexec/guix/substitute
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
|@ download-started
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
https://ci.guix.gnu.org/nar/gzip/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
14413465
@ download-progress
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
https://ci.guix.gnu.org/nar/gzip/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
14413465 16384
@ download-progress
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
https://ci.guix.gnu.org/nar/gzip/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
14413465 32768
@ download-progress
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
https://ci.guix.gnu.org/nar/gzip/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
14413465 49152
@ download-progress
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
https://ci.guix.gnu.org/nar/gzip/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
14413465 81920
/@ download-progress
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
https://ci.guix.gnu.org/nar/gzip/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
14413465 98304
@ download-progress
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
https://ci.guix.gnu.org/nar/gzip/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
14413465 114688
@ download-progress
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
https://ci.guix.gnu.org/nar/gzip/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
14413465 147456
-@ download-progress
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
https://ci.guix.gnu.org/nar/gzip/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
14413465 163840
\@ download-progress
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
https://ci.guix.gnu.org/nar/gzip/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
14413465 196608
@ download-progress
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
https://ci.guix.gnu.org/nar/gzip/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
14413465 212992
@ download-progress
/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2

bug#44428: Graphical Installer window clipping on "small" displays

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> Yes, I still see the situation on the welcome and partitioning pages. 
>> But I did not want to go past the partition step, because I have data
>> on this disk ;).
>
> Hehe, thanks for testing again :) I fixed a few more things, so that the
> welcome logo is not displayed on small resolutions and the partitioning
> and configuration pages do not overflow.
>
> Pushed as 6dcbbcdab7727946cf32e7a4e44e66d151380db2.

Awesome!

> On QEMU with 800x600 resolution there's no more box overflow. I hope
> it will be the same on your hardware that seem to have a slightly higher
> resolution.

How do you tell QEMU to use that resolution?

> Maybe we should take this one to the 1.2 branch. Ludo?

6dcbbcdab7727946cf32e7a4e44e66d151380db2 changes strings, so maybe we
should not take it.

8338d414b361e4fb961221642c1064e9dc89ba65 looks reasonable though, so I
think you can cherry-pick it in ‘version-1.2.0’.

Thank you!

Ludo’.

bug#44453:

[musics--- via Bug reports for GNU Guix]

Solved

bug#44353: guix system disk-image -t raw fails with grub-efi-bootloader

[Maxim Cournoyer]

Hello Mathieu!

Mathieu Othacehe  writes:

> 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!

> 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

>> +  ;; 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):

--8<---cut here---start->8---
(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
--8<---cut here---end--->8---

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

--8<---cut here---start->8---
  (when bootloader-installer
(display "installing bootloader...\n")
(bootloader-installer bootloader-package #f root))
--8<---cut here---end--->8---

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

Thank you,

Maxim

bug#44453:

[musics--- via Bug reports for GNU Guix]

Many thanks to Leo, Mark and Tobias; The problem was solved.

bug#44453:

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

musics--- via Bug reports for GNU Guix 写道：

What should I do now? Install this plugin from the source?


If you're OK with using patent-encumbered codex like MP4 simply:

 $ guix install gst-libav

if that doesn't fix your troubles:

 $ guix install gst-plugins-bad

(You won't need both.)

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#44453:

[musics--- via Bug reports for GNU Guix]

What should I do now? Install this plugin from the source?

bug#44453:

[musics--- via Bug reports for GNU Guix]

What should I do now? Install this plugin from the source?

bug#44428: Graphical Installer window clipping on "small" displays

[Mathieu Othacehe]

Hey Eric,

> Yes, I still see the situation on the welcome and partitioning pages. 
> But I did not want to go past the partition step, because I have data
> on this disk ;).

Hehe, thanks for testing again :) I fixed a few more things, so that the
welcome logo is not displayed on small resolutions and the partitioning
and configuration pages do not overflow.

Pushed as 6dcbbcdab7727946cf32e7a4e44e66d151380db2.

On QEMU with 800x600 resolution there's no more box overflow. I hope
it will be the same on your hardware that seem to have a slightly higher
resolution.

Maybe we should take this one to the 1.2 branch. Ludo?

Thanks,

Mathieu

bug#44353: guix system disk-image -t raw fails with grub-efi-bootloader

[Bengt Richter]

Hi Mathieu,

On +2020-11-07 10:08:36 +0100, Mathieu Othacehe wrote:
> 
> 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

bug#44353: guix system disk-image -t raw fails with grub-efi-bootloader

[Mathieu Othacehe]

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
>From 2145fc40d3eb949885ce94883b09c7291c607be6 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
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.

Fixes: .

* 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(-)

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