After the update the Ctrl key no longer works in my virtualbox virtual machines, it just treats Ctrl-C as the letter C etc, where it didn’t before the update.
Virtualbox guest additions are up to date, and the same behaviour is seen on both a Windows and Linux guest. When disabling its “mouse integration” option the ctrl key works as expected, but is a workaround that introduces its own usability issues. There’s an older issue relating to this in virtualbox relating to using ctrl on the host to locate the mouse pointer, however I don’t have this setting on.
This issue doesn’t occur in vmware virtual machines. I’m running the 5.15 kernel and Cinnamon.
I was just about to report the Ctrl key issue too. It’s not just Virtualbox. Any combo with left Ctrl is broken for me on multiple Cinnamon systems. I did some digging and previously they said this was a bug in XOrg that had to get patched. But that was in 2018.
So yeah, on my systems ( multiple ones so multiple keyboards ) if I try to do Ctrl+Shift for example, it does not work. But some things do. Ctrl+Alt left / right works. The majority of my issues are Ctrl+Shift but other things have not worked at times.
In the virtual keyboard I can bring up, when I press left Ctrl it never lights up to recognize it as being hit. Other keys do. But obviously that’s not completely right if Ctrl+Alt+left/right works.
I can use the right Ctrl and that works, but there’s no way I’m going to get used to that after a couple of decades of left Ctrl + something.
In any case, something got borked with using the left Ctrl key in the update
Hello, I have a problem that I can’t access the internet but i can connect to wifi right after the update. How to solve this sir?. Now i’m running on 5.15.59-1. Thanks in advance.
Oh my… You’ve right! Never thought about it. Reverted with Timeshift and made the update.
Disabled the Apparmor and now Samba share is working again
I hope there is a proper solution for it
LC_ALL=C rhythmbox
(rhythmbox:3399): libpeas-WARNING **: 10:12:22.324: Failed to load module 'daap': libcheck.so.0: cannot open shared object file: No such file or directory
(rhythmbox:3399): libpeas-WARNING **: 10:12:22.324: Error loading plugin 'daap'
This came with the 2022-08-13 update where libdmapsharing was updated from 2.9.39-3 to 2.9.41-1.
The following downgrade will fix it for the time beeing:
It seems that network manager cannot save or retrieve the wifi password from kwallet anymore.
Everytime I start my computer it asks me for the password again and if I check my journal I get the following warnings:
Aug 21 20:38:08 kded5[1307]: org.kde.plasma.nm.kded: Unhandled active connection state change: 1
Aug 21 20:38:34 kded5[1307]: org.kde.plasma.nm.kded: Error opening kwallet.
Aug 21 20:38:34 kded5[1307]: kf.bluezqt: PendingCall Error: "Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)"
Aug 21 20:40:08 NetworkManager[705]: <warn> [1661107208.9667] device (wlo1): no secrets: No agents were available for this request.
Aug 21 20:40:09 NetworkManager[705]: <warn> [1661107209.8227] device (wlo1): Activation: failed for connection 'NETWORKNAME'
However, according to kwalletmanager, kwallet is running and and the entry for the wifi is there. so it seems there might be some issue with the communication of NetworkManager and kwallet
After this update, it seems it can’t auto mount with my NAS (network mounts) anymore…
Once my machine is started and I execute the following command sudo mount -a, the network mounts does work!
I believe in the last update or something changed requiring the vers= option to be specified. I have always used the vers=3.0 in my config and it has continued to work without issue.
I looked but couldn’t find the posting on the site where it was discussed what changed within the last couple of updates but, basically for your example make it something like this:
You can use other versions if you are connecting to an older samba server 3.0 still goes back to windows 8 so it has been around for awhile and most NAS drives, etc are should be using and will probably work in most cases. If not just try the lower versions until you find one that works. Here is a little snipit I found awhile back explaining the versions and what version of windows used them.
vers=3.0 is SMB3 i.e. Windows 8, Windows Server 2012
vers=2.1 is SMB2_10 i.e. Windows 7, Windows Server 2008 R2
vers=2.0 is SMB2_02 i.e. Vista SP1, Windows Server 2008
vers=1.0 is NT1 i.e. Windows 95, NT 4.0
$ sudo pamac upgrade -a
Warnung: Pakete als dynamischer Benutzer bauen
Warnung: Konfiguriere Build-Verzeichnis /var/cache/pamac
Vorbereitung...
Synchronisiere Paketdatenbanken...
Aktualisierung von extra.db...
Aktualisierung von community.db...
Aktualisierung von AUR...
Überprüfe kde-servicemenus-rootactions Abhängigkeiten...
Warnung: libcpuid: Lokale Version (0.5.1.r10.g7a580fd-1) ist neuer als community (0.5.1-2)
Abhängigkeiten werden aufgelöst...
Interne Konflikte werden überprüft...
Zu aktualisieren (1):
inxi 3.3.21.1-1 (3.3.20.1-1) community 315,6 kB
Zu erstellen (1):
kde-servicemenus-rootactions 2.9.1-2 (2.9.1-1) AUR
Download-Größe gesamt: 315,6 kB
Gesamtgröße installiert: 5,5 kB
Somthing from KDE went to AUR?
(kde-servicemenus-rootactions)
Audio in Discord stopped working after upgrading. I’m using pipewire for audio; KDE. Audio is fine in all other software, including Steam + Proton. Rolling back (using TimeShift) fixes the issue. Deleting $HOME/.config/discord has not fixed it. I’ll follow up if I find a solution.
I found that uninstalling EasyEffects solved the issue, though this isn’t going to be a solution for anyone who regularly uses EasyEffects.
Before uninstalling EasyEffects, my system got into a state which caused other programs to lose sound as well. I found that they were always using EasyEffects as the default audio device and required switching to the real audio device each time the program started to resolve this. This didn’t seem to work with Discord, though I’d need to reinstall EasyEffects and retest to determine if the result is consistent.