Red Hat Bugzilla – Bug 59572
"finding packages to upgrade" takes forever
Last modified: 2007-04-18 12:40:14 EDT
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 ;-)
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.
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
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.
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).
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.
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 ;-)
Deferring to future release.
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.
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.
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)
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.
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.