Why does writing random data using dd result in disk partitions?
Prior to running the dd
command, the command lsblk
returned the output below:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
The command dd if=/dev/urandom of=/dev/sda conv=fsync status=progress
is run. The device however loses power and shuts down. When power is reinstated, the command lsblk
returns the following output:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
sda2 8:2 0 487.5G 0 disk
partition dd lsblk
|
show 4 more comments
Prior to running the dd
command, the command lsblk
returned the output below:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
The command dd if=/dev/urandom of=/dev/sda conv=fsync status=progress
is run. The device however loses power and shuts down. When power is reinstated, the command lsblk
returns the following output:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
sda2 8:2 0 487.5G 0 disk
partition dd lsblk
@RuiFRibeiro - Thanks for the analogy however it isn't clear as to whydd
would result in partitions especially if the command is intended to wipe disks?
– Motivated
yesterday
1
Coincidence: it is very un-likely to be related to the power cut. You write random data to the device. Some of this random data went to the first few blocks, this is where the partition tables live. You probably ended up defining a partition.
– ctrl-alt-delor
yesterday
can you post the result offile /dev/sda*
andsudo fdisk -l /dev/sda*
?
– phuclv
23 hours ago
@phuclv - As i have started the process, will the output still be valuable?
– Motivated
9 hours ago
1
@Motivated Note thatdd
purpose is not per-se to wipe disks. Writing random data to a disk can produce random results.
– jjmontes
7 hours ago
|
show 4 more comments
Prior to running the dd
command, the command lsblk
returned the output below:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
The command dd if=/dev/urandom of=/dev/sda conv=fsync status=progress
is run. The device however loses power and shuts down. When power is reinstated, the command lsblk
returns the following output:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
sda2 8:2 0 487.5G 0 disk
partition dd lsblk
Prior to running the dd
command, the command lsblk
returned the output below:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
The command dd if=/dev/urandom of=/dev/sda conv=fsync status=progress
is run. The device however loses power and shuts down. When power is reinstated, the command lsblk
returns the following output:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
sda2 8:2 0 487.5G 0 disk
partition dd lsblk
partition dd lsblk
edited 6 hours ago
Boann
1537
1537
asked yesterday
MotivatedMotivated
1566
1566
@RuiFRibeiro - Thanks for the analogy however it isn't clear as to whydd
would result in partitions especially if the command is intended to wipe disks?
– Motivated
yesterday
1
Coincidence: it is very un-likely to be related to the power cut. You write random data to the device. Some of this random data went to the first few blocks, this is where the partition tables live. You probably ended up defining a partition.
– ctrl-alt-delor
yesterday
can you post the result offile /dev/sda*
andsudo fdisk -l /dev/sda*
?
– phuclv
23 hours ago
@phuclv - As i have started the process, will the output still be valuable?
– Motivated
9 hours ago
1
@Motivated Note thatdd
purpose is not per-se to wipe disks. Writing random data to a disk can produce random results.
– jjmontes
7 hours ago
|
show 4 more comments
@RuiFRibeiro - Thanks for the analogy however it isn't clear as to whydd
would result in partitions especially if the command is intended to wipe disks?
– Motivated
yesterday
1
Coincidence: it is very un-likely to be related to the power cut. You write random data to the device. Some of this random data went to the first few blocks, this is where the partition tables live. You probably ended up defining a partition.
– ctrl-alt-delor
yesterday
can you post the result offile /dev/sda*
andsudo fdisk -l /dev/sda*
?
– phuclv
23 hours ago
@phuclv - As i have started the process, will the output still be valuable?
– Motivated
9 hours ago
1
@Motivated Note thatdd
purpose is not per-se to wipe disks. Writing random data to a disk can produce random results.
– jjmontes
7 hours ago
@RuiFRibeiro - Thanks for the analogy however it isn't clear as to why
dd
would result in partitions especially if the command is intended to wipe disks?– Motivated
yesterday
@RuiFRibeiro - Thanks for the analogy however it isn't clear as to why
dd
would result in partitions especially if the command is intended to wipe disks?– Motivated
yesterday
1
1
Coincidence: it is very un-likely to be related to the power cut. You write random data to the device. Some of this random data went to the first few blocks, this is where the partition tables live. You probably ended up defining a partition.
– ctrl-alt-delor
yesterday
Coincidence: it is very un-likely to be related to the power cut. You write random data to the device. Some of this random data went to the first few blocks, this is where the partition tables live. You probably ended up defining a partition.
– ctrl-alt-delor
yesterday
can you post the result of
file /dev/sda*
and sudo fdisk -l /dev/sda*
?– phuclv
23 hours ago
can you post the result of
file /dev/sda*
and sudo fdisk -l /dev/sda*
?– phuclv
23 hours ago
@phuclv - As i have started the process, will the output still be valuable?
– Motivated
9 hours ago
@phuclv - As i have started the process, will the output still be valuable?
– Motivated
9 hours ago
1
1
@Motivated Note that
dd
purpose is not per-se to wipe disks. Writing random data to a disk can produce random results.– jjmontes
7 hours ago
@Motivated Note that
dd
purpose is not per-se to wipe disks. Writing random data to a disk can produce random results.– jjmontes
7 hours ago
|
show 4 more comments
4 Answers
4
active
oldest
votes
Several possibilities:
Linux supports a lot of different partition table types, some of which use very few magic bytes, and then it's easy to mis-identify random data (*) [so it's possible to randomly generate a somewhat "valid" partition table].
Some partition table types have backups at the end of the disk as well (most notably GPT) and that could be picked up on if the start of the drive was replaced with random garbage.
The device doesn't work properly and it was disconnected before it finished writing the data, or keeps returning old data, so partition table survives. Sometimes this happens with USB sticks.
...
(*) Make 1000 files with random data in them and see what comes out:
$ truncate -s 8K {0001..1000}
$ shred -n 1 {0001..1000}
$ file -s {0001..1000} | grep -v data
0099: COM executable for DOS
0300: DOS executable (COM)
0302: TTComp archive, binary, 4K dictionary
0389: Dyalog APL component file 64-bit level 1 journaled checksummed version 192.192
0407: COM executable for DOS
0475: PGP11Secret Sub-key -
....
The goal of random-shredding a drive is to make old data vanish for good. There is no promise the drive will appear empty, unused, in pristine condition afterwards.
It's common to follow up with a zero wipe to achieve that. If you are using LVM, it's normal for LVM to zero out the first few sectors of any LV you create so old data won't interfere.
There's also a dedicated utility (wipefs
) to get rid of old magic byte signatures which you can use to get rid of filesystem and partition table metadata.
The devices had been previously erased using the ATA Secure Erase command. I assume that this would remove data such that 1. it is irrecoverable 2. no partition information survives. If this is true, do you mean to say that when running thedd
command, the generation of random data when interrupted can result in data that looks like partition tables? Also these are SATA hard disks (non-SSD).
– Motivated
yesterday
4
Random data can look like anything. That's what it means to be random. Are you familiar with the Infinite Monkeys Theorem? It states that if a large enough amount of monkeys randomly type on typewriters for a long enough time, one of them will at some point or another produce the complete works of Shakespeare. An MBR partition table is really small (only 64 bytes), it has no checksums or verification, and a very dense format. It is highly likely that a random string of 64 bytes will produce a valid partition table. Other partition table formats are similarly simple.
– Jörg W Mittag
yesterday
Yes the partition table is only 64 bytes, (at the end) the partition type is only 1 byte, and the entries need to be lawful or sequential. So zeroing the first cluster/sector/512 byes on MBR is sensible. You also do not want unpredictable boot behaviour, less likely, but still a risk.
– mckenzm
23 hours ago
add a comment |
As seen here, the MBR (Master Boot Record) is relatively simple; https://en.wikipedia.org/wiki/Master_boot_record.
When you use /dev/urandom
you can always create something that looks like a partition table. The solution is to fill the partition table regions with zero and use dev/urandom
for the rest.
Linux also supports other additional disk formats that can also potentially be triggered, causing "invalid" partitions to show up when filling with random data.
New contributor
add a comment |
The thing that defines a collection of 512 bytes as being a Master Boot Record is the presence of the values 0x55 0xAA
at the end. There's a 1-in-65,536 chance of /dev/urandom
producing such a value: not too likely, but similarly improbable things happen all the time.
(Some other partition tables, such as the Apple Partition Map, have similarly short signatures. It's possible you've generated one of them instead.)
add a comment |
Was such partition present some time before on that disk?
If the disk uses GPT, maybe the Secondary GPT Header got restored and it still had the old partition table.
https://en.wikipedia.org/wiki/GUID_Partition_Table
New contributor
add a comment |
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
});
}
});
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%2f492835%2fwhy-does-writing-random-data-using-dd-result-in-disk-partitions%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Several possibilities:
Linux supports a lot of different partition table types, some of which use very few magic bytes, and then it's easy to mis-identify random data (*) [so it's possible to randomly generate a somewhat "valid" partition table].
Some partition table types have backups at the end of the disk as well (most notably GPT) and that could be picked up on if the start of the drive was replaced with random garbage.
The device doesn't work properly and it was disconnected before it finished writing the data, or keeps returning old data, so partition table survives. Sometimes this happens with USB sticks.
...
(*) Make 1000 files with random data in them and see what comes out:
$ truncate -s 8K {0001..1000}
$ shred -n 1 {0001..1000}
$ file -s {0001..1000} | grep -v data
0099: COM executable for DOS
0300: DOS executable (COM)
0302: TTComp archive, binary, 4K dictionary
0389: Dyalog APL component file 64-bit level 1 journaled checksummed version 192.192
0407: COM executable for DOS
0475: PGP11Secret Sub-key -
....
The goal of random-shredding a drive is to make old data vanish for good. There is no promise the drive will appear empty, unused, in pristine condition afterwards.
It's common to follow up with a zero wipe to achieve that. If you are using LVM, it's normal for LVM to zero out the first few sectors of any LV you create so old data won't interfere.
There's also a dedicated utility (wipefs
) to get rid of old magic byte signatures which you can use to get rid of filesystem and partition table metadata.
The devices had been previously erased using the ATA Secure Erase command. I assume that this would remove data such that 1. it is irrecoverable 2. no partition information survives. If this is true, do you mean to say that when running thedd
command, the generation of random data when interrupted can result in data that looks like partition tables? Also these are SATA hard disks (non-SSD).
– Motivated
yesterday
4
Random data can look like anything. That's what it means to be random. Are you familiar with the Infinite Monkeys Theorem? It states that if a large enough amount of monkeys randomly type on typewriters for a long enough time, one of them will at some point or another produce the complete works of Shakespeare. An MBR partition table is really small (only 64 bytes), it has no checksums or verification, and a very dense format. It is highly likely that a random string of 64 bytes will produce a valid partition table. Other partition table formats are similarly simple.
– Jörg W Mittag
yesterday
Yes the partition table is only 64 bytes, (at the end) the partition type is only 1 byte, and the entries need to be lawful or sequential. So zeroing the first cluster/sector/512 byes on MBR is sensible. You also do not want unpredictable boot behaviour, less likely, but still a risk.
– mckenzm
23 hours ago
add a comment |
Several possibilities:
Linux supports a lot of different partition table types, some of which use very few magic bytes, and then it's easy to mis-identify random data (*) [so it's possible to randomly generate a somewhat "valid" partition table].
Some partition table types have backups at the end of the disk as well (most notably GPT) and that could be picked up on if the start of the drive was replaced with random garbage.
The device doesn't work properly and it was disconnected before it finished writing the data, or keeps returning old data, so partition table survives. Sometimes this happens with USB sticks.
...
(*) Make 1000 files with random data in them and see what comes out:
$ truncate -s 8K {0001..1000}
$ shred -n 1 {0001..1000}
$ file -s {0001..1000} | grep -v data
0099: COM executable for DOS
0300: DOS executable (COM)
0302: TTComp archive, binary, 4K dictionary
0389: Dyalog APL component file 64-bit level 1 journaled checksummed version 192.192
0407: COM executable for DOS
0475: PGP11Secret Sub-key -
....
The goal of random-shredding a drive is to make old data vanish for good. There is no promise the drive will appear empty, unused, in pristine condition afterwards.
It's common to follow up with a zero wipe to achieve that. If you are using LVM, it's normal for LVM to zero out the first few sectors of any LV you create so old data won't interfere.
There's also a dedicated utility (wipefs
) to get rid of old magic byte signatures which you can use to get rid of filesystem and partition table metadata.
The devices had been previously erased using the ATA Secure Erase command. I assume that this would remove data such that 1. it is irrecoverable 2. no partition information survives. If this is true, do you mean to say that when running thedd
command, the generation of random data when interrupted can result in data that looks like partition tables? Also these are SATA hard disks (non-SSD).
– Motivated
yesterday
4
Random data can look like anything. That's what it means to be random. Are you familiar with the Infinite Monkeys Theorem? It states that if a large enough amount of monkeys randomly type on typewriters for a long enough time, one of them will at some point or another produce the complete works of Shakespeare. An MBR partition table is really small (only 64 bytes), it has no checksums or verification, and a very dense format. It is highly likely that a random string of 64 bytes will produce a valid partition table. Other partition table formats are similarly simple.
– Jörg W Mittag
yesterday
Yes the partition table is only 64 bytes, (at the end) the partition type is only 1 byte, and the entries need to be lawful or sequential. So zeroing the first cluster/sector/512 byes on MBR is sensible. You also do not want unpredictable boot behaviour, less likely, but still a risk.
– mckenzm
23 hours ago
add a comment |
Several possibilities:
Linux supports a lot of different partition table types, some of which use very few magic bytes, and then it's easy to mis-identify random data (*) [so it's possible to randomly generate a somewhat "valid" partition table].
Some partition table types have backups at the end of the disk as well (most notably GPT) and that could be picked up on if the start of the drive was replaced with random garbage.
The device doesn't work properly and it was disconnected before it finished writing the data, or keeps returning old data, so partition table survives. Sometimes this happens with USB sticks.
...
(*) Make 1000 files with random data in them and see what comes out:
$ truncate -s 8K {0001..1000}
$ shred -n 1 {0001..1000}
$ file -s {0001..1000} | grep -v data
0099: COM executable for DOS
0300: DOS executable (COM)
0302: TTComp archive, binary, 4K dictionary
0389: Dyalog APL component file 64-bit level 1 journaled checksummed version 192.192
0407: COM executable for DOS
0475: PGP11Secret Sub-key -
....
The goal of random-shredding a drive is to make old data vanish for good. There is no promise the drive will appear empty, unused, in pristine condition afterwards.
It's common to follow up with a zero wipe to achieve that. If you are using LVM, it's normal for LVM to zero out the first few sectors of any LV you create so old data won't interfere.
There's also a dedicated utility (wipefs
) to get rid of old magic byte signatures which you can use to get rid of filesystem and partition table metadata.
Several possibilities:
Linux supports a lot of different partition table types, some of which use very few magic bytes, and then it's easy to mis-identify random data (*) [so it's possible to randomly generate a somewhat "valid" partition table].
Some partition table types have backups at the end of the disk as well (most notably GPT) and that could be picked up on if the start of the drive was replaced with random garbage.
The device doesn't work properly and it was disconnected before it finished writing the data, or keeps returning old data, so partition table survives. Sometimes this happens with USB sticks.
...
(*) Make 1000 files with random data in them and see what comes out:
$ truncate -s 8K {0001..1000}
$ shred -n 1 {0001..1000}
$ file -s {0001..1000} | grep -v data
0099: COM executable for DOS
0300: DOS executable (COM)
0302: TTComp archive, binary, 4K dictionary
0389: Dyalog APL component file 64-bit level 1 journaled checksummed version 192.192
0407: COM executable for DOS
0475: PGP11Secret Sub-key -
....
The goal of random-shredding a drive is to make old data vanish for good. There is no promise the drive will appear empty, unused, in pristine condition afterwards.
It's common to follow up with a zero wipe to achieve that. If you are using LVM, it's normal for LVM to zero out the first few sectors of any LV you create so old data won't interfere.
There's also a dedicated utility (wipefs
) to get rid of old magic byte signatures which you can use to get rid of filesystem and partition table metadata.
answered yesterday
frostschutzfrostschutz
26.2k15282
26.2k15282
The devices had been previously erased using the ATA Secure Erase command. I assume that this would remove data such that 1. it is irrecoverable 2. no partition information survives. If this is true, do you mean to say that when running thedd
command, the generation of random data when interrupted can result in data that looks like partition tables? Also these are SATA hard disks (non-SSD).
– Motivated
yesterday
4
Random data can look like anything. That's what it means to be random. Are you familiar with the Infinite Monkeys Theorem? It states that if a large enough amount of monkeys randomly type on typewriters for a long enough time, one of them will at some point or another produce the complete works of Shakespeare. An MBR partition table is really small (only 64 bytes), it has no checksums or verification, and a very dense format. It is highly likely that a random string of 64 bytes will produce a valid partition table. Other partition table formats are similarly simple.
– Jörg W Mittag
yesterday
Yes the partition table is only 64 bytes, (at the end) the partition type is only 1 byte, and the entries need to be lawful or sequential. So zeroing the first cluster/sector/512 byes on MBR is sensible. You also do not want unpredictable boot behaviour, less likely, but still a risk.
– mckenzm
23 hours ago
add a comment |
The devices had been previously erased using the ATA Secure Erase command. I assume that this would remove data such that 1. it is irrecoverable 2. no partition information survives. If this is true, do you mean to say that when running thedd
command, the generation of random data when interrupted can result in data that looks like partition tables? Also these are SATA hard disks (non-SSD).
– Motivated
yesterday
4
Random data can look like anything. That's what it means to be random. Are you familiar with the Infinite Monkeys Theorem? It states that if a large enough amount of monkeys randomly type on typewriters for a long enough time, one of them will at some point or another produce the complete works of Shakespeare. An MBR partition table is really small (only 64 bytes), it has no checksums or verification, and a very dense format. It is highly likely that a random string of 64 bytes will produce a valid partition table. Other partition table formats are similarly simple.
– Jörg W Mittag
yesterday
Yes the partition table is only 64 bytes, (at the end) the partition type is only 1 byte, and the entries need to be lawful or sequential. So zeroing the first cluster/sector/512 byes on MBR is sensible. You also do not want unpredictable boot behaviour, less likely, but still a risk.
– mckenzm
23 hours ago
The devices had been previously erased using the ATA Secure Erase command. I assume that this would remove data such that 1. it is irrecoverable 2. no partition information survives. If this is true, do you mean to say that when running the
dd
command, the generation of random data when interrupted can result in data that looks like partition tables? Also these are SATA hard disks (non-SSD).– Motivated
yesterday
The devices had been previously erased using the ATA Secure Erase command. I assume that this would remove data such that 1. it is irrecoverable 2. no partition information survives. If this is true, do you mean to say that when running the
dd
command, the generation of random data when interrupted can result in data that looks like partition tables? Also these are SATA hard disks (non-SSD).– Motivated
yesterday
4
4
Random data can look like anything. That's what it means to be random. Are you familiar with the Infinite Monkeys Theorem? It states that if a large enough amount of monkeys randomly type on typewriters for a long enough time, one of them will at some point or another produce the complete works of Shakespeare. An MBR partition table is really small (only 64 bytes), it has no checksums or verification, and a very dense format. It is highly likely that a random string of 64 bytes will produce a valid partition table. Other partition table formats are similarly simple.
– Jörg W Mittag
yesterday
Random data can look like anything. That's what it means to be random. Are you familiar with the Infinite Monkeys Theorem? It states that if a large enough amount of monkeys randomly type on typewriters for a long enough time, one of them will at some point or another produce the complete works of Shakespeare. An MBR partition table is really small (only 64 bytes), it has no checksums or verification, and a very dense format. It is highly likely that a random string of 64 bytes will produce a valid partition table. Other partition table formats are similarly simple.
– Jörg W Mittag
yesterday
Yes the partition table is only 64 bytes, (at the end) the partition type is only 1 byte, and the entries need to be lawful or sequential. So zeroing the first cluster/sector/512 byes on MBR is sensible. You also do not want unpredictable boot behaviour, less likely, but still a risk.
– mckenzm
23 hours ago
Yes the partition table is only 64 bytes, (at the end) the partition type is only 1 byte, and the entries need to be lawful or sequential. So zeroing the first cluster/sector/512 byes on MBR is sensible. You also do not want unpredictable boot behaviour, less likely, but still a risk.
– mckenzm
23 hours ago
add a comment |
As seen here, the MBR (Master Boot Record) is relatively simple; https://en.wikipedia.org/wiki/Master_boot_record.
When you use /dev/urandom
you can always create something that looks like a partition table. The solution is to fill the partition table regions with zero and use dev/urandom
for the rest.
Linux also supports other additional disk formats that can also potentially be triggered, causing "invalid" partitions to show up when filling with random data.
New contributor
add a comment |
As seen here, the MBR (Master Boot Record) is relatively simple; https://en.wikipedia.org/wiki/Master_boot_record.
When you use /dev/urandom
you can always create something that looks like a partition table. The solution is to fill the partition table regions with zero and use dev/urandom
for the rest.
Linux also supports other additional disk formats that can also potentially be triggered, causing "invalid" partitions to show up when filling with random data.
New contributor
add a comment |
As seen here, the MBR (Master Boot Record) is relatively simple; https://en.wikipedia.org/wiki/Master_boot_record.
When you use /dev/urandom
you can always create something that looks like a partition table. The solution is to fill the partition table regions with zero and use dev/urandom
for the rest.
Linux also supports other additional disk formats that can also potentially be triggered, causing "invalid" partitions to show up when filling with random data.
New contributor
As seen here, the MBR (Master Boot Record) is relatively simple; https://en.wikipedia.org/wiki/Master_boot_record.
When you use /dev/urandom
you can always create something that looks like a partition table. The solution is to fill the partition table regions with zero and use dev/urandom
for the rest.
Linux also supports other additional disk formats that can also potentially be triggered, causing "invalid" partitions to show up when filling with random data.
New contributor
New contributor
answered yesterday
Adam WaldenbergAdam Waldenberg
1613
1613
New contributor
New contributor
add a comment |
add a comment |
The thing that defines a collection of 512 bytes as being a Master Boot Record is the presence of the values 0x55 0xAA
at the end. There's a 1-in-65,536 chance of /dev/urandom
producing such a value: not too likely, but similarly improbable things happen all the time.
(Some other partition tables, such as the Apple Partition Map, have similarly short signatures. It's possible you've generated one of them instead.)
add a comment |
The thing that defines a collection of 512 bytes as being a Master Boot Record is the presence of the values 0x55 0xAA
at the end. There's a 1-in-65,536 chance of /dev/urandom
producing such a value: not too likely, but similarly improbable things happen all the time.
(Some other partition tables, such as the Apple Partition Map, have similarly short signatures. It's possible you've generated one of them instead.)
add a comment |
The thing that defines a collection of 512 bytes as being a Master Boot Record is the presence of the values 0x55 0xAA
at the end. There's a 1-in-65,536 chance of /dev/urandom
producing such a value: not too likely, but similarly improbable things happen all the time.
(Some other partition tables, such as the Apple Partition Map, have similarly short signatures. It's possible you've generated one of them instead.)
The thing that defines a collection of 512 bytes as being a Master Boot Record is the presence of the values 0x55 0xAA
at the end. There's a 1-in-65,536 chance of /dev/urandom
producing such a value: not too likely, but similarly improbable things happen all the time.
(Some other partition tables, such as the Apple Partition Map, have similarly short signatures. It's possible you've generated one of them instead.)
answered yesterday
MarkMark
2,13611328
2,13611328
add a comment |
add a comment |
Was such partition present some time before on that disk?
If the disk uses GPT, maybe the Secondary GPT Header got restored and it still had the old partition table.
https://en.wikipedia.org/wiki/GUID_Partition_Table
New contributor
add a comment |
Was such partition present some time before on that disk?
If the disk uses GPT, maybe the Secondary GPT Header got restored and it still had the old partition table.
https://en.wikipedia.org/wiki/GUID_Partition_Table
New contributor
add a comment |
Was such partition present some time before on that disk?
If the disk uses GPT, maybe the Secondary GPT Header got restored and it still had the old partition table.
https://en.wikipedia.org/wiki/GUID_Partition_Table
New contributor
Was such partition present some time before on that disk?
If the disk uses GPT, maybe the Secondary GPT Header got restored and it still had the old partition table.
https://en.wikipedia.org/wiki/GUID_Partition_Table
New contributor
New contributor
answered 9 hours ago
Jakub FojtikJakub Fojtik
212
212
New contributor
New contributor
add a comment |
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%2f492835%2fwhy-does-writing-random-data-using-dd-result-in-disk-partitions%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
@RuiFRibeiro - Thanks for the analogy however it isn't clear as to why
dd
would result in partitions especially if the command is intended to wipe disks?– Motivated
yesterday
1
Coincidence: it is very un-likely to be related to the power cut. You write random data to the device. Some of this random data went to the first few blocks, this is where the partition tables live. You probably ended up defining a partition.
– ctrl-alt-delor
yesterday
can you post the result of
file /dev/sda*
andsudo fdisk -l /dev/sda*
?– phuclv
23 hours ago
@phuclv - As i have started the process, will the output still be valuable?
– Motivated
9 hours ago
1
@Motivated Note that
dd
purpose is not per-se to wipe disks. Writing random data to a disk can produce random results.– jjmontes
7 hours ago