wipe entire disk without file system from command line


Hi, first time poster here. I built an xubuntu 12.04 live disk with persistence and installed bleach bit. The purpose is to wipe a handful of server machines for resale. All of these servers have hardware RAID controllers that don't allow me direct access to the individual SCSI devices. So I went in to the RAID firmware, broke the arrays and rebuilt new logical RAID 0 devices, each consisting of a single disk. On some of these servers, I can boot to the live disk GUI and use the bleachbit gui to secure wipe the raw drives without file systems. However, on some of the servers, I cannot get to the gui, but I can get to a cli. I know that I can use dd to write from either /dev/urandom or /dev/zero ensure that no old data is recoverable. I'm also aware of the long time debate between writing random or zero's, and 1 vs more than 1 passes. For my purposes, a single pass writing zero's is enough. Especially since I'm doing this to RAID 5 arrays that were broken and recreated as new, single disk RAID 0 arrays.

My question is, can I get the same result using BB's cli? The question is largely educational, as I've already completed the wipe for all devices using either BB GUI or dd from the cli. I read the CLI information on the web page, and played with the CLI version a bit to see what arguments and switches were available - but I was unable to find a way to accomplish what I wanted to (hence, my decision to use dd).

I've considered this kind of functionality but I haven't tested it or implemented any changes to make it work in BleachBit. One reason is there are two strong alternatives:

1. On Linux, I recommend using writing a single pass from /dev/zero like dd if=/dev/zero of=/dev/whatever.

2. Otherwise, I recommend booting from a DBAN CD.

If you have nothing to lose, then you are welcome to try the new --shred command line option in BleachBit version 1.0. Let me know how that goes. My biggest concern is, after it is done wiping, it will try to delete (unlink) the device---perhaps this will fail on /dev/whatever.

Andrew, lead developer