Thanks, yes I did. Now some good vibes managed to show a boot signature fault, clicked ok a couple of times an usb booted… maybe its community power… after 3h trying to boot… 
2 Likes
I was looking at Arch Linux Wiki: mkinitcpio - Common Hooks and I see that there is a “busybox column” which corresponds to the Manjaro default config file, and then there is the “systemd column” which you are using for your configuration.
I was going to change my config on my KDE laptop but lost my nerve and stopped. If the systemd config is better, then why is Manjaro not defaulting to it in the mkinitcpio.conf?
Or put another way, should I make the change now because Manjaro will change the defaults in the future? I don’t want to break anything… yeah I know about Timeshift, but still… Thanks for your time.
Hi BenHowl,
Thanks! I also did some testing and everything was working as expected so it left me puzzled. The fact that it was integrated into plasma-desktop 5.20.2-1 explains everything.
Thanks again!
No problem with the update, but the audio is muted after a restart on 2 out of 7 computers that I updated. I’m sure it’s a KDE bug. Any quick solution?
KDE Plasma.
After the update it would freeze after login. I restored and this time I did two things. Installed kernel 5.9, and made sure to also update kwin-lowlatency from the AUR since the new update includes kde 5.20. Rreboot after updating again and everything worked.
Thanks for the update guys.
Edit: Updated my other computer that also has KDE Plasma. I didn’t have to change to kernel 5.9 for that one to work. So I think you just have to make sure to update kwin-lowlatency from the aur right after the update before you restart.
Can’t connect to my bluetooth speaker anymore and startup doesn’t load gnome more often than it did awhile back.
KDE Plasma , Kernel 5.4.74, running like a charm after a smooth update and reboot.
Cheers Guys 
I can confirm that is harmless; on my system was attempted to be loaded from /etc/modules-load.d/fwupd-platform-integrity.conf, so from the package fwupd 1.5.0-1 but since my kernel 4.14 doesn’t have such module platform-integrity, I just removed /etc/modules-load.d/fwupd-platform-integrity.conf without downsides and hassles.
But, I don’t recommend to other users to do the same: any config files and actions that I report, is esclusivily related to my system and configuration.
Hi @n_b,
Be aware that you should not use sudo pip install $package or sudo pip uninstall $package as it will conflict with system packages.
It’s mentioned it the Arch Wiki: Python - ArchWiki
When installing packages from sources other than the official repositories and AUR, it is recommended to use a virtual environment (or Conda environment management) to prevent conflicts with system packages in /usr. Alternatively, pip install --user can be used to install packages into the user scheme instead of /usr.
You can follow the Manjaro Wiki to downgrade a package: Downgrading packages - Manjaro
4 Likes
Needed this for some k3b related files … other than that, update on KDE (intel graphics) went fine here. Thanks for the hard work!
Everything works fine after the update: Bluetooth, virtual machines … (Gnome, Kernel 5.8.18)
Thanks a lot.
Seems to be working so far…
@omano : Yes and no. I have experienced that a rolling release distro (or also one with a relatively sane upgrade approach like Debian) accumulates “cruft” over time. Over time, new things get added that are to replace old things, however without always cleaning up the old things or just leaving them installed for maintaining some kind of backward compatibility. So you get -over time- a web of dependencies (not necessarily in terms of package dependencies, let’s call it configuration dependencies) on an long-run system that you simply do not have on a freshly installed system. So while a given (major) update may run perfectly fine on a relatively new system, it might just bork up a long-run system (even a “well maintained” one).
Timeshift will bring you back to the “pre-borked” state, but it just won’t fix the issue that the well running long-run system has (and it will be very difficult to find out what to first change in the long-run system so that it “survives” the update; it’s simply easier to keep your /home and make a fresh install for many users).
Having time-sensitive tasks to do and doing an update on a system that you could trust on for a long time only then sounds like a bad idea when the update has gone south but not at the time typing sudo pacman -Syyu on a TTY. Honestly, if a user cannot have the faith that a stable update leaves him with a running system, then what shall the user do … at least we should not blame them for having had faith, no? 
@HarryHenryGebel: You’re welcome to troubleshoot the issue or make a clean install, just as you please . For quick getting back on track, yes indeed, Timeshift is a really good option to use before the next big update.
4 Likes
Manjaro KDE.
First I had errors like in this message. And I have solved them with the same recipe.
After update a got some errors in the system log from pulse:
→ pulseaudio[1258]: module-rescue-stream is obsolete and should no longer be loaded. Please remove it from your configuration.
→ pulseaudio[1258]: Failed to open module mbeq_1197.so: mbeq_1197.so: cannot open shared object file: No such file or directory
→ pulseaudio[1258]: Failed to load LADSPA plugin: file not found
→ pulseaudio[1258]: Failed to load module "module-ladspa-sink" (argument: "sink_name=ladspa_output.mbeq_1197.mbeq sink_master=a...")
→ pulseaudio[1258]: Sink ladspa_output.mbeq_1197.mbeq does not exist.
pulseaudio[1258]: Meta command .endif is not valid in this context
pulseaudio[1258]: Doing resync
pulseaudio[1258]: Playback after capture (-30767), drop sink 3976
I marked with arrows the rows those I was concerned. BTW during the problem my soundboard worked. I won’t tell the whole searching story, but I only tell you about the effective actions.
- I installed pulseaudio-equalizer-ladspa
sudo pacman -S pulseaudio-equalizer-ladspa. - I created symlink
sudo ln /usr/lib/ladspa/mbeq_1197.so /usr/lib/ - I commented the row
load-module module-rescue-streamsin the file~/.config/pulse/default.pa.
And now the error’s log looks like that
pulseaudio[1010]: Doing resync
pulseaudio[1010]: Playback after capture (-54464), drop sink 7008
pulseaudio[1010]: Meta command .endif is not valid in this context
For these errors I choose the best strategy: just ignoring.
Main sources
1 Like
Since the update I am getting some X errors:
nov 06 09:52:25 pc /usr/lib/gdm-x-session[3676]: (EE) client bug: timer event2 debounce short: scheduled expiry is in the past (-0ms), your system is too slow
nov 06 09:52:50 pc /usr/lib/gdm-x-session[3676]: (EE) event2 - Logitech Gaming Mouse G502: client bug: event processing lagging behind by 11ms, your system is too slow
I have not really been able to find anything online that matches this.
GNOME Shell 3.38.1
xorg-server 1.20.9-2
Any ideas?
This is probably one of the most important things anyone using a computer for anything should do as a matter of routine.
One extra suggestion I’d make is to have a complete image of your system cloned onto a rescue partition. Preferably on a different physical drive to your root partition, so you’ve got a hope if your primary drive fails and you can also install GRUB on that second drive to in extremis you can select that drive from the BIOS to get a live computer.
My personal preference is to keep my rescue system one update behind the live one, so that if any serious problem shows up with a release I’m still safe.
Another benefit of a rescue system is that it can safely be used for experimentation that might break your live system. For example, as the latest update breaks MPD, I’m working on fixing that on my rescue partition rather than breaking it on the live one.
1 Like
So why was it removed in .pacnew? Don’t we want it anymore?
Also I found a bug in makepkf.conf.pacnew:
MAKEFLAGS="-j$(($(nproc)+1))"
which would try to use 1 more thread than you have CPU cores. I think the intent was to use 1 less maybe?
1 Like
That’s a very good question. I presume that @philm ─ last time I looked, he was the one maintaining the mkinitcpio configuration ─ is following Arch, although I don’t know whether that is what Arch uses as well. But let’s just say that it’s a conservative configuration that’s known to work. 
Manjaro will not overwrite your changes. The update will simply install a mkinitcpio.conf.pacnew file if your mkinitcpio.conf has been modified by you, and you are then expected to manually merge the two files ─ or discard one of them and/or rename the other, as it may be.
1 Like
No, traditionally one always reserves one or two extra threads so as to make optimum use of parallelization.
1 Like