Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 232904 - anaconda: Dependency Check goes from 0 to 100% instantaneously
Summary: anaconda: Dependency Check goes from 0 to 100% instantaneously
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: ia64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
URL:
Whiteboard:
: 235088 (view as bug list)
Depends On:
Blocks: FC7Blocker fedora-ia64
TreeView+ depends on / blocked
 
Reported: 2007-03-19 13:54 UTC by Prarit Bhargava
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-04-02 15:21:07 UTC


Attachments (Terms of Use)

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. ***


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