Will dd if=/dev/zero of=/dev/sda wipe out a pre-existing partition table?
up vote
12
down vote
favorite
Will # dd if=/dev/zero of=/dev/sda wipe out a pre-existing partition table?
Or is it the other way around, i.e, does
# fdisk /dev/sda g (for GPT)
wipe out the zeros written by /dev/zero?
linux dd fdisk gpt
edited Nov 26 at 6:56
muru
35.3k582155
asked Nov 25 at 16:29
justinnoor.io
281214
add a comment |
up vote
12
down vote
favorite
Will # dd if=/dev/zero of=/dev/sda wipe out a pre-existing partition table?
Or is it the other way around, i.e, does
# fdisk /dev/sda g (for GPT)
wipe out the zeros written by /dev/zero?
linux dd fdisk gpt
edited Nov 26 at 6:56
muru
35.3k582155
asked Nov 25 at 16:29
justinnoor.io
281214
6
That's not/dev/zerowiping something out, it'sddwiping it out by copying over it. The facts that the bytes happen to be zero, and that the zero bytes happen to come from/dev/zeroinstead of some other source of zeroes, are minor details.
– chrylis
Nov 26 at 3:07
2
If you just want to wipe the partition table, wipefs could be more reliable.
– pipe
Nov 26 at 9:14
add a comment |
up vote
12
down vote
favorite
up vote
12
down vote
favorite
Will # dd if=/dev/zero of=/dev/sda wipe out a pre-existing partition table?
Or is it the other way around, i.e, does
# fdisk /dev/sda g (for GPT)
wipe out the zeros written by /dev/zero?
linux dd fdisk gpt
edited Nov 26 at 6:56
muru
35.3k582155
asked Nov 25 at 16:29
justinnoor.io
281214
Will # dd if=/dev/zero of=/dev/sda wipe out a pre-existing partition table?
Or is it the other way around, i.e, does
# fdisk /dev/sda g (for GPT)
wipe out the zeros written by /dev/zero?
linux dd fdisk gpt
linux dd fdisk gpt
edited Nov 26 at 6:56
muru
35.3k582155
asked Nov 25 at 16:29
justinnoor.io
281214
edited Nov 26 at 6:56
muru
35.3k582155
asked Nov 25 at 16:29
justinnoor.io
281214
edited Nov 26 at 6:56
muru
35.3k582155
edited Nov 26 at 6:56
muru
35.3k582155
edited Nov 26 at 6:56
muru
35.3k582155
35.3k582155
asked Nov 25 at 16:29
justinnoor.io
281214
asked Nov 25 at 16:29
justinnoor.io
281214
asked Nov 25 at 16:29
justinnoor.io
281214
281214
6
That's not/dev/zerowiping something out, it'sddwiping it out by copying over it. The facts that the bytes happen to be zero, and that the zero bytes happen to come from/dev/zeroinstead of some other source of zeroes, are minor details.
– chrylis
Nov 26 at 3:07
2
If you just want to wipe the partition table, wipefs could be more reliable.
– pipe
Nov 26 at 9:14
add a comment |
6
That's not/dev/zerowiping something out, it'sddwiping it out by copying over it. The facts that the bytes happen to be zero, and that the zero bytes happen to come from/dev/zeroinstead of some other source of zeroes, are minor details.
– chrylis
Nov 26 at 3:07
2
If you just want to wipe the partition table, wipefs could be more reliable.
– pipe
Nov 26 at 9:14
6
6
That's not
/dev/zero wiping something out, it's dd wiping it out by copying over it. The facts that the bytes happen to be zero, and that the zero bytes happen to come from /dev/zero instead of some other source of zeroes, are minor details.– chrylis
Nov 26 at 3:07
That's not
/dev/zero wiping something out, it's dd wiping it out by copying over it. The facts that the bytes happen to be zero, and that the zero bytes happen to come from /dev/zero instead of some other source of zeroes, are minor details.– chrylis
Nov 26 at 3:07
2
2
If you just want to wipe the partition table, wipefs could be more reliable.
– pipe
Nov 26 at 9:14
If you just want to wipe the partition table, wipefs could be more reliable.
– pipe
Nov 26 at 9:14
add a comment |
2 Answers
2
active
oldest
votes
up vote
23
down vote
accepted
Will
dd if=/dev/zero of=/dev/sdawipe out a pre-existing partition table?
Yes, the partition table is in the first part of the drive, so writing over it will destroy it. That dd will write over the whole drive if you let it run (so it will take quite some time).
Something like dd bs=512 count=50 if=/dev/zero of=/dev/sda would be enough to overwrite the first 50 sectors, including the MBR partition table and the primary GPT. Though at least according to Wikipedia, GPT has a secondary copy of the partition table at the end of the drive, so overwriting just the part in the head of the drive might not be enough.
(You don't have to use dd, though. head -c10000 /dev/zero > /dev/sda or cat /bin/ls > /dev/sda would have the same effect.)
does
fdisk /dev/sda g(for GPT) wipe out the zeros written by /dev/zero?
Also yes (provided you save the changes).
(However, the phrasing in the title is just confusing, /dev/zero in itself does not do anything any more than any regular storage does.)
answered Nov 25 at 16:43
ilkkachu
54.1k782147
Side note: if the output of the/bin/lsis enough short, then the write operation might overwrite only the few some bytes of the MBR, and the most important part (beginning and ending sectors of the partitions) can remain intact. Although an MBR reinstall (most commonly,grub --install /dev/sda) is still required to make the system bootable again.
– peterh
Nov 25 at 17:33
8
@peterh Note that they're redirecting the actuallsbinary, not the output from running it. The smallest possible "Hello World" ELF binary seems to be 98 bytes (so less than an MBR), but I think it's safe to assume that any binary with actual features should be bigger than an MBR (the notoriously small FreeBSD implementation oflsis 32784 bytes long, even large enough to overwrite the start-of-disk portion of a GPT). ;)
– n.st
Nov 25 at 17:52
Oh yeah, you could use the output oflstoo. A listing of/usr/binwould probably be long enough. I was going to use justechoas an example, but IIRC you need almost 500 bytes to overwrite an MBR partition table, so it's a bit weary to type. (whatever the exact number was)
– ilkkachu
Nov 25 at 18:18
1
You should probably use bs and count with dd for this, otherwise it will be going for some time, You only need to zero the sector. 512 bytes for legacy disks. (see @n.st below) In fact the partition table is at the end of this and is small enough for you to make a copy and zero with a hex editor before copying back to preserve the boot content. There are tools for this as well, it is common for NAS disk initialisation to do this.
– mckenzm
Nov 26 at 0:50
bs doesn't need to exactly match the disk's block size; it should be a large multiple of it.bs=1Morbs=8M(with count=1) might greatly improve performance due to reducing the syscall back-and-forth between dd and the kernel.
– grawity
Nov 26 at 6:56
|
show 3 more comments
up vote
10
down vote
The partition table is stored near the beginning1 of the (logical2) disk device.
Overwriting that area with anything (zeroes from /dev/zero or any other data) will replace the partition table with gibberish, so it will no longer be obvious where the partitions on the device begin.
One can still scan the whole disk and try to identify the "magic bytes" that mark the beginnings of file systems, though.
Conversely, if you use fdisk (or any other partitioning tool) to create a new partition table, the tool will overwrite the first few bytes of the disk to store that new table.
There's only one beginning to the disk, so whatever you do last will "stick" there.
Note, however, that some partition table formats (like GPT) will keep backup copies in different places (e.g. at the end of the disk for GPT), from which some of the partition information can be recovered.
1: e.g. in the first 512 bytes for an MBR or the first and last 17408 bytes for a GPT
2: The drive can internally remap the logical blocks to different parts of the physical medium, but that mapping is invisible to (and unimportant for) the operating system.
answered Nov 25 at 16:45
n.st
5,14311742
1
Almost right - the (old, MBR type) partition table resides in bytes 1BE - 1FD of the MBR. The first few bytes contain the IBL (initial boot loader) .
– RudiC
Nov 25 at 23:15
@RudiC Good point, I've stated it more precisely now.
– n.st
Nov 25 at 23:24
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
23
down vote
accepted
Will
dd if=/dev/zero of=/dev/sdawipe out a pre-existing partition table?
Yes, the partition table is in the first part of the drive, so writing over it will destroy it. That dd will write over the whole drive if you let it run (so it will take quite some time).
Something like dd bs=512 count=50 if=/dev/zero of=/dev/sda would be enough to overwrite the first 50 sectors, including the MBR partition table and the primary GPT. Though at least according to Wikipedia, GPT has a secondary copy of the partition table at the end of the drive, so overwriting just the part in the head of the drive might not be enough.
(You don't have to use dd, though. head -c10000 /dev/zero > /dev/sda or cat /bin/ls > /dev/sda would have the same effect.)
does
fdisk /dev/sda g(for GPT) wipe out the zeros written by /dev/zero?
Also yes (provided you save the changes).
(However, the phrasing in the title is just confusing, /dev/zero in itself does not do anything any more than any regular storage does.)
answered Nov 25 at 16:43
ilkkachu
54.1k782147
Side note: if the output of the/bin/lsis enough short, then the write operation might overwrite only the few some bytes of the MBR, and the most important part (beginning and ending sectors of the partitions) can remain intact. Although an MBR reinstall (most commonly,grub --install /dev/sda) is still required to make the system bootable again.
– peterh
Nov 25 at 17:33
8
@peterh Note that they're redirecting the actuallsbinary, not the output from running it. The smallest possible "Hello World" ELF binary seems to be 98 bytes (so less than an MBR), but I think it's safe to assume that any binary with actual features should be bigger than an MBR (the notoriously small FreeBSD implementation oflsis 32784 bytes long, even large enough to overwrite the start-of-disk portion of a GPT). ;)
– n.st
Nov 25 at 17:52
Oh yeah, you could use the output oflstoo. A listing of/usr/binwould probably be long enough. I was going to use justechoas an example, but IIRC you need almost 500 bytes to overwrite an MBR partition table, so it's a bit weary to type. (whatever the exact number was)
– ilkkachu
Nov 25 at 18:18
1
You should probably use bs and count with dd for this, otherwise it will be going for some time, You only need to zero the sector. 512 bytes for legacy disks. (see @n.st below) In fact the partition table is at the end of this and is small enough for you to make a copy and zero with a hex editor before copying back to preserve the boot content. There are tools for this as well, it is common for NAS disk initialisation to do this.
– mckenzm
Nov 26 at 0:50
bs doesn't need to exactly match the disk's block size; it should be a large multiple of it.bs=1Morbs=8M(with count=1) might greatly improve performance due to reducing the syscall back-and-forth between dd and the kernel.
– grawity
Nov 26 at 6:56
|
show 3 more comments
up vote
23
down vote
accepted
Will
dd if=/dev/zero of=/dev/sdawipe out a pre-existing partition table?
Yes, the partition table is in the first part of the drive, so writing over it will destroy it. That dd will write over the whole drive if you let it run (so it will take quite some time).
Something like dd bs=512 count=50 if=/dev/zero of=/dev/sda would be enough to overwrite the first 50 sectors, including the MBR partition table and the primary GPT. Though at least according to Wikipedia, GPT has a secondary copy of the partition table at the end of the drive, so overwriting just the part in the head of the drive might not be enough.
(You don't have to use dd, though. head -c10000 /dev/zero > /dev/sda or cat /bin/ls > /dev/sda would have the same effect.)
does
fdisk /dev/sda g(for GPT) wipe out the zeros written by /dev/zero?
Also yes (provided you save the changes).
(However, the phrasing in the title is just confusing, /dev/zero in itself does not do anything any more than any regular storage does.)
answered Nov 25 at 16:43
ilkkachu
54.1k782147
Side note: if the output of the/bin/lsis enough short, then the write operation might overwrite only the few some bytes of the MBR, and the most important part (beginning and ending sectors of the partitions) can remain intact. Although an MBR reinstall (most commonly,grub --install /dev/sda) is still required to make the system bootable again.
– peterh
Nov 25 at 17:33
8
@peterh Note that they're redirecting the actuallsbinary, not the output from running it. The smallest possible "Hello World" ELF binary seems to be 98 bytes (so less than an MBR), but I think it's safe to assume that any binary with actual features should be bigger than an MBR (the notoriously small FreeBSD implementation oflsis 32784 bytes long, even large enough to overwrite the start-of-disk portion of a GPT). ;)
– n.st
Nov 25 at 17:52
Oh yeah, you could use the output oflstoo. A listing of/usr/binwould probably be long enough. I was going to use justechoas an example, but IIRC you need almost 500 bytes to overwrite an MBR partition table, so it's a bit weary to type. (whatever the exact number was)
– ilkkachu
Nov 25 at 18:18
1
You should probably use bs and count with dd for this, otherwise it will be going for some time, You only need to zero the sector. 512 bytes for legacy disks. (see @n.st below) In fact the partition table is at the end of this and is small enough for you to make a copy and zero with a hex editor before copying back to preserve the boot content. There are tools for this as well, it is common for NAS disk initialisation to do this.
– mckenzm
Nov 26 at 0:50
bs doesn't need to exactly match the disk's block size; it should be a large multiple of it.bs=1Morbs=8M(with count=1) might greatly improve performance due to reducing the syscall back-and-forth between dd and the kernel.
– grawity
Nov 26 at 6:56
|
show 3 more comments
up vote
23
down vote
accepted
up vote
23
down vote
accepted
Will
dd if=/dev/zero of=/dev/sdawipe out a pre-existing partition table?
Yes, the partition table is in the first part of the drive, so writing over it will destroy it. That dd will write over the whole drive if you let it run (so it will take quite some time).
Something like dd bs=512 count=50 if=/dev/zero of=/dev/sda would be enough to overwrite the first 50 sectors, including the MBR partition table and the primary GPT. Though at least according to Wikipedia, GPT has a secondary copy of the partition table at the end of the drive, so overwriting just the part in the head of the drive might not be enough.
(You don't have to use dd, though. head -c10000 /dev/zero > /dev/sda or cat /bin/ls > /dev/sda would have the same effect.)
does
fdisk /dev/sda g(for GPT) wipe out the zeros written by /dev/zero?
Also yes (provided you save the changes).
(However, the phrasing in the title is just confusing, /dev/zero in itself does not do anything any more than any regular storage does.)
answered Nov 25 at 16:43
ilkkachu
54.1k782147
Will
dd if=/dev/zero of=/dev/sdawipe out a pre-existing partition table?
Yes, the partition table is in the first part of the drive, so writing over it will destroy it. That dd will write over the whole drive if you let it run (so it will take quite some time).
Something like dd bs=512 count=50 if=/dev/zero of=/dev/sda would be enough to overwrite the first 50 sectors, including the MBR partition table and the primary GPT. Though at least according to Wikipedia, GPT has a secondary copy of the partition table at the end of the drive, so overwriting just the part in the head of the drive might not be enough.
(You don't have to use dd, though. head -c10000 /dev/zero > /dev/sda or cat /bin/ls > /dev/sda would have the same effect.)
does
fdisk /dev/sda g(for GPT) wipe out the zeros written by /dev/zero?
Also yes (provided you save the changes).
(However, the phrasing in the title is just confusing, /dev/zero in itself does not do anything any more than any regular storage does.)
answered Nov 25 at 16:43
ilkkachu
54.1k782147
edited Nov 26 at 6:52
answered Nov 25 at 16:43
ilkkachu
54.1k782147
answered Nov 25 at 16:43
ilkkachu
54.1k782147
answered Nov 25 at 16:43
ilkkachu
54.1k782147
54.1k782147
Side note: if the output of the/bin/lsis enough short, then the write operation might overwrite only the few some bytes of the MBR, and the most important part (beginning and ending sectors of the partitions) can remain intact. Although an MBR reinstall (most commonly,grub --install /dev/sda) is still required to make the system bootable again.
– peterh
Nov 25 at 17:33
8
@peterh Note that they're redirecting the actuallsbinary, not the output from running it. The smallest possible "Hello World" ELF binary seems to be 98 bytes (so less than an MBR), but I think it's safe to assume that any binary with actual features should be bigger than an MBR (the notoriously small FreeBSD implementation oflsis 32784 bytes long, even large enough to overwrite the start-of-disk portion of a GPT). ;)
– n.st
Nov 25 at 17:52
Oh yeah, you could use the output oflstoo. A listing of/usr/binwould probably be long enough. I was going to use justechoas an example, but IIRC you need almost 500 bytes to overwrite an MBR partition table, so it's a bit weary to type. (whatever the exact number was)
– ilkkachu
Nov 25 at 18:18
1
You should probably use bs and count with dd for this, otherwise it will be going for some time, You only need to zero the sector. 512 bytes for legacy disks. (see @n.st below) In fact the partition table is at the end of this and is small enough for you to make a copy and zero with a hex editor before copying back to preserve the boot content. There are tools for this as well, it is common for NAS disk initialisation to do this.
– mckenzm
Nov 26 at 0:50
bs doesn't need to exactly match the disk's block size; it should be a large multiple of it.bs=1Morbs=8M(with count=1) might greatly improve performance due to reducing the syscall back-and-forth between dd and the kernel.
– grawity
Nov 26 at 6:56
|
show 3 more comments
Side note: if the output of the/bin/lsis enough short, then the write operation might overwrite only the few some bytes of the MBR, and the most important part (beginning and ending sectors of the partitions) can remain intact. Although an MBR reinstall (most commonly,grub --install /dev/sda) is still required to make the system bootable again.
– peterh
Nov 25 at 17:33
8
@peterh Note that they're redirecting the actuallsbinary, not the output from running it. The smallest possible "Hello World" ELF binary seems to be 98 bytes (so less than an MBR), but I think it's safe to assume that any binary with actual features should be bigger than an MBR (the notoriously small FreeBSD implementation oflsis 32784 bytes long, even large enough to overwrite the start-of-disk portion of a GPT). ;)
– n.st
Nov 25 at 17:52
Oh yeah, you could use the output oflstoo. A listing of/usr/binwould probably be long enough. I was going to use justechoas an example, but IIRC you need almost 500 bytes to overwrite an MBR partition table, so it's a bit weary to type. (whatever the exact number was)
– ilkkachu
Nov 25 at 18:18
1
You should probably use bs and count with dd for this, otherwise it will be going for some time, You only need to zero the sector. 512 bytes for legacy disks. (see @n.st below) In fact the partition table is at the end of this and is small enough for you to make a copy and zero with a hex editor before copying back to preserve the boot content. There are tools for this as well, it is common for NAS disk initialisation to do this.
– mckenzm
Nov 26 at 0:50
bs doesn't need to exactly match the disk's block size; it should be a large multiple of it.bs=1Morbs=8M(with count=1) might greatly improve performance due to reducing the syscall back-and-forth between dd and the kernel.
– grawity
Nov 26 at 6:56
Side note: if the output of the
/bin/ls is enough short, then the write operation might overwrite only the few some bytes of the MBR, and the most important part (beginning and ending sectors of the partitions) can remain intact. Although an MBR reinstall (most commonly, grub --install /dev/sda) is still required to make the system bootable again.– peterh
Nov 25 at 17:33
Side note: if the output of the
/bin/ls is enough short, then the write operation might overwrite only the few some bytes of the MBR, and the most important part (beginning and ending sectors of the partitions) can remain intact. Although an MBR reinstall (most commonly, grub --install /dev/sda) is still required to make the system bootable again.– peterh
Nov 25 at 17:33
8
8
@peterh Note that they're redirecting the actual
ls binary, not the output from running it. The smallest possible "Hello World" ELF binary seems to be 98 bytes (so less than an MBR), but I think it's safe to assume that any binary with actual features should be bigger than an MBR (the notoriously small FreeBSD implementation of ls is 32784 bytes long, even large enough to overwrite the start-of-disk portion of a GPT). ;)– n.st
Nov 25 at 17:52
@peterh Note that they're redirecting the actual
ls binary, not the output from running it. The smallest possible "Hello World" ELF binary seems to be 98 bytes (so less than an MBR), but I think it's safe to assume that any binary with actual features should be bigger than an MBR (the notoriously small FreeBSD implementation of ls is 32784 bytes long, even large enough to overwrite the start-of-disk portion of a GPT). ;)– n.st
Nov 25 at 17:52
Oh yeah, you could use the output of
ls too. A listing of /usr/bin would probably be long enough. I was going to use just echo as an example, but IIRC you need almost 500 bytes to overwrite an MBR partition table, so it's a bit weary to type. (whatever the exact number was)– ilkkachu
Nov 25 at 18:18
Oh yeah, you could use the output of
ls too. A listing of /usr/bin would probably be long enough. I was going to use just echo as an example, but IIRC you need almost 500 bytes to overwrite an MBR partition table, so it's a bit weary to type. (whatever the exact number was)– ilkkachu
Nov 25 at 18:18
1
1
You should probably use bs and count with dd for this, otherwise it will be going for some time, You only need to zero the sector. 512 bytes for legacy disks. (see @n.st below) In fact the partition table is at the end of this and is small enough for you to make a copy and zero with a hex editor before copying back to preserve the boot content. There are tools for this as well, it is common for NAS disk initialisation to do this.
– mckenzm
Nov 26 at 0:50
You should probably use bs and count with dd for this, otherwise it will be going for some time, You only need to zero the sector. 512 bytes for legacy disks. (see @n.st below) In fact the partition table is at the end of this and is small enough for you to make a copy and zero with a hex editor before copying back to preserve the boot content. There are tools for this as well, it is common for NAS disk initialisation to do this.
– mckenzm
Nov 26 at 0:50
bs doesn't need to exactly match the disk's block size; it should be a large multiple of it.
bs=1M or bs=8M (with count=1) might greatly improve performance due to reducing the syscall back-and-forth between dd and the kernel.– grawity
Nov 26 at 6:56
bs doesn't need to exactly match the disk's block size; it should be a large multiple of it.
bs=1M or bs=8M (with count=1) might greatly improve performance due to reducing the syscall back-and-forth between dd and the kernel.– grawity
Nov 26 at 6:56
|
show 3 more comments
up vote
10
down vote
The partition table is stored near the beginning1 of the (logical2) disk device.
Overwriting that area with anything (zeroes from /dev/zero or any other data) will replace the partition table with gibberish, so it will no longer be obvious where the partitions on the device begin.
One can still scan the whole disk and try to identify the "magic bytes" that mark the beginnings of file systems, though.
Conversely, if you use fdisk (or any other partitioning tool) to create a new partition table, the tool will overwrite the first few bytes of the disk to store that new table.
There's only one beginning to the disk, so whatever you do last will "stick" there.
Note, however, that some partition table formats (like GPT) will keep backup copies in different places (e.g. at the end of the disk for GPT), from which some of the partition information can be recovered.
1: e.g. in the first 512 bytes for an MBR or the first and last 17408 bytes for a GPT
2: The drive can internally remap the logical blocks to different parts of the physical medium, but that mapping is invisible to (and unimportant for) the operating system.
answered Nov 25 at 16:45
n.st
5,14311742
1
Almost right - the (old, MBR type) partition table resides in bytes 1BE - 1FD of the MBR. The first few bytes contain the IBL (initial boot loader) .
– RudiC
Nov 25 at 23:15
@RudiC Good point, I've stated it more precisely now.
– n.st
Nov 25 at 23:24
add a comment |
up vote
10
down vote
The partition table is stored near the beginning1 of the (logical2) disk device.
Overwriting that area with anything (zeroes from /dev/zero or any other data) will replace the partition table with gibberish, so it will no longer be obvious where the partitions on the device begin.
One can still scan the whole disk and try to identify the "magic bytes" that mark the beginnings of file systems, though.
Conversely, if you use fdisk (or any other partitioning tool) to create a new partition table, the tool will overwrite the first few bytes of the disk to store that new table.
There's only one beginning to the disk, so whatever you do last will "stick" there.
Note, however, that some partition table formats (like GPT) will keep backup copies in different places (e.g. at the end of the disk for GPT), from which some of the partition information can be recovered.
1: e.g. in the first 512 bytes for an MBR or the first and last 17408 bytes for a GPT
2: The drive can internally remap the logical blocks to different parts of the physical medium, but that mapping is invisible to (and unimportant for) the operating system.
answered Nov 25 at 16:45
n.st
5,14311742
1
Almost right - the (old, MBR type) partition table resides in bytes 1BE - 1FD of the MBR. The first few bytes contain the IBL (initial boot loader) .
– RudiC
Nov 25 at 23:15
@RudiC Good point, I've stated it more precisely now.
– n.st
Nov 25 at 23:24
add a comment |
up vote
10
down vote
up vote
10
down vote
The partition table is stored near the beginning1 of the (logical2) disk device.
Overwriting that area with anything (zeroes from /dev/zero or any other data) will replace the partition table with gibberish, so it will no longer be obvious where the partitions on the device begin.
One can still scan the whole disk and try to identify the "magic bytes" that mark the beginnings of file systems, though.
Conversely, if you use fdisk (or any other partitioning tool) to create a new partition table, the tool will overwrite the first few bytes of the disk to store that new table.
There's only one beginning to the disk, so whatever you do last will "stick" there.
Note, however, that some partition table formats (like GPT) will keep backup copies in different places (e.g. at the end of the disk for GPT), from which some of the partition information can be recovered.
1: e.g. in the first 512 bytes for an MBR or the first and last 17408 bytes for a GPT
2: The drive can internally remap the logical blocks to different parts of the physical medium, but that mapping is invisible to (and unimportant for) the operating system.
answered Nov 25 at 16:45
n.st
5,14311742
The partition table is stored near the beginning1 of the (logical2) disk device.
Overwriting that area with anything (zeroes from /dev/zero or any other data) will replace the partition table with gibberish, so it will no longer be obvious where the partitions on the device begin.
One can still scan the whole disk and try to identify the "magic bytes" that mark the beginnings of file systems, though.
Conversely, if you use fdisk (or any other partitioning tool) to create a new partition table, the tool will overwrite the first few bytes of the disk to store that new table.
There's only one beginning to the disk, so whatever you do last will "stick" there.
Note, however, that some partition table formats (like GPT) will keep backup copies in different places (e.g. at the end of the disk for GPT), from which some of the partition information can be recovered.
1: e.g. in the first 512 bytes for an MBR or the first and last 17408 bytes for a GPT
2: The drive can internally remap the logical blocks to different parts of the physical medium, but that mapping is invisible to (and unimportant for) the operating system.
answered Nov 25 at 16:45
n.st
5,14311742
edited Nov 25 at 23:23
answered Nov 25 at 16:45
n.st
5,14311742
answered Nov 25 at 16:45
n.st
5,14311742
answered Nov 25 at 16:45
n.st
5,14311742
5,14311742
1
Almost right - the (old, MBR type) partition table resides in bytes 1BE - 1FD of the MBR. The first few bytes contain the IBL (initial boot loader) .
– RudiC
Nov 25 at 23:15
@RudiC Good point, I've stated it more precisely now.
– n.st
Nov 25 at 23:24
add a comment |
1
Almost right - the (old, MBR type) partition table resides in bytes 1BE - 1FD of the MBR. The first few bytes contain the IBL (initial boot loader) .
– RudiC
Nov 25 at 23:15
@RudiC Good point, I've stated it more precisely now.
– n.st
Nov 25 at 23:24
1
1
Almost right - the (old, MBR type) partition table resides in bytes 1BE - 1FD of the MBR. The first few bytes contain the IBL (initial boot loader) .
– RudiC
Nov 25 at 23:15
Almost right - the (old, MBR type) partition table resides in bytes 1BE - 1FD of the MBR. The first few bytes contain the IBL (initial boot loader) .
– RudiC
Nov 25 at 23:15
@RudiC Good point, I've stated it more precisely now.
– n.st
Nov 25 at 23:24
@RudiC Good point, I've stated it more precisely now.
– n.st
Nov 25 at 23:24
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f484060%2fwill-dd-if-dev-zero-of-dev-sda-wipe-out-a-pre-existing-partition-table%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
6
That's not
/dev/zerowiping something out, it'sddwiping it out by copying over it. The facts that the bytes happen to be zero, and that the zero bytes happen to come from/dev/zeroinstead of some other source of zeroes, are minor details.– chrylis
Nov 26 at 3:07
2
If you just want to wipe the partition table, wipefs could be more reliable.
– pipe
Nov 26 at 9:14