[Testing Update] 2026-08-20 - Kernels, KDE Framework, Firefox, Thunderbird, Qemu, Mesa, VirtualBox

Announcements Testing Updates
1

Hello Manjaro user community, here we have another set of package updates. We are continuing our development of our current release ‘Bian-May’. If all went well, this will mark the first point release of 26.1 series.

Current Promotions

Recent News

New in Manjaro GNOME!

When choosing an accent color in Settings, the folder colors will now change automatically to match when using the Papirus Dark or Papirus Light icon theme.

To try it out, install gnome-shell-extension-papirus-folders-colorizer from Add/Remove Software, logout / login and enable Papirus Folder Colorizer from Extensions.

Or, if you prefer the command line:

Install:

sudo pacman -Syu gnome-shell-extension-papirus-folders-colorizer

Enable the extension:

 gnome-extensions enable papirus-folders-colorizer@NiffirgkcaJ.github.com

Logout:

gnome-session-quit --logout

Also, when applying accent colors from Layout Switcher settings, it will also set the matching folder color. Requires accent-color-change r172.c761c84-2 or newer.

KDE Plasma users with SDDM can now migrate to Plasma Login Manager

After ensuring plasma-login-manager 6.5.90-1 (or newer) is installed, run the following:

sudo pacman -Syu plasma-login-manager
systemctl disable sddm
systemctl enable plasmalogin
sudo pacman -R sddm-kcm sddm
NVIDIA 590 driver drops Pascal support

With the update to driver version 590, the NVIDIA driver no longer supports Pascal (GTX 10xx) GPUs or older.

Impact: Updating the NVIDIA packages on systems with Pascal, Maxwell, or older cards will fail to load the driver, which may result in a broken graphical environment.

Intervention required for Pascal/older users: Users with GTX 10xx series and older cards must switch to a legacy driver to maintain support:

  • Install the official linuxXXX-nvidia-580xx, or related DKMS packages.
  • Manjaro 26.1 Bian-May - Preview released
  • Manjaro 26.0 Anh-Linh released
  • Manjaro Summit public Alpha now available
  • As of Linux 6.16.12, the 6.16 series is now EOL (End Of Life). Please install 6.18 LTS (Long Term Support) and/or 6.12 LTS.
  • As of Linux 6.17.13, the 6.17 series is now EOL (End Of Life). Please install 6.18 LTS (Long Term Support) and/or 6.12 LTS.
  • As of Linux 6.19.14, the 6.19 series is now EOL (End Of Life). Please install 7.0, and/or 6.18 LTS (Long Term Support) and/or 6.12 LTS.
  • As of Linux 7.0.14, the 7.0 series is now EOL (End Of Life). Please install 7.1, and/or 6.18 LTS (Long Term Support) and/or 6.12 LTS.
Previous News

Notable Package Updates

Additional Info

Python 3.14 info

:information_source: You will need to rebuild any AUR Python packages that install files to site-packages or link to libpython3.13.so.

Print a list of of packages that have files in /usr/lib/python3.13/ :

pacman -Qoq /usr/lib/python3.13/

Rebuild them all at once:*

pamac build $(pacman -Qoq /usr/lib/python3.13)

Use rebuild-detector to see if anything else needs to be rebuilt:

 checkrebuild

* It’s recommended to clean your build cache first with pamac clean --build-files

Info about AUR packages

:warning: AUR (Arch User Repository) packages are neither supported by Arch nor Manjaro. Posts about them in Announcements topics are off-topic and will be flagged, moved or removed without warning.

For help with AUR packages, please create a new topic in Support > AUR and a helpful volunteer may be able to assist you.

Get our latest daily developer images now from Github: Plasma, GNOME, XFCE. You can get the latest stable releases of Manjaro from CDN77.

Our current supported kernels

  • linux61 6.1.183
  • linux66 6.6.152
  • linux612 6.12.104
  • linux618 6.18.45
  • linux71 7.1.9
  • linux72 7.2.0
  • linux61-rt 6.1.167_rt62
  • linux66-rt 6.6.135_rt74
  • linux612-rt 6.12.89_rt18

