Bug 124595

I forgot the part about the unable to register SCSI device /dev/sda in
the /var/log/messages file.

Hi Jason,

In what you wrote, the word 'hides' is very relevant.

I'm 99% sure that the problem is that the Megaraid RAID driver does
not allow a user-level application such as smartd or smartctl to talk
directly to the physical disk drives.  Currently the only supported
RAID hardware controller is made by 3ware, because the 3ware driver
DOES allow SMART commands to be passed directly to the disks.

If you have two physical drives, then the only way that smartmontools
might have a chance to talk with them is if there are two
corresponding device entires (eg, /dev/sda and /dev/sdb) which can be
directly accessed.  Is this the case?

It would be helful if you could add a couple of attachments. One for
the output(s) of smartctl -a /dev/sd? and the other for the syslog
messages left behind when smartd tries to start, and fails.

Thanks for checking the other bug reports.  This is not a duplicate of
bug 121872.  There the user had /dev/hda rather than /dev/sda.

Bruce

There are two physical drives, but only one entry, /dev/sda.  I have
attached the output from smartctl and the syslog

Jason

Created attachment 100741 [details]
smartctl output

Created attachment 100742 [details]
syslog output

Jason, thank you.  These logs confirm that the Megaraid driver does
not give you access to the raw disks -- hence smartctl/smartd can't
talk with them.

Looking for two minutes at the source code megaraid.[hc] it appears
that there is a 'pass-thru' ioctl available.  So if someone (you!)
wanted this badly enough you could add another device type
'-d megaraid' to smartmontools which utilized this passthru ioctl.
But until that's done, smartmontools has no way to talk with the
individual disks.

Cheers,
  Bruce

I wish I had that kind of talent.  I am a network administrator.  If I
ever get some free time I might take a look, but I do not know where
to begin.  Is there some documentation or advice on how to proceed?

My advice: since you are at Perdue, hire a physics, math or computer
science student who does linux/kernel hacking.  Tell them to download
the smartmontools source and look at escalade_command_interface() in
os_linux.c.  If they can figure out how to access data from the
megaraid controller, they probably need to add between 50 and 150
lines of code to os_linux.c.  If they have a spare system to work on
(no data to damage) they ought to be able to make progress in a day
and have it working in a week.

I am looking for a student to do some coding for this.  What can I 
say things always take 4 times as long to do something for this 
university.  

The question I have is "Why is smartd a part of kernel-utils?"  
Should it not be its own package?

Thanks,

Jason

Please see:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108569
I strongly agree with this.  As the smartmontools maintainer, a big
problem for me is that I frequently get support requests for
smartmontools release 5.21, which is badly out of date (more than a
year old).  I really wish Fedora were distributing an up-to-date version.

Bruce

Hi Bruce,

I sent an email to you last week at ballen.uwm.edu.  I
have finally hired a programmer to write the update.  How can we get
ahold of you to work out the details?

Thanks,

Jason

Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

It still does not work on FC3.  I have been unable to test FC4T2 yet.  I plan on
trying this this week.

I should note that this might be moot since this server uses the older megaraid
driver and not the newer megaraid_mbox driver.

Support for megaraid must be implemented upstream first.