On 06/07/18 12:51, Andrea Bolognani wrote: > On Thu, 2018-06-07 at 11:32 +0100, Richard W.M. Jones wrote: >> On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote: >>> Something that I haven't seen mentioned in the thread - and this >>> looks like as good a point as any to jump in - is that for q35 >>> guests using EFI as well as aarch64 guests the "one click import" >>> experience requires not only hints about the machine (and firmware!) >>> type, but also a copy of the EFI variable store: >>> >>> $ virt-builder fedora-27 --arch aarch64 --notes >>> Fedora® 27 Server (aarch64) >>> >>> [...] >>> >>> You will need to use the associated UEFI NVRAM variables file: >>> http://libguestfs.org/download/builder/fedora-27-aarch64-nvram.xz >> >> This is true, although only sometimes. If the bootloader[*] has a >> working fallback path then usually it is able to boot and reset the >> UEFI varstore back to the correct values. We have had bugs before >> where the fallback path was not working, eg: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1353689 (yours!) >> https://bugzilla.redhat.com/show_bug.cgi?id=1558793 > > [...] >> [*] I'm not sure exactly which bit of the bootloader does this, >> whether it's UEFI itself, or the grub-efi in the guest. > > IIUC the UEFI spec itself reserves certain file names in the ESP > for this fallback mechanism; it's then up to the guest operating > system to actually install something appropriate there. > > In Fedora and RHEL, shim is what takes care of it (except when it > doesn't ;), but in Debian and Ubuntu AFAIK shim is not included > and the fallback path doesn't work at all, which makes providing > the NVRAM file a hard requirement to boot such guests.
Quoting the UEFI-2.7 spec: > 3.4.3 Boot Option Variables Default Boot Behavior > > [...] the boot options require a standard default behavior in the > exceptional case that valid boot options are not present on a > platform. The default behavior must be invoked any time the BootOrder > variable does not exist or only points to nonexistent boot options, or > if no entry in BootOrder can successfully be executed. > > If system firmware supports boot option recovery as described in > Section 3.4, system firmware must include a PlatformRecovery#### > variable specifying a short-form File Path Media Device Path (see > Section 3.1.2) containing the platform default file path for removable > media (see Table 11). [...] (Note from Laszlo: think '\EFI\BOOT\BOOTX64.EFI' on the system disk's EFI System Partition.) > It is expected that this default boot will load an operating system or > a maintenance utility. > > If this is an operating system setup program it is then responsible > for setting the requisite environment variables for subsequent boots. > [...] More details: <https://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/>. Thanks Laszlo