You should try with the new config file for TLP instead of your old config.
Thanks for the suggestion. I replaced the old config file with the .pacnew
one, and my system didn’t crash or had a display reset after reloading tlp.service
and plugged my laptop back in. Then, I plopped back in my merged tlp.conf
, and I found out that the crashes only occurred when RADEON_DPM_PERF_LEVEL_ON_AC
is set to "high"
. I guess I should report this strange behavior in the TLP GitHub repo, even though setting that to the default (auto
) solved my issue here.
Edit: I submitted a GitHub issue about this matter on the said repository.
Hi, Code 1.60.2-1 (community repository) stoped working after the last update.
When I check journalctl -p 3 -xb
I get a long list which concludes with: Process 101947 (electron) crashed and dumped core.
Solved by reinstalling electron 13
Thanks!
Solved by setting XDG_DATA_DIRS=/usr/share/ in my .profile
gnucash 4.8 seems to need this variable to find its schema.
Do you know how XDG_DATA_DIRS is usually set ?
On my system, that is already set.
I don’t know how it gets set though
$ grep -rn XDG_DATA_DIRS /etc 2> /dev/null
/etc/profile.d/flatpak.sh:2: # set XDG_DATA_DIRS to include Flatpak installations
/etc/profile.d/flatpak.sh:14: case ":$XDG_DATA_DIRS:" in
/etc/profile.d/flatpak.sh:24: export XDG_DATA_DIRS
/etc/profile.d/flatpak.sh:25: XDG_DATA_DIRS="${new_dirs:+${new_dirs}:}${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"
$ pacman -Qo /etc/profile.d/flatpak.sh
/etc/profile.d/flatpak.sh is owned by flatpak 1.11.3-1
OK, thanks.
But flatpack is not installed on my system. So perhaps should it be a gnucash’s dependency now
Ehm, no: guncash
should definitely not depend on flatpak
.
It just happens, that the flatpak
package tries to extend the XDG_DATA_DIRS
variable and therefore sets/exports it. It’s the only package on my system that does the export
, but there are numerous counts of code trying to evaluate/use that variable - most with fallbacks like seen here:
${XDG_DATA_DIRS:-/usr/local/share:/usr/share}
guncash
should implement a similar fallback where it tries to use $XDG_DATA_DIRS
- that’s all.
You can remedy your problem for the time being by ensuring XDG_DATA_DIRS
is set on your system:
$ echo 'export XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"' | sudo tee /etc/profile.d/xdg-data-dirs-for-gnucash.sh
The Issue was with configuration of pulseaudio-sink-always-suspended - https://unix.stackexchange.com/questions/114602/pulseaudio-sink-always-suspended
Started getting issues with certificates and pacman after this update. Kernel 5.14
On every database sync, pacman errors with
error: failed retrieving file ‘community.db’ from mirrors.manjaro.org : SSL certificate problem: unable to get local issuer certificate
error: failed retrieving file ‘multilib.db’ from mirrors.manjaro.org : SSL certificate problem: unable to get local issuer certificate
error: failed retrieving file ‘core.db’ from mirrors.manjaro.org : SSL certificate problem: unable to get local issuer certificate
error: failed retrieving file ‘extra.db’ from mirrors.manjaro.org : SSL certificate problem: unable to get local issuer certificate
warning: too many errors from mirrors.manjaro.org, skipping for the remainder of this transaction
Then switch to a different mirror.
Thanks for the update! watchdog problem fixed!
Issue: pamac-gui has a big keyboard-delay when searching for packages
It is probably not a “keyboard delay”, I submitted a bug report last month Pamac windows unresponsive while searching when bandwidth saturated (#1097) · Issues · Applications / pamac · GitLab basically the interface hangs when it searches, and you can exacerbate this behavior when bandwidth is saturated.
Done, Thanks !
One thing i’m noticing since this update is that my HDDs are spinning up once in a while without using data on them. That didn’t happen before.
I can’t seem to figure out how to monitor which process is accessing these drives - iotop can’t be narrowed to just one disk, using lsof /mountpoint
when i hear the disk spin up seems to be too slow - maybe someone has an idea on how to narrow it down? ^^
This is fixed now
I remember you posting about it in an old testing update thread last month, and I forgot to ask you about it by the time it closed. In my own experience, I stopped those annoying “watchdog did not stop” messages and the occasional shutdown/reboot hang by blacklisting sp5100_tco
and iTCO_wdt
per the ArchWiki. Did you fix it yourself or did the update solve that for you?
No vhba-module for kernel 515. Is this an error or not? If so - where should i report it?