32-bit application do not run anymore after update on 64-bit architecture

English Applications
1

I just updated my opensuse 13.2 on 15 July 2015 and after the update all applications which are 32 bit are not running anymore. For example skype or wine are reporting:

bash: ./skype: Permission denied

and if I run ldd on them I get:
ldd ./skype:
not a dynamic executable

and
file ./skype
./skype: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=6eef9a3f7c9719980b6e317a00ea971d3717ac89, stripped

could it be that the kernel has been built without the capability to run 32 bit applications ?

Regards
Michele

2

Definitely not, at least not the kernel included in openSUSE.

But what kernel are you actually using?

uname -a

But “Permission denied” probably means that the ‘x’ (“executable”) flag is not set.
What does “ls -l ./skype” say?

The same for wine.

How did you install the two?

3

On 2015-07-15 14:16, mlaghi wrote:
>
> I just updated my opensuse 13.2 on 15 July 2015 and after the update all
> applications which are 32 bit are not running anymore.

You need to also install the 32 bit libraries available in the 64 bit
oss repo. Some of them, anyway. Maybe the opensuse skype wiki page lists
them.

> For example skype
> or wine are reporting:
>
> bash: ./skype: Permission denied

Does it have the ‘x’ executable attribute set, and is the partition
mounted “exec”?

>
> and if I run ldd on them I get:
> ldd ./skype:
> not a dynamic executable

It is static :slight_smile:

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

4

"ls -l ./skype
-rwxr-xr-x 1 michele users 36499124 May 22 2014 ./skype

ls -l /usr/bin/wine
-rwxr-xr-x 1 root root 9752 Oct 15 2014 /usr/bin/wine

uname -a:

Linux brix 3.16.7-21-desktop #1 SMP PREEMPT Tue Apr 14 07:11:37 UTC 2015 (93c1539) x86_64 x86_64 x86_64 GNU/Linux

but again: everything worked before the update. and this is not specific to skype or wine: it is the same for all 32-bit applications. And the partitions are also mounted as executable.

5

And everything still works fine here.

So what update did you actually install?

And “Permission denied” is the only error you get? For all 32bit applications?
Are there any messages in the kernel log after you try to run one?

dmesg|tail

What does e.g. “ldd /usr/bin/wine” say?

6

ldd which wine
not a dynamic executable

and dmesg|tail does not show anything.
I re-installed all packages with

zypper -n install -f ${list of all packages}

but that did not help either

7

Show us your repositories;
**zypper sl -d
**
and wrap the output in CODE tags


like this!
8

Hm, that’s what it displays on my 13.2 system:

wolfi@amiga:~/Desktop> ldd /usr/bin/wine
        linux-gate.so.1 (0xf7744000)
        libwine.so.1 => /usr/bin/../lib/libwine.so.1 (0xf758d000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xf751e000)
        libc.so.6 => /lib/libc.so.6 (0xf7371000)
        libdl.so.2 => /lib/libdl.so.2 (0xf736c000)
        /lib/ld-linux.so.2 (0xf7747000)
wolfi@amiga:~/Desktop>

Just to rule out a different wine in another directory: Try “ldd /usr/bin/wine” and/or post the output of “which wine”.

Is the 32bit dynamic linker (/lib/ld-linux.so.2) there? Is the package glibc-32bit installed?

9

Hi Carlos: it is not static (according to file):

file skype
skype: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=6eef9a3f7c9719980b6e317a00ea971d3717ac89, stripped

10

ldd /usr/bin/wine
not a dynamic executable

which wine
/usr/bin/wine

glibc-32bit is installed (and I reinstalled it too)

