bug#26815: [PATCH 3/3] vm: Support EFI boot in base image.

[ludo@gnu.org (Ludovic Courtès)]

Marius Bakke <mbakke@fastmail.com> skribis:

> From 9555239cfc9362a15cc3f255040c410395d49e04 Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke@fastmail.com>
> Date: Sun, 7 May 2017 15:31:30 +0200
> Subject: [PATCH] vm: Support EFI boot in base image.
>
> * gnu/system/vm.scm (qemu-image): Add GRUB-EFI to inputs. Append 40MB
> EFI System Partition.
> * gnu/build/vm.scm (initialize-hard-disk): Generate grub EFI blob when ESP is
> present.

[...]

> +    ;; If we have an ESP partition, generate a self-contained grub EFI
> +    ;; image and write it to a well-known location.
> +    (when esp
> +      (let* ((system %host-type)
> +             (efi-payload-directory (string-append efi-directory "/EFI/BOOT"))
> +             ;; Map the grub targets to the boot file names expected by
> +             ;; UEFI compliant firmware. See "Removable Media Boot Behavior":
> +             ;; http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf
> +             (efi-target-map (cond
> +                              ((string-prefix? "x86_64" system)
> +                               '("x86_64-efi" . "BOOTX64.EFI"))
> +                              ((string-prefix? "i686" system)
> +                               '("i386-efi" . "BOOTIA32.EFI"))
> +                              ((string-prefix? "armhf" system)
> +                               '("arm-efi" . "BOOTARM.EFI"))
> +                              ((string-prefix? "aarch64" system)
> +                               '("arm64-efi" . "BOOTAA64.EFI"))))
> +             (grub-tmp (string-append target "/tmp"))
> +             (grub.cfg (string-append grub-tmp "/grub.cfg")))
> +        (display "mounting EFI system partition...\n")
> +        (mkdir-p efi-directory)
> +        (mount (partition-device esp) efi-directory
> +               (partition-file-system esp))
> +        (mkdir-p efi-payload-directory)
> +
> +        ;; Grub needs a tmpdir to prepare the image.
> +        (setenv "TMPDIR" grub-tmp)
> +        ;; We also need a tiny configuration file telling the EFI blob where
> +        ;; to find the real thing.
> +        (with-output-to-file grub.cfg
> +          (lambda _
> +            (format #t
> +                    "insmod part_msdos~@
> +                    search --set=root --label gnu-disk-image~@
> +                    configfile /boot/grub/grub.cfg~%")))
> +        (display "creating grub firmware image...\n")
> +        (unless (zero? (system* "grub-mkstandalone" "-O" (car efi-target-map)
> +                                "-o" (string-append efi-payload-directory "/"
> +                                                    (cdr efi-target-map))
> +                                ;; Graft the contents of our configuration file
> +                                ;; into the image.  See grub-mkstandalone(1).
> +                                (string-append "boot/grub/grub.cfg=" grub.cfg)))
> +          (error "failed to create grub EFI image"))
> +
> +        (delete-file grub.cfg)
> +        (umount efi-directory)))

Could you move the body hi of ‘when’ to a separate procedure, say
‘install-efi’, such that this reduces to something like:

  (when esp
    (install-efi esp grub.cfg))

> +                                    (partition
> +                                     ;; Append a small FAT32 partition for
> +                                     ;; use with UEFI bootloaders.
> +                                     (size (* 40 (expt 2 20)))
> +                                     (label "gnu-esp")
> +                                     (file-system "vfat")
> +                                     (flags '(esp))))))
>               (initialize-hard-disk "/dev/vda"
>                                     #:partitions partitions
>                                     #:bootloader

All the images we create will now have that extra ESP, but maybe that’s
OK.

Is the “gnu-esp” label of this partition used for lookup anywhere?  If
it was, we’d run into problems as soon as we have several partitions
with this hard-coded label (say you have your installed GuixSD as well
as the installation image on a USB key that’s plugged in.)  If the label
is not used for lookup, that’s OK.

Apart from that LGTM, thank you!

Ludo’.