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