Disk Erasure report - smartctl requests HP adapter number
Chewie9999 opened this issue · comments
On page 2 of the report, the following is displayed:
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.4.16] (local build)
copyright (c) 2002-22, bruce allen, christian franke, www.smartmontools.org
/dev/sda: requires option '-d cciss,N'
please specify device type with the -d option.
use smartctl -h to get a usage summary
The server in question is an HP ProLiant DL385G8, and the wipe completed successfully.
It has 2 SAS cards installed - the internal one for the first array - a 420i, and a PCI card (also 420) for the second array.
cciss is the name of the driver used for these SAS controllers usually, so that part is correct.
The "BUS" in the report is listed as "UNK", is this a similar problem to #67 ?
I can provide similar info on this if you need it.
On the command line in ShredOS (ALT F2) can you run the following commands
smartctl -a -d cciss,0 /dev/sda Does it produce smart data ?
Can you post the output of
ls -al /sys/block
Thanks.
I'm assuming that the zero in cciss,0 is the first controller. To make this work I need to figure out what controller sda is on. Can you pick a drive on the second controller and then run smartctl -a -d cciss,1 /dev/sd.. Does the smartctl details match the drive correctly?
Thanks.
I think the cciss,0 is actually the physical drive as /dev/sda and /dev/sdb are the arrays on the different controllers.
Please see attached screenshots. Sorry, I couldn't find out how to pipe the output to the permanent part of the USB image :(
Changing the cciss,0 to 1, 2 etc, selects the different drives in the sda/sdb array.
The output of smart control does match the drive I am expecting.
nwipe can only see the arrays, it does not see the individual drives unfortunately, so I had to wipe the arrays, rather than the drives.
Does this help?
I could be wrong here, so bear with me ... but smartctl can access only drive specific data for the purposes of determining the state of the drive. If I understood the technical data for that controller I can't access the drive at a block level individually unless the controller is in HBA mode. That's assuming it can be switched to HBA mode, where the disc's are all accessible and not part of an array.
Personally if I was wiping those drives I'm not sure I'd be happy wiping as part of an array unless I'd taken out each drive attached to a non raid interface and verified it individually using nwipe in verify zeros mode or at the very least examined it with a hexeditor. The reason I say that is that I don't know whether the controller reserves parts of each drive for it's own use. Also HPA/DCO will definitely not be detectable in array mode.
So I would recommend wiping drives individually in HBA or IT(LSI) ? mode rather than as part of a array unless you are just doing it for in-house use.
All totally valid points.
In the current mode it only shows arrays. Any drives not configured as part of an array do not show up at all in nwipe.
I will see if there's an HBA mode - it sounds like there are for some HP SmartArray controllers.
Is it possible to somehow detect this (maybe by volume name, as on HP it says LOGICAL VOLUME (or similar)) to warn users that this is/was a bad idea and suppress smartctl errors ?
Is it possible to somehow detect this (maybe by volume name, as on HP it says LOGICAL VOLUME (or similar)) to warn users that this is/was a bad idea and suppress smartctl errors ?
Yes, that would be a good idea. Probably a warning that the device /dev/sdx appears to be an array rather than a individual disc, ideally on the drive selection screen. When the drive is selected a warning pops up.