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

From: Marius Bakke <[email-masked]>
Date: Sun, 07 May 2017 17:41:19 +0200

Hi Danny, thanks for the quick feedback!

Danny Milosavljevic <[email-masked]> writes:

>> +      (system* "grub-mkstandalone" "-O" "x86_64-efi" "-o"
>> +               (string-append efi-directory "/EFI/BOOT/BOOTX64.EFI")
>> +               ;; Embed the contents of grubdisk.cfg.
>> +               (string-append "boot/grub/grub.cfg=" target
>> +                              "/tmp/grubdisk.cfg"))
>
> Check return value of system* ?

Good point. Will wrap it in an (unless (zero? ...) (error ...)).

>>                    (partitions (list (partition
>>                                       (size #$(- disk-image-size
>> -                                                (* 10 (expt 2 20))))
>> +                                                (* 50 (expt 2 20))))
>
> <https://wiki.archlinux.org/index.php/EFI_System_Partition> says:
>
>>According to a Microsoft note[2], the minimum size for the EFI System Partition (ESP) would be 100 MB, though this is not stated in the UEFI Specification. Note that for Advanced Format 4K Native drives (4-KB-per-sector) drives, the size is at least 256 MiB, because it is the minimum partition size of FAT32 drives (calculated as sector size (4KB) x 65527 = 256 MiB), due to a limitation of the FAT32 file format. 

I have no idea what happens if you dd this image onto a 4k drive, only
tested with a 512B flash drive.

> Is this relevant for us?
>
> Also, <https://gist.github.com/Apsu/4108795> says that F32 is not required for most UEFI firmwares. FAT12, FAT32 usually work.  But better be safe than sorry, I guess.

If FAT32 may cause problems on some install media, perhaps it's better
to rely on the calculated allocation tables and "hope for the best". I
don't have a spare 4k drive to test with, though.

>> +                                     (size (* 40 (expt 2 20)))
>> +                                     (label "gnu-esp")
>> +                                     (file-system "vfat")
>
> Is it really vfat with long file names and everything? Or only FAT32 (with short file names)?

Good catch. I think it should be FAT32 indeed, according to parted from
a prepared disk image. AFAIK parted does not actually use this flag for
anything, but it's good to be accurate.