[Testing Update] 2026-05-11 - Kernels, COSMIC, Firefox, Thunderbird, KDE

Announcements Testing Updates
1

Hello Manjaro user community, here we have another set of package updates. We are continuing our development of the upcoming release of ‘Bian-May’ which can be expected end of May, beginning of June. Development speed may be a little slower the upcoming weeks. However, still let us know any issues you may found thus far.

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-575xx, linuxXXX-nvidia-570xx, 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 5.4.302, the 5.4 series is now EOL (End Of Life). Please install 5.10 LTS (Long Term Support) or 5.15 LTS.
  • 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.
Previous News
Finding information easier about Manjaro

Finding information easier about Manjaro always has been a topic that needed to be solved. With our new search we have put all Manjaro data accessible in one place and divided by sections so it makes it easier to digest: News – Manjaro

image
image679×348 45.7 KB

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

  • linux510 5.10.255
  • linux515 5.15.206
  • linux61 6.1.172
  • linux66 6.6.138
  • linux612 6.12.87
  • linux618 6.18.28
  • linux70 7.0.5
  • linux71 7.1.0-rc3
  • linux61-rt 6.1.167_rt62
  • linux66-rt 6.6.133_rt73
  • linux612-rt 6.12.79_rt17
  • linux617-rt 6.17.5_rt7

Package Changes (5/11/26 06:00 CEST)

  • testing core x86_64: 81 new and 81 removed package(s)
  • testing extra x86_64: 2549 new and 2642 removed package(s)
  • testing multilib x86_64: 21 new and 21 removed package(s)

A list of all 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
[Testing Update] 2026-05-01 - Kernels (CVE-2026-31431), NVIDIA, LibreOffice, Mesa, Deepin
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-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

Update went well, will implement the Dirty Frag fix shortly; only oddity was that there was a .pacnew file that was generated for my mkinitcpio.conf file in /etc/. I checked both old and new versions, and couldn’t find any difference (went through line by line), so I replaced the old version with the new version and restarted. No issue there.

1 Like
4

If they were identical — and please note that there are better ways to check this — then why did you even bother replacing the existing file with the .pacnew? :face_with_raised_eyebrow:

Simply restarting won’t make the new one take effect. You’ll have to rebuild your initramfs first and then reboot. :backhand_index_pointing_down:

sudo mkinitcpio -P && sudo systemctl reboot
1 Like
5

This update brings the kernel 618 kernel (it’s what I use) to match unstable. Do we still need to add mitigation even with the patch? Outside of the fact that we’ve had at very high cve incidents in the last week and are still not sure what the bast radius is, so at best it’s a “wasted” effort but could help someone?

On a slightly different topic, I have https://gitlab.manjaro.org/packages bookmarked for manjaro package builds. Is this link still valid? I get

This site can’t be reached

**gitlab.manjaro.org** unexpectedly closed the connection.

but that could also be me fiddling around with pihole.

1 Like
6

I’m coming over from using Windows or MacOS exclusively for 20 years; the last time I used Linux was in the days of Mandrake; so the need for having the latest update files for security has been inculcated in my habits. Going forward, if it’s better for me to stay with the older file, happy to do so.

Before going line by line, I checked the differences using the “diff” command, and it came up with differences that were “commented out”, so to speak, but I couldn’t spot the differences when I opened the two files up. It was confusing, but I’m willing to chalk it up to user error for now.

I appreciate these tips. Again, as a relative newcomer to Linux, there’s a LOT I don’t know, and a lot of old Windows habits that are still ingrained in me.

1 Like
7

Well, there is a package called manjaro-pacnew-checker in the repo, and as you might have guessed, it’s developed by Manjaro. It has a gtk-based graphical user interface.

As an alternative, there is also pacnew-chaser, which is an AUR package, and which has a qt-based interface, although it may use whatever graphical diff tool you have on your system — e.g. kompare, meld or diffuse. So there’s no need for faffing with the command line and/or looking at both files one line at the time. :wink:

The initramfs is an initial RAM-based filesystem populated with scripts and driver modules from a cpio archive, and the kernel requires this for booting. mkinitcpio is the utility which creates this initramfs image in /boot, based upon the configuration in /etc/mkinitcpio.conf and a preset file for the kernel version(s).

Normally, when installing a kernel by way of the mhwd-kernel command or the graphical manjaro-settings-manager utility, or whenever a kernel update is pushed out, mkinitcpio will be run automatically.

However, if you install a kernel manually by way of pacman, or if you modify /etc/mkinitcpio.conf, then mkinitcpio is not run, and then it must be run manually. And, it always requires a reboot after that for the changes to take effect. :wink:

As for Windows habits, yes, we are witnessing that phenomenon every day here at the forum. Not only is it hard for people to let go of them, but some even refuse to let go of them, and they think that all operating systems behave like Microsoft Windows, because they’ve never seen anything else. :stuck_out_tongue:

1 Like
8

Back to testing branch after my sojourn to unstable and stable branches yesterday . I’m on KDE , 7.05 with Nvidia 595 , updated via tty and everything is working . Deleted the file generated by the workaround since the kernels were patched .

9

@Aragorn Welp! I shouldn’t have replaced the old file with the new. Ah well, live and learn. Now I can’t even boot into Linux. I’m going to try loading a snapshot via live-USB. Really, trial by error is how I learn best, and so it goes.

1 Like
10

@Aragorn Holy crap, I had no idea how easy it would be to restore timeshifts using the Live USB method! I’m back, baby!

3 Likes
11

Manjaro Gitlab is currently reported as down
https://status.manjaro.org/history/manjaro-git-lab

Update: resolved 7:52:53 AM

12

Thanks, the status site is helpful.

13

mkinitcpio.conf has a pacnew file, and I’d like some advice on if the changes are “good” or not. Most of them are behind comment hashtags, but the two hooks that are not commented out are:

Original File

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=(/crypto_keyfile.bin)

Pacnew

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=()

The .bin file is probably critical, so I’ll copy that over. However, this next change is less clear:

The original file:

##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr and fsck hooks.
HOOKS=(base udev autodetect microcode kms modconf block keyboard keymap consolefont plymouth encrypt filesystems)

The pacnew file:

##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr and fsck hooks.
HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block filesystems fsck)

Looks like there’s a change from udev to systemd, and plymouth went missing.

Is this new change good to go or should I keep the original configuration?

14

What I might do is to comment the line:

# HOOKS=(base udev autodetect microcode kms modconf block keyboard keymap consolefont plymouth encrypt filesystems)

And add the line suggested in the .pacnew:

HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block filesystems fsck)

This way you can easily revert to the original HOOKS, or experiment with the new ones, as needed.

Reboot and try it out.

This looks to be an example. If you’re not using encryption, and actually using the file indicated, it probably serves no purpose. If you are using encryption, seek further advice.

Regards.

15

I do have full disk encryption enabled, so I’ll also port that over to the new file, too.

1 Like
16

After going over the diffs, and not being able to easily resolve merge errors, I made a backup of my then current mkinitcpio.conf file and replaced it with the pacnew version, then rebooted. As far as I can tell it made no difference to how my computer boots or performs.

17
18

This thread is now closed due to the publishing of another Testing Update announcement thread — see above — but considering the potential breakage involved with your question, I want to reply to your query here, so that you’d be notified.

You have obviously added the “FILES=(/crypto_keyfile.bin)” line yourself — or perhaps it was added by calamares — so yes, you definitely need to keep this.

On account of the systemd-based hooks, you can take them over — and this is actually the recommended approach — but, if you do this, then you will also need to convert any reference to the encrypted container and root filesystem in /etc/default/grub to the new systemd-specific syntax, or else your system won’t be able to boot.

The details have already been posted several times before, but the alternative approach — which will continue working well enough for the foreseeable future, unless upstream were to suddenly decide to break backwards compatibility, which I do not expect them to do any day soon — would be to stay with your current udev-based configuration instead and simply delete the .pacnew.

The plymouth hook is only needed if you do actually use plymouth, by the way, and in that case, it would still be required even with the systemd-based hooks.