Package Changes (8/19/26 14:50)

  • testing core x86_64: 96 new and 96 removed package(s)
  • testing extra x86_64: 2333 new and 2411 removed package(s)
  • testing multilib x86_64: 35 new and 72 removed package(s)

A list of all package changes can be found here.

  • No issue, everything went smoothly
  • Yes there was an issue. I was able to resolve it myself.(Please post your solution)
  • Yes I am currently experiencing an issue due to the update. (Please post about it)
0 voters

Check if your mirror has already synced:

1 Like
[Stable Update] 2026-08-12 - Kernels, Firefox, GStreamer, Python, Deepin, Haskell, Bazaar
[Testing Update] 2026-08-10 - Kernels, Firefox, GStreamer, Python, Deepin, Haskell
2

Known issues and solutions

This is a wiki post; please edit as necessary.
Please, consider subscribing to the Testing Updates Announcements RSS feed

Please RTFT (Read This Fine Thread) first before reporting the same issues over and over again!

Note: Do not forget to review your .pacnew files:

:arrow_right: 2026-08-20

2026-05-11

A week after Copy Fail, researcher Hyunwoo Kim disclosed a second Linux kernel flaw in the same broad area — IPsec ESP and rxrpc — that they have named Dirty Frag. The bug lives in the in-place decryption fast paths of esp4, esp6, and rxrpc: when a socket buffer carries paged fragments that are not privately owned by the kernel (e.g. pipe pages attached via splice(2)/sendfile(2)/MSG_SPLICE_PAGES), the receive path decrypts directly over those externally-backed pages, exposing or corrupting plaintext that an unprivileged process still holds a reference to.

Like the previous Copy Fail vulnerability, Dirty Frag immediately yields root on all major distributions. Every supported Manjaro release is affected. Dirty Frag chains two distinct kernel bugs, each with its own CVE: CVE-2026-43284 covers the IPsec ESP half (esp4 / esp6), and CVE-2026-43500 (NVD entry pending) covers the rxrpc half. Per Hyunwoo Kim’s public disclosure on oss-security (2026-05-07), the responsible-disclosure embargo was broken before distributions could coordinate, and a working exploit is publicly available. A second public exploit, Copy Fail 2: Electric Boogaloo, targets the same vulnerability under a different name; both reach root through the same esp4/esp6/rxrpc code paths and are blocked by the same fix.

Temporary mitigation

You can neutralize the attack surface by blacklisting the affected modules. None of esp4, esp6, or rxrpc are loaded on a typical workload that does not use IPsec transport mode or AFS, so on most systems this is safe to apply immediately:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

This writes a modprobe config that prevents the three modules from loading, and unloads them if they happen to be loaded already (the rmmod is best-effort and silent if the module isn’t present). To revert, remove /etc/modprobe.d/dirtyfrag.conf.

The Dirty Frag exploit works by corrupting page-cache pages of sensitive files (such as /etc/passwd or /usr/bin/su). If you suspect the system may have already been targeted before you applied the mitigation, drop the page cache so any tampered pages are evicted and the next read comes fresh from disk:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

This is safe to run on a live system — it only frees clean cache and dentry/inode entries — and pairs well with the blacklist above.

2026-05-01

On 29 April 2026, a high local privilege escalation vulnerability in the Linux kernel, tracked as CVE-2026-31431 and named “Copy Fail”, was publicly disclosed. The vulnerability affects Manjaro Linux since 2017. A public proof-of-concept exploit has been released.

We have patched most of our kernels and released them to our testing and unstable branches:

  • patched kernels are: 5.10.254+, 5.15.204+, 6.1.170+, 6.6.137+, 6.12.85+, 6.18.22+, 6.19.12+, 7.0-rc7+
  • affected kernels are: 6.1.167_rt62, 6.6.133_rt73, 6.12.79_rt17, 6.17.5_rt7 and lower

Temporary Mitigation

Disable the algif_aead kernel module persistently on all affected systems until a patched kernel is available:

sudo su
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
exit

More Information: CERT-EU - High Vulnerability in the Linux Kernel ("Copy Fail")

2026-04-06

udev-usb-sync and kernel 7.0-rc

