Okay, here's how to do it using mfsBSD (which is standard FreeBSD but very minimal and provides enough utilities to accomplish what we need with a small footprint.
Be aware you should use a USB 2.0 controller for this. USB 3.0 is not decently supported in FreeBSD 9.0, so stick with USB 2.0 please.Warning: If you are some random Internet user reading this "tutorial", DO NOT perform this on an SSD. This should only be used for mechanical HDDs.
If you want to make sure you don't risk destroying data on any of your other drives, I recommend detaching their SATA cables (you do not need to detach their power cable). I'm not responsible if you mess this up. :-)
1. Download this ISO
and burn it to a CD (note that this assumes you have at least a 64-bit capable CPU, i.e. something made in the past 7 years or so).
2. Make sure the USB drive is attached to your system and is AC-powered.
3. Boot the CD.
4. At the main FreeBSD logo text screen, just press Enter and wait. It can take some time for things to start.
5. The kernel should load and eventually present you with a
prompt. Enter the username
and the password
. You should now have a
6. Issue the command
, which should show all attached hard disks on your system (including USB ones). Example output:
In your case, you're looking for the drive labelled something like
What you need specifically is the device name at the end of the output, specifically labelled
for USB-attached hard disks and
for ATA/SATA native (non-USB-attached) hard disks. Using the above example text, WD20EFRX-68AX9N0 is
thus the device path is
. Ignore anything like
If the disk does not show up in
, then the disk is almost certainly not showing up on the USB bus. There are ways to figure this out (using
), but is outside the scope of this writing.
7. Check to make sure you can communicate with the disk reliably using
to read from the drive starting at LBA 0, using the device path as described above for the
There will be no output shown; it will appear as if the command is doing nothing. At this phase, check the LED on the USB enclosure; if it's lit or blinking, you're communicating with the right device.
BTW, the parameters in question:
stands for input file -- in this case, the disk
stands for output file -- in this case, a null device (i.e. all the data read from the disk gets thrown out)
stands for block size -- in this case, 64KBytes (65536 bytes)
You can check the status of dd as well -- on FreeBSD press Ctrl-T to get the status of a currently-running process. You'd see something like:
The 1st line is the system load, what kernel state the dd process is in, what the PID is, CPU usage for that process. The 2nd and 3rd lines indicate the number of blocks read/written to/from the relevant input/output files/devices, where 1 block correlates with the
parameter. The 4th line indicates the number of bytes written to the output file/device, as well as general speed.
Assuming the USB LED is blinking or lit, press Ctrl-C to end the process; the LED should cease.
Technical note: FreeBSD's dd interacts with disks directly (what Linux users would call O_DIRECT); unlike Linux, there is no caching involved here.
8. Finally, it's time to zero the drive -- This is non-recoverable, so do not make any typos!
should be the /dev/zero device, which just spits out raw zeros (byte 0x00)
should be the disk (i.e. you're writing to it)
is block size (same as above)
Like earlier, there will be no output. This will zero the entire drive (assuming you let it finish) from LBA 0 to the end. And like earlier, you can press Ctrl-T to get a general status of things.
9. After quite some time (remember, USB 2.0 can do up to something like 35MBytes/second, which is much slower than if you were using SATA natively), the dd command should finish.
However, you will almost certainly see some errors at the very end. The message shown will be something like this:
This is okay -- the reason is that actual capacity of the drive does not end on an even 64KByte boundary, so it wrote as much as it could, and one of those writes was a partial write (which is fine). Trust me, the entire drive got zeroed. :-)
In the case dd exits with a message like "I/O error" or some other text on-screen (if it's bold/white its from the kernel; if it's grey-ish it's from dd), then writes at some point failed. I'd need a photo of the monitor to know what the condition/issue was. FreeBSD CAM will output quite a lot of useful information (for me anyway) about the error, but I'm not used to using disks across USB so CAM might not be able to get the actual ATA level status. I would suggest re-doing the entire procedure but with the disk attached natively via SATA (preferably AHCI enabled too if possible).
10. In the case things exited smoothly, I recommend ejecting the CD, then cleanly rebooting the system:
11. Now go back into Windows and pull SMART statistics using smartmontools (
smartctl -x ...
). Attribute 197 should no longer have 1 pending LBA for analysis. I'd like to see the output regardless, as it will give some general information about the overall status of the disk after having every LBA written to.
Footnote: if you'd prefer to use a USB flash drive instead of a CD, use this instead
and follow this procedure
. The CD method should work regardless though, and IMO is probably easiest.--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.