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.)
Created attachment 35642 [details] Error dump from anaconda
At any point during the install, did you go to VC2 and look in the /mnt/sysimage directory?
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.
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.?)
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.
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.
Created attachment 37001 [details] anaconda dump for different hardware
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?
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?
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.)
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.)
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.washington.edu until I get this thing resolved.
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
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?
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'