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












12















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




















  • 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 '18 at 3:07






  • 2





    If you just want to wipe the partition table, wipefs could be more reliable.

    – pipe
    Nov 26 '18 at 9:14
















12















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




















  • 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 '18 at 3:07






  • 2





    If you just want to wipe the partition table, wipefs could be more reliable.

    – pipe
    Nov 26 '18 at 9:14














12












12








12








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 Nov 26 '18 at 6:56









muru

1




1










asked Nov 25 '18 at 16:29









justinnoor.iojustinnoor.io

360218




360218








  • 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 '18 at 3:07






  • 2





    If you just want to wipe the partition table, wipefs could be more reliable.

    – pipe
    Nov 26 '18 at 9:14














  • 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 '18 at 3:07






  • 2





    If you just want to wipe the partition table, wipefs could be more reliable.

    – pipe
    Nov 26 '18 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 '18 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 '18 at 3:07




2




2





If you just want to wipe the partition table, wipefs could be more reliable.

– pipe
Nov 26 '18 at 9:14





If you just want to wipe the partition table, wipefs could be more reliable.

– pipe
Nov 26 '18 at 9:14










2 Answers
2






active

oldest

votes


















23















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
    Nov 25 '18 at 17:33






  • 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 '18 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 '18 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 '18 at 0:50






  • 1





    Just wanted to add that in case of GPT drives, you MUST wipe the end of disk as well. A compliant GPT implementation will check the secondary table at the end of the disk and re-write the first part as well (ignoring whatever you have there already). See: news.ycombinator.com/item?id=18541493

    – wbkang
    Dec 3 '18 at 1:32



















10














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
    Nov 25 '18 at 23:15











  • @RudiC Good point, I've stated it more precisely now.

    – n.st
    Nov 25 '18 at 23:24











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',
autoActivateHeartbeat: false,
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









23















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
    Nov 25 '18 at 17:33






  • 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 '18 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 '18 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 '18 at 0:50






  • 1





    Just wanted to add that in case of GPT drives, you MUST wipe the end of disk as well. A compliant GPT implementation will check the secondary table at the end of the disk and re-write the first part as well (ignoring whatever you have there already). See: news.ycombinator.com/item?id=18541493

    – wbkang
    Dec 3 '18 at 1:32
















23















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
    Nov 25 '18 at 17:33






  • 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 '18 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 '18 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 '18 at 0:50






  • 1





    Just wanted to add that in case of GPT drives, you MUST wipe the end of disk as well. A compliant GPT implementation will check the secondary table at the end of the disk and re-write the first part as well (ignoring whatever you have there already). See: news.ycombinator.com/item?id=18541493

    – wbkang
    Dec 3 '18 at 1:32














23












23








23








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 Nov 26 '18 at 6:52

























answered Nov 25 '18 at 16:43









ilkkachuilkkachu

56.7k784156




56.7k784156













  • 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 '18 at 17:33






  • 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 '18 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 '18 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 '18 at 0:50






  • 1





    Just wanted to add that in case of GPT drives, you MUST wipe the end of disk as well. A compliant GPT implementation will check the secondary table at the end of the disk and re-write the first part as well (ignoring whatever you have there already). See: news.ycombinator.com/item?id=18541493

    – wbkang
    Dec 3 '18 at 1:32



















  • 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 '18 at 17:33






  • 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 '18 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 '18 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 '18 at 0:50






  • 1





    Just wanted to add that in case of GPT drives, you MUST wipe the end of disk as well. A compliant GPT implementation will check the secondary table at the end of the disk and re-write the first part as well (ignoring whatever you have there already). See: news.ycombinator.com/item?id=18541493

    – wbkang
    Dec 3 '18 at 1:32

















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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 at 0:50




1




1





Just wanted to add that in case of GPT drives, you MUST wipe the end of disk as well. A compliant GPT implementation will check the secondary table at the end of the disk and re-write the first part as well (ignoring whatever you have there already). See: news.ycombinator.com/item?id=18541493

– wbkang
Dec 3 '18 at 1:32





Just wanted to add that in case of GPT drives, you MUST wipe the end of disk as well. A compliant GPT implementation will check the secondary table at the end of the disk and re-write the first part as well (ignoring whatever you have there already). See: news.ycombinator.com/item?id=18541493

– wbkang
Dec 3 '18 at 1:32













10














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
    Nov 25 '18 at 23:15











  • @RudiC Good point, I've stated it more precisely now.

    – n.st
    Nov 25 '18 at 23:24
















10














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
    Nov 25 '18 at 23:15











  • @RudiC Good point, I've stated it more precisely now.

    – n.st
    Nov 25 '18 at 23:24














10












10








10







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 Nov 25 '18 at 23:23

























answered Nov 25 '18 at 16:45









n.stn.st

5,27111943




5,27111943








  • 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 '18 at 23:15











  • @RudiC Good point, I've stated it more precisely now.

    – n.st
    Nov 25 '18 at 23:24














  • 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 '18 at 23:15











  • @RudiC Good point, I've stated it more precisely now.

    – n.st
    Nov 25 '18 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 '18 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 '18 at 23:15













@RudiC Good point, I've stated it more precisely now.

– n.st
Nov 25 '18 at 23:24





@RudiC Good point, I've stated it more precisely now.

– n.st
Nov 25 '18 at 23:24


















draft saved

draft discarded




















































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.




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

How to change which sound is reproduced for terminal bell?

Image
3 Recently upgrade to 18.10 from 18.04, and using the terminal is becoming annoying: the new alert sound is a drip ( /usr/share/sounds/gnome/default/alerts/drip.ogg ), and the previous one is still located at ( /usr/share/sounds/ubuntu/stereo/bell.ogg ). My issue is that at the gnome-terminal, when autocompleting or pressing left BOTH sounds are reproduced, at the same time. I want to just have ubuntu/stereo/bell.ogg active, not both . At the moment I have been only able to reduce the volume of the alerts (but still both are played), or turn the alerts down (but I dislike both "solutions"). gnome-terminal 18.10 teminal-bell share | improve this question ...
Read more

Can I use Tabulator js library in my java Spring + Thymeleaf project?

Image
0 I want to add Tabulator js to my java project. I added tabulator.min.js, tabulator.min.css to resources folder. After that added to my html page these dependencies as recommending in readme.md. <link rel="stylesheet" th:href="@{/css/tabulator.min.css}"> <script type="text/javascript" th:src="@{/js/tabulator.min.js}"></script> Now my tables view all elements, that I have in the html page, but not correct. In the documentation of Tabulator is example how to create header and table, var table = new Tabulator("#example-table", { columns:[ {title:"Name", field:"name", sorter:"string", width:200, editor:true}, {title:"Age", field:"age", sorter:"...
Read more

Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents

Image
up vote 5 down vote favorite 2 I would like to make it so that the vertical space below the title of each chapter is the same when using the Bjornstrup package (i.e. so that the descenders do not affect the spacing - as shown by the red arrow in the picture below). I think I'm fairly happy with the spacing around "A chapter", so I'd really like titles without descenders (e.g. "Contents") to have the same vertical spacing as "A chapter" below the title. I would also like to remove the large "0" in the contents title. Any help appreciated, as always. documentclass[11pt,a4paper]{book} % Packages[![enter image description here][1]][1] usepackage[left=3.5cm, right=3.5cm, top=4.3cm, bottom=4.25cm]{geometry} usepackage[utf8]{inputenc} usepackage{libertine} usepackage[libertine]{newtx...
Read more