Tornar o disco rígido anteriormente criptografado utilizável normalmente novamente

Tornar o disco rígido anteriormente criptografado utilizável normalmente novamente

Meu antigo laptop morreu na manhã passada, mas o disco rígido ainda está funcionando.

Quando meu irmão fez a instalação do Ubuntu, ele optou por criptografar a homepasta. Portanto, sempre que tento usar o disco rígido em outro computador, ele me pergunta sobre a senha do disco rígido. Já perguntei ao meu irmão sobre isso e ele não tem ideia de onde está a senha antiga (já se passaram 3 anos).

Minhas perguntas:

  • Existe alguma maneira de limpar completamente o disco rígido ou formatá-lo de forma que possa ser usado em outra instalação?

  • Caso isso não seja possível, existe algum truque de hardware ou BIOS que eu possa fazer para desbloquear a unidade?

Algumas informações úteis:

Se eu tentar o comando, sudo mount /dev/sdb /mnt/hd2ocorrerá o seguinte erro:

mount: /dev/sdb: can't read superblock

Se eu tentar ver a tabela de partições usando, sudo fdisk -l /dev/sdbrecebo:

fdisk: cannot open /dev/sdb: Input/output error

Não tenho certeza se havia alguma senha no nível do BIOS.

E o sudo fsck /dev/sdbcomando fornece a seguinte saída:

fsck from util-linux 2.28.1
e2fsck 1.43.1 (08-Jun-2016)
fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdb
Could this be a zero-length partition?

No que diz respeito ao problema físico, se eu conectar o disco rígido, não há problema em aparecer /dev, não há ruídos de clique e as dmesg | tailsaídas são as seguintes:

[11267.246656] sd 51:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 00 02 00 00 02 00
[11267.246659] blk_update_request: critical medium error, dev sdb, sector 2
[11267.246665] Buffer I/O error on dev sdb, logical block 1, async page read
[11267.265418] sd 51:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[11267.265426] sd 51:0:0:0: [sdb] tag#0 Sense Key : Medium Error [current] 
[11267.265431] sd 51:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read error
[11267.265436] sd 51:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 00 04 00 00 04 00
[11267.265440] blk_update_request: critical medium error, dev sdb, sector 4
[11267.265445] Buffer I/O error on dev sdb, logical block 2, async page read
[11267.265449] Buffer I/O error on dev sdb, logical block 3, async page read

Acho que a maioria desses erros está relacionada ao fato do sistema não conseguir ler a tabela de partições do dispositivo, pois ela está criptografada.

Finalmente, há também uma partição do Windows nesta unidade, se isso faz alguma diferença.

Se houver necessidade de mais informações, fornecerei com prazer. Também posso dizer que a recuperação de dados pessoais não é minha prioridade neste caso, está mais relacionada a poder usar o drive novamente. Além disso, peço desculpas pelos meus erros de inglês ou formatação inadequada.

ATUALIZAÇÃO 1

Depois de ddterminar, estou enfrentando um problema estranho. O disco, que é uma unidade de 500 GB, aparece como 2 GB, mesmo depois de formatá-lo usando o arquivo gparted. Além disso, mesmo depois de formatado, quando eu mostro na gpartedGUI, ele aparece como abaixo:

Mostrando na GUI

Informações detalhadas da unidade no gparted

ATUALIZAÇÃO 2

ddrelatou que escreveu 2GB, que eu acho que foi o setor de inicialização ou algo semelhante.

sudo fdisk -l /dev/sdbsaída:

Disk /dev/sdb: 1,9 GiB, 1994428416 bytes, 3895368 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

lsblk /dev/sdbsaída:

lsblk: /dev/sdb: not a block device

sudo parted /dev/sdb printsaída:

Error: /dev/sdb: unrecognised disk label
Model:  (file)                                                            
Disk /dev/sdb: 1994MB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 

sudo hdparm -I /dev/sdbsaída:

/dev/sdb:
 HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device

