Antes de executar o dd
comando, o comando lsblk
retornou a saída abaixo:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
O comando dd if=/dev/urandom of=/dev/sda conv=fsync status=progress
é executado. No entanto, o dispositivo perde energia e desliga. Quando a energia é restabelecida, o comando lsblk
retorna a seguinte saída:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
sda2 8:2 0 487.5G 0 disk
Várias possibilidades:
O Linux suporta muitos tipos diferentes de tabelas de partição, algumas das quais usam muito poucos bytes mágicos, e então é fácil identificar incorretamente dados aleatórios (*) [portanto, é possível gerar aleatoriamente uma tabela de partição um tanto "válida"].
Alguns tipos de tabela de partição também têm backups no final do disco (principalmente GPT) e isso pode ser detectado se o início da unidade for substituído por lixo aleatório.
O dispositivo não funciona corretamente e foi desconectado antes de terminar de gravar os dados ou continua retornando dados antigos, então a tabela de partição sobrevive. Às vezes isso acontece com pendrives.
...
(*) Faça 1000 arquivos com dados aleatórios e veja o que sai:
O objetivo de fragmentar aleatoriamente uma unidade é fazer com que os dados antigos desapareçam para sempre. Não há promessa de que a unidade aparecerá vazia, não utilizada, em bom estado depois.
É comum seguir com uma limpeza zero para conseguir isso. Se você estiver usando o LVM, é normal que o LVM zere os primeiros setores de qualquer LV que você criar para que os dados antigos não interfiram.
Há também um utilitário dedicado (
wipefs
) para se livrar de antigas assinaturas de bytes mágicos que você pode usar para se livrar dos metadados do sistema de arquivos e da tabela de partição.Como visto aqui, o MBR (Master Boot Record) é relativamente simples; https://en.wikipedia.org/wiki/Master_boot_record .
Quando você usa
/dev/urandom
, sempre pode criar algo que se pareça com uma tabela de partição. A solução é preencher as regiões da tabela de partição com zero e usardev/urandom
para o resto.O Linux também suporta outros formatos de disco adicionais que também podem ser acionados, fazendo com que partições "inválidas" apareçam ao preencher com dados aleatórios.
O que define uma coleção de 512 bytes como sendo um Master Boot Record é a presença dos valores
0x55 0xAA
no final. Há uma chance de 1 em 65.536 de/dev/urandom
produzir tal valor: não muito provável, mas coisas igualmente improváveis acontecem o tempo todo.(Algumas outras tabelas de partição, como o Apple Partition Map , têm assinaturas curtas semelhantes. É possível que você tenha gerado uma delas.)
Essa partição estava presente algum tempo antes nesse disco? Se o disco usa GPT, talvez o cabeçalho GPT secundário tenha sido restaurado e ainda tenha a tabela de partição antiga.
https://en.wikipedia.org/wiki/GUID_Partition_Table