Bug 131822 - Most shared libraries are being reported as not an ELF file
Most shared libraries are being reported as not an ELF file
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-09-05 08:23 EDT by Ernesto
Modified: 2015-01-04 17:09 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-20 15:32:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ernesto 2004-09-05 08:23:25 EDT
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):

How reproducible:

Steps to Reproduce:
1. Update from latest Rawhide tree (Sept. 4, 2004)
Actual results:

After the rawhide update yesterday, I used my system for about an hour
or two.
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
__librt_multiple_threads, \  
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, oops:

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
fresh install?

Expected results:

Additional info:

I have a DELL precision M60 laptop.

I am not sure if this is a kernel problem or
a glibc problem
Comment 1 Stephen Tweedie 2004-09-06 10:17:23 EDT
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.
Comment 2 Ernesto 2004-09-07 07:00:04 EDT
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.
Comment 3 Ernesto 2004-09-07 07:10:30 EDT
My mistake!!
I actually never ran the 538 kernel.
I went from 533 to 541 only.
So, maybe there is some problem in the 541 kernel?

Comment 4 Stephen Tweedie 2004-09-07 07:18:55 EDT
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.
Comment 5 Ernesto 2004-09-08 00:49:26 EDT
Yes, I have already run fsck.

Note You need to log in before you can comment on or make changes to this bug.