From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: kraxel@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Tue, 04 Jun 2019 22:49:52 -0700 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0893D308212A; Wed, 5 Jun 2019 05:49:48 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-117-131.ams2.redhat.com [10.36.117.131]) by smtp.corp.redhat.com (Postfix) with ESMTP id 118B6611D2; Wed, 5 Jun 2019 05:49:45 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 3FD0C1752B; Wed, 5 Jun 2019 07:49:43 +0200 (CEST) Date: Wed, 5 Jun 2019 07:49:43 +0200 From: Gerd Hoffmann To: Laszlo Ersek Cc: Pavan Kumar Aravapalli , devel@edk2.groups.io Subject: Re: [edk2-devel] Help needed in building UEFI qcow2 images Message-ID: <20190605054943.so4v63o7c2hqw42r@sirius.home.kraxel.org> References: <88960f45-42c4-3420-e33a-880a55960e48@redhat.com> <15566.1559647737135151997@groups.io> <64f4a3ff-01c8-42b1-c2d0-41807aba03b2@redhat.com> MIME-Version: 1.0 In-Reply-To: <64f4a3ff-01c8-42b1-c2d0-41807aba03b2@redhat.com> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Wed, 05 Jun 2019 05:49:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > However: you're using a systemd-related UEFI boot loader, and I have > no clue whether it implements the above-referenced "fallback" > behavior. For now, I would suggest trying the shim+grub2 variant, and > even Fedora 29 rather than Fedora 28: > "fedora-29-efi-grub2-x86_64.qcow2.xz". I can boot the images just fine with empty vars. Just noticed that the systemd image has a lowercase efi directory, so the fallback bootloader path is "efi/BOOT/BOOTX64.EFI" not "EFI/BOOT/BOOTX64.EFI". Possibly that is the root cause for the problem. In theory it should not, FAT is case-insensitive after all, but who knows ... > ... I guess it's also possible that the UEFI boot loader in the disk > image that you've tried isn't properly signed, against the > certificates enrolled in "/usr/share/OVMF/OVMF_VARS.secboot.fd". If > that's the case, the OVMF debug log will show it. Oh, in secure boot mode. The systemd images don't use shim, so that most likely isn't going to fly due to bootloader being unsigned. The grub2 variants should work. Never actually tested that though. cheers, Gerd