Red Hat Bugzilla – Bug 155306
feature: add SMART HDD check to installation routine
Last modified: 2007-11-30 17:11:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0.2
Description of problem:
If anaconda would use smartctl to check a HDD for errors before installation proceeds, this would save some people some grief.
(On the other hand, I'm glad Fedora runs smartd by default!)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Fedora on bad hard drive.
Actual Results: I was disappointed I wasted time installing Fedora on a hard drive that was failing.
Expected Results: Anaconda could have used smartctl to check the drive's status. It would have discovered several "pre-fail" and "old age" flags.
After I installed and then rebooted, I got an email from smartd about these errors:
Device: /dev/hda, 54 Currently unreadable (pending) sectors
Device: /dev/hda, 34 Offline uncorrectable sectors
smartctl -H /dev/hda reported PASS, although smartctl -a /dev/hda reported several "pre-fail" warnings.
it reported PASS because it did pass. your drive has uncorrectable errors which
can be remapped, though it's a bit involved. it would only FAIL if the drive
wasn't able to remap them or had some other problem. 
 http://smartmontools.sourceforge.net/ see "My ATA drive is failing its
self-tests, but its SMART health status is 'PASS'. What's going on?"
I like this suggestion for anaconda. I plan to work on this post-FC5 since to
do it correctly, I don't really have enough time to get it done for FC5.
smartmontools consists of userspace tools and to do this correctly, I'd prefer a
library with Python bindings. Still, it's a cool idea and expect to see some
activity on this in rawhide after FC5.
are there any known buggy disks/IDE controllers which would cause problems for
Absolutely, which is why work for this needs to begin in smartmontools. I
haven't sat down to look at the smartmontools code closely, but I know that a
lot of controllers provide issues as well as certain manufacturers'
implementations of SMART. Their FAQ mentions the well-known problem disks and
so installing and running smartmon by default as it is done in FC right now is
not wise? a RFE should be opened to request smartmon NOT be installed and
enabled by default... at least until smartmontools are fixed
I don't think I explained that correctly. smartmontools works well and handles
a wide range of disks and controllers. It knows about a lot of manufacturer
specifics. What I was trying to point out is that we simply can't rely on a
pass/fail test for anaconda. We'll probably have to look at a variety of SMART
data fields and decide from there.
So this isn't that smartmontools is bad, it's interpreting the information it
gives you in the report(s) programatically that's more difficult.
I don't think this is a feature we can realistically add to the installation
process. We already have enough mechanisms that point out bad hardware in log