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?
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.
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.
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.
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ā¦
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.
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?
That would work fine. My own is on a different physical disc.
Alternatively, if the all of the secondary disc is allocated you could create a directory on one of the partitions and symlink it.
I wasnāt aware the directory could be changed in /etc/pacman.conf. Thatās certainly a better way to do it.
Why would a symlink break things? Iām curious.