GNU bug report logs - #26815
[PATCH 0/3] Hybrid UEFI disk image

Previous Next

Full log

View this message in rfc822 format

From: Marius Bakke <mbakke <at> fastmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 26815 <at> debbugs.gnu.org
Subject: bug#26815: [PATCH 3/3] vm: Support EFI boot in base image.
Date: Wed, 10 May 2017 21:58:56 +0200

[Message part 1 (text/plain, inline)]

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

> Marius Bakke <mbakke <at> fastmail.com> skribis:
>
>> From 9555239cfc9362a15cc3f255040c410395d49e04 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke <mbakke <at> 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))

Good idea. I've moved the grub parts into a separate procedure, but kept
the mounting etc here.

>> +                                    (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.

It's "only" 40MiB, so didn't see a reason to complicate it. Grub is
actually just ~10MiB, but left some space for..stuff?

There are some rare systems with 32-bit UEFI and 64-bit CPU, those users
should be able to copy "BOOTIA32.EFI" from an i686 image onto the ESP.

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

It's only used for informational purposes. Now even uppercase to display
properly on ancient systems :-P

I've sent a new patch series taking the reviews into account. The
patches from id:20170506154154.17836-1-m.othacehe <at> gmail.com are still
required.

(Also, --size=1G is no longer enough after the Guile 2.2 transition!)

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.