A post was split to a new topic: Black screen after update
Hi, I installed the latest stable image of Manjaro KDE on the 15th on a brand new Lenovo T14 and the touchpad was working fine.
After the update the touchpad is not working anymore 
I tried to downgrade libinput but the problem remains so it might be bigger than that 
Edit: I updated to the 5.9 kernel and the issues remained. I shutdown (not restart) the computer and start again and it worked.
I think the issue came from me rebooting from windows (dual boot), I just read that sometimes the driver for hardware is loaded in the flash memory, which means it’s always recommanded to shutdown and start computer when you want to change the operation sytem used (and not reboot).
So I don’t think my problem was coming from the update (just a bad coincidence). I leave my experience here, just so it can help.
There is solution posted already
OK, I’ve dug into the OpenVPN problems and I’ve found the solution.
The main problem is that the new systemd unit specifies running as user openvpn and group network, whereas the original (pretty sure I didn’t change it, though I may be wrong) didn’t specify a user/group.
So the big problem was the daemon not being able to read config in /etc/openvpn. The solution here is to change the ownership of that directory (and everything under it) to openvpn.
A secondary problem (for me) was that I was specifying AES-256-CBC as the cypher, and this is no longer supported. Changing that to AES-256-GCM fixed the problem (this was also set as one of the alternative options in my client device’s config, so this was safe for me. This may not be the case for everyone).
1 Like
You cloud also add
data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC
to the client config.
It is stated in OpenVPN log after connection fails.
I think it would be the “more sensible way” because of the change from --ncp-ciphers to --data-ciphers.
Maybe the following works for you as well?
I am unsure about why there was no pacnew or why quite a few users, including me, somehow apparently must have missed it – the problem is the (silent?) removal of the encrypt hook.
Yes I also had issues with lightdm failing and startx failed also. So I booted to latest kernel in single user mode and followed Phil advice in original post (pamac remove command, etc.). Then I had to reset mirrorlist and make sure downloading OK. Also had to boot into latest kernel and CTRL+ALT+F2 and finish off driver install: Trying to update to nvidia-450xx
1 Like
Updated on GIGABYTE AORUS B550I, Kernel 5.9.8, KDE
- no Sound on ALC1220-VB (since last Update)
- no more Bluetooth (that´s a new feature) - blanked on System Settings
- Back to LTS 5.4 not possible (BlackScreen after GRUB)
(for information - 5.4 also doesn´t support ETH on B550i - Realtek R8125)
Not updated 2nd PC with GIGABYTE X370 Gaming 5 (also no sound).
Very bad quality - it´s enough!!
1 Like
Maybe you added fsck to HOOKS in /etc/mkinitcpio.conf ?
I don’t even know what does that file do. I never touched it.
Does anyone know?
Please look above, in my two systems it is not fixed. 
No nvidia 418.xx drivers for Linux 5.9?
If a “pacman -Qi startup-notification” in the terminal says there is no 'required by" packages, you can remove it.
But using “sudo pacman -Rns startup-notification” will show you the dependencies too and you have the option to remove it or not.
Hardware accelerated video decode no longer works in Chromium with kernel 5.9.8.
I don’t think there was a removal of anything, as Manjaro update a pacnew file without touching your user config file. Maybe you as others have a helper tool which do auto merging of .pacnew (which is a bad idea IMO)?
Nope, currently you have 390 for legacy cards, or 450 and 455 see here Manjaro - Branch Compare
LTS 5.4 kernel has all of them though 
(340, 390, 418, 430, 435, 440, 450, 455)
nothing to do with Manjaro or kernel, it’s a Pulseaudio regression, you may try to downgrade Pulseaudio for the moment
may be fixed on Pulseaudio 14 I guess, you may try to do as suggest above…
1 Like
I would hope that you are right, as this is the intended way and as it should be, I understand (and have taken care of other pacnew files in the past). However, I cannot find the pacnew line related to mkinitcpio in my pacman log (as someone suggested otherwhere in this thread) and all I ever use is pamac (some rare times pacman). I cannot talk for others who seem to face the same “problem” of a miraculously changed mkinitcpio.conf.
So 
Adding to this: Say the mkinitcpio misconfiguration is to be blamed on me as user, still, I wonder why the update procedure mkinitcpio-updated (and thus rendered non-bootable due to the misconfiguration) all the initramfs’es – otherwise at least I could have selected one of the fallback entries in GRUB to boot an old kernel/initramfs and repair the system.