I just had a nasty experience under Linux: this is actually by default for windows administrators, I know, but still…
The task was to recreate a logical volume using LVM, utilizing old hard disks. The online recommendation in such cases is to erase the data from the disks before assigning them to a (physical) volume group. This can be very time consuming for numerous 2TB disks and even more for 8x 6TB disks. OK I admit there are no 6TB disks – these are actually hardware RAID volumes but the subject doesn’t change with that.
So before using pvcreate we have to be sure that there is no data, and no partitions on the disks. Funny enough cat /proc/partitions showed me the devices correctly, but fdisk -l was smart enough to check the devices thoroughly and thus presented me with the following input (truncated for one disk only):
WARNING: GPT (GUID Partition Table) detected on ‘/dev/sdf’! The util fdisk doesn’t support GPT. Use GNU Parted.
Disk /dev/sdf: 5991.4 GB, 5991479377920 bytes
255 heads, 63 sectors/track, 728422 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/sdf doesn’t contain a valid partition table
Now that’s a bummer for a newly reinitialized hardware RAID, but let’s skip this for a moment – since we presume that the thingy can happen on an old disk, we need to know how to erase the GPT information.
The above mentioned possibility to run dd if=/dev/zero of=/dev/sdf was dismissed because of time restrictions. To delete partition information on the start of the disk could be achieved running dd if=/dev/zero of=/dev/sdf bs=512 count=2 effectively deleting only the first 1024 bytes. But the problem still persisted. Until I found online that the GPT information is stored at the end of the physical disk as well. Now this could explain why fdisk "found" the GPT information despite all.
So we need to run dd if=/dev/zero of=/dev/sdg bs=512 seek=??? instead. The only left problem was, what to use for "???". We need to find the end of the disk and seek supports only BLOCKS and not BYTES as parameter. That was a thing not obvious to me until I read the manual and really frustrating when I tried to run dd if=/dev/zero of=/dev/sdg bs=512 seek=5991479377920 and nothing happened: how many block did the actual disk have was obscure to me. So it took me some time until I realized that with "bs=512" I was already preparing my way: all it was left to do was to divide the bytes returned from fdisk by the "bs"-parameter. And as such I finally guessed the proper form: dd if=/dev/zero of=/dev/sdf bs=512 seek=11702108158.
Actually if you feel freaky with only a couple of block being erased you can increase them to – let’s say 100 – on each end, but this is still much faster than complete disk wipe. So the right thing for me was:
if=/dev/zero of=/dev/sdf bs=512 count=100
dd if=/dev/zero of=/dev/sdf bs=512 seek=11702108060
So long and enjoy the weekend!
Thanks for this, very useful. If you’re feeling brave you can use awk to get the disk size from fdisk, then divide by 512 and subtract 2:
dd if=/dev/zero of=/dev/sdf bs=512 count=2 seek=$(fdisk -l /dev/sdf | awk ‘/GB/ { print $5 / 512 – 2 }’)
Hi Modeler,
thanks for the automating!