Eu pensei que poderia destruir todas as partições de uma unidade usando o dd if=/dev/zero of=/dev/sdX. No passado, isso sempre funcionou para mim, mas neste caso não está funcionando como esperado.
#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
O que realmente me confunde é que, se eu olhar no Gparted, o dispositivo é mostrado como 8 GB não alocados, mas esta é uma unidade de 16 GB.
Corri badblocks -wsv, que passou, mas o fez de forma suspeita rapidamente (minutos em vez de horas). Após desconectar e reconectar, a unidade aparece como /dev/sdc, e o Gparted vê uma partição de 14,56 GB chamada "gentoo"
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
Eu estou supondo que eu deveria apenas colocar esta unidade flash no pasto, mas parece-me uma sequência tão estranha de eventos, estou curioso para saber que tipo de falha pode ter causado isso (não estou realmente procurando uma correção).
Edit: Isso foi no Xubuntu 18.04
Edit2: Após uma reinicialização, a zeragem funciona conforme o esperado. Eu acho que foi apenas um problema temporário com o sistema operacional. Ainda estou curioso sobre que tipo de problema.
Edit3: falei muito cedo, uma reinicialização não foi suficiente. Achei que ddestava funcionando porque estava demorando um tempo normal, mas parece que não.
➜ ~ 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
Edit 4: Ok, ddrealmente funcionou, mas o lsblk não foi atualizado até que eu ejetasse e colocasse novamente.
➜ ~ 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
Edit 5: verifiquei o dmesg e há um aviso sobre o disco não estar montado corretamente.
➜ ~ 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
Esta parte, pelo menos, ainda é normal. Você precisa reler a tabela de partição para atualizar as informações da partição. Você pode acionar uma releitura com
(alternativamente,
sfdisk --re-readmas essa opção foi removida das versões recentes dosfdisk).Para todo o resto, sim, é possível que o armazenamento baseado em flash falhe em um modo somente leitura. Coisas estranhas também podem acontecer por outros motivos, por exemplo, se a conexão USB não for estável, o
/dev/sdxdispositivo pode ser descartado e redetectado como/dev/sdye todas as gravações para/dev/sdxir para o limbo, mas acho que isso teria mostrado no seu arquivolsblk.Às vezes, há mensagens de erro interessantes no
dmesg, mas no geral... se o seu pendrive falhou, você só precisa obter um novo, não há maneira de contornar isso.Por uma questão de completude, há também este caso especial aqui (erro do usuário):
Então. Este comando gravou em um dispositivo?
De jeito nenhum. Eu não tenho mesmo
/dev/sdx. Em vez disso, ele preencheu meus/devtmpfs com 50% de arquivo regular de zeros do tamanho de RAM. (Eu realmente deveria ajustar meus limites de tamanho de tmpfs. Se você fizer isso em duas instâncias de tmpfs, o sistema trava porque a RAM está cheia.)Isso acontece quando o dispositivo está totalmente ausente ou o nome do dispositivo foi digitado incorretamente, pois
ddnão verifica a existência de antemão e, se sua máquina tiver muita RAM e/devnão se limitar a um tamanho normal como10M, você obterá esse resultado confuso.