17

Would

dd if=/dev/zero of=somepartition bs=512

also wipe partitions after somepartition or stop at the end of somepartition?

Improve this question
1
  • 5
    Block devices representing partitions, e. g. /dev/sda1, are created by the kernel in such a way that it is impossible to access adjacent storage through them (assuming the partition table wasn't altered after the kernel read it the last time). If you could access adjacent storage in that way, it would be considered a huge bug.
    – David Foerster
    Oct 26, 2017 at 7:49

5 Answers 5

Reset to default
20

Overwrite a partition with dd

dd is a very powerful but also dangerous tool. It does what you tell it to do without questions. So if you tell it to wipe the family pictures, ... and it is a minor typing error away.

But if you check and double-check, you can use it.

dd if=/dev/zero of=somepartition bs=512

or I would suggest

dd if=/dev/zero of=/dev/sdxn bs=4096

where x is the drive letter and n is the partition number and block size 4096 bytes makes the write process faster.

It is important that you write to a partition in this case. If you write to the whole drive (the drive head end) /dev/sdx the whole drive will be overwritten. But writing to the partition will be interrupted at the end of the partition and partitions behind it will be preserved. (I tested now on a USB pendrive in Lubuntu 16.04 LTS, so I know that it works like that.)

Exception for an extended partition

There is an exception for an extended partition (which is a container for logical partitions, in order to have more than four partitions in an MSDOS partition table). This is described in the following link,

Can I make image of 'extended' partition using dd?

But there is another problem too. I tested your command in a test environment, and dd read only one kibibyte (1024 bytes) when I wanted it to make an image of an extended partition.

I tested also this now on a USB pendrive in Lubuntu 16.04 LTS, and this applies to writing (as well as to reading). Only the first kibibyte is overwritten.

So to summarize, overwriting primary partitions and logical partitions work according to the main description in this answer. But do not use this method to overwrite an extended partition because only the first kibibyte will be overwritten. The extended partition's logical partitions will no longer be found via the partition table, but the data stored in them are still there.

Improve this answer
6
  • I already accepted, but if this is so this should be the correct answer.
    – LogicBreaker
    Oct 25, 2017 at 18:38
  • 4
    @LogicBreaker, Maybe you can move the acceptance. But that is not important. It is more important that you understand how to use dd and that it is risky, so that you are very careful when using it. Good luck :-) In general, you should always have a backup of all files, that you cannot afford to lose.
    – sudodus
    Oct 25, 2017 at 18:42
  • 1
    When writing to bare partitions you don't have many alternatives. I moved, otherwise it would be misleading for others.
    – LogicBreaker
    Oct 25, 2017 at 18:49
  • 1
    This is why users normally cannot access the /dev/* "files".
    – Thorbjørn Ravn Andersen
    Oct 25, 2017 at 22:14
  • 1
    If this is the only copy of your family photos with no backup, then you're subject to losing them at any time by theft, fire, accident, or simple hardware failure :-)
    – user334639
    Oct 25, 2017 at 22:50
5

I think your question is based on a fundamental misunderstanding about how dd (and in fact Unix-like operating systems in general) work:

dd cannot overwrite adjacent partitions, simply because dd cannot overwrite partitions, period.

dd simply writes to files. That's it.

Now, if you pass dd a file which represents multiple partitions, then dd will overwrite that file. But in that case, it's not dd writing past the end of the partition. dd will still write until the end of the file, and only until the end of the file.

But, if you pass dd a file which only represents one partition, then dd will not write past the end of this partition. Again, this has nothing to do with dd. dd simply writes to the file you tell it to write to. The fact that this file represents a single partition is (in this case) ensured by the block device driver in the kernel. dd has nothing to do with that.

So, in short: dd writes to files. What those files represent, is none of dd's concern. dd knows nothing about partitions.

Improve this answer
3
  • Mmh... with dd only writing to files, you couldn't use it for writing to raw partitions.
    – LogicBreaker
    Oct 26, 2017 at 11:41
  • 1
    Correct. You cannot use dd for writing to raw partitions. You can only write to files. You can of course write to a block device file which represents a partition (such as /dev/sda1), but you cannot write to a raw partition. And since you can only write to a file that represents a partition, you cannot write past the end of the partition, because the file only represents the partition, and not the partition and a bit past the end.
    – Jörg W Mittag
    Oct 26, 2017 at 23:33
  • 3
    Jorg refers to one of the main ideas of Unix philosophy - "everything is a file". As such, kernel presents patitions, devices, ports etc. as files. As a result, every program which can write to a file can be used to write to a partition or a device. It's the job of the kernel to enforce the partition boundary. You can open /dev/sda in your text editor and change the data, dd is not different from any other program in terms of being able to access partitions. Very good answer!
    – Sergey
    Oct 31, 2017 at 19:12
4

Writes to a partition device won't write outside of that partition, with dd or anything else. You would need to use a wholedisk device to have any effect outside of a single partition.

(Caveat: unless your disk has a partition table with overlapping partitions, which should never happen.)

Improve this answer
1
  • 3
    Another caveat: if you're using something like LVM, writing to a physical volume can of course affect many logical volumes.
    – Maxpm
    Oct 26, 2017 at 2:09
1

There is a dangerous, but rare special scenario in which this could happen even with non-buggy block device drivers:

  • Partition table on disk is changed in a way that partition x is resized to end on a lower boundary than before. Either the partition y behind it is resized top start on a lower boundary, or a new partition y is added into the space.
  • Partition y is filled with relevant data by means that are independent of the partition table, eg using dd with skip/count options on the whole-disk block device (eg /dev/sda)
  • The ioctl that tells the kernel to reread the partition table is not issued, or fails due to busy devices
  • Partition x is written to by any process that tries to write to it until it hits an error condition.
Improve this answer
0

You have to be careful with dd as if you make a mistake you can overwrite more than you bargained for and it depends on what you are using dd for (the OP was vague in his or her use of dd and the exact syntax of the dd command).

If you specify a partition it will write to that partition until the partition is full.

If you make a mistake and put the entire drive, for example of=/dev/sda , dd will write to the entire drive start to finish ignoring (and overwriting) your partition table.

You can also us dd on a partition to overwrite deleted files (deleted files may remain on the partition and discovered by various recovery tools with various degrees of success until they are over written. In this case you can use dd to fill the free space by writing to a file.

dd if=/dev/zero of=/path/to/mount_point/zero_file bs=4096
rm -f /path/to/mount_point/zero_file

Depending on what you are doing, however, you may wish to use an alternate tool to securely delete files. See How to delete file(s) in secure manner? for options.

Improve this answer
11
  • 6
    If you could write to /dev/sdcX and manage to write across a partition boundary, it would not be dd that ignoring the partition table - it would be the block device driver in the kernel being buggy and ignoring the partition table.
    – rackandboneman
    Oct 25, 2017 at 20:36
  • 1
    @sudodus dd is not that low level. In fact most of the things people do using dd could have been done just the same with cat. In fact cat is slightly faster because it uses larger blocks than dd does by default. All of the low level code is in the kernel. And the driver does not really care if you are using dd or cat.
    – kasperd
    Oct 25, 2017 at 21:08
  • 1
    @sudodus - sorry for the confusion , I was not as clear as I intended. dd certainly can keep on writing , depends on what you tell it do do. dd if=/dev/zero of=/dev/sda bs=512 count=1 or dd if=/dev/zero of=/dev/sda bs=512 are examples. With the second command it will keep on writing and fill the entire disk "ignoring" the partition table. If you specify a partition dd if=/dev/zero of=/dev/sda1 it will not go beyond the partition. Sort of depends on what you want to do with dd.
    – Panther
    Oct 25, 2017 at 21:26
  • 1
    @Panther The question specifically says of=somepartition, so the case where you write to the whole disk device doesn't apply. dd can't get around the restrictions of the device driver.
    – Barmar
    Oct 26, 2017 at 4:19
  • 1
    @Bamar read up I already commented on that. I have seen many users confuse $somepartition for /dev/sda
    – Panther
    Oct 26, 2017 at 15:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .