Under CentOS 7.5, smartctl fails to read SMART data on changed drive behind MegaRAID

[rothmb]

I have two systems in which this is the case. The most recent just showed up today. What I did was this:

1. MegaCli64 commands: a) offline the drive (the hot spare begins rebuild) b) prepare for removal
2. Replace the drive
3. MegaCLI64 command to set the replaced drive as the new hot spare

After this, smartctl -H -d megaraid,<drive> /dev/sda fails, "INQUIRY failed". MegaCli64 reports the drive's perfectly fine, and is a hot spare.

Updated CentOS 7.6.1810, smartctl 6.5, from package smartmontools-6.5-1.el7.x86_64, which is the most current.

[Christian Franke]

Could the previous hot spare be accessed with some smartctl -i -d megaraid,N /dev/sdX?

Could the new hot spare possibly be accessed if a different -d megaraid,N which does not reflect the actual port number is used?

[rothmb]

MegaCli64 sees the drive just fine. There's an easy-to-find script lsi.sh - we have our own version, that front ends MegaCli64, and it shows the replaced drive as a hot spare just fine. smartctl gives up, with the FAILED INQUIRY.

[Christian Franke]

The fact that MegaCli64 sees the drive does not answer the questions from above. MegaCli64 might use a different API than smartctl. MegaCli64 and Megaraid Linux drivers are closed source.

See ticket this comment from ticket #800 for the API used by smartmontools.

Please provide the following information:

• Controller type
• Output of smartctl -r ioctl,2 -d megaraid,N -i /dev/sda for the affected drive N (as an attachment to this ticket).
• Could the other disks be accessed with smartctl?
• In the past, could any hot spare disk be accessed with smartctl?

[Christian Franke]

No feedback from reporter.