0

The controller doesn't let me convert drives to JBOD for some reason, so I can't reach them with hdparm to send --security-erase-enhanced ATA command. So I decided to use MegaCli for which I found two different commands but both fail:

MegaCli -PDInstantSecureErase -PhysDrv[32:1] -Force -a0

Adapter 0: Secure Erase is not allowed on device at Enclosure - 32, Slot - 1.

Exit Code: 0x00

MegaCli -SecureErase Start Simple -PhysDrv [32:1] -a0

Adapter: 0: Failed to start Secure Erase on Physical Device at EnclId-32 SlotId-1

FW error description:
  The requested command is invalid.

Exit Code: 0x02

This is not a one time task, so taking drives out and sec-erase them elsewhere doesn't solve the issue.

Ren
  • 45
  • 1
  • 9

1 Answers1

3

Legally required note: I work for Dell

Secure erase can be done via racadm, redfish, wsman, or the lifecycle controller.

If you want to do it with racadm see systemerase here. You could do something like racadm systemerase secureerasepd. All the drives sold these days are SED drives and this will blow away the keys used for the data or it will use the SCSI SANITIZE command.

If you're wanting to do it programmatically there's an example script here.

Grant Curell
  • 1,043
  • 6
  • 19
  • No SED drives in this ancient R620s sporting iDRAC7 and random mixture of drives, I am afraid. We're trying to put together nwipe-like tool capable of running on various hw when recycling servers. There are more complications, e.g. HDDs require physical rewrites, while SSDs accept quick ATA command, that's first huge difference the erasing app needs to know but I could go on. I'd prefer to use my own commands, as I'm always worried that I cannot see under the lid of ready-made solutions. – Ren Feb 02 '23 at 15:58
  • Got nothing for you there friend - perccli replaced megaraid's cli in PERC 8 and it has a secure erase command (https://dl.dell.com/content/manual47268554-dell-emc-poweredge-raid-controller-command-line-interface-reference-guide.pdf#page=27?language=en-us&ps=true). I got nothing for a server that old. My advice that I'm sure my employer would absolutely discourage me from giving is to buy an R630 from ebay for $500 and recycle the R620. Sorry that's not at all helpful hahaha – Grant Curell Feb 02 '23 at 16:56
  • Regarding being untrusting of vendor stuff: I used to be a red-teamer. Are vendor applications perfect? 10000% no. That said, I found a lot more problems with custom scripts than I ever did with vendor stuff. Ancient code people would run well after whoever wrote it had moved on and never maintained. If you're worried that a vendor's stuff isn't doing what it says it will, which is fair enough, I'd just go look at the commands being issued. Or simple enough - in this case, it's very straightforward to check if something like a cryptographic erase occurred. Open the drive and if you all you see – Grant Curell Feb 02 '23 at 16:59
  • is jibberish, success. The SED key be gone. Obviously not applicable to decade old drives but generally relevant. – Grant Curell Feb 02 '23 at 17:00
  • Thanks, Grant, I appreciate all the help. It's not actually about being untrusting towards vendors. In simple and straightforward cases like this: I know the drives, I know how to work with them, what and how to achieve, so I prefer to put together simple and transparent shell script. Easy to debug, upgrade, fix, it's vendor independent... Preferable over studying manuals for vendor specific tools, each having own caveats, principles etc.. But obviously, if controller here stands in my way and won't let me work directly with the drives, I'm going to have to look into these specific ways. – Ren Feb 02 '23 at 17:11