Bug 1727987
| Summary: | Secureboot VM cannot boot normally after complete powerdown. Manual intervention required. | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Strahil Nikolov <hunter86_bg> |
| Component: | BLL.Virt | Assignee: | Shmuel Melamud <smelamud> |
| Status: | CLOSED DUPLICATE | QA Contact: | Nisim Simsolo <nsimsolo> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.3.5.3 | CC: | ahadas, bugs, mathieu.simon |
| Target Milestone: | ovirt-4.4.4 | Flags: | sbonazzo:
ovirt-4.4?
|
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-09-29 14:22:57 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Nvram is not persisted. There’s RFE for that somewhere.... We should probably start with simple ansible to update the common template at least Note also that SecureBoot is tentatively scheduled for 4.4, so an immediate fix for nvram is unlikely, but this workaround is an easy start Hi I've been messing around with UEFI on RHV 4.3.6 and wanted to share some of my findings here: The main issue on OVMF in general without a persistent NVRAM is that it only looks for a loader in BOOT/BOOTX64.EFI in the EFI partition. This issue has equally existed on another KVM-based virtualization platform Proxmox VE, until they've added support for persistent NVRAM (back with Proxmox 4.3 in 2016, though without SecureBoot yet). -> Ultimately adding a persistent NVRAM is going to be required at some point for oVirt/RHV. For OpenSuse: Since currently OVMF isn't persisted, one cannot import their custom signing keys so IMO fully enforcing SecureBoot doesn't work with OpenSuse since they don't have a Microsoft-signed shim loader like RHEL/Ubuntu/CentOS. The OVMF delivered with RHV only ships with 2 Microsoft CAs so for SecureBoot to work, a Microsoft-signed shim loader is mandatory at that point. Debian 10 does have a Microsoft-signed shimx64.efi but puts it into debian/shimx64.efi where a non-persistent OVMF doesn't look for. However it is sufficient to manually copy this file to BOOT/BOOTX64.EFI. Thereafter Debian 10 boots without manual interaction and WITH SecureBoot enabled. Ubuntu 18.04 seems to apply a "trick" by copying its shimx64.efi like RHEL 7 and 8 on UEFI systems. (However I've failed booting RHEL 8.0 installers at all at this point) For details on this see this thread on the oVirt users list: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/UEK5EHLRZYGP73YVMAWUHVWLZYS7W2KI/ Regards Mathieu *** This bug has been marked as a duplicate of bug 1669178 *** Re-targeting to 4.4.4 being marked as duplicate of bug #1669178 which is targeted to 4.4.4. |
Description of problem: VMs with Secureboot cannot boot properly after a fresh poweron. On openSUSE - the certificate prompt comes up , while on RHEL 8 - the grub menu shows only Firmware Setup entry. Version-Release number of selected component (if applicable): ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch libvirt-4.5.0-10.el7_6.12.x86_64 libvirt-bash-completion-4.5.0-10.el7_6.12.x86_64 libvirt-client-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-config-network-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-config-nwfilter-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-interface-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-lxc-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-network-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-nodedev-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-nwfilter-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-qemu-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-secret-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-storage-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-storage-core-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-storage-disk-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-storage-gluster-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-storage-iscsi-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-storage-logical-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-storage-mpath-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-storage-rbd-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-driver-storage-scsi-4.5.0-10.el7_6.12.x86_64 libvirt-daemon-kvm-4.5.0-10.el7_6.12.x86_64 libvirt-libs-4.5.0-10.el7_6.12.x86_64 libvirt-lock-sanlock-4.5.0-10.el7_6.12.x86_64 libvirt-python-4.5.0-1.el7.x86_64 qemu-img-ev-2.12.0-18.el7_6.5.1.x86_64 qemu-kvm-common-ev-2.12.0-18.el7_6.5.1.x86_64 qemu-kvm-ev-2.12.0-18.el7_6.5.1.x86_64 OVMF-20180508-3.gitee3198e672e2.el7_6.1.noarch Engine is 4.3.5.3 How reproducible: Always.Tested with openSUSE15.1 & RHEL8 Steps to Reproduce: 1.Create a VM (RHEL8) with "Q35 Chipset with SecureBoot" 2. Update the VM 3.After initial install completely poweroff the system 3.Poweron the system - there will be only 'System setup' menu. Actual results: RHEL8 goes into the firmware menu and requires manual intervention- either send "Ctrl Alt End" or click "Continue" in UEFI menu. Workaround must be applied in order to get the system able to boot by itself. openSuSE 15.1 always asks for accepting the openSUSE key (which should happen only first time only).No workaround found , yet. Expected results: The system to poweron and boot normally after complete powerdown. Additional info: Workaround for RHEl8 - edit grub.cfg (or even better "/etc/grub.d/30_uefi-firmware" and run grub2-mkconfig -o) so the firmware section will look like this: ### BEGIN /etc/grub.d/30_uefi-firmware ### menuentry 'Reboot' $menuentry_id_option 'uefi-reboot' { reboot } menuentry 'System setup' $menuentry_id_option 'uefi-firmware' { fwsetup } ### END /etc/grub.d/30_uefi-firmware ### On power on - the first menu will be to reboot and afterward the default grub entry will be autoselected and boot process will not be interrupted. No workaround for openSUSE 15.1 found , yet.