About drive wiping: You're probably better off using the ATA Secure Erase command, which is very quick and does the entire disc. dd and other tools risk not doing blocks marked as bad, for example.<p>He's right that a single overwrite of zero is probably good enough to make sure that data is gone, but it's probably not enough to persuade other people that it's gone. A few passes of pseudo random data is probably better if you need to persuade other people that the data has gone.<p>But if it's really important drive wiping is what you do to protect the drives until you get a change to grind them.
> Unfortunately, there is no command-line option to have `dd` print progress<p>How difficult could it be to write a dd command from scratch that does include progress-reporting? I mean, dd is simply reading blocks of data from one file descriptor and writing them to another.
Does the third command really work as intended?<p><pre><code> sudo cat ubuntu-14.04-desktop-amd64.dmg >> /dev/sda1
</code></pre>
I believe this will attempt to write data after the of the the block device, which almost by defintion will fail.<p>However, I often do the following, which works pretty well:<p><pre><code> sudo cat ubuntu-14.04-desktop-amd64.dmg > /dev/sda1</code></pre>
You can 'dd' from Unix to the cloud ... well, some clouds ...<p><pre><code> pg_dump -U postgres db | ssh user@rsync.net "dd of=db_dump"
mysqldump -u mysql db | ssh user@rsync.net "dd of=db_dump"
</code></pre>
... although these days, now that we support attic and borg[1], nobody does things like this anymore.<p>[1] <a href="http://www.rsync.net/products/attic.html" rel="nofollow">http://www.rsync.net/products/attic.html</a>
> If you want to erase a drive fast then use the following command (where sdXXX is the device to erase):<p><pre><code> dd if=/dev/zero of=/dev/sdXXX bs=1048576
</code></pre>
Question: is there a disadvantage to using a higher blocksize? Is the read/write speed of the device the only real limit?
It is worth noteting that the shred program mentioned is more or less useless on modern filesystems for a variety of reasons, the man-page has a list that it will fail to work correctly on (btrfs, ext3, NFS).<p>It may well be that the only usable filesystem for it, is FAT32 (and possibly NTFS, not sure on that thou).
The "Unable to install GRUB" recommended fix to remove the GPT is wrong. The proper thing to do is create a 1MiB partition, BIOSBoot partition type (gdisk internal code 0xEF02), and then grub-install will find it and install core.img there automatically.