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
Yes, reserved are cores/cpu_threads, for the system responsiveness while you compile, so the leftover core or few cores can handle other tasks while most are 100% utilized. Right now you try to overload the system and make it even less responsive (by utilizing ALL cpu_threads … PLUS one ) .
Normally, stack overflow protection is not needed.
It slows down the code execution.
No, it is done so as to speed up the compilation/building/linking, so you won’t be starving the compiler in the process. It has traditionally always been done this way in GNU/Linux and other UNIX systems.
It has nothing to do with any considerations about system responsiveness, but with taking advantage of every CPU cycle.
Ahhh, Famous Last Words™. 
2 Likes
I think he means ones in testing / unstable probably
1 Like
After Update from 3.36 to 3.38.1 gnome-music crashes instantly at startup or after a few seconds while i am browsing through my music.
Terminal gives this:
/usr/lib/python3.8/site-packages/gi/overrides/Gio.py:43: Warning: g_atomic_ref_count_dec: assertion 'g_atomic_int_get (arc) > 0' failed
return Gio.Application.run(self, *args, **kwargs)
sys:1: Warning: g_atomic_ref_count_dec: assertion 'g_atomic_int_get (arc) > 0' failed
free(): invalid pointer
Abgebrochen (Speicherabzug geschrieben)My update leaded to huge issues in graphics. I use Manjaro as VMWare guest.
I made 2 screen videos displaying the issue:
Before:
https://photos.app.goo.gl/wHRwYzLWVeXXJHxE7
After:
https://photos.app.goo.gl/i1d4xjDdZUzGywD18Am I the only one with tor problems?
● tor.service - Anonymizing overlay network for TCP
Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2020-11-06 12:14:59 CET; 10s ago
Process: 2168 ExecStartPre=/usr/bin/tor -f /etc/tor/torrc --verify-config (code=exited, status=1/FAILURE)
Nov 06 12:14:59 inspiron7737 systemd[1]: tor.service: Scheduled restart job, restart counter is at 5.
Nov 06 12:14:59 inspiron7737 systemd[1]: Stopped Anonymizing overlay network for TCP.
Nov 06 12:14:59 inspiron7737 systemd[1]: tor.service: Start request repeated too quickly.
Nov 06 12:14:59 inspiron7737 systemd[1]: tor.service: Failed with result ‘exit-code’.
Nov 06 12:14:59 inspiron7737 systemd[1]: Failed to start Anonymizing overlay network for TCP.
Okay, so I find my first bug in new update… Audio on my external monitor don’t work… I don’t even see option to pick betwen laptop and monitor(hdmi), that option I had before update…
Can someone help me nad tell me what info should I post here, so it’s easier for you to understand problem
No sound after sleep:
$ pulseaudio
E: [pulseaudio] pid.c: Daemon already running.
E: [pulseaudio] main.c: pa_pid_file_create() failed.
$ ps x | grep pulseaudio
1497 ? S<sl 0:52 /usr/bin/pulseaudio --daemonize=no --log-target=journal
7963 pts/1 S+ 0:00 grep --colour=auto pulseaudio
temporary solve with:
$ killall pulseaudio
ref: sound - Pulseaudio not working, daemon already running and no permission for home folder - Ask Ubuntu
I found the fix solution from: PulseAudio/Troubleshooting - ArchWiki
Hi Manjaro team,
well, I tested Manjaro KDE 20.2-rc1 on my 2-in-1 (hybrid) PC for some testing. I must say that it works pretty well this RC1. I’m waiting for the fixes for wayland plasma support in plasma 5.20.3 (hopefully these fixes will be offered in time).