Agreed, marked both tasks Won't Fix.
** Changed in: edk2 (Ubuntu Eoan)
Status: Confirmed => Won't Fix
** Changed in: libvirt (Ubuntu Bionic)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Another +1 on leave it alone would be that Bionic users could (if for
whatever reason they don't want/can to modify the conffile) can also
consider getting the cloud archive based new version from focal along
that newer ovmf packages and then fully work as in focal.
For Eoan it is odd,
One other comment about bionic - this would require a default config
file change, so I believe every bionic user who has modified
/etc/libvirt/qemu.conf would then get prompted about differences there.
In my mind this tips the scales more towards "leave it alone".
--
You received this bug
This is now addressed in focal, so now let's discuss what we should do
for eoan/bionic.
= eoan =
At a high level the issue here is that cosmic/disco behaved a certain way,
eoan's behavior changed, and we've now restored the cosmic/disco behavior in
focal. Detail: the behavior change concerns
This bug was fixed in the package edk2 - 0~20191122.bd85bf54-2ubuntu2
---
edk2 (0~20191122.bd85bf54-2ubuntu2) focal; urgency=medium
* Bring back (and fix) the "ms" option and restore the behavior of the
"secboot" option, which had changed when libvirt moved from built-in
** Changed in: libvirt (Ubuntu)
Status: In Progress => Invalid
** Changed in: libvirt (Ubuntu Eoan)
Status: Confirmed => Invalid
** Changed in: edk2 (Ubuntu Eoan)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
I've just uploaded the following changes to Debian:
https://salsa.debian.org/qemu-team/edk2/-/commit/1698e2a07e5c8a07ff0d772d2a9377ebe577d544
https://salsa.debian.org/qemu-team/edk2/-/commit/a08b306955cfde78b39028ae8bad44922e0c8e1b
** Changed in: edk2 (Ubuntu Bionic)
Status: New => Invalid
** Changed in: edk2 (Ubuntu)
Status: New => In Progress
** Changed in: edk2 (Ubuntu)
Assignee: (unassigned) => dann frazier (dannf)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
After digging into this today, I'm thinking that I may not be using
OVMF_CODE.secboot.fd as intended. While I initially assumed that
specifying OVMF_CODE.secboot.fd would give you a system with Secure Boot
*active* - it actually just gives you a system where Secure Boot *could*
be activated, if
** Also affects: edk2 (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1864532
Title:
Incorrect nvram template for secboot firmware
To manage
** Changed in: libvirt (Ubuntu Eoan)
Status: New => Confirmed
** Changed in: libvirt (Ubuntu Eoan)
Importance: Undecided => Low
** Changed in: libvirt (Ubuntu)
Status: Confirmed => In Progress
** Changed in: libvirt (Ubuntu)
Assignee: (unassigned) => dann frazier (dannf)
** Also affects: libvirt (Ubuntu Eoan)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1864532
Title:
Incorrect nvram template for secboot firmware
To
** Also affects: libvirt (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: libvirt (Ubuntu)
Importance: Undecided => Low
** Changed in: libvirt (Ubuntu Bionic)
Importance: Undecided => Low
** Changed in: libvirt (Ubuntu Bionic)
Status: New => Confirmed
--
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: libvirt (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1864532
Title:
14 matches
Mail list logo
