Bug 13922

Summary: Core 199 - QEMU VMs no longer start - libfuse3.so.4 missing
Product: IPFire Reporter: Arno Jonker <admin>
Component: ---Assignee: Michael Tremer <michael.tremer>
Status: CLOSED FIXED QA Contact:
Severity: Major Usability    
Priority: - Unknown - CC: admin, adolf.belka, arne.fitzenreiter, michael.tremer
Version: 2   
Hardware: x86_64   
OS: Linux   

Description Arno Jonker 2026-01-07 21:13:54 UTC 
QEMU VMs no longer start - libfuse3.so.4 missing

Component: Virtualization / Pakfire / System

Severity: Major (breaks existing VM functionality and boot persistence)

Description: After upgrading from Core 198 to 199 on x86_64, QEMU/libvirt fails to start virtual machines. The investigation revealed two distinct but related issues caused by the upgrade process.

1. Library Version Mismatch (libfuse3)

The upgrade process seems to struggle with the upstream change where the library version was bumped to .so.4 while remaining in the 3.x branch.

Symptom: virsh and libvirtd fail with: version FUSE_3.17 not found (required by /usr/lib/libvirt.so.0).

Discovery: The symlink /usr/lib/libfuse3.so.4 exists, but the actual binary libfuse3.so.3.17.4 is missing from the filesystem (only the older version 3.15.0 remains).

Confirmed Fix: Manually extracting libfuse3.so.3.17.4 from the Core 199 ISO (distro.img) and placing it in /usr/lib/ resolves the linking error.

2. KVM Device Permissions (udev GID restriction)

After fixing the library, VMs still fail to start due to permission issues on /dev/kvm.

Symptom: qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory.

Discovery: /dev/kvm permissions default to 0600 (root:root) after reboot.

The udev Constraint: Custom rules in /etc/udev/rules.d/ (e.g., 99-kvm.rules) are ignored. udevadm test reports:

Group 'kvm' is not a system group, ignoring.

Root Cause: The kvm group on IPFire has GID 1001. The current udev implementation in Core 199 refuses to assign groups with a GID > 1000 to system devices during boot. Even using the numeric GID in the rule does not bypass this "system group" check.

Steps to Reproduce:

Upgrade an x86_64 system with KVM/Libvirt from Core 198 to 199.

Attempt to start a VM (virsh start [name]).

Observe the library error, then (after manually fixing the lib) observe the permission error after a reboot.

Suggested Fixes for Developers:

Packaging: Ensure the libfuse3.so.3.17.4 binary is correctly deployed despite the unconventional naming scheme from upstream.

Permissions: Consider changing the kvm group GID to a value below 1000 (standard system group range) so that udev rules can correctly manage /dev/kvm permissions.

Current Workaround for Users:

Manually restore the libfuse3.so.3.17.4 file from the ISO.

Add the following to /etc/sysconfig/rc.local to ensure persistence:

chown root:1001 /dev/kvm
chmod 0660 /dev/kvm
virsh start [vm_name]
Comment 1 Adolf Belka 2026-01-08 11:55:11 UTC 
The product should be specified as IPFire with the version of 2.x and the component of ---
Comment 2 Michael Tremer 2026-01-09 11:37:37 UTC 
Hello Arno,

thank you for the bug report. This update has been especially long available for testing, but we did not get any feedback. So, apologies for introducing these problems.

I fixed the removal of libfuse.so.* here:

> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5d44a45ea54e0402c01e3fec6c79fe902746614e

The fuse project seems to be using some creative versioning of their libraries which our cleanup script simply does not support.

The kvm group should already be created as a system group, but it could be that it wasn't initially on older systems.

I pushed this fix for it:

> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=050c9b39580d0c1deafb53c33a2543678a26e2b7
Comment 3 Arno Jonker 2026-01-11 07:20:36 UTC 
Thank you for the quick response and the fix!
Comment 4 Adolf Belka 2026-01-11 12:00:25 UTC 
The fix has been pushed out to the mirrors and should be available at all mirrors within an hour.

I have tested out the libfuse3 libraries and can confirm that libfuse3.so.3.17.4 is now available and is linked to libfuse3.so.4

It would be good if Arno could test this out to confirm that everything now works as expected with the qemu vm's.
Comment 5 Arno Jonker 2026-01-13 18:50:36 UTC 
I tested it and it works! Did an upgrade from core 198 to 199 and rebooted.

[root@fw2 ~]# ll /usr/lib/libfuse3.so.*
lrwxrwxrwx 1 root root     18 Oct 25 14:28 /usr/lib/libfuse3.so.3 -> libfuse3.so.3.15.0
-rwxr-xr-x 1 root root 270408 Oct 25 15:58 /usr/lib/libfuse3.so.3.15.0
-rwxr-xr-x 1 root root 282912 Jan 10 19:14 /usr/lib/libfuse3.so.3.17.4
lrwxrwxrwx 1 root root     18 Jan 10 17:34 /usr/lib/libfuse3.so.4 -> libfuse3.so.3.17.4

Libvirtd and VM's start normal. It all looks good. Do you need more information?
Comment 6 Adolf Belka 2026-01-13 21:27:43 UTC 
That information is fine as confirmation of the fix. Thanks very much.