SMART not reporting on HPE ProLiant DL360p Gen8
RobertH
27 Posts
January 20, 2022, 6:26 pmQuote from RobertH on January 20, 2022, 6:26 pmDrives in the server are connected to the onboard controller (Smart Array P420i Controller) which is set into HBA mode. Server is 1U with 2x PCI-E and both PCI slots are tied up with network cards so I dont have room to add a native HBA card.
I had this systems running with petasan 2.6 previously and the drives connected to the onboard controller would report their smart data in the admin gui (manage nodes > node list > disks) without a problem, but now with a new fresh install of petasan 3.0.1 the nodes are no longer showing the smart data for any of the drives attached to the onboard controller.
they are showing smart data for the NVMEs in the server in a PCI-E adapter card, and for the boot SSD that is attached to the onboard SATA controller that is typically used for the optical drive (swapped CD drive out for a 2.5 sata HDD adapter bay)
if I drop to a console / ssh into the box and run smartctl on one of the drives attached to the controller smartctl kicks back that it needs the option:
-d cciss,#
added to the command line, according to smartctl the # should be replaced with the drive number on the controller starting at index 0 for the first bay, 1 for the second, etc
on a node in another cluster that is still running PetaSAN 2.6, it doesnt require that extra option on the command line, the version of smartctl between 2.6 and 3.01 seems to have been upgraded (2.6 uses smartctl 6.6, where 3.01 uses smartcl 7.1)
we had two drives in another cluster throw smart warnings recently and I really dont want a production cluster running if it cant monitor the hardware properly
since this cluster isnt in production yet and just for giggles, I copied the smartctl 6.6 from the other cluster running PS 2.6 and was able to run it at the command line and get the smart data from any of the drives without the extra option so figured it was at least not going to have an issue with dependencies
I tried to use apt to roll the smartmontools package back but it said it would force a removal of the petasan package if I did that, so I tried the next best hack of renaming the program in the /usr/sbin/smartctl and making a symlink to the older version, that worked at the command line and in the web gui for that node the smart data was now populating for all the drives in the server
since this is a hack and is obviously going to get broken at some point down the line is there a way to prevent the system from updating smartmontools package going forward (so it wont overwrite the hack) or will I just have to deal with re-symlinking it every time we do an update potentially
Drives in the server are connected to the onboard controller (Smart Array P420i Controller) which is set into HBA mode. Server is 1U with 2x PCI-E and both PCI slots are tied up with network cards so I dont have room to add a native HBA card.
I had this systems running with petasan 2.6 previously and the drives connected to the onboard controller would report their smart data in the admin gui (manage nodes > node list > disks) without a problem, but now with a new fresh install of petasan 3.0.1 the nodes are no longer showing the smart data for any of the drives attached to the onboard controller.
they are showing smart data for the NVMEs in the server in a PCI-E adapter card, and for the boot SSD that is attached to the onboard SATA controller that is typically used for the optical drive (swapped CD drive out for a 2.5 sata HDD adapter bay)
if I drop to a console / ssh into the box and run smartctl on one of the drives attached to the controller smartctl kicks back that it needs the option:
-d cciss,#
added to the command line, according to smartctl the # should be replaced with the drive number on the controller starting at index 0 for the first bay, 1 for the second, etc
on a node in another cluster that is still running PetaSAN 2.6, it doesnt require that extra option on the command line, the version of smartctl between 2.6 and 3.01 seems to have been upgraded (2.6 uses smartctl 6.6, where 3.01 uses smartcl 7.1)
we had two drives in another cluster throw smart warnings recently and I really dont want a production cluster running if it cant monitor the hardware properly
since this cluster isnt in production yet and just for giggles, I copied the smartctl 6.6 from the other cluster running PS 2.6 and was able to run it at the command line and get the smart data from any of the drives without the extra option so figured it was at least not going to have an issue with dependencies
I tried to use apt to roll the smartmontools package back but it said it would force a removal of the petasan package if I did that, so I tried the next best hack of renaming the program in the /usr/sbin/smartctl and making a symlink to the older version, that worked at the command line and in the web gui for that node the smart data was now populating for all the drives in the server
since this is a hack and is obviously going to get broken at some point down the line is there a way to prevent the system from updating smartmontools package going forward (so it wont overwrite the hack) or will I just have to deal with re-symlinking it every time we do an update potentially
SMART not reporting on HPE ProLiant DL360p Gen8
RobertH
27 Posts
Quote from RobertH on January 20, 2022, 6:26 pmDrives in the server are connected to the onboard controller (Smart Array P420i Controller) which is set into HBA mode. Server is 1U with 2x PCI-E and both PCI slots are tied up with network cards so I dont have room to add a native HBA card.
I had this systems running with petasan 2.6 previously and the drives connected to the onboard controller would report their smart data in the admin gui (manage nodes > node list > disks) without a problem, but now with a new fresh install of petasan 3.0.1 the nodes are no longer showing the smart data for any of the drives attached to the onboard controller.
they are showing smart data for the NVMEs in the server in a PCI-E adapter card, and for the boot SSD that is attached to the onboard SATA controller that is typically used for the optical drive (swapped CD drive out for a 2.5 sata HDD adapter bay)
if I drop to a console / ssh into the box and run smartctl on one of the drives attached to the controller smartctl kicks back that it needs the option:
-d cciss,#
added to the command line, according to smartctl the # should be replaced with the drive number on the controller starting at index 0 for the first bay, 1 for the second, etcon a node in another cluster that is still running PetaSAN 2.6, it doesnt require that extra option on the command line, the version of smartctl between 2.6 and 3.01 seems to have been upgraded (2.6 uses smartctl 6.6, where 3.01 uses smartcl 7.1)
we had two drives in another cluster throw smart warnings recently and I really dont want a production cluster running if it cant monitor the hardware properly
since this cluster isnt in production yet and just for giggles, I copied the smartctl 6.6 from the other cluster running PS 2.6 and was able to run it at the command line and get the smart data from any of the drives without the extra option so figured it was at least not going to have an issue with dependencies
I tried to use apt to roll the smartmontools package back but it said it would force a removal of the petasan package if I did that, so I tried the next best hack of renaming the program in the /usr/sbin/smartctl and making a symlink to the older version, that worked at the command line and in the web gui for that node the smart data was now populating for all the drives in the server
since this is a hack and is obviously going to get broken at some point down the line is there a way to prevent the system from updating smartmontools package going forward (so it wont overwrite the hack) or will I just have to deal with re-symlinking it every time we do an update potentially
Drives in the server are connected to the onboard controller (Smart Array P420i Controller) which is set into HBA mode. Server is 1U with 2x PCI-E and both PCI slots are tied up with network cards so I dont have room to add a native HBA card.
I had this systems running with petasan 2.6 previously and the drives connected to the onboard controller would report their smart data in the admin gui (manage nodes > node list > disks) without a problem, but now with a new fresh install of petasan 3.0.1 the nodes are no longer showing the smart data for any of the drives attached to the onboard controller.
they are showing smart data for the NVMEs in the server in a PCI-E adapter card, and for the boot SSD that is attached to the onboard SATA controller that is typically used for the optical drive (swapped CD drive out for a 2.5 sata HDD adapter bay)
if I drop to a console / ssh into the box and run smartctl on one of the drives attached to the controller smartctl kicks back that it needs the option:
-d cciss,#
added to the command line, according to smartctl the # should be replaced with the drive number on the controller starting at index 0 for the first bay, 1 for the second, etc
on a node in another cluster that is still running PetaSAN 2.6, it doesnt require that extra option on the command line, the version of smartctl between 2.6 and 3.01 seems to have been upgraded (2.6 uses smartctl 6.6, where 3.01 uses smartcl 7.1)
we had two drives in another cluster throw smart warnings recently and I really dont want a production cluster running if it cant monitor the hardware properly
since this cluster isnt in production yet and just for giggles, I copied the smartctl 6.6 from the other cluster running PS 2.6 and was able to run it at the command line and get the smart data from any of the drives without the extra option so figured it was at least not going to have an issue with dependencies
I tried to use apt to roll the smartmontools package back but it said it would force a removal of the petasan package if I did that, so I tried the next best hack of renaming the program in the /usr/sbin/smartctl and making a symlink to the older version, that worked at the command line and in the web gui for that node the smart data was now populating for all the drives in the server
since this is a hack and is obviously going to get broken at some point down the line is there a way to prevent the system from updating smartmontools package going forward (so it wont overwrite the hack) or will I just have to deal with re-symlinking it every time we do an update potentially