Anticipate "kernel too old" errors between 2.6.16 and 2.6.26 kernel versions

19
votes

I build an application on a machine running Linux (Debian) with kernel 2.6.26-2-amd64 and I want to run this application on another machine running Linux (Suse) with kernel 2.6.16.60-0.21-smp but I get the error "FATAL: kernel too old".

I know from research on the internet that this can happen when building against a glibc library that was not compiled to support older kernel versions, but it usually concerns version 2.4. Is it possible to get such errors for kernel of the same series (2.6) or can this be from something else ?

Additionally I read that the solution to this problem is to rebuild the application against another version of glibc compiled with appropriate --enable-kernel=VERSION option. As an alternative can you just dynamically link your application with glibc to solve the problem ?

Thank you for your help.

UPDATE: I understand my question may seem vague or solved by one of the solutions already mentionned (dynamically linking, building on another [virtual] system, rebuilding glibc [which seems quite tricky considering the comments I read about it]) but what I am ultimately looking for are ways to prevent such problems.

For instance, is it possible to find which versions of the Linux kernel are compatible with a particular build of glibc ?

UPDATE 2: I eventually found a source patch for glibc (for Debian but I guess there are similar docs online for other distros) that (I guess) contains the information I was looking for.

From this page: 

--- eglibc-2.11.2.orig/debian/sysdeps/linux.mk
+++ eglibc-2.11.2/debian/sysdeps/linux.mk
@@ -0,0 +1,51 @@
[...]
+MIN_KERNEL_SUPPORTED := 2.6.18
[...]
+# Minimum Kernel supported
+with_headers = --with-headers=$(shell pwd)/debian/include
--enable-kernel=$(call xx,MIN_KERNEL_SUPPORTED)
[...]

Which explains the "kernel too old" error. Hope it helps other people.

1
c++linuxlinux-kernel
Your analysis seems plausible to me. So given the solutions you listed, have you tried the easy one: compiling your app with dynamic linkage? – Karmastan
Yes I've tried it and it seems to work so far but I have not yet tested all the features so I just hope It will continue to work. What I really wanted to know though was why I was getting this error between what seemed to me as not so different versions of the kernel and how can it be prevented for the future. Is there a document that lists known incompatibilities ? – Aabaz
Did you look at autoconf/automake? – Foo Bah
I don't really know how these programs would relate to my problem. As I understand them, these tools are used to build configure / makefile files from source. What I was looking for is close to the opposite: retrieving configure options without access to the source. But my knowledge of these tools is very limited so I may have missed something. – Aabaz

1 Answers

20
votes

One way you can determine the minimum kernel version for a given ELF file is to run file on it, like so:

$ echo 'int main(){}' > test.c
$ gcc -o test test.c
$ file test
test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.38, not stripped

The important part here is the "for GNU/Linux 2.6.38", which indicates the minimum kernel version.