When running a Linux server it is sometimes necessary to check which kernel version you are using to be able to choose certain software to install etc.
There are a few ways to do this. We will be trying out the methods in this linfo.org article. Since I am running an OpenVZ CentOS 6 Linux there are, as we will see, some differences.
uname -r
The uname command is so helpful. Let’s see what it can do.
[ahmed@amayem ~]$ uname --help
Usage: uname [OPTION]...
Print certain system information. With no OPTION, same as -s.
-a, --all print all information, in the following order,
except omit -p and -i if unknown:
-s, --kernel-name print the kernel name
-n, --nodename print the network node hostname
-r, --kernel-release print the kernel release
-v, --kernel-version print the kernel version
-m, --machine print the machine hardware name
-p, --processor print the processor type or "unknown"
-i, --hardware-platform print the hardware platform or "unknown"
-o, --operating-system print the operating system
--help display this help and exit
--version output version information and exit
Report uname bugs to bug-coreutils@gnu.org
GNU coreutils home page: <http://www.gnu.org/software/coreutils/>
General help using GNU software: <http://www.gnu.org/gethelp/>
For complete documentation, run: info coreutils 'uname invocation'
So it seems that -r and -v are the most interesting:
[ahmed@amayem kernel]$ uname -r
2.6.32-042stab078.28
Worked like a charm. I am running an OpenVZ CentOS system and I found that version archived here. It turns out that what I have is actually an RHEL6 openvz kernel. According to OpenVZ’s versioning system this is an OpenVZ kernel based on RHEL 2.6.32 with a major OpenVZ release of 042 and a minor OpenVZ release of 078. The stab means it is stable, and out of testing.
What about -v:
[ahmed@amayem kernel]$ uname -v
#1 SMP Mon Jul 8 10:17:22 MSK 2013
It seems to be mentioning the release date.
cat /proc/version
[ahmed@amayem kernel]$ cat /proc/version
Linux version 2.6.32-042stab078.28 (root@rh6-build-x64) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Mon Jul 8 10:17:22 MSK 2013
Easy, same info as before.
rpm -q kernel
[ahmed@amayem kernel]$ rpm -q kernel
package kernel is not installed
This makes sense, because in OpenVZ the container cannot change the kernel. If I were able to query the kernel then I might be able to change the kernel, which would be a problem. Let’s try something else.
[ahmed@amayem kernel]$ rpm -qa | grep kernel
kernel-headers-2.6.32-431.11.2.el6.i686
The -q flag means query, and the a flag means all, so we were asking rpm to show us all the installed packages, and we piped the output into grep to find us the ones with kernel. Not exactly the Kernel but good enough.
dmesg | grep Linux
[ahmed@amayem kernel]$ dmesg | grep Linux
[ahmed@amayem kernel]$ dmesg
[ahmed@amayem kernel]$
Looks like nothing is being registered by dmesg. Let me try it again after a fresh reboot:
[ahmed@amayem kernel]$ dmesg
[ahmed@amayem kernel]$
Still nothing. After some digging around I found out that printk must be configured to show kernel-info messages. You can see your printk configurations like this:
[ahmed@amayem kernel]$ sysctl -a | grep printk
error: permission denied on key 'kernel.cad_pid'
error: permission denied on key 'kernel.usermodehelper.bset'
error: permission denied on key 'kernel.usermodehelper.inheritable'
kernel.printk = 4 4 1 7
kernel.printk_ratelimit = 5
kernel.printk_ratelimit_burst = 10
kernel.printk_delay = 0
error: permission denied on key 'kernel.pid_ns_hide_child'
error: permission denied on key 'fs.quota./fake'
Ouch lot’s of permission denied‘s. let’s try it with sudo:
[ahmed@amayem ~]$ sudo sysctl -a | grep printk
kernel.printk = 4 4 1 7
kernel.printk_ratelimit = 5
kernel.printk_ratelimit_burst = 10
kernel.printk_delay = 0
Much better. Or the easier way is this:
[ahmed@amayem ~]$ cat /proc/sys/kernel/printk
4 4 1 7
What do these numbers mean? According to the CentOS wiki for /proc/sys/kernel/,
Each of these values defines a different rule for dealing with error messages. The first value, called the console loglevel, defines the lowest priority of messages printed to the console. (Note that, the lower the priority, the higher the loglevel number.) The second value sets the default loglevel for messages without an explicit loglevel attached to them. The third value sets the lowest possible loglevel configuration for the console loglevel. The last value sets the default value for the console loglevel.
Ok, so what are the possible loglevel values? The CentOS wiki tells us the following:
printk — This file controls a variety of settings related to printing or logging error messages. Each error message reported by the kernel has a loglevel associated with it that defines the importance of the message. The loglevel values break down in this order:
0 — Kernel emergency. The system is unusable.
1 — Kernel alert. Action must be taken immediately.
2 — Condition of the kernel is considered critical.
3 — General kernel error condition.
4 — General kernel warning condition.
5 — Kernel notice of a normal but significant condition.
6 — Kernel informational message.
7 — Kernel debug-level messages.
Perhaps the problem is that out first value is a 4, which is the level for a “General kernel warning condition”. Let’s change it to 7 and give it a try:
[ahmed@amayem kernel]$ echo 7 > /proc/sys/kernel/printk
-bash: /proc/sys/kernel/printk: Permission denied
[ahmed@amayem kernel]$ sudo echo 7 > /proc/sys/kernel/printk
-bash: /proc/sys/kernel/printk: Permission denied
Argh even sudo isn’t working. This looks like another version of the sudo cd problem. As mentioned in that article we will have to switch to root:
[ahmed@amayem kernel]$ su
Password:
[root@amayem kernel]# echo 7 > /proc/sys/kernel/printk
Ok let’s check if it worked:
[root@amayem kernel]# cat /proc/sys/kernel/printk
4 4 1 7
No change. This looks like another limitation of OpenVZ. dmesg is not enabled for containers by default, which is why it was not showing anything. Trying to change the loglevels as a container was meaningless and clearly we were not even able to do it.
ls /boot
[ahmed@amayem kernel]$ ls /boot
grub
[ahmed@amayem kernel]$
No luck here, though the article did mention that this might not work for all systems.
Summary
Working methods to find the kernel version on my OpenVZ CentOS
- uname -r
- cat /proc/version
Broken methods to find the kernel version on my OpenVZ CentOS
- rpm -q kernel
- dmesg | grep Linux
- ls /boot
I would love to hear your experiences trying to find your kernel verion.
