I am happy to announce that the latest release of Qubes Mirage Firewall has just been released (0.9.5).
In addition to ecosystem and compiler updates, this release update ARP entry behavior: the unikernel now responds with its MAC address for every APR request from a client. This fixes issues with some VPN clients (#221). Also, this version update HVM client handling: HVM Clients, such as Windows, have two network interfaces but only use one. This causes deadlock states because the connection protocol for one interface is not completed, leading the unikernel to wait for the client to shut down. Now, each connection uses its own thread, and the unikernel can handle Windows HVM (#219).
You can update either manually (local compilation with podman/docker, or download from github, check hashsum, copy to dom0) or with the salt formula available on the github repository, or with @ben-grande or @unman’s repositories.
If you have any comments, please let us know, on this forum or on github.
Actually error in build process failed to get extra source ocaml-config.install I think I didn’t check build process and did everything after trying again I am having error during build with both docker and podman
I am already using it (for the 1st time) and it is working without any issues
Was it ever considered to add rpmspec / builder config to it, have it available as a proper independent easy to install rpm package? (even as a part of qubes-contrib repo)
The command at the top of your screenshot shows a failure due to too many requests. Maybe there is other people that use GH on your local net, or maybe it should work after a delay?
Podman or Docker should cache a lot of work, so a succesful build should already have a working ocaml.
It would be great to have rpm in qubes-contrib repo. Last time I tried there was issues installing such rpm builded with qubes-builder-mirage (and anyway that was builderv1)
mirage-firewall: Start failed: internal error: libxenlight failed to create new domain 'mirage-firewall', see /var/log/libvert/libxl/libxl-driver.log for details
The appVM is named “mirage-firewall”.
The log shows “The kernel doesn’t support reset from sysfs for PCI device ####”(#### means it’s showing a bunch of different PCI devices).
Update: I’m an idiot – just swapped the file locations from dom0 to a dispVM I copied the files to and it worked. But now I’m having different issue.
When I run the mirage-firewall VM, it shuts down immediately and logs give me this:
[2025-10-31 17:00:31] Logfile Opened
[2025-10-31 17:00:31] Solo5: Xen console: port 0x2, ring @0x00000000FEFFF000
[2025-10-31 17:00:31] | ___|
[2025-10-31 17:00:31] __| _ \ | _ \ __ \
[2025-10-31 17:00:31] \__ \ ( | | ( | ) |
[2025-10-31 17:00:31] ____/\___/ _|\___/____/
[2025-10-31 17:00:31] Solo5: Bindings version v0.9.3
[2025-10-31 17:00:31] Solo5: Memory map: 32 MB addressable:
[2025-10-31 17:00:31] Solo5: reserved @ (0x0 - 0xfffff)
[2025-10-31 17:00:31] Solo5: text @ (0x100000 - 0x315fff)
[2025-10-31 17:00:31] Solo5: rodata @ (0x316000 - 0x390fff)
[2025-10-31 17:00:31] Solo5: data @ (0x391000 - 0x528fff)
[2025-10-31 17:00:31] Solo5: heap >= 0x529000 < stack < 0x2000000
[2025-10-31 17:00:31] qubes-firewall: too many arguments, don't know what to do with 'root=/dev/mapper/dmroot', 'ro', 'nomodeset', 'console=hvc0', 'rd_NO_PLYMOUTH', 'rd.plymouth.enable=0', 'plymouth.enable=0'
[2025-10-31 17:00:31] Usage: qubes-firewall [OPTION]
[2025-10-31 17:00:31] Try 'qubes-firewall --help' for more information.
[2025-10-31 17:00:31] Hint: To pass a space, it needs to be escaped twice: .[1m--hello='Hello,\ world!'.[m
[2025-10-31 17:00:31] Another possibility is: .[1m--hello='"Hello, world!"'.[m
[2025-10-31 17:00:31] Solo5: solo5_exit(64) called
Edit again:
I just need to slow down
This resolved my issue!
For some reason running the entire command at once didn’t include those two lines at the end.
Do you know if Qubes Mirage Firewall is on its way to be accepted as a Qubes community template? I looked at the instructions on the GitHub repo and found them daunting. I know it’s a “me” problem, hence my question .
Thank you for your comments. There are tools by @unman and @ben-grande that also facilitate installation.
To ease the installation process, it would be best to be able to generate rpm files with latest qubes-builder, which would avoid parsing the kernel in dom0 as is currently the case. There was a builder for mirage (GitHub - marmarek/qubes-builder-mirage: qubes-builder plugin for building MirageOS templates), but it uses the “old” qubes-builder, and I haven’t yet found the time to look into an updated process for creating rpm files.
When rpm files are available, maybe there will be no more stoppers to be distributed in qubes-templates-community. (But I might be wrong here?)
Though something tells me you already know about it and it doesn’t help. Sadly, it’s the best I can do. I have miserable searching skills. I am also ignorant about building packages to anything, much less qubes.
Edit: did I mention I have miserable searching skills? Is this what you meant as version 2?
Yes, if I’ve understood correctly, Qubes now uses qubes-builderv2, but I don’t have knowledge on how to use it to create template files
It seems like a step forward for better integration into Qubes, but as I said, I haven’t found the time to look into it yet
If anyone has this knowledge and would like to discuss the mirage compilation, I would be happy to help
I currently want to use Mirage, but I don’t trust I’ll be able to manage manual updates, nor do I really want yet another dom0 package I have to teach myself to read/understand.
I await the progress towards a community template with great interest. Thanks for the work you’ve been doing!
