Re: Patch wheezy's glibc to run on ancient kernel (2.6.16)?
On 2014-09-01 10:28 +0200, Clemens Eisserer wrote:
> I would like to run debian wheezy on my nokia-770 (Linux-2.6.16.27) in a
> chroot environment, unfourtunately chroot telling me the kernel is too old.
> The latest version that worked this way is Debian Lenny, which is
> unsupported since mid 2012.
This is not too worrying since the 2.6.16 kernel has been unsupported
since 2008, and 2.6.16.27 is even two years older.
> Because updating the kernel almost impossible (binary wlan driver blob,
> texas instrument`s patched OMAP source tree, ancient toolchain), is there
> any way to patch a debootstrapped debian installation with a self-compiled
> glibc that is compatible with older kernel versions?
Probably. To patch eglibc for supporting older kernels, change the
MIN_KERNEL_SUPPORTED variable in debian/sysdeps/linux.mk and update the
check in debian/debhelper.in/libc.preinst for the minimum kernel version
accordingly.
> I reason I ask is because the minimum kernel version also seems to be
> stored in all the executeables too, e.g. I get the following output on a
> MIPS box:
>
> root@OpenWrt:/usr/bin# file xz
> xz: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically
> linked (uses shared libs), for GNU/Linux 2.6.26, .....
The requirement is stored in a section in the binary labeled
NT_GNU_ABI_TAG and is usually the same as the one for the glibc version
the binary was linked with. AFAIK the dynamic linker does not use this
information for executable programs, but it does for libraries (refuses
to load them if the kernel is too old).
You can set the LD_ASSUME_KERNEL environment variable to tell the
dynamic linker about that you're actually a different kernel. Here I'm
telling it that my kernel is actually too old:
,----
| $ LD_ASSUME_KERNEL=2.6.25 /bin/true
| /bin/true: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
`----
> ... however as the binary does not talk directly to the kernel (or, does
> it?), I don't understand how the binary itself has a requirement on the
> linux kernel.
The binary might make syscalls which are not implemented in older
kernels, but most programs use glibc wrappers instead. So I think a
wheezy chroot should mostly work once you have rebuilt eglibc.
Cheers,
Sven
Reply to: