From inside the chrooted DomU guest
Re-installing grub, without overwriting the physical, motherboard efi-related nvram, grub2-install -v --target=x86_64-efi --efi-directory=/boot/efi --no-nvram ... grub2-install: info: copying `/boot/grub2/x86_64-efi/core.efi' -> `/boot/efi/EFI/opensuse/grubx64.efi'. Installation finished. No error reported. Ensuring the startup boots the right loader echo "fs0:\EFI\opensuse\grubx64.efi" > /boot/efi/startup.nsh What's installed at this point is tree -D /boot/efi /boot/efi ├── [root 512 Jun 21 2016] EFI │ ├── [root 512 Jan 7 9:47] boot │ │ ├── [root 1164376 Jan 7 9:47] bootx64.efi │ │ ├── [root 72240 Jan 4 6:37] fallback.efi │ │ ├── [root 120 Jan 7 9:47] grub.cfg │ │ ├── [root 1008720 Jan 7 9:47] grub.efi │ │ └── [root 1166552 Jan 7 9:47] MokManager.efi │ └── [root 512 Jun 21 2016] opensuse │ ├── [root 58 Jan 4 6:37] boot.csv │ ├── [root 120 Jan 4 6:37] grub.cfg │ ├── [root 1008720 Jan 4 6:37] grub.efi │ ├── [root 129024 Jan 7 13:53] grubx64.efi │ ├── [root 1166552 Jan 4 6:37] MokManager.efi │ └── [root 1164376 Jan 4 6:37] shim.efi └── [root 30 Jan 7 13:53] startup.nsh exit the chroot, then create the DomU xl create -c /etc/xen/vm/opensuse.cfg It still fails as reported above. Destroy the guest again xl destroy opensuse re-enter chroot Now, note the creationg/addition of tree -D /boot/efi /boot/efi ... ├── [root 12673 Jan 7 13:55] NvVars ... Checking that strings /boot/efi/NvVars | head 10 Washington1 Redmond1 Microsoft Corporation1;09 2Microsoft Corporation Third Party Marketplace Root0 110624204129Z 260624205129Z0 Washington1 Redmond1 Microsoft Corporation1*0( !Microsoft Corporation KEK CA 20110 So clearly the Guest's BIOS (tianocore/ovmf) at least 'touches' the EFI partition -- i.e. it's aware of the Guest. Why SecureBoot is involved is unclear. Is there some new Xen mechanism, or config param, to ensure it's DISABLED for Guests ? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org