Red Hat Bugzilla – Bug 125136
anaconda crashes w/ invalid operand
Last modified: 2015-01-04 17:06:43 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Galeon/1.3.11a Description of problem: I am doing a new install on an old machine (Intel 440LX chipset, dual PII-300). Anaconda exits abnormally and does not ask to save an anacdump.txt file. This follows immediately after a kernel-issued error (see attachment). It happens consistently after filesystems are made and before the first package is loaded. Switching to the shell prompt, I can navigate around and save /tmp/syslog and friends, but if I ls the mounted partitions, the ls never returns. I can still switch screens, so I assume the ls is in diskwait. However, if I boot into rescue mode, I can make filesystems on the partitions, mount them, and list them without trouble. I make those filesystems with mke2fs -j -v /dev/hda1 mke2fs -j -v /dev/hda2 The problem happens consistently for the installaton type I am using: The FTP install (from rescue CD, to a site serving the contents of the FC2 DVD) errors out *right* after the mkfs. This is what the attachment refers to. The CD install errors out a short time later, after filesystems are made and one or two other progress bars complete, but before the actual package loading. I tried the FTP install about half a dozen times with identical results. I tried the CDs only once. The disk passes badblocks -c 65536 -w /dev/hda The disk held an FC1 installation before. All media pass muster. Memory passes (at least) 15 minutes of memtest86+. The CDs installed an even older uniprocessor PII-266 machine previously with an "everything" install. Version-Release number of selected component (if applicable): FC2 Anaconda How reproducible: Always Steps to Reproduce: 1.See above 2. 3. Actual Results: See above Expected Results: Clean install. Additional info: --jh--
Created attachment 100809 [details] logs, etc., from /tmp
An FC1 CD install succeeds. When doing an FC2 CD install, it fails right after putting up the first RPM install screen, after "Preparing to install..." Screen switching is still possible with control-alt-F#. The shell prompt exists but does not respond. I tried this three times and it was consistent (I didn't check the shell status the first of those three times). When doing an FC2 FTP install from the rescue CD, it fails a little earlier, just before the in the pause just before the "Formatting /boot filesystem..." status bar reaches the right end. Screen switching is still possible with control-alt-F#. I still have a shell. In that shell, commands that do not access /dev/hda work, those that do never return or print anything, but the keyboard and Ctrl-Alt-F# screen switching still work. For example, df works, but ls /mnt/sysimage goes into the diskwait-like state (which I'll call diskwait below). works: df fdisk -l /dev/hda dd if=/dev/hda of=/dev/null bs=10240 count=1 dd if=/dev/hda of=/dev/null bs=10240k count=1 dd if=/dev/hda of=/dev/null bs=10240k (I quit after ~1900 of ~2500 blocks) dd if=/dev/zero of=/dev/hda bs=10240 count=1 dd if=/dev/zero of=/dev/hda bs=10240k count=1 dd if=/dev/zero of=/dev/hda bs=10240k count=100 (I quit after 74 of 100 blocks) fails: fdisk /dev/hda (interaction works, but it diskwaits on write) badblocks -c 65536 -w /dev/hda (diskwaits, later the partition table is found intact, so it didn't write much) ls /mnt/sysimage (diskwaits) Previously, I reported that badblocks -c 65536 -w /dev/hda worked. It didn't, but it didn't report any bad blocks. I had assumed that after an hour or so of run with no bad blocks reported, it had checked the top quarter of the disk, more than enough to cover / and /boot. In fact it had diskwaited. Note that if I boot into the FC2 rescue mode, fdisk (including write), mke2fs, mount, and ls all work on the disk. The diskwait failures all happen after the kernel error is reported. --jh--
If I install FC1 from the CD and then try to upgrade to FC2, it gets the same error when the upgrade is reading package headers, or immediately after that. --jh--
One more failed test. I tried it on a different disk. The first was an IBM 25GB disk. The new one is a Maxtor 160GB. Same problem. Since it works on FC1 and fails on FC2, and since hardware parts are working fine under FC1 and pass the tests I can throw at them, I think this is a real kernel bug. Perhaps it has to do with the IDE driver for the aging chipset. Folks, I'm out of ideas. I'm willing to try more things if someone tells me what else to try. Otherwise, I guess I'm stuck running FC1 on this machine. --jh--
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.