Fedora 41 template update on 20-12-2024 makes Fedora lag severely

User Support
1

Hello, I received an update notification for Fedora 41 tonight and now after I have updated all my Fedora AppVMs are extremely slow to load and run. Is anyone else experiencing this?

2

I was experiencing this too. I noticed my vmā€™s only had the 400mb ram that was set for the initial amount of memory. I assume thereā€™s some check that happens that qubes does to detect if there is more memory available. Then it allocates more ram to the vm as part of memory balancing but itā€™s not happening. My pc has plenty of ram so my work around was to disable memory balancing and set the appropriate amount of ram for the initial amount of memory in my various vmā€™s.

1 Like
3

I noticed my AppVMs were running at no more than the configured ā€œInitial RAMā€. Fedora-41 based StandaloneVMs do not exhibit this behavior (so far). About to spin up a fresh one from scratch to see if it does as well.

In the meantime, anyone got ideas on logs to sift through?

1 Like
4

EDIT I am not experiencing any notable performance hits. Then again, my work load is very light.

Wierd,

Maybe this is a GUI issue fix with the Qubes Manager?

In dom0, ā€˜xentopā€™ shows the same memory usage on the two StandaloneVMs and itā€™s far below the initial RAM setting and ā€˜free -hā€™ shows similar patterns.

Then again, who do we trust?

1 Like
5

After some testing all my Fedora AppVMs were limited to 400 MB RAM initial limits as fiddler #2 wrote, but a Debian AppVM I spun up did not get stuck at the initial limit and ran normally. I set all my Fedora AppVMs to 4000 initial and everything is smooth, though it does not appear that my Fedora AppVMs are balancing RAM as they must have been doing previously to run without lag. For me the lag was obvious with Firefox running one tab.

6

I rebooted and now I am experiencing sluggish performance in Fedora-41 VMs. Firefox is a slide show and KeePassXC appears to be calculating the fine structure constant.

Time to track down that 386 Turbo buttonā€¦

7

This was an issue earlier in the template building process based on this comment:

It seems to have been brought back with the new update of selinux-policy and selinux-policy-targeted.

For some reason, it changes the labels of qubes-related binaries so that qrexec canā€™t access the information it needs:

fedora-41-xfce audit[606]: AVC avc:  denied  { read } for  pid=606 comm="qrexec-agent" name="meminfo-writer.pid" dev="tmpfs" ino=785 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0

Temporarily fix:

  1. Set initial memory to 2048
  2. Start impacted standalone/template
  3. Reinstall all selinux related packages:
    sudo dnf reinstall $(rpm -qa --qf "%{NAME}\n" | grep selinux | tr '\n' ' ')
  4. Shutdown standalone/template
  5. Change initial memory back to 500
  6. Start standalone/template and check memory:
    # Should display the maximum memory value in the Total column
free -hm

This selinux issue will probably appear every time both selinux-policy and selinux-policy-targeted are updated. @marmarek Now that the Fedora 41 template is official, a lot of users will get this issue. Any idea how to fix this transparently?

3 Likes
8

Itā€™s nice to wake up to a solution. Thank you! This resolved this issue on my setup.

Note: If you forget to change the initial memory before reinstalling SELinux, it will fail to complete some installation steps.

1 Like
9

I was having the same sluggish symptoms. I just rolled back to fedora40 until the fedora41 templates are ready for prime time.

10

I created the issue :

2 Likes
11

Iā€™ve the same situation ā€œFed-41ā€ is very very laggy.