From Bugzilla Helper: User-Agent: Mozilla/4.79 [en] (Win98; U) Description of problem: Upgrading existing 7.2 system (AMD K5-2, 500 MHZ, 294MB MEM, Root on raid 1- 15gb. Downloaded ISO from Red Hat, checked ISO with md5sum---all good. Ran "linux mediacheck" all pass. Had earlier identical problem, researched Bugzilla, downloaded "73raid.img." Installed proceded, got to screen after find all packages to upgrade. When if finally got to screen that said, "About to upgrade," hit "Next" buttom. After a few moments, exception occured. Saved dump info to floppy. CDs would not automatically boot, had to use install floppy. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. First 7.3 cd in cdrom drive, booted from floppy created from 7.3 boot.img. 2. At text menu screen, entered "linux updates" and hit enter 3. followed instructions, and inserted disk created from 73raid.img. Acaconda began as usual. Detected MD0 and I indicated that root was on md0. Went through upgrade files scan (took long time.) Finally screen appeared sawying beyond this point it would begin to write to disk. Hit "next" button, and after a moment exception occured. Actual Results: Exception occured Expected Results: Would begin to copy upgrade files from CDROM to disks Additional info: This is a home-built server for small ISP for a number of churches and theif members. It contains web, pop3 and sendmail for the use of the member churches. It has been in operation since RH Linux 6.2 being upgraded with each version. Current version is 7.3 with all current errata applied. Since Limbo has been release, I want to upgrade to 7.3. I normally stay one release behind. This bug prevents be from upgrading to 7.3 from 7.2.
Created attachment 70965 [details] Ananconda dump file created when exception occurred.
Typoed the CPU type. It's an AMD K6-2 (i586) not a K5-2.
Its a bad CD or drive: <4>end_request: I/O error, dev 16:40 (hdd), sector 1114040 <4>hdd: tray open During the install the drive is accessed differently (more random seeks) and this seems to expose problems that a checksum test (which is sequentially reading the disc) doesn't.