[Bug 2022312] Re: Adding IA32 to X64 pkg, because secure boot is not working on Focal

Mon Jan 15 21:11:19 UTC 2024

Hi Christian,

Thanks for reviewing!

> AFAICS In his comment #25 DannF was leaning towards solution #2 of comment #20 but solution #1 seemed ok as well.
> ...
>  (Gladly solutions #1 and #2 are not mutually exclusive, we can go for #2 now and worst case still consider #1 later)

Right. What I expressed was my opinion after considering comments #25
and #11, with a preference for your suggestion in #11 (nova to set
libvirt options), while taking Dann's remark in #25 (not do something
atypical -- by default).

I see that Dann provided a detailed regression risk assessment in #25
(2nd paragraph) with positive, technical observations on areas for
potential regressions, and did not block an edk2 SRU from proceeding.

On that option, I think if we could run test scenarios for such areas,
that would alleviate concerns a lot (eg, create Linux/Windows VMs with
the existing firmware, upgrade it to test packages, power off/on VMs,
and check for issues; hopefully none).

However, as you, I too think #1 seems OK (since other tools/upper layers
already do it) and like a consistent/similar approach.

If you prefer option #2 (edk2) now, I think that is OK and has valid
reasons too (we know some use-case is broken, and could fix it with a
reasonable understanding of regression risk and sufficient testing to
mitigate it).

I'll proceed with the remaining 2x +0.01 for now :)

> ... if we know if this is working well for the users that are affected by this ...
> ... we should avoid releasing this only to end up with people stating "But I can't change my nova.conf"

Good point.

We can definitely provide test packages and usage instructions for the affected users (support customer).
I'm not sure of specific scenarios that users cannot change their config files, and have previously provided a similar method (opt-in config option) that has been used.

(The usage of the 'DEFAULT' section for the workaround, instead of the
traditional 'workarounds' section, is on purpose, so that the nova-
compute charm options can be used to enable it; as done in the other
case.)

Would an ACK from this particular affected user/customer be sufficient for this point?
I'm happy to check for additional things if needed!

> If we add this to Nova in focal it will make it react to ubuntu_libvirt_uefi_secboot_disable_s3 config option. 
> Once such a user upgrades to Jammy, will it break, will it silently be ignored but working the same way, will it need a patch to jammy and later to handle such upgrades well?

Good point.
Unknown options are ignored on Focal with Yoga/UCA and Jammy (which ships Yoga), and need no additional handling in later/unaffected releases.

I have verified this today, with a juju openstack deployment on focal-
yoga then do-release-upgrade the nova-compute unit from focal to jammy.

In all cases, an unknown config option was present in the DEFAULT section of the config file, and all service restarts happened successfully and the service stayed up/active.
I found no mention of errors or that option in /var/log/nova/nova-compute.log (it has a dump of all config options, and nothing mentioned it).

@ /etc/nova/nova.conf
[DEFAULT]
unknown_config_option=value

# systemctl status nova-compute.service  | grep -e Active: -e config-file
     Active: active (running) since Mon 2024-01-15 18:24:51 UTC; 14s ago
             └─113113 /usr/bin/python3 /usr/bin/nova-compute --config-file=/etc/nova/nova.conf --config-file=/etc/nova/nova-compute.conf --log-file=/var/log/nova/nova-compute.log

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/2022312

Title:
  Adding IA32 to X64 pkg, because secure boot is not working on Focal

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive yoga series:
  Confirmed
Status in edk2 package in Ubuntu:
  Fix Released
Status in edk2 source package in Focal:
  In Progress
Status in edk2 source package in Jammy:
  Fix Released

Bug description:
  [Impact]

  In Focal, secureboot is not working ( black screen right after
  instance is started )

  [Test Case]
  0. juju bundle for focal-yoga openstack env
  - https://pastebin.ubuntu.com/p/G38JwXMX5G/
  1. create custom image with cirros
  - openstack image create --container-format bare --disk-format qcow2 --file cirros-0.5.1-x86_64-disk.img cirros
  2. set image properties.
  - $ openstack image set --property hw_machine_type=q35 --property hw_firmware_type=uefi --property os_secure_boot=required cirros
  3. In focal, create instance, and enable secureboot
  4. start instance.
  5. you just can see only blackscreen.

  [Where problems could occur]
  Secureboot may have issue.

  [Others]
  For Jammy, it is ok

  instance xml
  - https://pastebin.ubuntu.com/p/MnK6nx3vwy/

  #ADDED
  Testing
  1. Prepared cirros and cirros2 image
  2. only set secure boot parameters to cirros image
  3. launch instances
  - instance with cirros image
  - instance with cirros2 image
  4. test result
  - booting cirros instance doesn't work(black screen) with original OVMF_CODE_4M.secboot.fd
  - booting cirros instance does work(shows uefi prompt) with patched OVMF_CODE_4M.secboot.fd
  - booting cirros2 instance either cases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2022312/+subscriptions