One of my machines is a Lenovo Thinkpad T420s running Sabayon Linux. Since a long time I experienced issues with my USB mouse and keyboard after resuming from standby, while the notebook and the input devices were plugged into the dock. Both devices stuttered occasionally, i.e. the first key stroke or move of the mouse were not recognized. Sometimes I was able to fix the issues by disconnecting and reconnecting the dock’s power connector. Sometimes only a restart helped.
After doing lots of research in the web, I stumbled over a mailinglist post that suggested to remove the package laptop-mode-tools, if installed.
Guess what, the particular package was installed, I removed it and the issues have not reappeared since then.
After the last weekly update of my Sabayon Notebook I encountered a high CPU load of one core caused by syslog-ng. The process was literally flooding /var/log/messages and within a couple of minutes tens of Megabyte accumulated. logrotate did not help. The messages were months old, it appeared as syslog-ng would be processing old logs from somewhere else.
I knew that journald was active too, complementing syslog-ng I thought. Some ddg searches later I stumbled over a Gentoo bug report confirming my issue.
Instead of masking syslog-ng-3.6.1 I headed to #sabayon and asked around. Someone explicitly mentioned that syslog-ng is likely pulling logs from journald.
I ended up editing /etc/syslog-ng/syslog-ng.conf and replacing the default source src:
One of my machines is a Lenovo T420s running on Sabayon Linux in a dual monitor setup with discrete graphics set up in the BIOS. The latest sabayon-weekly update (installed on 22.10.2014) shipped the nvidia-drivers-340.46, afterwards the graphics setup was messed up: The second monitor was not recognized anymore while Xorg continued to handle the desktop as usual, i.e. expanded over two displays. Even after a reboot with detached monitor I just saw a background pattern on my integrated display where I should have a login box.
I tried a couple of approaches to fix this behaviour:
Tried to downgrade the drivers to the previously installed version 340.32 by masking nvidia-drivers-340.46 and nvidia-userspace-340.46. I could not go back to that version with Entropy, instead it installed 304.123. That version broke my Xorg completely with lots of slow flickering indicating a couple of tries to initialize the graphics adapter, eventually leading to a crashed Xorg startup.
Removed/modified/replaced /etc/X11/xorg.conf with previously working configurations and tried tips from various forums.
I noticed that in xrandr the second monitor was detected as attached. I was just not able to configure it at all using nvidia-settings. That one was quite persistent in just offering me two display labeled with some Lenovo name.
Eventually I decided to get rid of the proprietary Nvidia drivers and give Nouveau another try. I had tried Nouveau a couple of years ago and at that time I had trouble to get it up and running. Nouveau has since evolved and I was able to restore my graphics setup to a working state:
$ sudo equo install nouveau
Checked available OpenGL implementations:
$ sudo eselect opengl list
Available OpenGL implementations:
 nvidia *
Set the OpenGL implementation to xorg-x11:
$ sudo eselect opengl set 2
Commented out the blacklisted nouveau in /etc/modprobe.d/blacklist.conf.
Moved /etc/X11/xorg.conf temporarily to have a fresh Xorg startup.
One note: Step (4) is critical. I did not check the blacklisting and was wondering why Xorg was only using 1024x768 and the control center display settings in Gnome were just showing an “unknown monitor”. Sabayon seems to blacklist nouveau by default.
Since a couple of updates my Sabayon machine had a broken wlan0 interface after resuming from standby. The NetworkManager connected to the WIFI as expected and even received a correct IP from the DHCP server but something was broken with the routing as far as I know. The route command didn’t return any route, pings failed.
I was able to fix the issue after every resume by running sudo dhclient wlan0 manually. Needless to say, this was something that I did not want to do all the time. I found this helpful tip in the Ubuntu forums: Just create a bash script using root permissions in /etc/NetworkManager/dispatcher.d, e.g. 20-dhclient, with this content:
# This script runs dhclient when using wireless
if [ “$1” = “wlan0” ]; then
if [ “$2” = “up” ]; then
Save it, make it executable with sudo chmod +x 20-dhclient and restart the network with either sudo /etc/init.d/NetworkManager restart or sudo systemctl restart NetworkManager.
If you know a better way to fix this issue, please let me know in the comments.
Today I ran a regular update of my Linux machine and after the next reboot I saw a continuous high CPU load caused by gnome-shell. Beside a couple of other updates, Entropy had updated Gnome and the Nvidia drivers. I checked the settings for OpenGL and found a strange setting:
$ sudo eselect opengl list
Available OpenGL implementations:
 xorg-x11 *
Fixing the setting by executing $ sudo eselect opengl set 1 and restarting the X server solved the issue: Since then the CPU load is back to normal.
In my particular use case I wanted links in Gwibber to open in Chromium instead of Firefox. Gwibber is a Twitter client written in Python. Unfortunately all the proposed solutions from above didn’t work. Fortunately I found a solution.
<p>Geniale Sache und gleichzeitig eine Frage der Sicherheit – vor allem in Produktionsumgebungen. Vielleicht sollte dort je nach Einsatzgebiet lieber auf die Option <a href=“http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/security-sysrq.html”>“žMagic SysRQ key„</a> beim Kernel kompilieren verzichtet werden. ;)</p>
<p>Ansonsten kann man als root beispielsweise mit </p>
$ sysctl -w kernel.sysrq=0
<p>die SysRQ-Taste deaktivieren.<br />
Alternativ kann ebenso die Datei /etc/sysctl.conf vorhanden sein, die man so anpassen muss, damit der gleiche Effekt erzielt wird: