Hi - I have set up QEMU and connect using Virt-Manager on the latest build, though cannot seen to enable the UEFI firmware as there is no OVMF addon that can be installed. Thankyou in Advance
Sorry, we currently do not package this.
@jschlag, do you want to have a look at this if it is possible to build it for IPFire?
1 Like
Hi Thankyou for your answer - I suspect I don’t have the skills and appreciate that you have only a limited amount of time.
Thankyou for your response.
Did this ever end up being packaged?
I think Fedora dropped BIOS support, so this would be nice to have for booting Fedora based images.
No it didn’t.
Discussed this topic in the IPFire conf call. I will pick it up to look at the possibilities for building the OVMF package capability.
This won’t happen straight away as I need to complete a few things that I am currently working on or that are on my list for a while but I will get round to it and see how things go.
2 Likes
I have unpacked the open virtual machine firmware debian binary package and converted it for ipfire.
cd /opt/pakfire/tmp
wget https://people.ipfire.org/~arne_f/highly-experimental/ovmf-2024.11-5-1.ipfire
tar xvf ovmf-2024.11-5-1.ipfire
./install.sh
4 Likes
This is great news. I was trying to come up with an alternative solution, but if there is a chance that this lands in ipfire officially soon I guess I can wait a bit on my production system.
It is already in unstable tree. I think i will add it to testing at this weekend. And should go to stable in around a month.
1 Like
POV here, @povoq
I’d not use Proxmox nor ESXi as a firewall.
I’d really not use IpFire as Type1 virtualizer.
I just want to run a reverse-proxy and a few related tools on the same physical machine to avoid lots of back and forths in the internal network. The currently available tools on ipfire like nginx and dehydrated kinda do the job, but are a bit too limited.
Thanks for the explaination about the goals of your setup. As any skilled, competent and senior sysadmin this setup achieve the results needed and allow a manageable security risk.
AFAIK virtualize a computer on top of IpFire means that if anyone unauthorized gets access to IpFire (not implying nor alluding there’s currently any way to allow that…) has complete access of the virtualized system: can be compromised, shut off, destroyed.
The other way around (virtualized IPfire as guest of any Type 1 virtualizer, an adversed solution by IPfire project and mantainers) can stack vulnerabilities of the host, the virtualizzing software and the guest, complicating the security level. But for escaping the isolation of the guest at least one or more of the vulnerabilites have to match each other…
Anyway… again POV. Hope that it will be mind food for the readers.
1 Like
Did this make it into 192?
