[Stable Update] 2024-02-21 - Kernels, KDE, VirtualBox, Calamares, ROCm, Firefox, Thunderbird

Issues: with the plymouth resulted in a stuck black screen before login screen.
Resolved by: remove splash from GRUB entry
See: here…

Guide for plymouth (and fix for related blackscreen) available:


@Jangadance I think you missed the part where pacman-contrib was split out.
Thats the package that would provide pacdiff (now).


Pacdiff was one of the utilities that got removed with pacman-contrib. If you want it back, you’ll have to install pacman-contrib separately.


Yeah I did not see this. I did see the pacman-contrib part but assumed I had nothing installed that needed it, so I could ignore it.


this (the qt5 variable) should go in the known issues i think? @philm

By the way i now see some blue lines while booting, between the other Starting something green OK messages. But it is moving very fast. Where can i check? Journal does not seem to have new errors.

Post update, ran into problems on a couple machines where plymouth appeared either at an incorrect resolution or not at all. Followed instructions here to remove plymouth and rebooted. Then followed same instructions to add back plymouth and rebooted. Not sure if it makes a difference, but when adding back, I placed the plymouth hook after the encrypt hook at step 1 of the instructions in the link. Plymouth now appears correctly on both machines.

1 Like

And how we gonna do that?

1 Like

You should already have bash if you are using it.

pacman -Qs bash

Note: Most manjaro’s use zsh by default.

But I suppose you could finger it to be double sure.

sudo pacman -Syu bash

And if you still have bashrc-manjaro you should remove it.

sudo pacman -Rns bashrc-manjaro

None of which though, if you did your updates, should be required, because bash would replace bashrc-manjaro during the course of updates … so really, nothing should be needed at all except to accept the changes.


I was thinking to replace only the first lane, but im not sure:


and replace it with


While leaving the other lines untouched.

Maybe someone can confirm?

The whole thing about pacnews is that pacman recognized that the file it wanted to update was changed from the packaged version. The user could have made a configuration change or it could have been done on behalf of the user, but it’s a good bet the user doesn’t want to lose their configuration changes.

Several threads on the arch bbs regarding this update and the pacnew.

Bottom line, only change that line.

Only when necessary.

Nope. If it was present, and got removed, it wasn’t by me.

As for my issue #1, that didn’t involve file “/bin/fakeroot”, but rather, package “rebuild-detector”, so it does not appear to be connected to issue #3.

I was never the topic. The topic is philm’s request, “Please post your solution”. I simply complied.

I’ve been using Manjaro Linux, with multiple AURs, for several years, but I’ve never ran into “could not build AUR because binary file ‘fakeroot’ could not be found” errors before. (Indeed, I’ve had few problems of any kind with AURs; I’ve had far more issues with snaps and flatpaks.)

So either file “/bin/fakeroot” wasn’t needed before, or it was needed but was present (at that time), so the problem didn’t occur. But this update, for whatever reason, the file “/bin/fakeroot” was needed-but-not-present at the time Pamac attempted to update AUR files, so those updates failed until after I installed “fakeroot”.

Btw, running Ctrl-F on the Arch AUR page shows that the string “fakeroot” is not present on that page, so reading it would not have helped with my issue #3. Pamac, on the other hand, was very clear as to what needed to be done to solve issues #1 and #3, so those were easy fixes. Issue #2 was a bit thornier. (There’s also an issue #4 which I’m about to add, but that’s a whole other story.)

For years I’ve added a single line at the bottom of /etc/bash.bashrc. All local, system-wide changes go into bash.bashrc.local. I usually get a bash.bashrc.pacnew and just re-add the line. Check for a .pacsave.

[ -f /etc/bash.bashrc.local ] && source /etc/bash.bashrc.local

1 Like

Your solution isn’t a solution at all…

…and it wouldn’t be a problem if you actually READ what prerequisites for using AUR are – as is expected from every user of AUR.

1 Like

/bin is a symlink to /usr/bin so both lines will work. And keep the other lines untouched.

ls -l /bin                                                                                                                            ✔ 
lrwxrwxrwx 1 root root 7 ene 19 18:16 /bin -> usr/bin
1 Like

Going through yet another update thread, I want to post a short note on my experience. I have been using Manjaro as my only OS for the last four years, and I am still on my first install since then. It was a new experience as I was switching from the Debian/Ubuntu world. I had to adjust my update habits to a whole new process. Doing a lot of reading, I came across two things that were extremely helpful:

System Maintenance
Update Manjaro the smart way

They are in my bookmarks, and I reread them every now and then.

Additionally, create, verify, and test your backups (obvious, I know, we all do them, right?).

Last but not least, keep learning your system. The Manjaro is a rolling distribution. It has perks, but with great power comes some responsibilities. :wink:

Thanks Manjaro Team, and many happy updates to all of us.


fakeroot is part of base-devel which is mandatory when using custom build scripts.

The knowledge is mandatory - pamac may have had a basic check earlier - I think the present situation is that you need to know that base-devel is required possibly to raise more awareness to the casual user.

The text at the Third Party tab in Pamac Preferences states

AUR is a community maintained repository so it presents potential risks and problems.
All AUR users should be familiar with the build process

One of the topics within the familiarity, is to know the base-devel must be synced and the system is fully synced.

1 Like

I have encountered an issue with this update.
I am using urxvt with i3, and additionally fcitx5 with mozc for japanese input.
Hitting the trigger button (alt + `) will not change the typed symbols in the console.
It works as expected (before the update) in other applications though, just the console is not working.
Fonts are installed and tested working, the console can display Japanese just fine.
Has anyone any idea where this could come from?
I am out of luck, and i am sourcing ~/.profile through a line in ~/.bashrc

This issue is fixed again.
Since the .profile file is no longer sourced, i added a line (source ~/.profile) to .bashrc.
This is wrong!
I found here that you should do things you did previously in .profile now in .bash_profile.
i moved the entire file contents over there, and now it works (of course disable the .bashrc line where i call .profile.

1 Like

This really can’t be emphasised enough. I’ve seen the consequences of backups failing silently in my days as a data centre operator. The time those failed backups were needed and weren’t there cost the business something like £5m.

1 Like

About the issue with the blue lines (errors/warnings) on boot, it was plymouth related. Obviously, removing plymouth and kms hooks was not enough, i also had to add the kernel parameters to disable it as per the guide above.

If you had updated with pacman instead of through the pamac GUI, then you would have seen the question to replace the package appear right at the top of the update process. :grin: