Bug 131822 - Most shared libraries are being reported as not an ELF file
Summary: Most shared libraries are being reported as not an ELF file
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-05 12:23 UTC by Ernesto
Modified: 2015-01-04 22:09 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-11-20 20:32:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ernesto 2004-09-05 12:23:25 UTC
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
corrupt.


Version-Release number of selected component (if applicable):
kernel-2.6.8-1.541


How reproducible:
Very


Steps to Reproduce:
1. Update from latest Rawhide tree (Sept. 4, 2004)
2. 
3.
  
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
reference.
========================================================


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 14:17:23 UTC
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 11:00:04 UTC
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 11:10:30 UTC
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 11:18:55 UTC
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 04:49:26 UTC
Yes, I have already run fsck.



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