dd if = / dev / zeroは、ドライブの内容をそのまま残しますか？悪いUSBスティック？
dd if=/dev/zero of=/dev/sdXを使用して、ドライブのすべてのパーティションを削除できると思いました。過去にはこれは常に私にとってはうまくいきましたが、この場合は期待どおりに機能していません。
#check the partitions
➜ ~ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 477G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 476.4G 0 part /
sdb 8:16 1 14.6G 0 disk
├─sdb1 8:17 1 292M 0 part /media/james/Gentoo AMD64 20190703T214502Z
└─sdb2 8:18 1 6.3M 0 part /media/james/GENTOOLIVE
#unmount and confirm the drive is still seen.
➜ ~ Sudo umount "/media/james/Gentoo AMD64 20190703T214502Z"
➜ ~ Sudo umount "/media/james/GENTOOLIVE"
➜ ~ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 477G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 476.4G 0 part /
sdb 8:16 1 14.6G 0 disk
├─sdb1 8:17 1 292M 0 part
└─sdb2 8:18 1 6.3M 0 part
#Run dd
➜ ~ Sudo dd if=/dev/zero of=/dev/sdb bs=3M
dd: error writing '/dev/sdb': No space left on device
2649+0 records in
2648+0 records out
8330620928 bytes (8.3 GB, 7.8 GiB) copied, 5.50879 s, 1.5 GB/s
#the partitions are still there!
➜ ~ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 477G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 476.4G 0 part /
sdb 8:16 1 14.6G 0 disk
├─sdb1 8:17 1 292M 0 part
└─sdb2 8:18 1 6.3M 0 part
➜ ~ lsblk
#after unplugging and replugging the drive, the old partition still mounts and still contains files. I was able to open several and read the contents.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 477G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 476.4G 0 part /
sdb 8:16 1 14.6G 0 disk
├─sdb1 8:17 1 292M 0 part
└─sdb2 8:18 1 6.3M 0 part /media/james/GENTOOLIVE
私を本当に混乱させているのは、Gpartedを見ると、デバイスが8GBの未割り当てとして表示されているのですが、これは16GBのドライブです。
badblocks -wsvを実行しましたが、通過しましたが、疑わしいほど迅速に実行されました（数時間ではなく数分）。プラグを抜いてから再度差し込むと、ドライブは/dev/sdcと表示され、Gpartedには「gentoo」と呼ばれる14.56GBのパーティションが表示されます。
Testing with pattern 0xaa: set_o_direct: Invalid argument/0/0 errors)
done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff: done
Reading and comparing: done
Testing with pattern 0x00: done
Reading and comparing: done
Pass completed, 0 bad blocks found. (0/0/0 errors)
➜ ~ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 477G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 476.4G 0 part /
sdc 8:32 1 14.6G 0 disk
├─sdc1 8:33 1 292M 0 part
└─sdc2 8:34 1 6.3M 0 part
このフラッシュドライブを放牧するだけでいいのではないかと思いますが、奇妙な一連のイベントのように思われます。どのような障害が原因であるのか知りたいです（実際には修正を探していません）。
編集：これはXubuntu18.04にありました
Edit2：再起動後、ゼロ調整は期待どおりに機能します。 OSの一時的な問題だったと思います。でも、どんな問題なのかまだ気になります。
Edit3：話が早すぎたので、再起動だけでは不十分でした。 ddは通常の時間がかかっていたので機能していると思いましたが、そうではないようです。
➜ ~ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 477G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 476.4G 0 part /
sdb 8:16 1 14.6G 0 disk
├─sdb1 8:17 1 292M 0 part /media/james/Gentoo AMD64 20190703T214502Z
└─sdb2 8:18 1 6.3M 0 part
➜ ~ Sudo dd if=/dev/zero of=/dev/sdb
[Sudo] password for james:
Sorry, try again.
[Sudo] password for james:
dd: writing to '/dev/sdb': No space left on device
30629377+0 records in
30629376+0 records out
15682240512 bytes (16 GB, 15 GiB) copied, 4232.1 s, 3.7 MB/s
➜ ~ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 477G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 476.4G 0 part /
sdb 8:16 1 14.6G 0 disk
├─sdb1 8:17 1 292M 0 part /media/james/Gentoo AMD64 20190703T214502Z
└─sdb2 8:18 1 6.3M 0 part
編集4：わかりました。ddは実際に機能しましたが、イジェクトして元に戻すまでlsblkは更新されませんでした。
➜ ~ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 477G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 476.4G 0 part /
sdb 8:16 1 14.6G 0 disk
編集5：dmesgを確認しましたが、ディスクが正しくマウントされていないという警告が表示されます。
➜ ~ journalctl --dmesg --since="3 days ago" | grep sdb
Jul 09 19:59:27 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] 30595072 512-byte logical blocks: (15.7 GB/14.6 GiB)
Jul 09 19:59:27 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write Protect is off
Jul 09 19:59:27 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00
Jul 09 19:59:27 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Jul 09 19:59:27 james-Latitude-E7470 kernel: sdb: sdb1
Jul 09 19:59:27 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
Jul 09 19:59:33 james-Latitude-E7470 kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Jul 10 02:38:38 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] 30629376 512-byte logical blocks: (15.7 GB/14.6 GiB)
Jul 10 02:38:38 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write Protect is off
Jul 10 02:38:38 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00
Jul 10 02:38:38 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Jul 10 02:38:38 james-Latitude-E7470 kernel: sdb: sdb1 sdb2
Jul 10 02:38:38 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
Jul 10 04:12:42 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] 30629376 512-byte logical blocks: (15.7 GB/14.6 GiB)
Jul 10 04:12:42 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write Protect is off
Jul 10 04:12:42 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00
Jul 10 04:12:42 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Jul 10 04:12:42 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
#the partitions are still there!
この部分は、少なくとも、まだ正常です。パーティション情報を更新するには、パーティションテーブルを再度読み取る必要があります。で再読込をトリガーできます
blockdev --rereadpt /dev/sdx
（またはsfdisk --re-readですが、そのオプションは最近のバージョンのsfdiskから削除されています）。
それ以外の場合は、フラッシュベースのストレージが読み取り専用モードに失敗する可能性があります。 USB接続が安定していない場合、/dev/sdxデバイスがドロップされ、/dev/sdyとして再検出され、/dev/sdxへのすべての書き込みが制限されるなど、他の理由でも奇妙なことが起こる可能性があります。 、しかし、それはあなたのlsblkに示されていると思います。
dmesgに興味深いエラーメッセージが表示されることがありますが、全体として... USBスティックに障害が発生した場合は、新しいものを入手するだけで、回避することはできません。
完全を期すために、ここにもこの特別なケースがあります（ユーザーエラー）：
# dd bs=1M if=/dev/zero of=/dev/sdx
dd: error writing '/dev/sdx': No space left on device
7956+0 records in
7955+0 records out
8341966848 bytes (8.3 GB, 7.8 GiB) copied, 2.08568 s, 4.0 GB/s
そう。このコマンドはデバイスに書き込みましたか？
どういたしまして。 /dev/sdxすら持っていません。代わりに、/devtmpfsを50％RAMサイズのゼロの通常ファイルで埋めました（実際にはtmpfsのサイズ制限を調整する必要があります。tmpfsの2つのインスタンスでこれを行うと、システムRAMがいっぱいであるため、クラッシュします。）
これは、デバイスが完全に欠落している場合、またはデバイス名の入力ミスが発生した場合に発生します。これは、ddが事前に存在をまったくチェックしておらず、マシンに大量のRAMがあり、/devが正常なサイズに制限されていないためです。 10Mのように、この紛らわしい結果が得られます。