If you experience slow transfers to USB attached disks, remove the package udev-usb-sync. It is not known why the 7.0-rc kernel causes this. There may be a regression of some sort. Awaiting the final release of the 7.0 kernel before jumping to conclusions.

See [Unstable Update] April 2026 thread for more info

2026-04-23T22:00:00Z
The issue is solved with the release of 7.0 kernel

Previous testing threads:

3

All went well on all systems (AMD CPU/GPU desktop, Intel laptops). No shut down/restart problems with 7.2 as I was experiencing with rc5, 6 and 7

2 Likes
4

Noticed manjaro-kde-settings with a significant version downgrade - is that expected? I can’t access the GitLab repo to check (getting timeouts on that site).

manjaro-kde-settings 20260210-2 1:20240501-1

5

That’s not a downgrade: the epoch changed and therefore the new version is higher.

FWIW the gitlab commit looks like cleanup work to me:

1 Like
6

Post update, there were two new TPM related pacnew files. I don’t use TPM, and as far as I know, neither do vanilla Manjaro installations.

I made backups of the old files and overwrote the old files with the pacnew files. If I should not have done that, then please let me know - I can restore the old files.

/etc/tpm2-tss/fapi-profiles/P_ECCP384SHA384.json.bak
/etc/tpm2-tss/fapi-profiles/P_RSA3072SHA384.json.bak

Rebooted and all seems fine. System is vanilla Manjaro with LUKS encryption.

Thanks Manjaro Team for the great work. It feels like Christmas each time there’s an update.

6 Likes
7

Got it - thanks. I’m still getting timeouts from gitlab.manjaro.org; not sure if that’s indicative of some wider problem? isitdownrightnow.com is also reporting it as down.

8

It is, yes. gitlab.manjaro.org has been having issues for months already.

1 Like
9

I’m using the new KDE Oxygen theme and icon packs and after this update the volume icon in the system tray isn’t respecting the dark theme (the icon is showing dark making it almost invisible).

Volume icon not using dark mode

10

I hope it has nothing to do with this:

1 Like
11

Exactly the same here, but given that right now, my system boots just fine and I do use full disk encryption, I discarded the pacnew files. From googling around, most of the changes are just the same code written for different abstraction layers, so I don’t think there was any system related change that I’m missing out on by keeping my old (working) configuration.

12

A little typo in Kernel Name:

❯ uname -r
7.2.0--1-MANJARO

will fix this

3 Likes
13

I would rather recommend to use the new settings of the pacnew files and to replace the old config files by the pacnew files. If you are unsure just make a backup of the old configs.

4 Likes
14

Agreed. If one has never modified the file in question, it should be perfectly fine to replace it with the .pacnew.

15

Received 2 pacnew files

/etc/tpm2-tss/fapi-profiles/P_ECCP384SHA384.json.pacnew
/etc/tpm2-tss/fapi-profiles/P_RSA3072SHA384.json.pacnew

Replaced the original files

/etc/tpm2-tss/fapi-profiles/P_ECCP384SHA384.json
/etc/tpm2-tss/fapi-profiles/P_RSA3072SHA384.json

Kwallet-manager failed to open

Replaced the updated files with the backups I made.

Kwallet-manager functioning again

2 Likes
16

I did that once, per this thread here: [Testing Update] 2026-05-11 - Kernels, COSMIC, Firefox, Thunderbird, KDE - #4 by Aragorn

I ended up having to restore from a previous timeshift, but that created a weird problem with a GRUB boot menu that would not go away (I don’t dual-boot, this is my only OS), and to make a long story short, I ended up going with the nuclear option.

ANYWAYS! So, that’s a long-winded way to explain why I tend towards keeping what works with these pacnew files. Live and learn. I’m sure there’s a happy medium, and with the next update, I’ll give your method a whirl as well.

2 Likes
17

Always best to do a sanity check first though, using e.g. meld.
I have “fond” memories of the issues created by users blindly overwriting something they didn’t think they’d modified, e.g. /etc/passwd. :wink:

(I accidentally overwrote mine :facepalm:, but knew how to fix things).

6 Likes
18