libc6 integration gives way wrong error message to libc5 binaries.

[William Cattey]

Binary package hint: libc6

I know from the start I'm asking for something that doesn't fit in a simple place.

The problem goes like this:
The way libc6 has been integrated, any libc5 binaries that are run will give a way wrong error message.

For example, clueless users running old programs out of remotely mounted filesystems:

WDC-ATHENA-2% which ez
/mit/andrew/arch/i386_linux24/bin/ez
WDC-ATHENA-2% ez
ez: Command not found.

The problem is NOT that the ez binary is not found. The problem is that there is no ld-linux.so.1 to help link
in libc5. The reason for this is, sensibly, there IS no libc5 installed.

What needs to happen is that the person running the program needs to be told that the binary is so old
that it's linking against libc5 when it needs to be recompiled against libc6.

Instead the user is told that the file that can be accessed from myriad file utilities does not exist.

I suggest a work-around:

a Recommends /lib/ld-linux.so.1 that gets installed if none is present that will at least
print an error message that makes sense.

Since Ubuntu is all about the usability experience, I hope I'm not off base here asking for this amendment.

[Colin Watson (cjwatson)]

Ugh.

The problem here is that if you execve() a binary whose interpreter is missing, then the kernel just gives you ENOENT. I'm not sure that dropping in stub interpreters for anything that might need to exist is a good solution here.

Maybe this would be better fixed at the command-not-found level. It could check whether the binary is actually present on $PATH, and then hunt around to tell you which package you need to install in order to get hold of its interpreter.

[William Cattey (wdc-mit)]

One other manifestation of the problem is that if you try and find out what libraries the binary wants by using ldd, you get the same wrong error mesage. Instead of saying it wants to link against libc5, it says the the binary being examined does not exist.

Perhaps the place to address the issue is in the same realm that discovers we're not allowed to run sparc code on an i386? (I say that not having thought terribly hard about where that might be.)

[Geoffrey Thomas (geofft)]

So I was looking into two workarounds for this.

One is a stub ld-linux.so.5 that gets mad at you and exits. If you just compile a short program that write()s an error message with gcc -static -fPIC, it "works" as an interpreter.

The other option, which I think is a little more suitable, is to address this at the kernel level. The current code path in fs/binfmt_elf.c attempts to find the interpreter specified in the file, and if this returns an error, that errno returned is returned directly by exec. We can translate ENOENT (and perhaps other errors?) to ENOEXEC before returning. The patch attached has been tested on Intrepid, and should actually apply to kernel 2.6.20 onwards.

unpatched$ sed "s/ld-linux.so.2/ld-linux.so.1/" < /bin/ls > ls && chmod +x ls && ./ls
bash: ./ls: No such file or directory

patched$ sed "s/ld-linux.so.2/ld-linux.so.1/" < /bin/ls > ls && chmod +x ls && ./ls
-bash: ./ls: cannot execute binary file

According to the Open Group's copy of POSIX at
http://opengroup.org/onlinepubs/009695399/functions/exec.html
ENOENT is only to be returned from execve if "path" or "file" doesn't exist, and ENOEXEC indicates the binary has an "unrecognized format".

So this seems like a reasonable (and very tiny) change to make. Could we get it in Ubuntu's kernel? I also plan to submit this to the LKML.

[Steve Conklin (sconklin)]

This patch does not appear to be upstream. It creates a significant amount of extra work for the Ubuntu kernel team to maintain out of tree patches. As such they typically require patches to be submitted and accepted upstream first. Do you know if the patch referenced here has gone upstream? Please let us know. Thanks.

[Michael Vogt (mvo)]

I looked at it from a command-not-found perspective and we would have to modify the internal bash code that calls the command-not-found function to deal with this as well. It sounds to me like the proposed kernel patch is a better solution (also it would be a nice feature to integrate that with command-not-found).

[Zygmunt Krynicki (zyga)]

I agree that getting a more helpful message is important.

Still given the complexity and required dependencies I'll rather wait for a consensus / upstream help for this one

[Geoffrey Thomas (geofft)]

I've submitted a longer version of the patch above to the LKML:

http://lkml.org/lkml/2009/7/9/74

[Leann Ogasawara (leannogasawara)]

Seems the patch was NACK'd upstream - http://lkml.org/lkml/2009/7/11/133

"NAK. Current behaviour is useful -- and it is really file thats
missing.

Please improve manpage instead.

(chmod 000 /lib also produces 'interesting' error messages. Better
document those, too)."

[William Cattey (wdc-mit)]

Which manpage should be improved?

Indeed you are technically correct that the obscure ld.so file is not found.

It is too bad that the error message cannot tell the name of the file it was looking for so as to provide both accurate and useful information. Perhaps the fix is not to change a man page, and not to put a kludge file in to patch around the problem but to change the kernel so "file not found" becomes ("System library file %s not found", filename).

It would be really wonderful if we could evolve the kernel and other subsystem code to be better at providing diagnostics that are useful and correct, rather than continuing to rely on an oral tradition, or to accept as complete a single line change in documentation that may not be easily found when the problem occurs.