I updated my system to Core 199 today and since then my VMs no longer start via QEMU.
I get the following error message.
[root@router ~]# virsh start webproxy error: Failed to start domain ‘webproxy’ error: internal error: Failed to start QEMU binary /usr/bin/qemu-system-x86_64 for probing: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libfuse3.so.4: cannot open shared object file: No such file or directory
I don’t have a package called libfuse3 in pakfire.
With the error message, I only found this for now:
I’ve encountered another issue unfortunately with the update in 199,
virsh # start HomeAssistant
error: Failed to start domain 'HomeAssistant'
error: internal error: Failed to start QEMU binary /usr/bin/qemu-system-x86_64 for probing: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libfuse3.so.4: cannot open shared object file: No such file or directory
Any suggestions how to fix this one?
Edit: I found this file from inside the flash image, but now stuck again,
virsh # start Docker-Green
error: Failed to start domain 'Docker-Green'
error: internal error: process exited while connecting to monitor: 2026-01-07T14:03:11.333740Z qemu-system-x86_64: -accel kvm: Could not access KVM kernel module: No such file or directory
2026-01-07T14:03:11.334029Z qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
Not really sure. This message is saying that qemu could not find the libfuse3.so.4 library but I just checked in the CU199 git repo and it was definitely shipped. I just checked on my CU199 Testing vm system and that library is present in /usr/lib/
If it is not in that directory on your system then I don’t know how that would have happened as the fusr updates was done about 4 weeks before CU199 was released for Testing.
I have just seen that CU199 has had its full release. I will update a CU198 vm system to CU199 and check if the libfuse3.so.4 library is present on that system.
Is the problem with that missing library on the full release of CU199 or from the CU199 Testing version? Although they should be the same.
virsh # start Docker-Green
error: Failed to start domain 'Docker-Green'
error: internal error: process exited while connecting to monitor: 2026-01-07T14:03:11.333740Z qemu-system-x86_64: -accel kvm: Could not access KVM kernel module: No such file or directory
2026-01-07T14:03:11.334029Z qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
I am afraid I have no idea what the issue is here. I don’t use qemu or libvirt.
It looks like it can’t find the kvm module which is required for the virtualisation but that should get loaded if qemu or libvirt are being used.
EDIT:
Just did a quick check and the kvm module is made available and so if qemu or libvirt are being used the module should be loaded automatically.
The file that defines the modules only had the kernel version line changed from 6.12.57 to 6.12.58 but no modules were changed at all.
not sure if this is the right place for my report but i am also not sure how bugzilla works so i go with the forum. So sorry in advance if this is the wrong place.
Today i made my update from 194 to 199 and yes i am aware that this is currently under testing, but somehow despite the fact i am on the stable branch ipfire said thats the package to go. Funny enough the addon packages did not update for me probably there was the update working as intended. So i switched to test branch. Not sure if this is a bug or it is intended to work like that in pakfire.
Then came the actual issue with libvirt-11.7.0-44 installed i got now the following error by starting my vm:
error: internal error: Failed to start QEMU binary /usr/bin/qemu-system-x86_64 for probing: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libfuse3.so.4: cannot open shared object file: No such file or directory
After some digging around it turned out that the symbolic link from /usr/lib/libfuse3.so.4 was pointing to libfuse3.so.3.17.4 but that file was not present on my system. Reinstalling the addon did not changed anything there so i checked ipfire-2.x/lfs/fuse at master · ipfire/ipfire-2.x · GitHub how that file should be there and compiled it myself with the script as a template and voila first error down. Can someone confirm that it is in the package there or did just something stupid happend on my system ? Thanks everyone.
Next issue was then this one:
error: internal error: process exited while connecting to monitor: qemu-system-x86_64: -accel kvm: Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
After some digging around i found no clue why i have this issue after the update. It just turns out by setting the permission for /dev/kvm to 666 instead of the 600 it had before it was now just working. As i then checked the ps output it seems that the vm is started with the user nobody which technically has no permission with 600 to /dev/kvm. Again no clue why qemu runs as “nobody” and if it is intended but if someone who knows a bit better qemu can guide me if this is intended and something else funky happens, feel free to ping me.
Last issue of today is that the new options from Hostapd seems to break my wifi settings from before. I am not an hostapd expert but when i use the new auto generated config it starts hostapd but i can’t connect any device to the network. Again no clue how to fix that so if anyone can guide me to some hostapd docus which could help would be awesome.
In order to fix that i changed the initd script which write the generated config everytime it starts to commenting that part out. Yes with the next patch i have the same issue but this way i can keep the config from before. That’s why in general if someone can help me to dig through the issue, absolutly no plan why hostapd starts but no client can connect.
Thanks everyone who read my whole post and happy for some feedback.
I had the same problem. It looks like a bug. It looks like libfuse3.so.3.17.4 does not get properly placed in /usr/lib and thus the symlink to it does not work. Here’s what I did as a workaround (with help from AI):
Summary of Issues and Fixes: IPFire Core 198 to 199 Upgrade (x86_64)
Environment:
System: IPFire 2.29 - Core 199
Kernel: 6.12.58-ipfire
Scenario: Upgrading a system running KVM/Libvirt virtualization.
Issue 1: Missing shared library for FUSE 3.17
After the upgrade, virsh and libvirtd failed to start because of a missing library version.
Symptom: Error message: libvirt.so.0: version 'FUSE_3.17' not found (required by libvirt.so.0).
Discovery: The symlink /usr/lib/libfuse3.so.4 was pointing to libfuse3.so.3.17.4, but the actual binary file libfuse3.so.3.17.4was missing from the disk. Only the older version (3.15.0) was present.
Fix: 1. Downloaded the IPFire Core 199 ISO. 2. Extracted libfuse3.so.3.17.4 from the distro.img (Zstd compressed archive). 3. Manually placed the binary in /usr/lib/ and restored the symlinks.
Issue 2: Broken KVM Permissions (udev system group restriction)
Even after fixing the libraries, VMs failed to start with a KVM initialization error.
Symptom:qemu-system-x86_64: -accel kvm: Could not access KVM kernel module: No such file or directory.
Discovery:/dev/kvm permissions were reset to 0600 (root:root).
The udev Problem: Attempts to fix this via /etc/udev/rules.d/99-kvm.rules failed. Running udevadm test revealed that the kvm group (GID 1001) was being ignored with the error: Group 'kvm' is not a system group, ignoring.
Root Cause: IPFire’s udev implementation in Core 199 seems to strictly enforce that only groups with GIDs < 1000 can be assigned to system devices via udev rules. Since the kvm group is GID 1001, the rule is discarded.
Final Workaround/Solution:
To ensure the fix survives a reboot, we moved the permission handling to the end of the boot process:
Created/Edited /etc/sysconfig/rc.local.
Added the following lines:
Bash
# Manual fix for KVM permissions (bypassing udev GID restriction)
chown root:1001 /dev/kvm
chmod 0660 /dev/kvm
# Ensure VMs start after permissions are set
virsh start [vm_name]
Advice for Developers: 1. Please ensure libfuse3.so.3.17.4 is included in the Pakfire update package for Core 199. 2. Consider changing the kvm group GID to a value below 1000 to comply with udev “system group” requirements, or provide a default udev rule in the core image that handles this correctly.
As there have been three separate posts covering the same topic I have merged them into a single post to make future searching easier, plus not having to enter the same answer in three separate threads.
I confirm that the updated libs for fuse-3.17.4 were deleted but not the old 3.15.0 libs.
It looks like the fact that the fuse package developers decided to leave the libs in a 3.x branch but change the top level lib from libfuse3.so.3 to libfuse3.so.4 might have caused an issue with the lib linking software due to this peculiar mismatch as the correct libs were available in the rootfile for the fuse package in IPFire.
Unfortunately it looks like no IPFire user that uses qemu/libvirt has provided any CU199 Testing feedback as this is the first notification of this issue.
I will raise it in the dev mailing list to see if there are any thoughts on the best way to resolve this.
When I copy the file libfuse3.so.3.17.4 to usr/lib, I get the following error.
error: internal error: process exited while connecting to monitor: 2026-01-07T20:22:17.496243Z qemu-system-x86_64: -accel kvm: Could not access KVM kernel module: No such file or directory 2026-01-07T20:22:17.496266Z qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
Since I have four important VMs here, this is unfortunately not ideal for me.
Is there any way to go back, or what is the best course of action to take now to avoid any problems with the next update?
P.S.: Unfortunately, I don’t have a test system to try something like this out beforehand.
That would be good if you could do that and a positive feedback that things are working is also valuable so we know the things that have been successfully used.
I don’t use qemu or libvirt in any of my systems. My development vm systems are running with VirtualBox.
If no one tests it then the first time there will be feedback is when the full release occurs and the first qemu/libvirt user updates, which is where we are today - 6 to 7 weeks after CU199 Testing was issued.
Arno’s workaround helped, and even after a restart, the VMs are now running.
I don’t know yet whether I can get a VM with IPfire and QEMU running on my Windows PC using VirtualBox.
I’ll have to take a look at that over the weekend.
I think it would be good for someone to raise this as a bug so it is recorded and is unlikely to be missed in future. Just leaving it as a post in the forum will very quickly be lost after some period has gone by and many more posts have been created.
