ddを使用してランダムデータを書き込むとディスクパーティションが作成されるのはなぜですか？
ddコマンドを実行する前に、コマンドlsblkは以下の出力を返しました。
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
コマンド dd if=/dev/urandom of=/dev/sda conv=fsync status=progressが実行されます。ただし、デバイスは電力を失い、シャットダウンします。電源が回復すると、コマンドlsblkは次の出力を返します。
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
sda2 8:2 0 487.5G 0 disk
いくつかの可能性：
Linuxは多くの異なるパーティションテーブルタイプをサポートしており、そのうちのいくつかはマジックバイトをほとんど使用しないため、ランダムデータ（*）を誤って識別してしまう可能性があります（そのため、「有効な」パーティションテーブルをランダムに生成する可能性があります）。
パーティションテーブルの種類によっては、ディスクの最後にもバックアップがあり（特にGPT）、ドライブの先頭がランダムなガベージに置き換えられた場合にバックアップが取得される可能性があります。
デバイスは正常に動作せず、データの書き込みが完了する前に切断されたか、古いデータが返され続けるため、パーティションテーブルは存続します。これはUSBスティックで発生することがあります。
...
（*）ランダムデータを含む1000個のファイルを作成し、何が表示されるかを確認します。
$ 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: PGP\011Secret Sub-key -
....
ドライブをランダムに細断する目的は、古いデータを完全に消滅させることです。その後、ドライブが空の未使用の状態で元の状態に表示されるという保証はありません。
それを達成するためにゼロワイプでフォローアップするのが一般的です。 LVMを使用している場合、LVMが作成するLVの最初のいくつかのセクターをゼロにするのは正常なことであり、古いデータが干渉しないようにします。
古いマジックバイトシグネチャを削除するための専用ユーティリティ（wipefs）もあり、ファイルシステムとパーティションテーブルのメタデータを削除するために使用できます。
ここに見られるように、MBR（マスターブートレコード）は比較的単純です。 https://en.wikipedia.org/wiki/Master_boot_record 。
/dev/urandomを使用すると、いつでもパーティションテーブルのようなものを作成できます。解決策は、パーティションテーブルの領域をゼロで埋め、残りにはdev/urandomを使用することです。
Linuxはまた、トリガーされる可能性のある他の追加のディスク形式もサポートしているため、ランダムなデータでいっぱいになると「無効な」パーティションが表示されます。
512バイトのコレクションを マスターブートレコード として定義するのは、最後に値0x55 0xAAが存在することです。 65,536分の1の確率で/dev/urandomがそのような値を生成する可能性があります。あまり可能性は高くありませんが、同様にありえないことが常に発生します。
（ Apple Partition Map などの他のパーティションテーブルにも同様に短い署名があります。代わりにそれらの1つを生成した可能性があります。）
そのようなパーティションは以前にそのディスク上に存在していましたか？ディスクがGPTを使用している場合、セカンダリGPTヘッダーが復元され、古いパーティションテーブルが残っている可能性があります。