Red Hat Bugzilla – Bug 44277
(IDE)System lock up and corrupts hard drive while mounting CD
Last modified: 2008-08-01 12:22:51 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
Description of problem:
Please refer to bug 38654 for possible related issue.
After setting ide=nodma on the linux install. A subsequent reboot and
attempted mounting of a CD, the machine locks up. During the subsequent
reboot, fsck finds many errors like some number is 64 should be 8, inode
this, inode that. It eventually dumps me to a forced maintenance mode. I
then run fsck manually on /hda but that usually fails. I then eventually
have to run fsck on the hda6 partition. After several more reboots it
eventually comes back to life. I am willing to live with the fact that
the CDROM may not be the best quality and I could get a new one but it
seems a little extreme that the simple attempt to mount a CD would corrupt
the hard drive.
Steps to Reproduce:
Expected Results: the cd should have been mounted
Definitely not a mount issue, assigning to kernel
If you need "ide=nodma" during install, you might also need it during normal
use. I've seen a "bad" cdromdrive totally lock up the IDE bus, and as
a result the kernel was unable to write back pending data to the harddisk.
What model cdrom-drive is this ?
(type "cat /proc/ide/*/model" to get a list)
output from /proc/ide/hdc/model
I dont remember what brand it was that I bought but I dont think it was
a 'name' brand.
I can accept that this isnt an 'authorized', supported model, but can you
recommend the fastest CD burner that RedHat supports, or for instance which one
that you use and have good results with?
I had a similar(?) problem using RedHat 7.1 and the following drive
$ cat /proc/ide/*/model
CRD-8482B (no problem CDROM drive)
IOMEGA ZIP 250 ATAPI (no problem zip drive)
_NEC CD-RW NR-7800A (problem CDRW drive; use can corrupt /dev/hda7 hard drive)
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda7 36G 2.3G 32G 7% /
/dev/hda2 15M 3.5M 10M 24% /boot
/dev/hda5 14G 939M 12G 7% /windata
/dev/hda1 4.9G 2.7G 2.1G 55% /winme
/dev/hdc4 239M 175M 63M 74% /mnt/zip0
/dev/hdb 638M 638M 0 100% /mnt/cdrom0
/dev/scd0 641M 642M 0 100% /mnt/cdrom1
I had the CRD-8482B CDROM and IOMEGA ZIP 250 ATAPI drive attached for about a
month with no problems. Then, I attached the NEC CDRW drive, restarted Linux and
noted that it had detected and mounted the drive as /dev/hdd. Dell told me this
was a very recent model CDRW drive. I planned to follow the HOWTO on simulating
a SCSI device modifying lilo.conf, etc. in order to permit use of the new drive
as a CDRW later; but for a few days kept using it as an ATAPI CDROM. Apparently,
over that period of about a week, use of the new drive under WindozeMe was
successful; both as a CDROM & CDRW. But, either as a result of those few
WindozeMe tests I ran, or as a result of daily use as an audio CD & a CDROM
under Linux, I began to accumulate some kind of file corruption problems.
The problems first manifested themselves to me when I started up Sawfish after
logging in. Although this problem did not happen the first time; after a while,
Sawfish always crashed. Eventually I had to run KDE or twm in order to use the X
gui. As root, I removed and replaced the Sawfish package several times; but each
time I'd restart (init 5), I'd get the file corruption problem again and usually
it stopped Sawfish. Removing the old package became increasingly difficult too,
as bizzare and "illegal" file permissions and sizes seemed to prevent many file
utilities (rm, ls, rmdir, mv, cp, gmc, [and kde's gui too]) from working.
Eventually, a restart one morning required a single user mode use of fsck to get
the system in some kind of semi-functional order. The command, "rpm -Va" would
show more and more packages being corrupted, which I kept replacing. Finally,
even the /bin/rpm command was corrupted. So, I saved all personal (some of the
files under /home) and ISP-connection configuration information from the "/"
drive to "/windata" and "/mnt/zip0" and reinstalled RedHat 7.1.
I should not that I was pleasantly surprised to note that after a fairly close
inspection of some 1300+ personal files on /home that none of them seems to have
The re-installation detected my CDRW drive and set up the scsi emulation for me.
I don't know if that fixed the problem or hid it; but for over a week now I have
had no file corruption problems. Since I have the machine "up" over 12 hours a
day, 6 or 7 days a week and I am often moving and creating files while the "rpm
-Va" output was not showing any surprises, I felt all was well.
I am certain that files in /bin or /usr/bin or /sbin were not corrupted, until
after the first few days. When that did start to happen the corrupted commands
were not (as I understand) the sort a hacker usually tinkers with via a root
kit. Files like rpm and zcat were some of the corrupted files, and the type of
corruption usually just made them impossible to execute or sometimes even to
stat. This (to me) suggests I was not a victim of a hacking break in, though I
am connected to the network at least 8 of those 12 hours. Since I was a breakin
victim using RH 6.2 a few months ago I take many precautions to watch things,
running trafshow in a window I keep an eye on, etc. and never leave the keyboard
for even a few minutes without breaking the network connection. The tech support
staff at RedHat also helped rule out this cause as well as memory problems
(using memtest86). Anyway, in the near future (now that things are stable) I
plan to be setting up snort.
Please let me know if I can provide any other information that might be helpful.
Since the problem "went away" for me there is no urgency in obtaining a
solution; but I'd hate to have others go through what I went through.
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/