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
*** Bug 481543 has been marked as a duplicate of this bug. ***
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?
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? Thanks, -Eric
Scratch build at http://porkchop.devel.redhat.com/brewroot/scratch/esandeen/task_1663717/ if it helps anyone. :)
Hans, can we test this with updates.img ? Will anaconda pick up the new library or this works only for python files?
(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.
In e2fsprogs-1.35-12.24.el4
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. http://rhn.redhat.com/errata/RHBA-2009-0996.html