Bug 690323 - "yum upgrade" hangs on glibc-common on fresh Fedora 15 alpha install
Summary: "yum upgrade" hangs on glibc-common on fresh Fedora 15 alpha install
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 15
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Andreas Schwab
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-23 22:25 UTC by tfox
Modified: 2016-11-24 12:44 UTC (History)
9 users (show)

Fixed In Version: glibc-2.13.90-8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-28 06:12:55 UTC


Attachments (Terms of Use)
yum.log after "yum upgrade" hang (828 bytes, application/octet-stream)
2011-03-23 22:25 UTC, tfox
no flags Details
Full "yum check" output (1.41 KB, text/plain)
2011-03-23 22:27 UTC, tfox
no flags Details

Description tfox 2011-03-23 22:25:44 UTC
Created attachment 487155 [details]
yum.log after "yum upgrade" hang

Description of problem:
"yum upgrade" hangs on glibc-common on fresh Fedora 15 alpha install

Version-Release number of selected component (if applicable):
    yum-3.2.29-4.fc15.noarch

How reproducible:
100%

Steps to Reproduce:
1. Do a fresh install of Fedora 15 x86_64 alpha (install DVD)
2. yum upgrade
  
Actual results:
Yum hangs when updating glibc-common-2.13.90-7.x86_64.

Expected results:
Yum completes the upgrade successfully.

Additional info:
I installed Fedora 15 alpha the day it was released.  Mostly daily "yum upgrade"s worked fine (sometimes with --skip-broken).  The yum upgrade on March 22 (yesterday) hung at glibc-common-2.13.90-7.x86_64.  Same thing today.  I have repeated this a number of times including twice from a fresh install running yum from the console (ie, no Gnome).

yum upgrade with "-e 10 -d 10" shows nothing interesting.  There are "Adding Package" messages up til "Running Transaction" after which there are no messages other than the normal Updating/Installing messages.  yum.log just contains one entry for each of the packages updated or installed to that point.  There is no entry for glibc-common.

After 1 hour, I ctrl-C'ed yum.  It says:
    Non-fatal POSTIN scriptlet failure in rpm package glibc-common-2.13.90-7.x86_64

Related "yum check" output is (will attach the full output):
    glibc-common-2.13.90-7.x86_64 is a duplicate with glibc-common-2.13.90-3.x86_64
    glibc-common-2.13.90-7.x86_64 has missing requires of glibc = ('0', '2.13.90', '7')

Comment 1 tfox 2011-03-23 22:27:07 UTC
Created attachment 487157 [details]
Full "yum check" output

Comment 2 Panu Matilainen 2011-03-24 10:18:18 UTC
This is a glibc problem, and apparently quite hardware specific: it happens 100% reliably on my system (Intel Core i5-2500K) but I can't reproduce it in a virtual box.

On update to glibc-common-2.13.90-7.x86_64, /usr/sbin/build-locale-archive gets stuck in a busy loop, and if you kill that process this starts happening to many many other commands too, resulting in a very broken system.

Here's what gdb says on the stuck /usr/sbin/build-locale-archive process during update:

Attaching to process 5395
Reading symbols from /usr/sbin/build-locale-archive...Reading symbols from /usr/lib/debug/usr/sbin/build-locale-archive.debug...done.
done.
0x000000000044293a in intel_check_word (name=194, value=29360191, 
    has_level_2=0x7fff4622433f, no_level_2_or_3=0x7fff4622433e)
    at ../sysdeps/x86_64/cacheinfo.c:196
196		      asm volatile ("xchgl %%ebx, %1; cpuid; xchgl %%ebx, %1"
(gdb) bt
#0  0x000000000044293a in intel_check_word (name=194, value=29360191, 
    has_level_2=0x7fff4622433f, no_level_2_or_3=0x7fff4622433e)
    at ../sysdeps/x86_64/cacheinfo.c:196
#1  0x0000000000442b21 in handle_intel (name=194, maxidx=<optimized out>)
    at ../sysdeps/x86_64/cacheinfo.c:338
#2  0x00000000004011b1 in init_cacheinfo ()
    at ../sysdeps/x86_64/cacheinfo.c:570
#3  0x0000000000408767 in __libc_csu_init (argc=1, argv=0x7fff46224498, 
    envp=0x7fff462244a8) at elf-init.c:141
#4  0x0000000000407ff8 in __libc_start_main (main=0x400cda <main>, argc=1, 
    ubp_av=0x7fff46224498, init=0x4086f0 <__libc_csu_init>, 
    fini=0x408780 <__libc_csu_fini>, rtld_fini=0, stack_end=0x7fff46224488)
    at libc-start.c:185
#5  0x0000000000401401 in _start ()
(gdb) 

No idea what it's really doing there, but quite obviously something Intel-specific.

Comment 3 Panu Matilainen 2011-03-24 11:46:48 UTC
The endless loop has been noticed (and supposedly also fixed) at upstream too: http://sourceware.org/bugzilla/show_bug.cgi?id=12587

Comment 4 Fedora Update System 2011-03-24 14:59:29 UTC
glibc-2.13.90-8 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/glibc-2.13.90-8

Comment 5 tfox 2011-03-24 21:00:17 UTC
My failure is also with Intel Core i5-2500K (on Intel DH67GD motherboard).

I couldn't imagine hardware being part of this.  I should have added that to the initial report.

Comment 6 Andrew Gormanly 2011-03-24 23:01:57 UTC
A "me too" on Intel DH67GD board and Core i5 2500K, exactly the same symptoms, only resolvable by booting from CD and "rpm -r" downgrading.

Comment 7 Fedora Update System 2011-03-28 06:12:43 UTC
glibc-2.13.90-8 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 tfox 2011-03-28 18:22:29 UTC
"yum upgrade" now completes for me with glibc-2.13.90-8


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