[Yahoo-eng-team] [Bug 1960758] Re: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria
** Also affects: nova (Ubuntu) Importance: Undecided Status: New ** Also affects: nova (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: nova (Ubuntu) Status: New => Invalid ** Changed in: nova (Ubuntu Focal) Status: New => In Progress ** Changed in: nova (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: nova (Ubuntu Focal) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Changed in: nova/victoria Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned) ** Changed in: nova/ussuri Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1960758 Title: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria Status in OpenStack Compute (nova): Invalid Status in OpenStack Compute (nova) ussuri series: Invalid Status in OpenStack Compute (nova) victoria series: Invalid Status in nova package in Ubuntu: Invalid Status in nova source package in Focal: In Progress Bug description: Description: === Currently, setting hw_firwmare_type=uefi might create _unbootable_ servers on 20.04 hypervisors with Ussuri and Victoria (Wallaby and later are OK). This might hit other distros w/ OVMF_CODE.secboot.fd. We should not use the Secure Boot firmware on the 'pc' machine type, as 'q35' is _required_ by OVMF firmware if SMM feature is built (usually the case, to actually secure the SB feature). [See comment #6 for research and #7 for test evidence.] Steps to Reproduce: === $ openstack image set --property hw_firmware_type=uefi $IMAGE $ openstack server create --image $IMAGE --flavor $FLAVOR --network $NETWORK uefi-server Expected Result: === The server's libvirt XML uses UEFI _without_ Secure Boot. /usr/share/OVMF/OVMF_CODE.fd Guest boots, and console log confirms UEFI mode: $ openstack console log show srv | grep -i -e efi -e bios ... Creating boot entry "Boot0003" with label "ubuntu" for file "\EFI\ubuntu\shimx64.efi" ... [0.00] efi: EFI v2.70 by EDK II [0.00] efi: SMBIOS=0x7fbcd000 ACPI=0x7fbfa000 ACPI 2.0=0x7fbfa014 MEMATTR=0x7eb30018 [0.00] SMBIOS 2.8 present. [0.00] DMI: OpenStack Foundation OpenStack Nova, BIOS 0.0.0 02/06/2015 ... Actual Result: === The server's libvirt XML uses UEFI _with_ Secure Boot. /usr/share/OVMF/OVMF_CODE.secboot.fd Guest doesn't boot; empty console log; qemu-kvm looping at 100% CPU. $ openstack console log show srv | grep -i -e efi -e bios $ openstack console log show srv | wc -l 0 $ juju run --app nova-compute 'top -b -d1 -n5 | grep qemu' 67205 libvirt+ ... 100.0 1.4 1:18.35 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:19.36 qemu-sy+ 67205 libvirt+ ... 99.0 1.4 1:20.36 qemu-sy+ 67205 libvirt+ ... 101.0 1.4 1:21.37 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:22.38 qemu-sy+ Environment: === - Hypervisor running Ubuntu 20.04 LTS (Focal) - Nova from Ussuri (Ubuntu Archive) or Victoria (Cloud Archive). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1960758/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1960758] Re: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria
This bug was fixed in the package nova - 2:22.4.0-0ubuntu1~cloud5 --- nova (2:22.4.0-0ubuntu1~cloud5) focal-victoria; urgency=medium . * d/p/lp1960758-ubuntu-uefi-loader-path.patch: add config option 'ubuntu_libvirt_uefi_loader_path' to restrict UEFI loaders to only those shipped/supported in Ubuntu/Ussuri. (LP: #1960758) ** Changed in: cloud-archive/victoria Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1960758 Title: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive ussuri series: Fix Committed Status in Ubuntu Cloud Archive victoria series: Fix Released Status in OpenStack Compute (nova): Invalid Status in OpenStack Compute (nova) ussuri series: Invalid Status in OpenStack Compute (nova) victoria series: Invalid Status in nova package in Ubuntu: Invalid Status in nova source package in Focal: Fix Committed Bug description: Impact: === Currently, setting `hw_firwmare_type=uefi` may create _unbootable_ servers on 20.04 hypervisors with Ussuri and Victoria (Wallaby and later are OK). We should not use the Secure Boot firmware on the 'pc' machine type, as 'q35' is _required_ by OVMF firmware if SMM feature is built (usually the case, to actually secure the SB feature). [See comment #6 for research and #7 for test evidence.] We should not use the Secure Boot firmware on the 'q35' machine type _either_, as it might not work regardless, since other libvirt XML options such as SMM and S3/S4 disable may be needed for Secure Boot to work, but are _not_ configured by Openstack Ussuri (no SB support). Approach: === Considering how long Focal/Ussuri have been out there (and maybe worked with UEFI enabled for some cases?) add a config option to _opt-in_ to actually supported UEFI loaders for nova/libvirt. This seems to benefit downstream/Ubuntu more (although other distros might be affected) add the config option "ubuntu_libvirt_uefi_loader_path" (disabled by default) in the DEFAULT libvirt config section (so it can be set in nova-compute charm's 'config-flags' option). Test Plan: === $ openstack image set --property hw_firmware_type=uefi $IMAGE $ openstack server create --image $IMAGE --flavor $FLAVOR --network $NETWORK uefi-server (with patched packages:) Set `ubuntu_libvirt_uefi_loader_path = true` in `[DEFAULT]` in /etc/nova/nova.conf (eg `juju config nova-compute config-flags='ubuntu_libvirt_uefi_loader_path=true'`) $ openstack server stop uefi-server $ openstack server start uefi-server - Expected Result: The server's libvirt XML uses UEFI _without_ Secure Boot. /usr/share/OVMF/OVMF_CODE.fd The guest boots, and console log confirms UEFI mode: $ openstack console log show srv | grep -i -e efi -e bios ... Creating boot entry "Boot0003" with label "ubuntu" for file "\EFI\ubuntu\shimx64.efi" ... [0.00] efi: EFI v2.70 by EDK II [0.00] efi: SMBIOS=0x7fbcd000 ACPI=0x7fbfa000 ACPI 2.0=0x7fbfa014 MEMATTR=0x7eb30018 [0.00] SMBIOS 2.8 present. [0.00] DMI: OpenStack Foundation OpenStack Nova, BIOS 0.0.0 02/06/2015 ... - Actual Result: The server's libvirt XML uses UEFI _with_ Secure Boot. /usr/share/OVMF/OVMF_CODE.secboot.fd The guest doesn't boot; empty console log; qemu-kvm looping at 100% CPU. $ openstack console log show srv | grep -i -e efi -e bios $ openstack console log show srv | wc -l 0 $ juju run --app nova-compute 'top -b -d1 -n5 | grep qemu' 67205 libvirt+ ... 100.0 1.4 1:18.35 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:19.36 qemu-sy+ 67205 libvirt+ ... 99.0 1.4 1:20.36 qemu-sy+ 67205 libvirt+ ... 101.0 1.4 1:21.37 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:22.38 qemu-sy+ Where problems could occur: === The changes are opt-in with `ubuntu_libvirt_uefi_loader_path=true`, so users are not affected by default. Theoretically, regressions would more likely manifest and be contained in nova's libvirt driver, when `hw_firwmare_type=uefi` (not by default). The expected symptoms of regressions are boot failures (server starts from openstack perspective, but doesn't boot to the operating system). Other Info: === - Hypervisor running Ubuntu 20.04 LTS (Focal) - Nova packages from Ussuri (Ubuntu Archive) or Victoria (Cloud Archive). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1960758/+subscriptions -- Mailing list: https://launchpad
[Yahoo-eng-team] [Bug 1960758] Re: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria
This bug was fixed in the package nova - 2:21.2.4-0ubuntu2.6 --- nova (2:21.2.4-0ubuntu2.6) focal; urgency=medium * d/p/lp1960758-ubuntu-uefi-loader-path.patch: add config option 'ubuntu_libvirt_uefi_loader_path' to restrict UEFI loaders to only those shipped/supported in Ubuntu/Ussuri. (LP: #1960758) -- Mauricio Faria de Oliveira Tue, 25 Jul 2023 17:34:00 -0300 ** Changed in: nova (Ubuntu Focal) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1960758 Title: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive ussuri series: Fix Committed Status in Ubuntu Cloud Archive victoria series: Fix Released Status in OpenStack Compute (nova): Invalid Status in OpenStack Compute (nova) ussuri series: Invalid Status in OpenStack Compute (nova) victoria series: Invalid Status in nova package in Ubuntu: Invalid Status in nova source package in Focal: Fix Released Bug description: Impact: === Currently, setting `hw_firwmare_type=uefi` may create _unbootable_ servers on 20.04 hypervisors with Ussuri and Victoria (Wallaby and later are OK). We should not use the Secure Boot firmware on the 'pc' machine type, as 'q35' is _required_ by OVMF firmware if SMM feature is built (usually the case, to actually secure the SB feature). [See comment #6 for research and #7 for test evidence.] We should not use the Secure Boot firmware on the 'q35' machine type _either_, as it might not work regardless, since other libvirt XML options such as SMM and S3/S4 disable may be needed for Secure Boot to work, but are _not_ configured by Openstack Ussuri (no SB support). Approach: === Considering how long Focal/Ussuri have been out there (and maybe worked with UEFI enabled for some cases?) add a config option to _opt-in_ to actually supported UEFI loaders for nova/libvirt. This seems to benefit downstream/Ubuntu more (although other distros might be affected) add the config option "ubuntu_libvirt_uefi_loader_path" (disabled by default) in the DEFAULT libvirt config section (so it can be set in nova-compute charm's 'config-flags' option). Test Plan: === $ openstack image set --property hw_firmware_type=uefi $IMAGE $ openstack server create --image $IMAGE --flavor $FLAVOR --network $NETWORK uefi-server (with patched packages:) Set `ubuntu_libvirt_uefi_loader_path = true` in `[DEFAULT]` in /etc/nova/nova.conf (eg `juju config nova-compute config-flags='ubuntu_libvirt_uefi_loader_path=true'`) $ openstack server stop uefi-server $ openstack server start uefi-server - Expected Result: The server's libvirt XML uses UEFI _without_ Secure Boot. /usr/share/OVMF/OVMF_CODE.fd The guest boots, and console log confirms UEFI mode: $ openstack console log show srv | grep -i -e efi -e bios ... Creating boot entry "Boot0003" with label "ubuntu" for file "\EFI\ubuntu\shimx64.efi" ... [0.00] efi: EFI v2.70 by EDK II [0.00] efi: SMBIOS=0x7fbcd000 ACPI=0x7fbfa000 ACPI 2.0=0x7fbfa014 MEMATTR=0x7eb30018 [0.00] SMBIOS 2.8 present. [0.00] DMI: OpenStack Foundation OpenStack Nova, BIOS 0.0.0 02/06/2015 ... - Actual Result: The server's libvirt XML uses UEFI _with_ Secure Boot. /usr/share/OVMF/OVMF_CODE.secboot.fd The guest doesn't boot; empty console log; qemu-kvm looping at 100% CPU. $ openstack console log show srv | grep -i -e efi -e bios $ openstack console log show srv | wc -l 0 $ juju run --app nova-compute 'top -b -d1 -n5 | grep qemu' 67205 libvirt+ ... 100.0 1.4 1:18.35 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:19.36 qemu-sy+ 67205 libvirt+ ... 99.0 1.4 1:20.36 qemu-sy+ 67205 libvirt+ ... 101.0 1.4 1:21.37 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:22.38 qemu-sy+ Where problems could occur: === The changes are opt-in with `ubuntu_libvirt_uefi_loader_path=true`, so users are not affected by default. Theoretically, regressions would more likely manifest and be contained in nova's libvirt driver, when `hw_firwmare_type=uefi` (not by default). The expected symptoms of regressions are boot failures (server starts from openstack perspective, but doesn't boot to the operating system). Other Info: === - Hypervisor running Ubuntu 20.04 LTS (Focal) - Nova packages from Ussuri (Ubuntu Archive) or Victoria (Cloud Archive). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1960758/+subscriptions
[Yahoo-eng-team] [Bug 1960758] Re: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria
This bug was fixed in the package nova - 2:21.2.4-0ubuntu2.6~cloud0 --- nova (2:21.2.4-0ubuntu2.6~cloud0) bionic-ussuri; urgency=medium . * New update for the Ubuntu Cloud Archive. . nova (2:21.2.4-0ubuntu2.6) focal; urgency=medium . * d/p/lp1960758-ubuntu-uefi-loader-path.patch: add config option 'ubuntu_libvirt_uefi_loader_path' to restrict UEFI loaders to only those shipped/supported in Ubuntu/Ussuri. (LP: #1960758) ** Changed in: cloud-archive/ussuri Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1960758 Title: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive ussuri series: Fix Released Status in Ubuntu Cloud Archive victoria series: Fix Released Status in OpenStack Compute (nova): Invalid Status in OpenStack Compute (nova) ussuri series: Invalid Status in OpenStack Compute (nova) victoria series: Invalid Status in nova package in Ubuntu: Invalid Status in nova source package in Focal: Fix Released Bug description: Impact: === Currently, setting `hw_firwmare_type=uefi` may create _unbootable_ servers on 20.04 hypervisors with Ussuri and Victoria (Wallaby and later are OK). We should not use the Secure Boot firmware on the 'pc' machine type, as 'q35' is _required_ by OVMF firmware if SMM feature is built (usually the case, to actually secure the SB feature). [See comment #6 for research and #7 for test evidence.] We should not use the Secure Boot firmware on the 'q35' machine type _either_, as it might not work regardless, since other libvirt XML options such as SMM and S3/S4 disable may be needed for Secure Boot to work, but are _not_ configured by Openstack Ussuri (no SB support). Approach: === Considering how long Focal/Ussuri have been out there (and maybe worked with UEFI enabled for some cases?) add a config option to _opt-in_ to actually supported UEFI loaders for nova/libvirt. This seems to benefit downstream/Ubuntu more (although other distros might be affected) add the config option "ubuntu_libvirt_uefi_loader_path" (disabled by default) in the DEFAULT libvirt config section (so it can be set in nova-compute charm's 'config-flags' option). Test Plan: === $ openstack image set --property hw_firmware_type=uefi $IMAGE $ openstack server create --image $IMAGE --flavor $FLAVOR --network $NETWORK uefi-server (with patched packages:) Set `ubuntu_libvirt_uefi_loader_path = true` in `[DEFAULT]` in /etc/nova/nova.conf (eg `juju config nova-compute config-flags='ubuntu_libvirt_uefi_loader_path=true'`) $ openstack server stop uefi-server $ openstack server start uefi-server - Expected Result: The server's libvirt XML uses UEFI _without_ Secure Boot. /usr/share/OVMF/OVMF_CODE.fd The guest boots, and console log confirms UEFI mode: $ openstack console log show srv | grep -i -e efi -e bios ... Creating boot entry "Boot0003" with label "ubuntu" for file "\EFI\ubuntu\shimx64.efi" ... [0.00] efi: EFI v2.70 by EDK II [0.00] efi: SMBIOS=0x7fbcd000 ACPI=0x7fbfa000 ACPI 2.0=0x7fbfa014 MEMATTR=0x7eb30018 [0.00] SMBIOS 2.8 present. [0.00] DMI: OpenStack Foundation OpenStack Nova, BIOS 0.0.0 02/06/2015 ... - Actual Result: The server's libvirt XML uses UEFI _with_ Secure Boot. /usr/share/OVMF/OVMF_CODE.secboot.fd The guest doesn't boot; empty console log; qemu-kvm looping at 100% CPU. $ openstack console log show srv | grep -i -e efi -e bios $ openstack console log show srv | wc -l 0 $ juju run --app nova-compute 'top -b -d1 -n5 | grep qemu' 67205 libvirt+ ... 100.0 1.4 1:18.35 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:19.36 qemu-sy+ 67205 libvirt+ ... 99.0 1.4 1:20.36 qemu-sy+ 67205 libvirt+ ... 101.0 1.4 1:21.37 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:22.38 qemu-sy+ Where problems could occur: === The changes are opt-in with `ubuntu_libvirt_uefi_loader_path=true`, so users are not affected by default. Theoretically, regressions would more likely manifest and be contained in nova's libvirt driver, when `hw_firwmare_type=uefi` (not by default). The expected symptoms of regressions are boot failures (server starts from openstack perspective, but doesn't boot to the operating system). Other Info: === - Hypervisor running Ubuntu 20.04 LTS (Focal) - Nova packages from Ussuri (Ubuntu Archive) or Victoria (Cloud Archive). To manage notifications about this bug go to: https
[Yahoo-eng-team] [Bug 1960758] Re: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria
** Also affects: nova/victoria Importance: Undecided Status: New ** Also affects: nova/ussuri Importance: Undecided Status: New ** Changed in: nova Status: New => Invalid ** Changed in: nova/victoria Status: New => In Progress ** Changed in: nova/ussuri Status: New => Confirmed ** Changed in: nova/ussuri Importance: Undecided => Medium ** Changed in: nova/victoria Importance: Undecided => Medium ** Changed in: nova/ussuri Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Changed in: nova/victoria Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1960758 Title: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria Status in OpenStack Compute (nova): Invalid Status in OpenStack Compute (nova) ussuri series: Confirmed Status in OpenStack Compute (nova) victoria series: In Progress Bug description: Description: === Currently, setting hw_firwmare_type=uefi might create _unbootable_ servers on 20.04 hypervisors with Ussuri and Victoria (Wallaby and later are OK). This might hit other distros w/ OVMF_CODE.secboot.fd. We should not use the Secure Boot firmware on the 'pc' machine type, as 'q35' is _required_ by OVMF firmware if SMM feature is built (usually the case, to actually secure the SB feature). [See comment #6 for research and #7 for test evidence.] Steps to Reproduce: === $ openstack image set --property hw_firmware_type=uefi $IMAGE $ openstack server create --image $IMAGE --flavor $FLAVOR --network $NETWORK uefi-server Expected Result: === The server's libvirt XML uses UEFI _without_ Secure Boot. /usr/share/OVMF/OVMF_CODE.fd Guest boots, and console log confirms UEFI mode: $ openstack console log show srv | grep -i -e efi -e bios ... Creating boot entry "Boot0003" with label "ubuntu" for file "\EFI\ubuntu\shimx64.efi" ... [0.00] efi: EFI v2.70 by EDK II [0.00] efi: SMBIOS=0x7fbcd000 ACPI=0x7fbfa000 ACPI 2.0=0x7fbfa014 MEMATTR=0x7eb30018 [0.00] SMBIOS 2.8 present. [0.00] DMI: OpenStack Foundation OpenStack Nova, BIOS 0.0.0 02/06/2015 ... Actual Result: === The server's libvirt XML uses UEFI _with_ Secure Boot. /usr/share/OVMF/OVMF_CODE.secboot.fd Guest doesn't boot; empty console log; qemu-kvm looping at 100% CPU. $ openstack console log show srv | grep -i -e efi -e bios $ openstack console log show srv | wc -l 0 $ juju run --app nova-compute 'top -b -d1 -n5 | grep qemu' 67205 libvirt+ ... 100.0 1.4 1:18.35 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:19.36 qemu-sy+ 67205 libvirt+ ... 99.0 1.4 1:20.36 qemu-sy+ 67205 libvirt+ ... 101.0 1.4 1:21.37 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:22.38 qemu-sy+ Environment: === - Hypervisor running Ubuntu 20.04 LTS (Focal) - Nova from Ussuri (Ubuntu Archive) or Victoria (Cloud Archive). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1960758/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1960758] Re: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria
This turned out not to be needed in practice; marking as Won't Fix. ** Changed in: nova/ussuri Status: Confirmed => Invalid ** Changed in: nova/victoria Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1960758 Title: UEFI libvirt servers can't boot on Ubuntu 20.04 hypervisors with Ussuri/Victoria Status in OpenStack Compute (nova): Invalid Status in OpenStack Compute (nova) ussuri series: Invalid Status in OpenStack Compute (nova) victoria series: Invalid Bug description: Description: === Currently, setting hw_firwmare_type=uefi might create _unbootable_ servers on 20.04 hypervisors with Ussuri and Victoria (Wallaby and later are OK). This might hit other distros w/ OVMF_CODE.secboot.fd. We should not use the Secure Boot firmware on the 'pc' machine type, as 'q35' is _required_ by OVMF firmware if SMM feature is built (usually the case, to actually secure the SB feature). [See comment #6 for research and #7 for test evidence.] Steps to Reproduce: === $ openstack image set --property hw_firmware_type=uefi $IMAGE $ openstack server create --image $IMAGE --flavor $FLAVOR --network $NETWORK uefi-server Expected Result: === The server's libvirt XML uses UEFI _without_ Secure Boot. /usr/share/OVMF/OVMF_CODE.fd Guest boots, and console log confirms UEFI mode: $ openstack console log show srv | grep -i -e efi -e bios ... Creating boot entry "Boot0003" with label "ubuntu" for file "\EFI\ubuntu\shimx64.efi" ... [0.00] efi: EFI v2.70 by EDK II [0.00] efi: SMBIOS=0x7fbcd000 ACPI=0x7fbfa000 ACPI 2.0=0x7fbfa014 MEMATTR=0x7eb30018 [0.00] SMBIOS 2.8 present. [0.00] DMI: OpenStack Foundation OpenStack Nova, BIOS 0.0.0 02/06/2015 ... Actual Result: === The server's libvirt XML uses UEFI _with_ Secure Boot. /usr/share/OVMF/OVMF_CODE.secboot.fd Guest doesn't boot; empty console log; qemu-kvm looping at 100% CPU. $ openstack console log show srv | grep -i -e efi -e bios $ openstack console log show srv | wc -l 0 $ juju run --app nova-compute 'top -b -d1 -n5 | grep qemu' 67205 libvirt+ ... 100.0 1.4 1:18.35 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:19.36 qemu-sy+ 67205 libvirt+ ... 99.0 1.4 1:20.36 qemu-sy+ 67205 libvirt+ ... 101.0 1.4 1:21.37 qemu-sy+ 67205 libvirt+ ... 100.0 1.4 1:22.38 qemu-sy+ Environment: === - Hypervisor running Ubuntu 20.04 LTS (Focal) - Nova from Ussuri (Ubuntu Archive) or Victoria (Cloud Archive). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1960758/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
