Error using DBAN when trying to wipe SCSI drives on a Compaq Proliant ML350.

I am trying to wipe several SCSI  hard drives, using an older Compaq Proliant ML350. The server was working and decommissioned this week. DBAN has worked in the past on different servers, but now having the following issue.

 The HP SCSI hard drives vary in size from 72 to 300 GB, I have tried some different DBAN versions 1.0.6 thru the newest 2.2.6. I have tried only 1 drive and multiple drives and in differend slots, but keep getting the same error:

DBAN Failed.
The disks have not been wiped.
Error: Disks not found.
DBAN could need a driver for this computer.

I also tried DBAN with a newer known good hard drive, to prove the old drives werent physically bad, but same issue. The server can't see the drives.

Has anyone run into anything like this before?

Who is Participating?
DavidConnect With a Mentor PresidentCommented:
Shred or wipe won't do it.  It is not a matter of just getting drivers.  The RAID controller presents a logical device to the booted O/S, not the physical drive.  You can wipe it all day long and it will still leave data there.  The "drivers", even if you had them, facilitate communicating at the logical device level.

You need to get yourself a JBOD SCSI controller and hook them up that way

my guess, since the computer is pretty old and dban is a bootdisk, that its a controller/raid/drive issue.

i would hunt down old reliable adaptec 1542 (yea, im that old) plug in the drives on a regular computer and wipe em down that way.  if you're gonna toss the drives, just get a hex tip driver, open them up and expose them to that sweet sweet air.. and then scratch em up.  kick em, let your friends throw them off buildings.. :)

you could also use something like Diskwipe, spinrite, and my old favortie BCWipe.
DBAN doesn't have the drivers for the Hard disk controller of that compaq server, so it can't see the drives.  You can try another Linux live CD and use the utility "shred" or "wipe" or just dd (e.g. dd if=/dev/random of=/dev/hda).
Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to and use offer code ‘EXPERTS’ to get 10% off your first purchase.

PcGod718Connect With a Mentor Commented:
im gonna have to disagree on that one dlethe. unless im misunderstanding you, wiping the drive, whether it was in a raid or solo, will wipe the drive.  if i pull a drive out of a raid 5, and put it solo on a system and reformat it, when i stick it back into the raid, it will need a rebuild, because the drive is wiped.

what he needs is some form of access to the drives, in this case since it was a raid, he needs physical access (either 1 drive at a time or all together, doesn't matter) but the drives must show up in whatever OS/utility he uses.

on re-reading your statement a few times, i retract my disagreement,  i now understand what u are saying and i agree  :)  

You can use the raid controller on the compaq to blow out the drives as well, but we all know that isnt secure, although ur average techhead wont be able to get anything off of them.

Anyhoo, i stand by my first suggestion.  wipe the drives 1 by 1 with a standard scsi controller, or just break em.  :)

mccrackyConnect With a Mentor Commented:
@dlethe: shred or wipe would do the same as DBAN, wipe the data on the drives.  It may be that the RAID controller presents a logical drive, but the data was put on them that way, so wiping them the same way should do the data the same.  Or reconfigure the RAID to JBOD and wipe them that way or pull them and hook them to a different controller like PcGod718 said.  wipe the actual drive rather than the partition like I said (/dev/sda not /dev/sda1).  Or just go out and mix up some of that stuff that burns through metal and melt the drives.  Or just use them for target practice at your local rifle range or....

There are many ways...
Ordinarily yes, but you are forgetting the drive metadata.   That will always remain.  Prove it to yourself.  How many blocks are usable on the disk as reported by ACU?  How many blocks are on the disk as reported by the label?

Or wipe a disk this way, put it in a PC with a JBOD SCSI controller, and just read first few blocks.  
It doesn't matter that you haven't wiped the metadata since all the user data will have been wiped which is what matters. You won't have wiped the S.M.A.R.T data either but who cares.

Newer Smart Array controllers provide Int13H BIOS extensions so DBAN etc would see them without a driver but not so for the older ones so putting them on a non-RAID controller is normally the way and it's probable that the server has one inbuilt into the motherboard - can't be absolutely certain as don't know generation number. In that case all you need to do is move the cable from RAID controller connector to motherboard connector.
The  DoD, and NIST specifications for erasing a disk require 100% of the disk to go through the procedure.  This is not negotiable.  One of the reasons is that if somebody wanted to, they could put all sorts of information in the "metadata" area like credit cards, and it would survive the process and nobody would know except for the person that put it there, and the person that acquired the disk later.

Also the 5220M and NIST Clear validation passes dictate 100% read validation pass.  Metadata will fail it.

So technically you can only erase some of the disk with DBAN this way.  If you require any level of compliance, then you simply can not do it with your controller in the mix.
The metadata can be erased with System Erase anyway.
yes, but the validation suite specifies that you have to run the n-erase passes in order, for the entire disk, then immediately follow with a full verification on all addressable blocks.  Yes, it will ultimately be erased this way, but it will not be compliant to any formal specification.  This may or may not be acceptable for the author.  I am just bring up the point that they can not erase the disk per any of the formal data sanitization specifications unless they use a different controller in that system.
Hmm, would you know if DBAN tries to erase sectors that have been spared out by the disk because of unrecoverable read errors and the area at the end of the disk that isn't seen if one has set the size of the disk to be smaller than the physical size? Compaq/HP (and Dell) fix the reported size of the disk to be a bit less than the maximum to allow them to use more than one source of disks but maintain identical sizes.
I know for a fact that DBAN does not do this, as I have the source code (well, the source code as it was Dec 2009).  I was working on a large sanitization project on a site that had a bunch of  HP G3 and higher servers, and was hoping I could use DBAN .. had to do something else, because of the SMARTArray controllers.   Luckily they had plenty of the JBOD enclosures and tape libraries, so just moved the JBODs to the controllers reserved for tapes.

DBAN (at that time, and unless there has been a change) will not address disks that have had capacity changed via CHANGE CAPACITY CDB.  Nor does it facilitate doing anything about the grown defects. This is true for both ATA family and disks that use SCSI protocols.    Also it was quite annoying that DBAN requires you to boot the system, and it is also profoundly slow. I was able to get a single server to wipe 288 HP FATA & Fibre channel disks concurrently using another product that has much more intelligence.  It took maybe 24 hours to get the approx 150 FC drives to go through the 3 write passes, maybe another 48 hours to get the FATA drives done).  I had to add multiple controllers to the system so that I would not saturate all of the pipes, and certainly could have done it faster had the HP server had PCIe 2.0 bus, but still this part was rather painless.   The annoying thing was that we were constantly moving around those 5-1/4" SCSI drives in and out of the same 6 expansion units to keep everything going. Still we did over 1000 disk drives in a secure cage  where you couldn't bring in any hardware other than cables & controllers due to the nature of the data in just a few days.

DBAN is a good product, but it is more of a consumer product.  it isn't designed for volume and won't do in-band erasing on native windows, solaris, unix, etc..
So in other words not erasing the metadata and what may be hidden by it is pretty irrelevant since most permanent erase programs also leave holes where data could be sneaked out surrepitiously?

If DBAN could erase the user data while it was still on the RAID controller (not in this case as no drivers) then any accidental data loss would be covered and only deliberately obfuscated data would get through?

I'm just trying to qualify what you mean by "the whole disk" since there's manufacturer's data (firmware etc.) on what one could consider negative tracks on the platters.

If not erasing through a RAID controller isn't sufficient is anything sufficient except a grinder?
NoneProfitAuthor Commented:
Thanks for the help. We are taking the easy way out and drilling holes!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.