> uname -r
FATAL: kernel too old
> cat /proc/cmdline
FATAL: kernel too old

There are 3 *.vmlinuz-linux files in /boot. How do I determine which kernel is currently running?

Note that I'm running in a limited environment with a minimal shell. I've also tried:

> sh -c 'read l < /proc/version; echo $l'
FATAL: kernel too old
> dd if=/proc/version
FATAL: kernel too old

Any thoughts?

  • reboot. If GRUB is installed maybe you can have options to solve your problem. Or use a live-cd or usb...
    – jcm69
    Commented Jul 21, 2017 at 20:08
  • 2
    I'm curious, how did you boot the thing? And what is it? Seems to be missing some key bits of information. Is this a rescue shell? Can you provide more details?
    – Lizardx
    Commented Jul 21, 2017 at 20:32
  • If you have chromium installed see : chrome://system/
    – GAD3R
    Commented Jul 21, 2017 at 21:19
  • Yes, it's a rescue shell. I was upgrading many packages, including glibc. The daemon running the rescue shell is still alive and listening on a port, so I was able to get in there. Commented Jul 21, 2017 at 21:19
  • 1
    It appears that the machine has been hard-restarted (eg, someone pressed a button) and this has become an academic question. It was an interesting state, and I would have liked some hard data on what to look out for, but I suppose the takeaway is: upgrade the kernel and reboot before upgrading glibc. Commented Jul 21, 2017 at 21:21

4 Answers 4


You have upgraded your libc (the most basic system library) and now no program works. To be precise, no dynamically linked program works.

In your particular scenario, rebooting should work. The now-installed libc requires a newer kernel, and if you reboot, you should get that newer kernel.

As long as you still have a running shell, there's often a way to recover, but it can be tricky if you didn't plan for it. If you don't have a shell then usually there's no solution other than rebooting.

Here you may not be able to recover without rebooting, but you can at least easily find out what kernel is running. Just use a way to read /proc/version that doesn't require an external command.

read v </proc/version; echo $v
echo $(</proc/version)               # in zsh/bash/ksh

If you still have a copy of the old libc around, you can run programs with it. For example, if the old libc is in /old/lib and you have executables that work with this old libc in /old/bin, you can run

LD_LIBRARY_PATH=/old/lib /old/lib/ld-linux.so.2 /old/bin/uname

If you have some statically linked binaries, they'll still work. I recommend installing statistically linked system utilities for this kind of problem (but you have to do it before the problem starts). For example, on Debian/Ubuntu/Mint/…, install one or more of busybox-static (collection of basic Linux command line tools including a shell), sash (shell with some extra builtins), zsh-static (just a shell but with quite a few handy tools built in).

busybox-static uname
sash -c '-cat /proc/version'
zsh-static -c '</proc/version'
  • if you reboot, you should get that newer kernel. or a black screen which seems far more likely
    – cat
    Commented Jul 22, 2017 at 3:54
  • Assigning LD_LIBRARY_PATH is a great suggestion. Unfortunately, the rescue shell doesn't have an internal read, doesn't allow redirects, and doesn't even allow assignment of environment variables! I am filing a bug to get env assignment into the shell. Commented Jul 22, 2017 at 8:41

That appears to be the error glibc throws if it's running on a kernel that is older than what the library is compiled to support. The error message is in the DL_SYSDEP_OSCHECK(FATAL) macro in sysdeps/unix/sysv/linux/dl-osinfo.h

There's a compile time option for this:

This option is currently only useful on GNU/Linux systems. The version parameter should have the form X.Y.Z and describes the smallest version of the Linux kernel the generated library is expected to support. The higher the version number is, the less compatibility code is added, and the faster the code gets.

So it seems that for some reason, you're running a system with an old kernel but an installed glibc that doesn't support the old kernel any longer. How you got the is hard to tell without information on what system it is, but one might assume that could happen if the library is updated but the kernel isn't.

file seems to show the minimum version required by an executable or a library (but of course you need a working library to run it):

/lib/x86_64-linux-gnu/libc-2.23.so: ELF 64-bit LSB shared object, x86-64, ..., for GNU/Linux 2.6.32, stripped

On my semi-current Debian systems, the required kernel version is 2.6.32 as above on all binaries I checked, which would make it quite unlikely to hit an issue with the kernel version.


Try with this:

cat /proc/version
  • > cat /proc/version FATAL: kernel too old Commented Jul 21, 2017 at 19:54
  • This is a good thought, but with the incompatible glibc, cat is not available. Commented Jul 21, 2017 at 19:54
  • I feared as much, but it was worth a try ...
    – Sven
    Commented Jul 21, 2017 at 19:55
  • Is it just because cat is unavailable? Why not vim or nano /proc/version then?
    – jesse_b
    Commented Jul 21, 2017 at 20:02
  • How about: head /proc/version || tail /proc/version || sed '1q;d' /proc/version
    – jesse_b
    Commented Jul 21, 2017 at 20:05

Use strings command to extract the printable information from the vmlinuz file.

strings vmlinuz | grep version

Sample output:

4.9.0-6-amd64 ([email protected]) (gcc version 6.3.0 20170516
(Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .