strange wiping problem with DBAN

Since the disk shows up as a /dev/sd device instead of a /dev/hd device, then this indicates the drive is emulating a SCSI disk.

Do you have a native ATA  HBA, so some funky fakeraid   HBA ?  Try changing BIOS temporarily to make sure it is a native SATA, AHCI=ON, non-RAID settings, and appropriate SATA slot in motherboard.

(Some motherboards use special slots for plain-vanilla SATA devices, like a SATA CDROM, for example).

Also make sure that the USB stick is the FIRST boot path in the BIOS.

Haven't used that one. But as a backup try the free edition of KillDisk. http://killdisk.com/

Sometimes I have seen issues with wiping software if the BIOS is configured for SATA RAID or some level of enhanced SATA. Try to go into the BIOS and look to put the motherboard in a Legacy SATA mode. Or whatever sounds the most basic. Then retry with either product.

dlethe when i boot with this disk connected - there's no problem.it shwos all the files on disk, and it can read and write from disk diags fine
it is not a funky raid mobo - it's a P5Q-VM with ide and Sata connectors
so you're saying to change the setting from ide compatible to sata?

diggisaur - i have used 1 x Killdisk and guess what the result was ?
an effectively bad drive - unusable; had to throow it away
so you may understand i never want to use that utility again

So what makes you think the HDD doesn't have a problem in the first place.  The DoD 5220M spec says if a HDD can not be sanitized in it's entirety, then it can't be wiped.

Not saying that DBAN crashes when this happens, and you simply have crappy code.
Do this to make sure you can wipe

dd if=/dev/zero of=/dev/sdb bs=64k

(Assuming the HDD to wipe is /dev/sdb)

In fact, this is good enough, it puts zeros on the entire surface.  If you want to put random data, use /dev/random

Three passes with dd to do /dev/random will suffice, but it won't be compliant with the spec, because the official DoD sanitization spec says full write with zero, full write with  one, full write with random, full read/verify.

so unless you need compliance,, then personally screw the software, and just use dd.

P.s. you'll get an error on the last write if the capacity is not a multiple of 64K, but still it will do all it can. If you want to make a better shell script you could query capacity and modify dd to do all but the l last  X blocks that are left over, and then do that on a separate write.

You're call. I'm giving you a way to solve the problem of erasing, and not how to muck with some shareware that has bugs in it.

>>  So what makes you think the HDD doesn't have a problem in the first place.  The DoD 5220M spec says if a HDD can not be sanitized in it's entirety, then it can't be wiped.  <<  experience  !!!!   it has never shown problems or faults always runnign fine; diags ok, os ok, never disk errors

>>  Not saying that DBAN crashes when this happens, and you simply have crappy code  <<  what do you mean??


>>  Do this to make sure you can wipe   dd if=/dev/zero of=/dev/sdb bs=64k   <<  i have no choice when i start dban; anyhow -that does not answer my question as to why it happens -it offers another way to it from linux - right? anyway it is a "second best" solution, so tx !

i simply want to know why dban does not simply do it's job -that's all
i thought running it in a snap (yeah i know - it takes long) for testing purposes on this drive - but i was mistaken...it does not even start
i'll try the bios suggestion - probably tomorrow - it is no rush job

It lists sda, sdb and sdc, so maybe there's a non-disk device plugged in such as a multi-device reader attached. Would like to see the disk selection screen to see what devices it lists and possibly unplug some of them or disable them in BIOS.

no its simply another disk (that i normally boot from - and DBAN shows it correct
the picture also shows the usb stick, from which i booted dban
nothing wrong there !

When writing code that sends low-level ATA commands to HDDs, the emulation mode (whether legacy ATA, IDE, or SATA) is vital.  The ATA spec has numerous opcodes for reads/write, depending on whether the HDD requires commands needing 28bit address space.   [Equate this to 10 vs 16 byte CDBs]

But the emulation mode in a bios prevents 28-bit commands from working, and so if capacity > ~128GB and the hardware BIOS settings prevent 28-bit commands from executing it will break DBAN and any other program that does pass-through ATA.

Unlike SCSI pass-through there are multiple ATA read/write commands to choose from, that go beyond the equivalent of READ(10), READ(12) and READ(16).   The maximum # of blocks also varies with different op codes.   The maximum size of the various read/write op codes varies depending on the controller, driver, and disk as well.

There are other similar constraints, depending on whether or not you have an expander, which is a whole different can of worms.

Anyway, futz with the BIOS settings. You want plain vanilla ATA commands with AHCI enabled. If AHCI is not enabled then other restrictions on opcodes are also added.

P.S. writing pass-through ATA command code and getting it right is quite difficult. Last time I looked at the DBAN code was a few years ago, and it was flawed.  It does not go through any testing to find out what commands actually work, and verifies they do.  It just makes assumptions and then blows up if it guessed wrong.

But then, again, you get what you pay for.

P.S.  I do not know if it properly handles a disk with a user or master password, or if it handles disks that have been short stroked to give you a reserved (hidden) area.

But if that particular disk has these issues, you wouldn't necessarily know unless you have diagnostic code to reveal it.

o k - i changed the bios to AHCI (it was IDE compatible)
nothing has changed, i get the same error - and it still does not wipe anything ! !

comments?

Does the same rig wipe other disks with DBAN?

i have no other ones for wiping directly...
but why does it not start at all?  it recognises all the drives ok
i thought using DBAN was simple -straightforward -  apparently it is not..

Anybody?

bummer...
i'll try it on anothe rmotherboard then

You can always try nwipe which uses the same dwipe algorithm but it's not graceful so don't be surprised if you accidentally wipe the wrong thing. http://www.andybev.com/index.php/Nwipe

no tx andy -wiping the wrong thing is nothing for me...
but tx for the suggestion

I've requested that this question be closed as follows:

Accepted answer: 0 points for nobus's comment #a40022747

for the following reason:

i tried the disk on another mobo - and it worked
i hope you all agree?
if not just say so !

Hi nobus - Problem is exactly what i said in #40022226 and you took  my advice.  (Points are points, you know the  drill ;)

i agree you said a lot about ide / ata scsi and sas
but no solution was given
my Q was : anybody knows how to correc t this problem ?
but i'll grant you 1/2 of it- if that is ok with you?

fair enough, but I DO know how to correct the problem, get me a command dump from an ATA protocol analyzer and I will tell you what is wrong.   But that won't fix it.  The fix, as I said was to use better software that sends the right commands for your config, or replace the  hardware (disk controller/motherboard and try again).

hey dlethe - i know that you know your stuff
send me the "ATA protocol analyzer " and i'll oblige you in every way i can

you knwo what - you get it all !
enjoy the weekend

i hope all agree?

Heck, I don't even have one.  Can't justify keeping $20K worth of hardware that I might need for a few hours every year. You can watch it depreciate ;)

Have a good weekend too.