For some time now I have noticed that my Smart Drive Check does not display the drive after a kernel update and a reboot, but displays as ‘other’ instead of ‘sda’ or ‘sdb’.
I have to visit the module and change the drive location from ‘other’ to ‘sda’ and ‘sdb’, and save. Is this an expected function?
I have screenshots but didn’t know how to attach them here.
I’m not sure I understand what you mean. Can you post a screenshot?
Is your system a bare hardware system (i.e. not a virtual machine?). VMs don’t usually expose SMART data (and the disks are usually virtualized, anyway).
I’m trying to figure out what is triggering the problem. If you browse back to the Status monitors page now, without doing any updates or rebooting, does is still point at the right driver and show “OK”, or is it just not saving at all?
Huh, I think we need to narrow down a cause. Does just a reboot (with no updates) make it stop working, or does it only happen on a kernel update+reboot?
I can’t figure out how either could do it, but knowing specifically what’s doing it will maybe help reproduce it (but only maybe…I’ve never seen this, but then again I’m mostly running on VMs now which don’t have SMART).
Always after a kernel update and reboot. It has just become a standard procedure for me to change the dropdown menu from ‘other’ to ‘sda’ and ‘sdb’ and ‘save’ in the SMART drive monitor page. Once activated again, it doesn’t change till another kernel update and reboot.
From the ‘Bootup and Shutdown’ page I have just rebooted the system (with no kernel update) just to see if this only happens after a reboot.
In this instance ‘sda’ showed active with a tick but my second drive ‘sdb’ displayed a dash and the drive to check in the monitor page showed ‘other’ that I would have to change and choose ‘sdb’ fromthe dropdown.
The SMART drive status under ‘Hardware’ for ‘sdb’ is showing that SMART is enabled.
I really can’t figure out how a reboot or a kernel upgrade could change it. The monitor config is just a simple text file. Kernel shouldn’t have anything to do with it, and nothing happens during a reboot that would alter it either; it only gets looked at when the monitor scheduled job runs, and when you browse to it in the UI (and neither of those are write operations).
The only way I can see this happening is if a kernel upgrade and reboot caused the device to be renamed from say /dev/xvda to /dev/sda . But I’d only expect that to happen a single time, and be fixable by re-saving the SMART monitor with the correct drive selected.