A única coisa que posso imaginar é que o drive foi desmontado dde remontado bem rápido, isso estragou alguma coisa. Ainda assim, não sei exatamente o que está acontecendo. Devo tentar de ddnovo?

ATUALIZAÇÃO 3

Conforme solicitado, file /dev/sdbme dá a seguinte saída:

/dev/sdb: data

ATUALIZAÇÃO 4

Acho que encontrei algo que pode ser útil para entender o que está acontecendo. Aqui está uma captura de tela ddcom a unidade conectada:

insira a descrição da imagem aqui

E aqui, depois de desconectar fisicamente a unidade:

insira a descrição da imagem aqui

Como você pode ver, não há /dev/sdbmais nenhum erro sobre não existir, e ele ainda está listado em ls como você pode ver na captura de tela abaixo:

insira a descrição da imagem aqui

Notei também essa cor diferente que sdbaparece, é a mesma mesmo com o drive conectado.

Pelo que entendi, esse dispositivo "fantasma" é o responsável pelo ddproblema, existe alguma maneira de se livrar dele?

ATUALIZAÇÃO 5

Eu costumava rmdeletar o arquivo "fantasma", mas não tenho ideia de como ele foi parar ali. Agora, se eu executar o dd, ele não me diz que gravou 2GB, e como você pode ver, após uma rápida execução e interrupção, o disco está aparecendo "corretamente" no gparted:

insira a descrição da imagem aqui

Mas mesmo assim, abrir gpartedestá me dando muitas janelas de erro como esta:

insira a descrição da imagem aqui

Janelas semelhantes aparecem se eu tentar criar uma nova tabela de partições ou criar uma nova partição na unidade. Isso significa que preciso executar ddtodo o dispositivo ou que a unidade apresenta danos físicos? Uma coisa a notar é que adicionei a opção status=progressno ddcomando, e depois de algum tempo de execução(nem sempre no mesmo tamanho) não há mais atualizações de progresso, e não tenho certeza se ddestá preso em um setor defeituoso ou algo parecido que. O comando que estou usando agora é sudo dd if=/dev/zero of=/dev/sdb bs=4M status=progress.

ATUALIZAÇÃO 6

Então, gnome-disksnão me dá a opção (pelo menos não está habilitando) de realizar um autoteste no drive. Mesmo assim, tentei usar gsmartcontrole foi isso que consegui:

insira a descrição da imagem aqui

insira a descrição da imagem aqui

E se eu tentar realizar um autoteste usando esta ferramenta, recebo este erro.

insira a descrição da imagem aqui

usando a versão de linha de comando, a execução sudo smartctl /dev/sdb -adeve me fornecer as informações SMART e, como a saída era bastante longa, colei-a no pastebin porque não tinha certeza se a postagem estava ficando muito grande.

saída de comando

De acordo com o resultado, há muitos erros, mas não tenho certeza se eles estão acontecendo devido ao problema da unidade criptografada.

ATUALIZAÇÃO FINAL

Como há uma senha de nível de BIOS ativa na unidade e o computador antigo está morto, não há mais nada a fazer, exceto comprar uma nova unidade. Estou marcando este post como resolvido. Obrigado a todos que participaram e deram reflexões sobre isso.

Responder1

Portanto, sempre que tento usar o disco rígido em outro computador, ele me pergunta sobre a senha do disco rígido.

Leia cuidadosamente. Seu HDD está criptografado. Talvez a sua pasta inicial do Ubuntu TAMBÉM esteja, mas o disco rígido em si também está criptografado. Normalmente a criptografia pode ser habilitada e desabilitada no BIOS, se você tiver a senha. Se você não tiver sorte, a unidade foi criptografada por meio de chips TPM no computador antigo, onde você não conseguirá recuperar a senha de qualquer maneira. Leia a documentação do sistema, onde ficava o disco rígido.

É por isso que o smart alega tantos erros, todo comando sata é negligenciado, porque a unidade primeiro precisa de autorização.

informação relacionada