Bug 131822

Summary:	Most shared libraries are being reported as not an ELF file
Product:	[Fedora] Fedora	Reporter:	Ernesto <ernesto>
Component:	kernel	Assignee:	Dave Jones <davej>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	3	CC:	ernesto, pfrields, sct, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-11-20 20:32:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.