media-libs/mesa: getting broken so libraries

[osti]

On a particular amd64-system, I am failing to emerge media-libs/mesa, both in currently stable 17.0.6 and in latest ~amd64 17.3.0_rc5. Certain so-files are corrupted and contain only ZEROs:

Code: Select all

>>> media-libs/mesa-17.3.0_rc5 merged.
>>> Regenerating /etc/ld.so.cache...
/sbin/ldconfig: /usr/lib64/libGL.so.1.2.0 is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libGL.so.1 is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libglapi.so.0.0.0 is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libEGL.so.1 is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libEGL.so is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libglapi.so.0 is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libGL.so is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libEGL.so.1.0.0 is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libglapi.so is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib32/libEGL.so.1.0.0 is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib32/libEGL.so.1 is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib32/libEGL.so is not an ELF file - it has the wrong magic bytes at the start.


m4600 ~ # file /usr/lib64/libGL.so.1.2.0
/usr/lib64/libGL.so.1.2.0: data
m4600 ~ # hexdump /usr/lib64/libGL.so.1.2.0
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0072230 0000 0000 0000 0000                    
0072238

The emerge itself (~30 minutes) seems fine. Due to these broken libs, other packages fail to emerge / start.

Any advise how I could continue to find the problem?

[albright]

FWIW, I have the same hexdump and my system is working fine

scratch the above ... not awake yet

[krinn]

FWIW, I have the same hexdump and my system is working fine

Well, i think it add another mystery to his mystery
- Why you end up with zeroed file
- Why albright system is working with such a file

Code: Select all

file /usr/lib64/libGL.so.1.2.0 
/usr/lib64/libGL.so.1.2.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

[osti]

Although I have no idea why, but after certain iterations of
- removing the bad files,
- emerging mesa in different version,
now I got the (currently stable) 17.0.6 to work.

It might be some hardware problem; also the file /etc/conf.d/nfs got zeroed. So far I did not see this for the other many packages I emerged on my big update day.

Edit: After emerging evince, it continues:

Code: Select all

>>> app-text/evince-3.22.1-r1 merged.
>>> Regenerating /etc/ld.so.cache...
/sbin/ldconfig: /usr/lib64/libevview3.so.3 is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libevdocument3.so is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libevview3.so is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libevview3.so.3.0.0 is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libevdocument3.so.4 is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig: /usr/lib64/libevdocument3.so.4.0.0 is not an ELF file - it has the wrong magic bytes at the start.

I might take this to a vote:
[ ] reinstall everything
[ ] trying to re-build within the broken system

memcheck will be run for several hours now...

[krinn]

what fs are you using for /?

[osti]

In order to further complicate matters :)

zfs on luks

No related error messages in /var/log/messages / dmesg, and zfs scrub does not complain.

[krinn]

In order to further complicate matters

Ok i could cast my vote:
- reinstall but with a rock solid fs

[osti]

- reinstall but with a rock solid fs :)

Well, I will first try with fresh install on pure zfs w/o luks.

I created (= am debugging) an installation script, so let's see what happens.