regarding the (/lib/ld-linux.so.2 I also noticed the following strange thing:

ls /lib/ld-linux.so.2 -l
lrwxrwxrwx 1 root root 19 Jul 16 21:24 /lib/ld-linux.so.2 -> ld-2.19.so;55a55c57

and in the same directory I notice the following too:
ls /lib/ld* -l
-rwxr-xr-x 1 root root 152330 Jun 17 16:52 /lib/ld-2.19.so
---------- 1 root root 152330 Jul 14 20:58 /lib/ld-2.19.so;55a55bce
---------- 1 root root 152330 Jul 14 20:58 /lib/ld-2.19.so;55a55bcf
---------- 1 root root 152330 Jul 14 20:59 /lib/ld-2.19.so;55a55bff
---------- 1 root root 152330 Jul 14 20:59 /lib/ld-2.19.so;55a55c00
---------- 1 root root 152330 Jul 14 20:59 /lib/ld-2.19.so;55a55c01
---------- 1 root root 152330 Jul 14 21:00 /lib/ld-2.19.so;55a55c3b
---------- 1 root root 152330 Jul 14 21:00 /lib/ld-2.19.so;55a55c3c
---------- 1 root root 152330 Jul 14 21:00 /lib/ld-2.19.so;55a55c3d
---------- 1 root root 152330 Jul 14 21:00 /lib/ld-2.19.so;55a55c3e
---------- 1 root root 152330 Jul 14 21:00 /lib/ld-2.19.so;55a55c3f
---------- 1 root root 152330 Jul 14 21:00 /lib/ld-2.19.so;55a55c54
---------- 1 root root 152330 Jul 14 21:00 /lib/ld-2.19.so;55a55c55
---------- 1 root root 152330 Jul 14 21:00 /lib/ld-2.19.so;55a55c57
---------- 1 root root 152330 Jul 14 21:03 /lib/ld-2.19.so;55a55cf2
lrwxrwxrwx 1 root root 19 Jul 16 21:24 /lib/ld-linux.so.2 -> ld-2.19.so;55a55c57

all of them have the same content: an md5sum gives:

md5sum /lib/ld-2.19.so
f2fffb2da695a7797454d16952452207 /lib/ld-2.19.so

the creation time (or last touch time) is aproximately consistent with the notorious update I ran (after which I experienced the problem)

Also I now tried to change the soft link to point to this:

rm ld-linux.so.2
ln -s ld-2.19.so ld-linux.so.2

which leads to:

lrwxrwxrwx 1 root root 10 Jul 16 23:18 ld-linux.so.2 -> ld-2.19.so

and after that I run an ldconfig and the soft link changes to:

lrwxrwxrwx 1 root root 19 Jul 16 23:19 ld-linux.so.2 -> ld-2.19.so;55a55c57

**SOLVED:

I now moved away all ld-* to a subdirectory and recreated the softlink as above:
ln -s ld-2.19.so ld-linux.so.2
ran
ldconfig

and now it did not change.
Since that moment all my 32-bit apps are running again !!!

Thanks to all of you helping me.

I am however puzzled what the mechanisms and the reason behind this problem.

**

11

rpm creates such files when updating a package to not overwrite the old files immediately.
After the old files/packages are removed, those new files should get renamed to the final name.
So apparently rpm crashed a few times when updating glibc-32bit, or some other problem prevented it from renaming the files/changing the permissions.

I would suggest you run a filesystem check (from a LiveCD e.g. or add “rd.break” to the boot options to stop the boot before the root filesystem is mounted read-write), this might be caused by filesystem errors.

Then I’d suggest to delete all these files and re-install glibc-32bit.

It should look like this:

wolfi@amiga:~/Desktop> ls -l /lib/ld*
-rwxr-xr-x 1 root root 152330 17. Jun 16:52 /lib/ld-2.19.so
lrwxrwxrwx 1 root root     10 28. Jun 23:16 /lib/ld-linux.so.2 -> ld-2.19.so

Note that your files (ld-2.19.so;55a55c57 in particular, to which your /lib/ld-linux.so.2 points) do not have any read or execute permissions, which probably causes your problem.

the creation time (or last touch time) is aproximately consistent with the notorious update I ran (after which I experienced the problem)

There was nothing wrong with that update, or everybody would experience that.
Btw, the last glibc update was at the end of June…