Will dd if=/dev/zero of=/dev/sda wipe out a pre-existing partition table?











up vote
10
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







share|improve this question




















  • 2




    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
    4 hours ago















up vote
10
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







share|improve this question




















  • 2




    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
    4 hours ago













up vote
10
down vote

favorite









up vote
10
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







share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 29 mins ago









muru

35.1k581155




35.1k581155










asked 14 hours ago









justinnoor.io

267213




267213








  • 2




    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
    4 hours ago














  • 2




    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
    4 hours ago








2




2




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
4 hours ago




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
4 hours ago










2 Answers
2






active

oldest

votes

















up vote
15
down vote



accepted











Will dd if=/dev/zero of=/dev/sda wipe 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.)






share|improve this answer























  • 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
    13 hours ago






  • 6




    @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
    13 hours ago












  • 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
    13 hours ago






  • 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
    6 hours ago










  • 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
    30 mins ago




















up vote
8
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.






share|improve this answer



















  • 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
    8 hours ago










  • @RudiC Good point, I've stated it more precisely now.
    – n.st
    8 hours ago











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















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

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
15
down vote



accepted











Will dd if=/dev/zero of=/dev/sda wipe 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.)






share|improve this answer























  • 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
    13 hours ago






  • 6




    @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
    13 hours ago












  • 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
    13 hours ago






  • 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
    6 hours ago










  • 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
    30 mins ago

















up vote
15
down vote



accepted











Will dd if=/dev/zero of=/dev/sda wipe 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.)






share|improve this answer























  • 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
    13 hours ago






  • 6




    @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
    13 hours ago












  • 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
    13 hours ago






  • 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
    6 hours ago










  • 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
    30 mins ago















up vote
15
down vote



accepted







up vote
15
down vote



accepted







Will dd if=/dev/zero of=/dev/sda wipe 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.)






share|improve this answer















Will dd if=/dev/zero of=/dev/sda wipe 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.)







share|improve this answer














share|improve this answer



share|improve this answer








edited 33 mins ago

























answered 14 hours ago









ilkkachu

54k782147




54k782147












  • 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
    13 hours ago






  • 6




    @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
    13 hours ago












  • 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
    13 hours ago






  • 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
    6 hours ago










  • 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
    30 mins ago




















  • 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
    13 hours ago






  • 6




    @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
    13 hours ago












  • 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
    13 hours ago






  • 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
    6 hours ago










  • 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
    30 mins ago


















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
13 hours ago




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
13 hours ago




6




6




@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
13 hours ago






@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
13 hours ago














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
13 hours ago




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
13 hours ago




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
6 hours ago




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
6 hours ago












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
30 mins ago






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
30 mins ago














up vote
8
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.






share|improve this answer



















  • 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
    8 hours ago










  • @RudiC Good point, I've stated it more precisely now.
    – n.st
    8 hours ago















up vote
8
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.






share|improve this answer



















  • 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
    8 hours ago










  • @RudiC Good point, I've stated it more precisely now.
    – n.st
    8 hours ago













up vote
8
down vote










up vote
8
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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








edited 8 hours ago

























answered 14 hours ago









n.st

4,49011439




4,49011439








  • 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
    8 hours ago










  • @RudiC Good point, I've stated it more precisely now.
    – n.st
    8 hours ago














  • 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
    8 hours ago










  • @RudiC Good point, I've stated it more precisely now.
    – n.st
    8 hours ago








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
8 hours ago




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
8 hours ago












@RudiC Good point, I've stated it more precisely now.
– n.st
8 hours ago




@RudiC Good point, I've stated it more precisely now.
– n.st
8 hours ago


















 

draft saved


draft discarded



















































 


draft saved


draft discarded














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





















































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







-

Popular posts from this blog

Costa Masnaga

Image
.mw-parser-output .avviso .mbox-text-div>div,.mw-parser-output .avviso .mbox-text-full-div>div{font-size:90%}.mw-parser-output .avviso .mbox-image div{width:52px}.mw-parser-output .avviso .mbox-text-full-div .hide-when-compact{display:block} Questa voce o sezione sull'argomento Lombardia non cita le fonti necessarie o quelle presenti sono insufficienti . Puoi migliorare questa voce aggiungendo citazioni da fonti attendibili secondo le linee guida sull'uso delle fonti. Segui i suggerimenti del progetto di riferimento. Costa Masnaga comune Localizzazione Stato   Italia Regione Lombardia Provincia Lecco Amministrazione Sindaco Sabina Panzeri (Al centro il cittadino) dall'08/06/2009 Territorio Coordinate 45°46′N 9°17′E  /  45.766667°N 9.283333°E 45.766667; 9.283333  ( Costa Masnaga ) Coordinate: 45°46′N 9°17′E  /  45.766667°N 9.283333°E 45.766667; 9.283333  ( Costa Masnaga ) Altitudine 318 m s.l.m...
Read more

Fotorealismo

Image
Guerrino Boatto, Venice's St. Barnaba Church and canal Il fotorealismo è un genere di pittura basato sull'uso di una o più fotografie dalle quali l'artista prende le informazioni necessarie da utilizzare poi nel processo della creazione dell'opera, in genere ad olio o ad acrilico, al fine di avere un aspetto finale il più simile possibile alla fotografia. Indice 1 Storia 2 Lista dei fotorealisti 3 Note 4 Voci correlate 5 Altri progetti Storia | Il fotorealismo è un movimento che nasce negli Stati Uniti d'America alla fine degli anni sessanta [1] sulla scia della Pop Art [2] [3] [4] , e insieme condividono il carattere reazionario verso la travolgente ascesa dei media, che alla metà del ventesimo secolo si trasforma in un fenomeno di massa talmente imponente da minacciare il valore dell'immagine nell'arte. [5] [6] Ne consegue così che, colto il gesto d'inizio che fu della Pop Art, i fotorealisti aprono ad un ...
Read more

Sidney Franklin

Image
Questa voce sull'argomento registi statunitensi è solo un abbozzo . Contribuisci a migliorarla secondo le convenzioni di Wikipedia. Sidney Franklin, foto di Carl Van Vechten Oscar alla memoria Irving G. Thalberg 1943 Sidney Franklin , all'anagrafe Sidney Arnold Franklin , (San Francisco, 21 marzo 1893 – Santa Monica, 18 maggio 1972), è stato un regista, produttore cinematografico e attore statunitense. Il 20 giugno 1963, si sposò con l'attrice australiana Enid Bennett. Il matrimonio durò fino alla morte dell'attrice, il 14 maggio 1969 [1] Indice 1 Filmografia 1.1 Regista 1.2 Aiuto regia (parziale) 1.3 Produttore 1.4 Attore (parziale) 2 Note 3 Altri progetti 4 Collegamenti esterni Filmografia | Regista | The Baby , co-regia Chester M. Franklin (1915) The Rivals , co-regia Chester M. Franklin (1915) Little Dick's First Case , co-regia Chester M. Franklin (1915) Her Filmland Hero , co-...
Read more