Bug 481466 - [RHEL4.8]: latest e2fsprogs causes install failure
[RHEL4.8]: latest e2fsprogs causes install failure
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: e2fsprogs (Show other bugs)
All Linux
high Severity high
: beta
: ---
Assigned To: Eric Sandeen
Alexander Todorov
: Regression
: 481543 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-01-25 04:05 EST by Hans de Goede
Modified: 2009-05-18 16:25 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-18 16:25:37 EDT
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 Hans de Goede 2009-01-25 04:05:09 EST
Taking this to bugzilla to make sure it does not fall through the cracks.

I hate to be the bearer of bad news, but I tried to do an install with the 
latest RHEL-4 nightly to try and reproduce an anaconda bug, but the installer 
crashed at startup with the following error:
Import error: libuuid.so.1: cannot handle TLS data

Creating an updates.img with the libuuid.so.1 from the e2fsprogs from the 0120 
nightly fixes this, so its most likely an issue with e2fsprogs.

This was an i386 install on a  q8200 (single quad core cpu) machine.

Eric Sandeen wrote:
> Hans de Goede Wrote:
> > Note in the nightly tree's the version jumped from 1.35-12.17.el4 to 
> > 1.35-12.23.el4, the other versions never got in to the nightly's.
> Ah, yes, then I have a better idea what it is.  In fact the
> uuiid changes didn't even  compile before (thanks to a gcc bug) and I
> had to work around it w/ Jakub's help.  Ok, it's less than of a mystery
> now, at least.
> > As for logs, the error I've given you is all I have, I think it is some
> > kind of linker (ld.so) error, and that the TLS refers to /lib/tls/
> thread local storage... it all comes flooding back :)
> Ok, will try to look into this soon.
> Thanks
> -Eric
Comment 1 Hans de Goede 2009-01-26 05:01:13 EST
*** Bug 481543 has been marked as a duplicate of this bug. ***
Comment 4 Eric Sandeen 2009-01-26 11:38:23 EST
This same code is in RHEL5 and seems to work fine; I wonder if this is a bug/limitation of python and/or gcc and/or glibc?
Comment 5 Eric Sandeen 2009-01-26 18:03:25 EST
Ok, I think I have an e2fsprogs rpm which has libuuid in /lib as well as /lib/tls, with the tls bits only in the latter.

If I do a scratch build, how can this be tested?
Comment 6 Eric Sandeen 2009-01-27 00:33:50 EST
Scratch build at http://porkchop.devel.redhat.com/brewroot/scratch/esandeen/task_1663717/ if it helps anyone.  :)
Comment 7 Alexander Todorov 2009-01-27 02:26:57 EST
can we test this with updates.img ? Will anaconda pick up the new library or this works only for python files?
Comment 8 Hans de Goede 2009-01-27 03:21:51 EST
(In reply to comment #7)
> Hans,
> can we test this with updates.img ? Will anaconda pick up the new library or
> this works only for python files?

You can out libraries into updates.img too (don't forget adding the soname symlink too), I've just done that and done an install witht he resulting updates.img on the same system where I originally hit this bug when I reported it, with this updates.img with the libuuid.so.1* from /lib from the scratchbuild in it, the install now works properly. So I can confirm that the scratchbuild fixes this.
Comment 9 Eric Sandeen 2009-01-27 12:19:16 EST
In e2fsprogs-1.35-12.24.el4
Comment 13 errata-xmlrpc 2009-05-18 16:25:37 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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