Configure your Linux system

Testing an overclocked CPU on Linux

I’m in the process of tweaking / upgrading my PC for better performance. Just a minor upgrade as I think I can still make use of the old AMD FX8350 on my daily work, at least for a while. I’ll wait for the next year’s AMD CPU releases and then decide which direction to go next.
As of now I managed to overclock the CPU to a stable 4.6GHz at 1.44 Vcore. Cooler is Noctua NH-D14 which keeps the CPU under 60C. RAM is 2x4GB @1866MHz, planning on upgrading to 2x8GB. There’s room for improvement so I’ll get back at it.

I initially had 2 drives (an SSD with W7 and an SSHD with Linux), so I could boot into W7 and make use of OCCT, Intel Burn Test and other software to stress test the CPU. Unfortunately the SSD failed so I had to test the overclock stability in Linux. Was surprised to see Linux (still) doesn’t have benchmark equivalents, at least not reasonable ones. I admit I didn’t search too far and I did find mprime which is the Linux version of Prime95 and it is actually pretty good. Even though it doesn’t have a GUI, it’s pretty easy to use — download, extract the tar.gz and run the mprime binary from a terminal, then select an option from the menu. It has several features, but I didn’t play with them. Not yet at least.

I barely found a CPU-Z-like app available for Linux and was happy to see there’s a CentOS 7 (my current main OS) precompiled binary. It’s available here.
CPU-Z is a GUI app, but it doesn’t display important info such as voltages so I have to use these commands instead:

watch -n0.2 'cat /proc/cpuinfo  | grep MHz'
watch -n0.2 sensors

I’ll investigate some more and keep posting what I find. Hope this helps.

Desura on CentOS7

After a lot of time the Desura client for Linux finally received an update. It wasn’t without issues, many users complained about not being able to install it properly due to unresolved library dependencies. The latest release (build 120.26, as of today) still doesn’t work out of the box on CentOS 7, so here’s how to fix it.

I tested this on two separate instances of the 64-bit CentOS, so this applies to the 64-bit release of Desura (the 32-bit version doesn’t seem to be supported any more).


1. Desura is not installed


After downloading and extracting the latest installer to $HOME/Downloads/desura, the following error is displayed when attempting to start the client:

/home/lsc/Downloads/desura/lib/desura: error while loading shared libraries: cannot open shared object file: No such file or directory

To fix it we need to create a symlink to the required library after verifying it is installed:

rpm -qf /usr/lib64/
cd /home/lsc/Downloads/desura/lib
ln -s /usr/lib64/

Doing this allows desura to launch properly and perform an auto-update. After that everything works fine except for the application shortcut which is not added automatically to the start menu. To add it manually:

cp ~/Downloads/desura/desura.desktop /usr/share/applications


2. Desura is installed


If an older client was previously installed and updated, the above trick doesn’t seem to work. Forcing the desura update also failed on me. The fix was to download the latest client and extract it to the same installation path in order to overwrite existing files (this does not delete any game data stored in the common folder):

tar zxv --overwrite --overwrite-dir -f desura-x86_64.tar.gz -C /home/lsc/Downloads
ln -s /usr/lib64/ ~/Downloads/desura/lib/

Inplace migration from Oracle Linux 7 to CentOS 7

This is my 2nd attempt to migrate from Oracle Linux to CentOS; a while ago I tested it with success on OL6.4. This time I’m using an OL7 VM instance with a default desktop installation. Having 3rd party repositories installed on OL7 should not cause any issues when switching to CentOS as the RPMs from the EL7 repos are usually compatible with most EL7 clones, except for maybe drivers compiled against specific kernel versions such as Nvidia. I only had the EPEL repo configured with 1 or 2 packages installed, so I didn’t have any problems.


1. Make kernel-uek default and update the OS


Changing the default kernel (from kernel to kernel-uek) in /etc/sysconfig/kernel is not mandatory, as one can choose to boot a specific kernel while in the Grub2 menu. However, changing the file will automatically configure any new kernel-uek as default, which is what we need.

sed -i 's/DEFAULTKERNEL=kernel/DEFAULTKERNEL=kernel-uek/' /etc/sysconfig/kernel
yum update


2. Confirm kernel-uek is the default or otherwise select it manually


If the above yum command didn’t find any updates to the kernel RPMs, the Grub2 configuration hasn’t changed. In this case we can change the default kernel manually. The following tool returns the current default kernel:

grub2-editenv list

My OL 7 installation was using the Red Hat Compatible Kernel as default, so I changed it:

awk -F "'" '$1=="menuentry " {print $2}' /boot/grub2/grub.cfg
Oracle Linux Server, with Linux 3.10.0-123.el7.x86_64
Oracle Linux Server, with Linux 3.10.0-123.20.1.el7.x86_64
Oracle Linux Server, with Unbreakable Enterprise Kernel 3.8.13-55.1.5.el7uek.x86_64
Oracle Linux Server, with Unbreakable Enterprise Kernel 3.8.13-35.3.1.el7uek.x86_64
Oracle Linux Server, with Linux 0-rescue-f4f6b4c2976d454eade4da24993a1308
grub2-set-default 'Oracle Linux Server, with Unbreakable Enterprise Kernel 3.8.13-55.1.5.el7uek.x86_64'


3. Change the default target (runlevel) and restart


systemctl set-default


4. Install the CentOS repos


After rebooting into Oracle’s kernel UEK3 we are ready to proceed. First, remove Oracle-specific RPMs and install the CentOS repository files.

rpm --import
rpm -e --nodeps `rpm -qa | egrep 'redhat|oracle|rhn|uname26|libdtrace-ctf'`
yum install

[Read the rest of this entry…]

Randomizing cron scheduling across multiple servers

This is not about running cron at random hours every time on each server, but configuring different time schedules for multiple machines. This is especially useful when dealing with many servers as having the same cron entries on all of them might affect LAN / WAN bandwidth or increase load on the master server (yum internal repository, backup server) that all of the machines are trying to reach at the same time.

My approach on this is to write a small script to generate random hours / minutes /etc. and have that script run on each server. This can be done during kickstart installations (%post section) or at any time after the OS is installed (e.g. by installing an RPM package that includes crontab configuration or simply by pushing and triggering the script execution automatically).

Here is a sample shell coding which makes use of the shuf utility:


Generate random hours between 9AM-6PM:
MINS=`/usr/bin/shuf -i 1-59 -n 1`
HRS=`/usr/bin/shuf -i 9-17 -n 1`


Install crontab:


  • for root:
echo "$MINS $HRS * * *    $COMMAND" > /tmp/cronjob
cat /tmp/cronjob | crontab


  • for generic user:
echo "$MINS $HRS * * *    $COMMAND" | crontab -u $USER -

Hope this helps.