Core 199 - QEMU VMs no longer start - libfuse3.so.4:

Add-Ons
21

Thanks Arno

I will setup a test PC or VM, so I can do some testing on libvirt/kvm before a release is pushed to stable.

2 Likes
22

I have the same problem too… *error while loading shared libraries: libfuse3.so.4: cannot open shared object file: No such file or directory* hopefully they will fix it soon with update…

23

I had just updated IPFire and having the same issue with Qemu. I will track this post for updates. Thanks.

24

You can get that file from the flash image, if you download it and open the file with 7zip or like.

25

It looks like the libfuse libraries do not follow the standard library versioning system approach.

A change has been made to the filesystem cleanup script used in the update process to no longer do any filesystem cleanup for the libfuse libraries.

That will mean that old library versions will not be removed from your systems but that is better than removing the wrong libraries due to the non-standard versioning approach.

That change has been merged into the core199 git repo. It will now be built and will then be applied to any new updates to CU199. I will communicate here when it has been applied to the CU199 update process.

Any users that have already updated will need to follow the advice from @callifo in post 24 of this thread.

Any users doing a fresh install of CU199 will get the correct libraries as the filesystem-cleanup script is only used in the update process.

3 Likes
26

Thank you for your prompt response :waving_hand:

These incidents also highlight the lack of testers during the testing phase, particularly for add-ons.

27

Hello

I just installed the new patch from QEMU, and after restarting, I’m getting the error again.
(qemu-10.1.0-53)

error: Failed to start domain ‘vmtest’
error: internal error: process exited while connecting to monitor: 2026-01-10T22:19:38.374011Z qemu-system-x86_64: -accel kvm: Could not access KVM kernel module: No such file or directory
2026-01-10T22:19:38.374033Z qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory

The file still contains the following lines, and the permissions are still set.

/etc/sysconfig/rc.local

# Manual fix for KVM permissions (bypassing udev GID restriction)
chown root:1001 /dev/kvm
chmod 0660 /dev/kvm

Do I have to dismantle anything again now?

28

OK
I removed the lines from the /etc/sysconfig/rc.local file and reset the “/dev/kvm” file.

chown root:root/dev/kvm
chmod 0600 /dev/kvm

After restarting, the VMs are running again.

29

The fixes for the libfuse3 library and the kvm group have now been pushed out to the mirrors. It is available at the first mirrors now and should be available at all of them within an hour.

This should now work correctly for all users who have not yet updated to CU199.

For users who have already updated to CU199 then you need to change the contents of the file
/opt/pakfire/db/core/mine
from 199 to 198 and then refresh the settings on your pakfire WUI page and it will provide you with the update from CU198 to CU199 again.

Before you run that update make sure that any workaround changes you have implemented are removed otherwise they might get in the way of the update working correctly.

2 Likes
30

Do these guidelines apply to all users or only those using faulty add-ons?

31

This only applies to users doing a core update to CU199. A fresh install does not have this problem.

I am presuming that you must have found a copy of the libfuse3.so.3.17.4 library from somewhere and have copied it into the library directory and remade the linkage to libfuse3.so.4. In that case, as long as the ownership and the permissions are the same then it should be fine.

The other factor was the group uid which for some older installations looks like they might not have been in the correct system range, which worked until version in CU199. So a fix has been put in to remove the kvm group if it already exists but is a non-system uid and then recreate it as a system group uid.
If your kvm group had a uid in the system range then it would be fine and you would not have had the kvm group issues..

My conclusion would be that if you are certain that your workaround changes end up with a system the same as would now be created by IPFire CU199 then everything should be fine but you need to make that judgement as you know what changes were made on your system.