Red Hat Bugzilla – Bug 37285
upgrade causes problems; full install succeeds
Last modified: 2007-04-18 12:32:48 EDT
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.
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:
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
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
beta w/ Red Carpet.
After the 7.1 upgrade I experienced serious problems w/ SB16 support (see bug
general flakiness w/ Gnome - sluggishness, crashing, problems w/ Sawfish
deselected, trashing my desktop settings at random, etc. When I started rooting
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
removed all the Helix stuff I could find, but the X/Gnome stability continued to
At one point, I had 3 instances of Sawfish starting up when logging in to
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
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
I believe that there is better athlon detetction in