Known issues and solutions
This is a wiki post; please edit as necessary.
Please, consider subscribing to the Stable 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:
Prepare the update beforehand
Preparation steps
From [INFO] Stable branch - BIG update BEST practice
If it has been a long time since your last update, you may want to refresh your pacman-keyring before running the actual update.
- Create a list of custom packages for later reference
pamac list --foreign > ~/alien-pkgs.txt
- Remove all foreign packages
pamac remove $(pamac list --foreign --quiet)
- Remove all orphans and other unneeded packages
pamac remove --orphans --unneeded
- Optional: ensure the keyrings are up-to-date
sudo pacman -Syy manjaro-keyring archlinux-keyring
- Optional: Run a simulated update
pamac update --dry-run
- Looking good? Repeat the above without
--dry-runreboot
- Consult the list of packages created in the first step and rebuild only those you really need
Important Note: Users of Plasma and GNOME may lose their X11 session support. Checkout our guides below before restarting your systems!
Important Note: Users of Pascal, Maxwell, or older cards will fail to load the NVIDIA driver when they were using 580xx series earlier, because the 590xx doesn’t support the older hardware anymore. Only Turing series and newer are still supported.
2026-06-26
2026-05-27
Attention users with encryption - read before updating!
Several months ago upstream switched the mkinitcpio hooks from udev to systemd. There was a pacnew file which in theory everybody has seen and merged (right? Shame on you, yes you, who forgot 
). Until now it was kind of optional, because the udev hooks will not stop working overnight. Well, with this update it seems the new systemd hooks are forced upon at least on some users without them noticing. It should’t happen but in some cases it looks like it happened. The result is a system that throws a cryptic error about device not found on boot and nonbooting.
You either have to restore the udev hooks, or adapt the kernel boot line for the systemd.
The easiest is to not reboot after update (otherwise you will have to chroot). Check the hooks and cmdline:
grep HOOKS /etc/mkinitcpio.conf
cat /proc/cmdline
The right combination is either similar to the old one with udev
HOOKS=(base UDEV autodetect microcode kms modconf block keyboard keymap consolefont plymouth encrypt filesystems)
AND the following syntax on the boot line
cryptdevice=UUID=device
OR
the new systemd hooks, similar to
HOOKS=(SYSTEMD autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)
AND
rd.luks.uuid=XXXXXXXX-XXXX-XXXX
ANY MIX BETWEEN THE TWO WILL NOT BOOT!
The currently reported situation is usually systemd hook + cryptdevice= boot line.
If that happend, you have to change either one of those two places. Preferably go to systemd and rd.luks.uuid. The boot line is changed in /etc/default/grub
After that you need to sudo update-grub
Now you can reboot.
Some reading (pretty much obligatory)
mkinitcpio - ArchWiki
dm-crypt/System configuration - ArchWiki
Note: the hooks above are an example! Do not blindly replace your hooks with the examples above. Also, the capitalization of some hooks is to put a focus here, in reality all hooks are with small letters.
Mesa problems on some Intel GPUs (lines on screen, fuzzy fonts)
Intel ix-2xxx CPUs (Core i 2nd Generation aka Sandy Bridge, from 2011 and all earlier CPUs)
Either wait with the update, or downgrade mesa.
For some chome browsers a workaround can be to disable the hardware acceleration.
Alternative workarounds: manually upgrade to the patched version from unstable branch
sudo pacman -U https://mirrors2.manjaro.org/unstable/extra/x86_64/mesa-1:26.1.2-1-x86_64.pkg.tar.zst
Or install (replace) mesa with mesa-amber for those old gpus. Note that this is the only workaround which doesn’t put you in an unsupported state!
2026-05-19
Yet another vulnerability - local privilege escalation
TLDR: And yet another one
Until patches arrive (should be soon), a mitigation:
sudo sh -c "printf 'kernel.yama.ptrace_scope=2' > /etc/sysctl.d/10-ptrace.conf"
More vulnerabilities - Pintheft, Dirtydecrypt
More vulnerabilities were discovered. Until patches hit your mirror and update, the mitigation is as always to block the modules:
rmmod rds_tcp rds
sudo su -
printf 'install rds /bin/false\ninstall rds_tcp /bin/false\n' > /etc/modprobe.d/pintheft.conf
exit
Note that a good Samaritan created a script, proactively blocking all modules not currently loaded from automatic loading. Which mitigates all current and future vulnerabilities connected with modules. If you are interested - here is the script:
GitHub - jnuyens/modulejail: Proactively shrink a Linux host's kernel-module attack surface by blacklisting every module not currently in use. · GitHub
Please read the description and way of function carefully. If you decide to use that script, check if you have any of the vulnerable modules loaded first:
lsmod | grep -E "esp4|esp6|rxrpc|rds|rds_tcp|algif_aead"
If it returns nothing, you are all good, you can run modulejail with profile desktop.
You do not need to remove other blocking .conf files if you already installed something (unless you want the logging feature).
You might also be interested in the following tutorial which should proactively help:
[HowTo] modulejail
Kernels 5x removed - change kernel before updating!
Although kernel series 5x are still maintained upstream, they are pretty old. To simplify maintenance, Manjaro drops support for those kernels. Note that this change is still not updated in the graphical Manjaro-settings-manager (but mhwd-kernel shows the correct list). Please, if you are still running a 5x kernel, install a newer LTS one first, preferably the latest 6.18 before attempting to update. Then reboot and after that you can update. If linux-latest is blocking the update, remove it too.
2026-05-08
NTFS partitions or usb drives cannot be mounted anymore after update
The explanation:
Concerning NTFS3 and NTFS-3G - #15 by Ben
Note that forcing the system to use the old ntfs-3g driver to mount the drive/partition, although the dirty bit is set, means you will be mounting a potentially damaged filesystem. It is your decision and the responsibility for potential data loss is yours.
The only recommended solution is to check the filesystem from windows. If you don’t have windows anymore, you can get one designed for such repairs free and legal here:
https://www.hirensbootcd.org/
DIRTY FRAG VULNERABILITY (also read if scared from Fragnesia)
[ALERT] Dirty Frag (CVE-2026-43284, CVE-2026-43500) - Root Privilege Vulnerability
Note that the newly discovered vulnerability Fragnesia is still not patched, it is however in the same modules as Dirty frag and the described mitigation works for it too. Just apply the mitigation and you will be ok.
refind - booting problem
The currently shipped version of refind breaks booting on both ext4 and btrfs. Upstream cooks a fix, but until it comes there are several workarounds:
- Downgrade refind before rebooting or from chroot with manjaro-downgrade
- Make a backup of the refind_x64.efi file on the ESP partition and restore it after the update before rebooting or from chroot
- Search for the hook that updates the .efi on package update and remove it
- Remove the package refind before updating the system which will also remove the hook, but will leave the efi file on the ESP (not tested)
In any case be sure to have live usb at hand.
P.S. refind is alternative boot loader. It is not part of the default installation. If you don’t know what it is (you didn’t install it yourself) - you don’t have it and this doesn’t concern you.
2026-05-02
Issues with updating Kernels due to Nvidia drivers
We know that some of our users still use either 570xx or 575xx drivers from Nvidia. Both of these drivers are unsupported since several months: Current graphics driver releases - Linux - NVIDIA Developer Forums
The current legacy driver 580xx is still supporting older graphic cards by Nvidia, as in Maxwell, Pascal, and Volta GPUs. 470xx is unsupported by Nvidia, however the community is still patching that driver for newer kernels so GKxxx “Kepler” GPUs still work. Same goes for the 390xx driver series, which has the support of GF1xx “Fermi” GPUs.
With linux619+ there is no support for 570xx and 575xx. Our kernel-team had no time to look into this issue further, as backporting patches takes a lot of effort. Since we dropped driver support for these series in recent mhwd-db updates, you may still want to stay on linux618 kernel series, if you still need those drivers. To check if newer drivers support your hardware, please use 26.1x install medias and choose proprietary drivers on boot selection. No changes are performed on your installed system. It is a save environment to test new drivers before changing stuff on your OS.
It would be good to remove installed drivers by mhwd before using it to reinstall supported drivers for your system: Configure Graphics Cards - Manjaro
Also look for known issues within drivers at the Nvidia developer forum:
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:
- 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 for non-patched kernels/systems
Disable the algif_aead kernel module persistently on all affected systems until a patched kernel is available:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
More Information: CERT-EU - High Vulnerability in the Linux Kernel ("Copy Fail")
2026-03-23
pamac-manager gui (Add/Remove Programs) does not start or starts very slow
For now, disable flatpak support (you can just browse flathub.org and install and update from terminal)
sudo nano /etc/pamac.conf
scroll to the end and put # before EnableFlatpak
press ctrl+q , y to save and exit
`plasma-applet-window-buttons` is broken
The plasma-applet-window-buttons package included in this update is version 0.14.0-3, which looks for /usr/lib/libPlasma.so.7, but this library does not exist — the version of the library included in this Stable Update is /usr/lib/libPlasma.so.6.5.6.
The solution is to downgrade plasma-applet-window-buttons to version 0.14.0-2. You do this by way of manjaro-downgrade. 
sudo manjaro-downgrade plasma-applet-window-buttons
Update: In the meantime, the faulty package has been replaced in the repository by the working one already, but if you had updated your system and you have version 0.14.0-3 while you did not downgrade the package yet, run…
sudo pacman -Syuu
… just once. It will downgrade the faulty package back to the working one.
2026-02-23
Possible signature validity issues with packages taken over from Arch
Do this before updating!
Edited by @linux-aarhus 2026-02-26T06:35:00Z
Before you jump to the big 
and wipe the pacman gnupg folder
sudo pacman -Syy archlinux-keyring manjaro-keyring
Optionally
sudo pacman-key --populate archlinux manjaro
Original suggestion
The problem…
https://www.reddit.com/r/archlinux/comments/1rafluf/pacman_and_keyring_issues/
The solution…
sudo rm -rf /etc/pacman.d/gnupg
sudo pacman-key --init && sudo pacman-key --populate archlinux manjaro && sudo pacman -Syu
Unreliability of the `pamac` package manager
Rationale
There recently appears to be a high incidence of pamac crashing in the middle of a system update, be it only in the form of the pamac-manager crashing with the update process continuing in the background, or in the form of a complete crash of the pamac infrastructure, leading to a non-bootable system.
Advice
Until the Manjaro Team has managed to correct this issue, we would advise our users…
- to either (install and) use
octopi — see the screenshot below — as a graphical package manager
Previous stable update threads:
You will need to rebuild any AUR Python packages that install files to site-packages or link to 