Red Hat Bugzilla – Bug 131822
Most shared libraries are being reported as not an ELF file
Last modified: 2015-01-04 17:09:28 EST
Description of problem:
All shared libraries have invalid ELF headers.
Any shell commands fail with invalid headers.
Appears that most of the system shared libraries are
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Update from latest Rawhide tree (Sept. 4, 2004)
After the rawhide update yesterday, I used my system for about an hour
The last thing I did was lock the screen.
Now next morning, I launch up2date and get an error:
/usr/lib/rpmio-4.3.so is not an ELF file
I thought maybe this was limited to up2date or rpm, however, it worse.
If I type "ls", I get:
ls: relocation error: /lib/i686/librt.so.1: symbol
version GLIBC_PRIVATE not defined in file libc.so.6 with link time
The next thing I did which was probably a huge mistake!! I ran
ldconfig reports some bad things like so:
ldconfig:/lib/tls/librt.so.1 is not an ELF file - it has the wrong
magic bytes at the start.
The above happens with 541 or 533 kernel.
Has anyone else seen this? Is there a way around this avoiding a
I have a DELL precision M60 laptop.
I am not sure if this is a kernel problem or
a glibc problem
Did you run a 538 kernel at some point? Unfortunately, there was an
ext3 bug in that kernel which could have corrupted some data; there's
no automated way to undo that short of reinstalling the broken files.
You'll need to force a fsck to clean up the fs first.
I was indeed running the 538 kernel at some point.
What I did as a work-around:
-- copy the affected files from an earlier FC3T1 systems.
I did not run an fsck. I will do this as well.
At this point, I am stable again. To be safe, when FC3T2 is released,
I will do a fresh install. Since I don't know what other corrupt
files could be lurking about.
I actually never ran the 538 kernel.
I went from 533 to 541 only.
So, maybe there is some problem in the 541 kernel?
These sorts of problems are much more likely to be caused by the
kernel you were updating _from_ than the one you're updating _to_,
since it's the older kernel which is running when the disk-intensive
rpm updates are going on. So the report here is more likely to be
implicating 533 than 541.
Have you fsck'ed yet? If not, could you capture the output of that so
we can see what's actually wrong with the fs? Thanks.
Yes, I have already run fsck.