>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: [email protected]
To contact the owner, e-mail: [email protected]
