Bug 232904

Summary: anaconda: Dependency Check goes from 0 to 100% instantaneously
Product: [Fedora] Fedora Reporter: Prarit Bhargava <prarit>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: gajownik, hez, redhat-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: ia64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-04-02 15:21:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 150226, 163350    

Description Prarit Bhargava 2007-03-19 13:54:18 UTC
Description of problem:  Anaconda "Dependency Check" does not make progress.


Version-Release number of selected component (if applicable):
anaconda-11.2.0.37-1.ia64.rpm


How reproducible: 100%


Steps to Reproduce:
1. Attempt to install.
2. After selecting packages (ex, only the "Software Development" group) click OK.
3.
  
Actual results:

Dependency Check screen is displayed.  Progress bar does not move -- stays at 0%.

System is responsive, and does not hang.

Expected results:  Dependency check should complete.


Additional info:

Comment 1 Prarit Bhargava 2007-03-19 13:59:44 UTC
It turns out the initial report in this BZ is incorrect -- the dependency check
DOES complete, however the check goes from 0% to 100% instantaneously ...

P.

Comment 2 Chris Lumens 2007-03-19 14:32:19 UTC
This is probably due to Jeremy's new progress bar API or perhaps changes in yum.
 Either way, he seems like the best person to handle this.

Comment 3 Jeremy Katz 2007-03-19 20:24:54 UTC
Yeah, progress isn't working right with the depsolver right now.  And I'm not
100% sure why off-hand.

Comment 4 Julius B. 2007-04-01 12:47:10 UTC
I'm having an similar problem:

The progress bar hangs at 0%, but my PC isn't doing anything (no hdd-working, no
cpu-working, no cd-working...).

The last outputs of my tty:

tty1: No handlers could be found for logger "yum.YumBase"
tty3: 14:20:30 INFO: moving (1) to step postselection
      14:20:30 Info: selected kernel package for kernel
tty4: <7>SELinux: initialized (dev sdc3, type ext3), uses xattr

After 10 to 15 minutes it is still exactly the same.

PS: Using x86, not ia64, so please change "Hardware" to "All".

Comment 5 Jeremy Katz 2007-04-02 15:21:07 UTC
This is fixed in yum CVS

Comment 6 Julius B. 2007-04-02 17:58:01 UTC
Thank you!

But is it possible to get a proper rawhide install at this stage? Using the
daily rescue CD and installing over FTP is one option, but is there a
possibility to patch an existing test 3 CD/DVD or sth. like that?

Comment 7 Leslie Satenstein 2007-04-02 22:45:14 UTC
My annaconda experience is that the time to check dependencies seems to be
proportional to the cube of the number of programs selected.  

With programs from every category selected, on my system (Intel 930 dual core, 1
gig memory) and intel d945gnt motherboard, 250gig hard disk, the check
dependencies operation never finished after one hour or execution. In the past
that operation on the same system, (FC6 version) for the same selection was in
the order of 20 minutes. 

Reducing the number of programs to the minimum, Choosing annaconda defaults, the
check references took about 5 minutes.

Is there optimization to improve the reference checking algorithm?

There is another bug in that grub does not install where it is told to.
If I set my motherboard bios to my first hard drive (/hda), even though I signal
annaconda to install on my second drive, /sda, where the kernel and everything
else installed, grub fails to complete properly. The same is true when I switch
bios settings.   

Currently it is necessary that the hard disk onto which the mbr will be updated
be the default hard disk from which the bios will boot. 



Comment 8 Will Woods 2007-04-03 19:35:33 UTC
*** Bug 235088 has been marked as a duplicate of this bug. ***