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.
