You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On a Debian sid system, Incus 0.4 fails to properly detect that QEMU is available as a backend. This is caused by a hardcoded check for the file OVMF_CODE.fd (driver_qemu.go line 8309).
Beginning with trixie, Debian's ovmf package only ships the 4M images, which include "_4M" in their file names.
I've come up with the following patch that mimics other bits of code in driver_qemu.go to dynamically determine the correct firmware file. This would essentially be the third copy of the same logic in that file, so I didn't submit a PR because it feels like there should be some refactoring as well.
checkFeatures is a function which is called once on daemon startup to validate that QEMU is functional and detect some QEMU capabilities. It's not tied to any particular instance's config so we don't need that much logic in there.
I think I'll just put in a simple loop to try to find "any" firmware it can use.
stgraber
added a commit
to stgraber/incus
that referenced
this issue
Jan 8, 2024
On a Debian sid system, Incus 0.4 fails to properly detect that QEMU is available as a backend. This is caused by a hardcoded check for the file
OVMF_CODE.fd
(driver_qemu.go
line 8309).Beginning with trixie, Debian's ovmf package only ships the 4M images, which include "_4M" in their file names.
I've come up with the following patch that mimics other bits of code in
driver_qemu.go
to dynamically determine the correct firmware file. This would essentially be the third copy of the same logic in that file, so I didn't submit a PR because it feels like there should be some refactoring as well.The text was updated successfully, but these errors were encountered: