Hello Manjaro user community, here we have another set of package updates.
Recent News
Linux 7.1 series is now EOL
As of Linux 7.1.13, the 7.1 series is now EOL (End Of Life). Please install 7.2, and/or 6.18 LTS (Long Term Support) and/or 6.12 LTS.
New for Cinnamon users
As of Xreader 4.6.7, ePub support was removed and a new XApp called Xepub was added for ePub support. There’s also a new calendar application called Clockenstein.
Mkinitcpio >=42 requires manual intervention for TPM2-based unlocking of LUKS devices
2026-09-22 - David Runge
Starting with package version 42-1, the mkinitcpio systemd hook now includes systemd-pcrosseparator.service (as intended by systemd v261).
This affects the measurements of PCR values 0-7, 9 and 12-14. If you configured the systemd hook and unlock LUKS partitions, that depend on these values, you need to re-enroll the TPM2 in use.
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
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.
tar backup/restore scripts have been moved to tar-scripts
tar package no longer ships the helper scripts /usr/bin/backup and /usr/bin/restore.
If you rely on these tools, install tar-scripts
The core tar archiving utility itself is unaffected.
2026-05-11
Dirty Frag vulnerability
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:
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
Copy Fail vulnerability
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:
Had to manually remove lib32-fluidsynth which was linked to lib32-openal so removed that too, both seem to be moved to AUR, anyway once removed update worked fine.
Also just checked and had about another 8 or 9 packages moved to AUR, mostly lib32 packages, have now removed them all.
I’m off to test the Nvidia Driver and hope it’s as good as people are saying it is.
I update my Manjaro Linux Testing on VirtualBox. It uses EFI boot and btrfs filing system.
After system reboot the following error Message appears on a black screen:
Error: commands/loadenv.c:check_blocklists:289:sparse file not allowed.
After some seconds, the system starts as usual. This message did not appear before the update. I don’t know if that’s a message from the VirtualBox boot or from GRUB.
The logging changes. I’m not interested in the Theme changes.
From reading this
Kernel parameters
Change the kernel parameters using the configuration options of your boot loader, to include the following parameters:
quiet
Note
Adding vga=current as a kernel argument avoids weird behaviors like FS#32309. Keep in mind that this conflicts with KMS, so only use this argument if you are affected by said bug.
If you are still getting messages printed to the console, it may be dmesg sending you what it thinks are important messages. You can change the level at which these messages will be printed by using quiet loglevel=level, where level is any number between 0 and 7, where 0 is the most critical, and 7 is debug levels of printing.
quiet loglevel=3
Note that this only seems to work if both quiet and loglevel=level are used, and they must be in that order (quiet first). The loglevel parameter will only change that which is printed to the console, the levels of dmesg itself will not be affected and will still be available through the journal as well as dmesg. For more information, see kernel parameters.
If you also want to stop systemd from printing its version number when booting, you should also append udev.log_level=3 to your kernel parameters. If systemd is used in an initramfs, append rd.udev.log_level=3 instead. See systemd-udevd.service(8) § KERNEL COMMAND LINE for details.
If you are using the systemd hook in the initramfs, you may get systemd messages during initramfs initialization. You can pass systemd.show_status=false to disable them, or systemd.show_status=auto to only suppress successful messages (so in case of errors you can still see them). Actually, auto is already passed to systemd.show_status=auto when quiet is used, however for some motive sometimes systemd inside initramfs does not get it. Below are the parameters that you need to pass to your kernel to get a completely clean boot with systemd in your initramfs:
quiet loglevel=3 systemd.show_status=auto rd.udev.log_level=3
Also touch ~/.hushlogin to remove the Last login message.
Users of plymouth must use both the quiet and splash kernel parameter, otherwise the details fallback theme is used and shows systemd messages.
I can not see any reason why I need to impliment those changes.
After the update, the system would no longer boot in EFI mode. Instead, there was a black screen and the following message: error: kern/dl.c:grub_dl_resolve_symbols:403:symbol ´ grub_user_error' not found. Entering rescue mode... grub rescure>
Fortunately, it booted successfully after I restarted with EFI disabled in the BIOS.
Banjo’s suggestion mentioned earlier did not solve the problem.
It still won’t boot in EFI mode
The new options in grub.pacnew just disable superfluous console output, particularly noticeable if your using plymouth from what I understand.
I’m half guessing here because the GRUB documentation doesn’t seem to have been updated, but do you mean there are additional menu options in GRUB? If so the GRUB_DISABLE_BOOTNEXT=true disables those options. It is my understanding that unless you’re dual booting with Windows (or other edge dual boot cases) you should set this option so it doesn’t display.
Ran the update on my system and the update process obviously ran update-grub adding the extra BootNext entries. I then added GRUB_DISABLE_BOOTNEXT=true to /etc/default/grub and ran update-grub again, and it skips BootNext and doesn’t create those entries.
The other options don’t seem to make any difference on my system either.
You will need to rebuild any AUR Python packages that install files to site-packages or link to 
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.
2026-10-07
I forgot to run