Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.4.2-ac28 i686) I tried to upgrade RH7.0 -> RH7.1 on (1) an athlon system (2) a Dell inspiron 4000. Both were running RH 7.0 with recent upgrades of gcc and glibc. I had also upgraded rpm to 4.0.2-7x. The upgrade looked like it succeeded because both systems booted fine into 7.1. However on my athlon system, rpm crashed when doing 'rpm -e ...' (unfortunately I can't remember what package ... was). This made me think that other things may have been flaky too. On my Dell laptop, things were OK until I tried to run StarOffice on a large document and the kernel started paging (the laptop has 128 Meg of memory). X would immediately crash and I had to restart it. On both systems, I tarred and saved /home then did a workstation install on the athlon, and a laptop install on the laptop. Both went flawlessly. I suspect that whatever version of RPM I had prior to trying to upgrade was more than the installer could handle. Reproducible: Didn't try Steps to Reproduce: 1. Pretty much impossible because I didn't save the entire /usr directory prior to trying the upgrade. Of course I could have tried to re-upgrade but that seemed less likely to succeed. 2. As indicated above I did a clean install on both machines. 3. Actual Results: Everything is fine now, but I just think you should do something about the 'upgrade' option. Expected Results: The upgrade should have given me the stability I am enjoying now instead of the flakiness I observed (rpm crashing, X crashing) These are packages I KNOW I had installed on my 2 RH 7.0 systems before trying the upgrade to RH7.1: rpm-4.0.2-7x.i386.rpm rpm-devel-4.0.2-7x.i386.rpm rpm-build-4.0.2-7x.i386.rpm rpm-python-4.0.2-7x.i386.rpm popt-1.6.2-7x.i386.rpm cpp-2.96-69.i386.rpm gcc-2.96-69.i386.rpm gcc-c++-2.96-69.i386.rpm libstdc++-2.96-69.i386.rpm glibc-2.2-12.i386.rpm glibc-common-2.2-12.i386.rpm glibc-devel-2.2-12.i386.rpm glibc-profile-2.2-12.i386.rpm nscd-2.2-12.i386.rpm db3-devel-3.1.14-6.i386.rpm db3-devel-3.1.17-5.i386.rpm db3-utils-3.1.17-5.i386.rpm I had also done a "Make World" of XFree86 4.0.2 but had NOT installed it. Finally, I had done smaller upgrades to vim (vim-enhanced-5.7-8.i386.rpm) but I can't imagine that being the problem.
My 7.1 upgrade experience was similarly problematic, and ultimately required a clean 7.1 install due to a plethora of more recent Gnome content in my 7.0 install. I beefed my 7.0 Gnome setup w/ Helix Gnome, and I've recently been keeping up to date on the Gnome 1.4 beta w/ Red Carpet. After the 7.1 upgrade I experienced serious problems w/ SB16 support (see bug 35052) and general flakiness w/ Gnome - sluggishness, crashing, problems w/ Sawfish becoming deselected, trashing my desktop settings at random, etc. When I started rooting through gnorpm, I realized that there were multiple X/Gnome libraries and desktop files - some of which were holdovers from my Helix install, and some were from the new 7.1 install. I removed all the Helix stuff I could find, but the X/Gnome stability continued to deteriorate. At one point, I had 3 instances of Sawfish starting up when logging in to Gnome. Weird! I decided to bite the bullet w/ a fresh install. Things were markedly improved as root, and got a little weird once I tried using the contents of a personal account I'd backed up. Ultimately, I ended up blowing away all Gnome and Sawfish related init files in that account, kickstarted X, and things were good. Not the painless upgrade I'd hoped for, but I got there. On the bright side, 7.1 along w/ 2.4 made short work of that reinstall. Devices I've typically had to fidget w/ to make work all ran out of the box. Excellent! My recently trashed 3dfx drivers also seem to be showing signs of life under 7.1, although they need a little tweaking. The only outstanding issue remains a complete lack of sound support - per bug 35052. The short of it all? Be cautious doing a 7.1 upgrade from 7.0 w/ any recent Gnome updates. (Ximian, Helix, or otherwise) The resulting Gnome halfbreed will be ill-behaved at best.
The second bug is unreleated to the first and sounds like a packaging problem with Gnome. Please file a separate bug report under Gnome. As for the first report, let me understand...the upgrade succeeded and then RPM behaved strangely? If so, then this is an RPM problem and the component should be changed. If the installer hung, crashed, or behaved strangely during the installation process, then it's an installer problem. I just want to make sure we're looking for the problem in the right piece of software.
On the athlon box, yes, the upgrade looked like it worked fine, but RPM acted strangely. No flakiness at all during install, except that I was a little puzzled because I didn't see the message (which I had seen on yet another machine with a clean 7.1 install) saying "creating swap file". I say this is puzzling because that athlon box has 768 Meg of RAM but the swap partition only had the RH7.0 standard (70 Meg I believe). As precisely as I recall, after the (apparently successful) upgrade to 7.1 I logged in as root and tried removing Mesa-related packages in preparation for installing the latest NVIDIA drivers (I have a GForce graphics card). That's when I saw rpm crashing. Not just saying 'unresolved this and that' nor 'this package is not installed'; just "segmentation violation". Since I was a little perplexed by the swap business and I had a (perhaps ill-advised, but that's the way I am) desire to size the swap partition correctly for the 2.4 kernel instead of relying on a swap file, I didn't pursue the matter too far before deciding that a clean install would be a good idea. (Things work A-OK now, by the way, I have a 1.5G swap partition and enjoy fabulous Quake playing.)
It looks like this might not be an anaconda problem. Jeff, does this look like an RPM problem?
This smells more like an athlon than a rpm problem. You might want to try rpm packages from ftp://ftp.rpm.org/pub/rpm/test-4.0.3 I believe that there is better athlon detetction in those packages.