Bug 55359 - Installer crashes when upgrading existing system
Installer crashes when upgrading existing system
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Brent Fox
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-30 04:42 EST by Toralf
Modified: 2007-04-18 12:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-21 12:06:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Error dump from anaconda (71.48 KB, text/plain)
2001-10-30 04:43 EST, Toralf
no flags Details
anaconda dump for different hardware (72.45 KB, patch)
2001-11-09 05:39 EST, Toralf
no flags Details | Diff

  None (edit)
Description Toralf 2001-10-30 04:42:16 EST
Description of Problem:
Anaconda exits with unhandled exception when I try to upgrade from Red Hat
7.1 to Red Hat 7.2 via CD install. A dump file will be attached. The
problem occurs for text as well as graphical install, and it may happen
from different packages depending on what is selected.

I suspect that the error occurs when anaconda tries to switch from CD 1 to
CD 2. I'm installing from a Yamaha SCSI CD-RW. I have successfully
installed Red Hat Linux 7.0 and 7.1 via the same unit.

What *really* annoys me about this is not so much that errors occur, but
that I have to restart completely when they do. Why can't the installer
keep the packages that were already upgraded?


How Reproducible:
Every time

Steps to Reproduce:
1. Boot from install CD
2. Start upgrade install


Actual Results:
Installer exits with error message.

Expected Results:
Well, I think you have gathered that already.

Additional Info:
I've now successfully upgraded the host by copying the contents of the
"RedHat" directories on both CDs to the hard drive of a file server, then
running network install (FTP mode.)
Comment 1 Toralf 2001-10-30 04:43:48 EST
Created attachment 35642 [details]
Error dump from anaconda
Comment 2 Brent Fox 2001-10-30 15:35:41 EST
At any point during the install, did you go to VC2 and look in the /mnt/sysimage
directory?
Comment 3 Toralf 2001-11-05 10:57:39 EST
Not during the original install, but I tried switching when I tried again on a
similar setup. I was unsure what to look for, but I did notice that the CDROM
was mounted as /mnt/source, and 'umount /mnt/source' (after the error message
occured) failed with "device busy". I was not able to find out why, as there was
no "fuser" command.

Also, I tried again on a host with an IDE CD-ROM, and got the same problem.
Comment 4 Brent Fox 2001-11-06 17:28:06 EST
I have seen a few bug reports regarding this, but it doesn't seem to be reliably
reproducible.  I have not been able to duplicate it here.  Some process has a
lock on a file and won't let go, which causes unmounting the drive to fail.

But this happens to you everytime?  What kind of install are you doing
(workstation, server, etc.?)
Comment 5 Toralf 2001-11-07 03:27:38 EST
Has happened everytime I've tried so far. I guess I wasn't clear enough on what
I'm trying to do: I'm running "upgrade" install on our existing Red Hat 7.0 or
7.1 systems. I haven't tried complete reinstallation yet.
Comment 6 Brent Fox 2001-11-08 15:30:10 EST
We've done a lot of upgrade testing and haven't been able to reproduce this
behavior.  
I took another look at your attachment, and I came across this message:

<4>probable hardware bug: clock timer configuration lost - probably a VIA686a
motherboard.
<4>probable hardware bug: restoring chip configuration.
<4>probable hardware bug: clock timer configuration lost - probably a VIA686a
motherboard.
<4>probable hardware bug: restoring chip configuration.
<4>probable hardware bug: clock timer configuration lost - probably a VIA686a
motherboard.
<4>probable hardware bug: restoring chip configuration.
<4>probable hardware bug: clock timer configuration lost - probably a VIA686a
motherboard.
<4>probable hardware bug: restoring chip configuration.

This leads me to believe that this is a problem that we aren't going to be able
to fix.
Comment 7 Toralf 2001-11-09 05:39:49 EST
Created attachment 37001 [details]
anaconda dump for different hardware
Comment 8 Toralf 2001-11-09 05:45:07 EST
I tried again on completely different hardware (different mainboard brand, IDE
instaead of SCSI disk, different CD-ROM model) and did not get the error
messages you indicate, but the problem still occured.

Let me stress the point that I'm quite sure this happens as the installer tries
to switch from operating CD 1 to CD 2. This means that the problem occurs only
if the upgrade selection contains packages from CD 2. Are you sure it did when
you tested?
Comment 9 Brent Fox 2001-11-09 15:54:07 EST
Hmm...I have tested many, many full installs (both cd's) and haven't seen this
problem before.  Are you sure that the cd's themselves are good?  Have you
checked the md5sums of the ISOs?  Or are they the retail cds?
Comment 10 Toralf 2001-11-12 05:18:16 EST
But I'm not talking about full installs, I'm talking about upgrading an existing
system (how many times do I have to repeat that?)

I'm using retail CDs. I'm assuming they are all right, as network installation
based on their contents works just fine (but I already said that, too.)
Comment 11 Toralf 2001-11-20 10:46:51 EST
I feel that the discussion has taken a wrong turn here; it has become too
focused on whether or not you can reproduce the problem. I don't really care
about that, as I have a workaround I'm perfectly happy with.

What I do care about, and am not happy with, is the error recovery offered,
especially when upgrading an existing system. I really can't see why it's
necessary to install every package all over again when an upgrade fails half-way
through, and I restart it. Or even worse: Should I have to run 'fsck', update
/etc/fstab etc., before I'm even allowed to try again? (That has happened too,
e.g. when I got ext3 related problems - see Bug 56519.)
Comment 12 Jeff Silverman 2001-12-10 01:10:36 EST
I have the same problem.  This is discussed in the support forum at http://www.redhat.com/WebX?14@159.6BFgaCQURY8^7@.ee78889/1

What would be nice would be if the installer would tell us what file system is dirty and give us a chance to fix the problem and then continue with the 
process.  In general, whenever an error occurs in the installation process, give us a chance to fix it.

At the moment, my sendmail is broken, so I can't receive E-mails here.  Send them to jeffs@rcs.ee.washington.edu until I get this thing resolved.
Comment 13 Owen Jones 2002-01-19 09:35:34 EST
I have experienced a similar failure on an upgrade from RedHat 6.2 to 7.2.  There seems to be a problem in reading the old packages database.

The failure is repeatable: it always fails at exactly the same place, when reading the package information. I have done a full install on 2 other 
systems using the same CD's so the full install works fine, it's just the upgrade that fails.

I'm using pretty standard hardware: a PI PC@133MHz, dual boot with Win98 on /dev/hda and RedHat Linux 6.2 on /dev/hdb. A standard IDE 
CDROM on /dev/hdd. It's worked well for some time now.

I can provide an anaconda text dump from my system if you wish.

                                      Regards, Owen Jones
Comment 14 Brent Fox 2002-01-21 12:06:44 EST
ojones, I think that the RPM database on your 6.2 system is corrupted.  I would
recommend booting into your 6.2 system and running 'rpm --rebuilddb' as root,
then run the upgrade.  Does that help?
Comment 15 Brent Fox 2002-02-06 22:36:39 EST
toralf, I agree that it would be nice for the installer not to have to start
from scratch if an install fails, but unfortunately we don't have a mechanism
for the installer to pick up where a failed install left off.  Technically, it's
possible, but it would require more effort than it's worth.  Marking as 'wontfix'

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