[Stable Update] 2023-11-13 - Kernels, KDE Gear, LibreOffice, LXQt, Pipewire, Phosh, Firefox, Thunderbird

Anyone else getting any erros with VirtualBox after this upgrade? I’m getting “Could not load the Host USB Proxy service: VERR_NOT_FOUND.” and there is no /proc/bus/usb. My VM still opens properly; however, I still get that error every time I open VirtualBox and never got it before.

Thanks, this solved my problem.

Straight after this stable update, my Veracrypt shows error messages when i mount a drive,
Not Enough Data and Broken Pipe.

I restarted Veracrypt and lucky its working for now… but there is something wrong with Veracrypt in the official repos!

systemd-coredump[17265]: [🡕] Process 17230 (veracrypt) of user 1000 dumped core.
                                                      
                                                      Stack trace of thread 17230:
                                                      #0  0x00007f6ede4ac83c n/a (libc.so.6 + 0x8e83c)
                                                      #1  0x00007f6ede45c668 raise (libc.so.6 + 0x3e668)
                                                      #2  0x00007f6ede4444b8 abort (libc.so.6 + 0x264b8)
                                                      #3  0x00007f6ede6dd3b2 _ZSt21__glibcxx_assert_failPKciS0_S0_ (libstdc++.so.6 + 0xdd3b2)
                                                      #4  0x00005609b2c64762 n/a (veracrypt + 0x1c7762)
                                                      #5  0x00005609b2b85a94 n/a (veracrypt + 0xe8a94)
                                                      #6  0x00007f6ede445cd0 n/a (libc.so.6 + 0x27cd0)
                                                      #7  0x00007f6ede445d8a __libc_start_main (libc.so.6 + 0x27d8a)
                                                      #8  0x00005609b2b8c775 n/a (veracrypt + 0xef775)
                                                      ELF object binary architecture: AMD x86-64
░░ Subject: Process 17230 (veracrypt) dumped core
░░ Defined-By: systemd
░░ Support: https://forum.manjaro.org/c/support
░░ Documentation: man:core(5)
░░ 
░░ Process 17230 (veracrypt) crashed and dumped core.
░░ 
░░ This usually indicates a programming error in the crashing program and
░░ should be reported to its vendor as a bug.

Edit:
It looks like the error is gone, maybe a bug in a config file that only occurred a singletime after this update and is vanished after a simple application restart.

After this update, ctrl + Q keyboard for quit no longer works for libreoffice. It works for all other applications.

Since this update, the laptop moves into standby when i close the lid.
This is a default setting, what i have change a few years ago. So the system does not move into standby when i close the lid.

When i want to reactivate this setting, i noticed that inside the gnome-tweaks (optimization tool), the tab for exactly this settings is missing.
Here it is described that there should be a tab for it. I was also looking into the other tabs, without fining any setting for my problem. Sometimes, settings move from the gnome-tweaks to the real settings menu inside gnome. But there are no settings for this too.

Do you have any idea what could be the reason for it?

Hello folks,

I have a question about HDD spin down

The problem with kernel 6.1.59 is pointed out in the testing branch, but not in the stable branch.

see

https://forum.manjaro.org/t/testing-update-2023-11-13-systemd-kde-frameworks-wine-gamescope-plus-handygccs/151443[Testing Update] 2023-11-13 - Systemd, KDE Frameworks, Wine, Gamescope-Plus, HandyGCCS

Mechanical HDDs may not spin-down properly on shutdown

Is the problem present in the stable branch and does it not exist with the current kernel 6.1.60?
I have a mechanical HDD and I do not want do damage it.

Thanks and Greetings

2 Likes

Re “please post your solution”: I had to delete “jdk-openjdk” and “jre-openjdk-headless” on each of my (several) Manjaro computers. Otherwise, no issues.

1 Like

6.1.60 does not exhibit the problem anymore.

3 Likes

From the 11-06-update thread:

Continuing the discussion from [Stable Update] 2023-11-06 - Kernels, Gnome 45.1, Plasma 5.27.9, Firefox, Thunderbird, Pipewire:

I have looked and found similar in my journal. Is this worrysome ? Ignorable? Fixable? Normal?

