Bug 59572 - "finding packages to upgrade" takes forever
"finding packages to upgrade" takes forever
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2002-02-10 14:50 EST by Chris Ricker
Modified: 2007-04-18 12:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-05-25 10:52:53 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 Chris Ricker 2002-02-10 14:50:04 EST
I'm attempting an upgrade from 7.2 to hampton beta1 (text; gui hangs the box). 
When the installer gets to the "Finding packages to upgrade..." it is almost
literally taking forever.  The machine has been on that screen for 10 minutes
and counting so far.  

I'm not sure if this step is just much slower than in the past, or if anaconda
is looping.  ps shows that the process is still running, and disk activity
suggests that the system is doing something....

Okay, after literally 12 minutes of clock time, the system finished this screen.
 This is orders of magnitude longer than it has taken in the past.  If this step
actually needs to take that long, some sort of progress meter is needed to let
end users know something's happening.  Ideally though, this step would occur
much quicker ;-)
Comment 1 Chris Ricker 2002-02-10 14:59:38 EST
There also appears to be no caching.  Moving past this screen, then going back
to force it again, takes just as long the second time.

In both cases, the option to customize packages to be upgraded was selected.
Comment 2 Chris Ricker 2002-02-10 15:26:08 EST
This slowness might be more generic.  The "Preparing to install..." stage is at
15 minutes and counting (though at least it has a progress meter)

All of this is on a K6-III, 531 MHz (according to /proc) with 192 megs RAM and
an additional 256 megs swap
Comment 3 Chris Ricker 2002-02-10 16:18:55 EST
While I'm making speed complaints, upgrade of dev also took over 10 minutes....
 I realize it has to mknod a lot, but that's still insane.
Comment 4 Chris Ricker 2002-03-21 00:40:56 EST
still true with beta3....

I attached a strace (I'm doing an NFS install) to the process when it was taking
10 minutes for the upgrade, but it didn't show anything immediate obvious that
was needing to time out or anything like that (just a whole bunch of pread(),
mremap(), etc., like expected).
Comment 5 Chris Ricker 2002-03-21 00:49:13 EST
The "Preparing to install" phase still takes forever as well.  The majority of
that time seems to be spent endlessly looping through attempts to stat locales
that don't exist:

stat64("/usr/lib/local/ru_RU", 0xbfffe110) = -1 ENOENT


over, and over, and over again....  That seems strange.
Comment 6 Chris Ricker 2002-03-21 00:51:04 EST
my typo.  It actually is trying to stat "/usr/lib/locale/foo" and failing, not
"/usr/lib/local/foo" (which would obviously also fail, if it actually tried it ;-)
Comment 7 Michael Fulbright 2002-03-26 12:30:38 EST
Deferring to future release.
Comment 8 Aleksey Nogin 2002-06-17 23:49:51 EDT
Still there in Milan beta2.

"Finding packages to upgrade" needs:

(a) to be faster, if possible

(b) some progress indicator (as bug 33412 requests) or at least some message
telling that it's *supposed" to take that long.

(c) to go *after* "Click next to begin upgrade" window when the user decided not
to customize the list of packages to upgrade. Currently I have to wait around
several minutes for the "Finding packages to upgrade" phase to complete just so
that I can press the "Next" button. Obviously, I have to wait if I want to
customize the package list, but if I don't, then there is no reason for me to
wait for it.
Comment 9 Jeremy Katz 2003-01-03 02:19:43 EST
It should be faster now that we're not using the old orphan file checking. 
Also, it now occurs later in the process and does do some caching of if it's
been done before for this filesystem.
Comment 10 Chris Ricker 2003-01-03 12:25:30 EST
Is this speedup in beta3, or post-beta3? beta3 didn't seem much / any faster (~
1.5 hours to upgradc a 2 gig 8.0 install to beta3 over 100mbit fd NFS)
Comment 11 Aleksey Nogin 2003-01-06 20:49:08 EST
The "finding packages to upgrade" is indeed quite fast in beta3, but then the
upgrade process itself is quite slow - 1hr 28 min to upgrade 2663Mb in 708
packages from CD on 1.8Gz P-IV. Still, this is a big improvement since now we at
least get a good procress indicator and a semi-reasonable ETA during the upgrade.
Comment 12 Brent Fox 2003-05-25 10:52:53 EDT
I'm going through Bugzilla closing some bugs that have been marked as Modified
for some period of time.  I believe that most of these issues have been fixed,
so I'm resolving these bugs as Rawhide.  If the bug you are seeing still exists,
please reopen this report and mark it as Reopened.

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