Bug 160978 - FC1->FC4 upgrade crashes
FC1->FC4 upgrade crashes
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
Blocks: 135587
  Show dependency treegraph
Reported: 2005-06-19 09:11 EDT by Jan Kratochvil
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-10 16:46:50 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 Jan Kratochvil 2005-06-19 09:11:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Galeon/1.3.21

Description of problem:
Trying to "yum update yum" clean installation of Fedora Core 1 to Fedora Core 4 starts upgrading glibc, yum(8) gets frozen and system is crashed with unusable glibc.

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

How reproducible:
Didn't try

Steps to Reproduce:
1. Installed minimal Fedora Core 1.
2. rpm -U fedora-release-4-2.noarch.rpm
3. yum update yum
4. killall -9 yum
5. rpm --rebuilddb
6. yum update yum

Actual Results:  System frozen and/or crashed. Crashed by:
relocation error: /lib/tls/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference

Expected Results:  glibc+yum upgrade to their Fedora Core 4 versions.

Additional info:

According to my experience it should be workaroundable by FC1->FC3->FC4 upgrade cycle.
FC1->FC{last} I consider useful as FC1 was the last FC providing floppy boot image to bootstrap servers w/o any CD/DVD-ROM (maybe USB boot flash would be also possible).
Comment 1 Jakub Jelinek 2005-06-20 06:14:20 EDT
That would mean some dynamically linked program is started between unpacking
the FC4 glibc and running FC4 glibc's %post, which is something that should not
happen, but it is certainly not under glibc rpm's control.
glibc %post program is statically linked and will wipe up old glibc libraries
from /lib/tls etc. first before running ldconfig (also statically linked)
and other (already dynamically linked) programs.
But if yum starts other programs in between, you are out of luck.
Can you find out which program was the one that triggered the error
(e.g. from update log)?
Comment 2 Jakub Jelinek 2005-07-10 16:46:50 EDT
No feedback.

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