[CS-FSLUG] Hard drive won't format - or maybe stay formatted.

[Tim Young]

  One "desperate measure" is to toast all the information on the 
drive with something like:

dd if=/dev/zero of=/dev/sdb bs=512 count=1024

This line assumes that the drive is /dev/sdb.  :)
This basically blasts the partition table and MBR off the drive, 
regardless of whether or not anything is mounted, etc.  It is a great 
and exciting way to modify the drive.  Exciting, in that, if you do 
it to your primary OS drive, you are in deep trouble...  ;)

Doing this is nearly guranteed to remove the partitions.  The only 
reason it might fail would be if there was something protecting the 
boot sector ("antivirus" in the BIOS or the like).  The dd command 
reads in from /dev/zero (which produces an unlimited number of zeros) 
and writes it out to the beginning of the drive specified (I used 
/dev/sdb).   The beginning of the drive is where the MBR and 
partition information is stored.  The bs (Block Size) and count 
(number of blocks to copy) options just tell it how many to do before 
stopping.  Removing them will write zeros across the whole HD until 
ctrl-c is pressed, or you have overwritten the whole drive with zeros.

If you do this, reboot, and then try to repartition, you should be 
able to avoid anything that pre-mounts the drive before you do your 
fdisk.

I have not run into hard-drives that have built-in MBR protection, 
but since some BIOSes have that option, it would be worth looking 
into as a possibility.  What model of HD is it?

     - Tim Young

On 8/5/2010 1:04 PM, Karl Kleinpaste wrote:
> It's possible that some partition on the drive is being automatically
> mounted.  If that's the case, then the kernel's sense of the drive
> partitioning is fixed until the last partition is unmounted.  This is
> the point where good ol' fdisk(8) mutters, "writing partition table to
> disc...re-reading partition table," or something thereabouts.
> Basically, you're screwed in such a situation until you convince the
> kernel to let go of the last remnant of its belief about the drive.
>
> Qparted won't have any idea that this is the problem; it will know only
> that the ioctl() call that attempts to read the table back gives the
> same result it used to have.
>
> _______________________________________________
> ChristianSource FSLUG mailing list
> Christiansource at ofb.biz
> http://cs.uninetsolutions.com
>