Nov 14 00:09:02 COMPUTERNAME akonadi_control[1734]: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
Nov 14 00:09:03 COMPUTERNAME akonadiserver[1746]: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
Nov 14 00:09:03 COMPUTERNAME ksmserver[1272]: kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but has no Exec field.


Nov 14 00:09:05 COMPUTERNAME plasmashell[1326]: org.kde.plasma.containmentlayoutmanager: Trying to take space not available BasicAppletContainer_QMLTYPE_90_QML_113(0x563f23406840, parent=0x563f241d5b20, geometry=8157,1187 84x104)
Nov 14 00:09:05 COMPUTERNAME plasmashell[1326]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:47: TypeError: Cannot read property 'location' of null
Nov 14 00:09:05 COMPUTERNAME plasmashell[1326]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:48: TypeError: Cannot read property 'location' of null
Nov 14 00:09:05 COMPUTERNAME plasmashell[1326]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:49: TypeError: Cannot read property 'location' of null
Nov 14 00:09:05 COMPUTERNAME plasmashell[1326]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:46: TypeError: Cannot read property 'location' of null
Nov 14 00:09:05 COMPUTERNAME ksmserver[1272]: kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but has no Exec field.

# then later I have this same message 200 times in a row:
Nov 14 19:58:10 COMPUTERNAME kactivitymanagerd[56508]: kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but has no Exec field.
Nov 14 19:58:10 COMPUTERNAME kactivitymanagerd[56508]: kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but has no Exec field.

Known issue which was just fixed in KDE Frameworks version 5.113. Until that gets to Stable branch nothing to worry about it’s just an annoyance - 430157 – KDE .desktop parser complains about files that have Type= "Application" but no Exec line, although this situation is normal.

3 Likes

What does this message mean?

error: failed retrieving file 'jdk11-openjdk-11.0.21.u9-3-x86_64.pkg.tar.zst' from mirror.alpix.eu : Recv failure: Connection reset by peer

When I restart the update, I get a message that there’s nothing to do. Is this package updated?

Hey @41a,

this option was dropped about 4 months ago with this commit: tweaks: Drop general tweaks and lid suspend script (782c881e) · Commits · GNOME / GNOME Tweaks · GitLab

Some info that might be useful for you:

Hey CyberOto,
thanks a lot, for your hint. With the correct systemd settings, it is possible to bring back the old behaviour.
Thanks!

Still works here, you might want to check the file menu if it’s indeed still bound to Ctrl+Q. If yes, then you might need to check your DE’s global shortcut config which might have overridden it…

kernel: amdgpu 0000:27:00.0: amdgpu: Secure display: Generic Failure.
kernel: amdgpu 0000:27:00.0: amdgpu: SECUREDISPLAY: query securedisplay TA failed. ret 0x0. 

apparently this has something to do with this DRM crap

  • i’m using, and have been for some time, kernel v6.5.11
  • issue is present in v6.1 kernel
  • issue is (so far) not present in v6.6 kernel issue is present in v6.6 kernel

I skipped the previous stable update and after reading this thread, I ran:
sudo pacman -Sy jdk-openjdk
(said Yes to remove packages in conflict)

It kept me away from trouble. As soon as I start thinking that everything went smoothly, the “ran out of space on the root partition” error message showed up, just as someone already reported here. My root partition is 100GB in size and there’s always more than 10GB available which was always enough during the major stable updates. This is the first time it wasn’t enough, but I cleared the cache, re-ran the update to fix the leftovers and I’m good. This issue when running out of space on the root partition should be automatically handled by pamac perhaps.

My issue was more that I wasn’t checking to ensure I was clearing cache space. The question I guess is If only the most recent previous copy of a package was being kept, what was taking up so much disk space.

If you’ve got free space on a disc, it could be worthwhile putting /var/cache/pacman on a separate partition.
This would also have the advantage that if for some reason you have to revert your root filesystem, you’ll still have the package files rather than having to download them again.

2 Likes

Just for the record… :point_down:

:wink:

4 Likes

I could make a spare partition, but not on the same physical SSD, since it’s quite small. I could make some space for this on my secondary HDD that is automatically mounted on boot. Would that work? :thinking: