This post is a central place for us to publicize high visibility known issues, with links to bug reports when we have them and workarounds where available. This will be updated over time, check back if you experience problems. General help and troubleshooting are available on our Help Site
If you don't find your issue listed here, please search our issue tracker and open a new issue if necessary.
Budgie 10.9.3 breaks Electron-based apps that use safeStorage causing an error to appear at launch
On Budgie, when starting Signal-Desktop (and other Electron apps) you may see an error:
Database Error
Unable to access the database encryption key because the OS encryption keyring backend has changed from gnome_libsecret to basic_text. This can occur if the desktop environment changes, for example between GNOME and KDE.
Please switch to the previous desktop environment or try to run signal with the command line flag --password-store="gnome_libsecret".
There's an issue on the Budgie-Desktop tracker for this. Until this is fixed, use the workaround mentioned in the last sentence of the error.
For systems with an AMD Zen 5 processor, at boot you may see "RDSEED32 is broken. Disabling the corresponding CPUID bit"
This is due to an AMD security issue with the Zen 5. The kernel is disabling RDSEED 16 & 32-bit forms (32-bit is fine).
This is not a bug with the kernel or Solus. The message can be ignored.
See this bulletin from AMD for details.
Failure to update kernels during updates with an error no space left on device
This is caused by the /boot partition running out of space, which can happen for a few reasons.
See this for instructions on how to check if your /boot partition is at least 1GB, and how to remove old kernels properly to free up space.
Discover doesn't launch
Trying to open Discover sometimes doesn't work, no window appears. This is an upstream issue with a bug report on the KDE bug tracker which will need to be fixed by the KDE folks.
Workaround; Launch Discover from command line like this:
plasma-discover --backends packagekit-backend --backends flatpak-backend
Updates taking a long time - related to the linux-firmware package
The linux-firmware package was split into several subpackages to address a prior issue (now resolved). New installations from the public ISO, and systems that haven't been updated for a while, will take a long time to process this update. This one package can take between 8 and 15 minutes. Many file conflict warnings will also appear if the update is done in the terminal; these can be completely ignored.
GNOME VM black screen with X cursor
This appears to be an upstream bug, which also affects other distros.
Workaround: Do a forced reset on the VM
Budgie only has a black background with mouse cursor after login
There is an open issue here
Workaround: install the proprietary Nvidia drivers and see if that allows Budgie to load normally.
KDE Plasma - virtual / onscreen keyboard doesn't appear when clicking the button on the login screen
There are two aspects to this.
The user must install a virtual keyboard, and then set it to be used in System Settings.
There's a issue on our tracker to consider installing and configuring a virtual keyboard by default in a new Solus install.
The Virtual Keyboard button on the login screen doesn't respond to clicks, only touch. There is an upstream issue on the KDE bug tracker to fix this.
eopkg / Discover errors
KDE Discover / eopkg update error
If you see an error that starts like the below one:
$sudo eopkg.bin it qjackctl
Program terminated.
Component.localName: 'ar' language of tag 'LocalName' is empty.
Component.localName: 'bg' language of tag 'LocalName' is empty.
Component.localName: 'he' language of tag 'LocalName' is empty.
Workaround
Run this:
sudo eopkg dc
or
sudo eopkg ur --force
bash not loading scripts in ~/.bashrc.d (e.g. the packaging scripts like gotosoluspkgs)
If you try to run gotosoluspkgs or another command from your scripts in ~.bashrc.d you may get an error like
bash: gotosoluspkgs: command not found
This is because a bug was fixed in this PR
The files in ~.bashrc.d had been incorrectly sourced for all shells, which had caused errors in non-bash shells. Unfortunately, this means that existing users will no longer have ~.bashrc.d sourced by /usr/share/defaults/etc/profile.
New users created after this change will have the scripts sourced normally.
Workaround for existing users
Add this to ~/.bashrc
# User specific bash aliases and functions
if [ -d ~/.bashrc.d ]; then
for rc in ~/.bashrc.d/*; do
if [ -f "$rc" ]; then
. "$rc"
fi
done
unset rc
fi
There's an open issue to correct the problem for users created before this change.
