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
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.
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?
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.