Comment 12 for bug 1989078
Revision history for this message
| Christian Ehrhardt (paelzer) wrote | #12 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
I'm testing this on an rpi4 (using arm64).
root@faavmf:~# virt-install --name test --ram 512 --vcpus 2 --disk size=2 --location https:/
...
Now this is a bit tricky now, as it works fine with the fix.
I checked the guest definition and it has what we expected it to have to make it trigger:
<loader readonly='yes' type='pflash'
The qemu being the guest has it open:
root@faavmf:~# ll /proc/7904/fd/12
lr-x------ 1 libvirt-qemu kvm 64 Feb 2 10:54 /proc/7904/fd/12 -> /usr/share/
And the tricky part is that it also works fine without the fix!
You might think - that seems wrong, I thought so as well - as I said, it is tricky.
The locking of images, and later of boot resources was added to qemu over time.
And using the original qemu of focal didn't lock the aavmf path yet.
But if one would be using a newer qemu then this would happen (An example might be using server-backports, but TBH the libvirt from there would already have the fix).
We want to be open to other use-cases, the rule is considered safe, and applied upstream and in later releases. Users can use other qemu builds, and while we do not support them, we do not artificially block them either.
Also I continued testing the new version and it is fine.
So where are we:
1. the new libvirt works fine and allows the access we got reported
2. the old libvirt works also fine in any common config (but would not allow the access)
I'd call this verification-done (it does work, and the new access is allowed).
But at the same time since this is such a edge case of edge cases I think it would be wasting bandwidth and patience to release that.
Hence i'd also mark it block-proposed to only be released when riding on top of any other follow on fix that is worth triggering downloads on millions of machines.
If anyone is affected and can show that it is more real and more urgent, please describe the case to demonstrate why.
[1]: https:/