disk_smart needs to catch a new unsupported case

[Jeff Lane ]

there are some test results showing disk_smart failing on some disks. The reason seems to be that there's a different output possible in the logs that is not accounted for in the script when looking for errors. So far, I know of two different outputs that signify a storage device does not support SMART:

The following shows a case where SMART is not supported, and the test properly detects this and exits properly, showing a WARNING in the results like such:
disk/smart_sdb certification Pass WARNING SMART not available on /dev/sdb

manson@ubuntu:~$ sudo smartctl -l selftest /dev/sdb
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-23-generic] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

Device does not support Self Test logging

This next example was recently seen on some serves with RAID devices. This is the case that is NOT properly handled and triggers a false failure in the results like such:
disk/smart_sda certification Fail INFO Starting SMART self-test on /dev/sda ERROR Error reported during smartctl test

manson@ubuntu:~$ sudo smartctl -l selftest /dev/sda
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-23-generic] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Self-test Log not supported

The test script keys in on the "START OF READ" line and assumes that means testing is underway...

[Brendan Donegan (brendan-donegan)]

I haven't witnessed this myself, but there's enough evidence gathered here to clearly demonstrate that this is in fact an issue. Also assigning the usual importance for a test failure.

[Sitian Liu (goldensunliu)]

I will also confirm this bug, also getting excatly the same error output.

My disk info is below:
soberpower@ubuntu:~$ sudo smartctl --all /dev/sdb
smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.5.0-17-generic] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Model Family: SandForce Driven SSDs
Device Model: OCZ-AGILITY3
Serial Number: OCZ-8UI588C2Y20841O0
Firmware Version: 2.15
User Capacity: 120,034,123,776 bytes [120 GB]
Sector Size: 512 bytes logical/physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: ACS-2 revision 3
Local Time is: Mon Jan 28 23:19:42 2013 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

[Daniel Manrique (roadmr)]

I'll set to Triaged since the work to be done here is clear (make the script handle the second case input which indicates smart is not supported).

[Rod Smith (rodsmith)]

I'm not sure if this bug report is valid any more. If I'm correctly interpreting your original description, Jeff, the test was looking for a line that included the string "START OF READ". That line wasn't always present, so the test was failing. The current disk_smart script doesn't include any code that looks for such a line, though. When I got it, the code was looking for "SMART support is: Available" and "SMART support is: Enabled" in specific lines near the end of the output. One of my changes (in https://code.launchpad.net/~rodsmith/checkbox/smart-detection) was to generalize this because I found some disks that added an extra blank line at the end of the output, which resulted in failure to find the strings that were actually present, just at the wrong place. My latest patch now searches for those strings (or their component substrings; there's some variability in the number of spaces, too!) anywhere in the "smartctl -i" output.

If I'm right, then this bug can be closed out, since it was probably fixed in some previous revision, or maybe it's actually a duplicate of the bug I've filed and fixed. If you know what machine produced that buggy behavior, though, it would be best to check the latest version of the script on it.