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 home
pasta. 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/hd2
ocorrerá o seguinte erro:
mount: /dev/sdb: can't read superblock
Se eu tentar ver a tabela de partições usando, sudo fdisk -l /dev/sdb
recebo:
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/sdb
comando 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 | tail
saí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 dd
terminar, 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 gparted
GUI, ele aparece como abaixo:
ATUALIZAÇÃO 2
dd
relatou que escreveu 2GB, que eu acho que foi o setor de inicialização ou algo semelhante.
sudo fdisk -l /dev/sdb
saí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/sdb
saída:
lsblk: /dev/sdb: not a block device
sudo parted /dev/sdb print
saí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/sdb
saída:
/dev/sdb:
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
A única coisa que posso imaginar é que o drive foi desmontado dd
e remontado bem rápido, isso estragou alguma coisa. Ainda assim, não sei exatamente o que está acontecendo. Devo tentar de dd
novo?
ATUALIZAÇÃO 3
Conforme solicitado, file /dev/sdb
me 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 dd
com a unidade conectada:
E aqui, depois de desconectar fisicamente a unidade:
Como você pode ver, não há /dev/sdb
mais nenhum erro sobre não existir, e ele ainda está listado em ls como você pode ver na captura de tela abaixo:
Notei também essa cor diferente que sdb
aparece, é a mesma mesmo com o drive conectado.
Pelo que entendi, esse dispositivo "fantasma" é o responsável pelo dd
problema, existe alguma maneira de se livrar dele?
ATUALIZAÇÃO 5
Eu costumava rm
deletar 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
:
Mas mesmo assim, abrir gparted
está me dando muitas janelas de erro como esta:
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 dd
todo o dispositivo ou que a unidade apresenta danos físicos? Uma coisa a notar é que adicionei a opção status=progress
no dd
comando, 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 dd
está 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-disks
não me dá a opção (pelo menos não está habilitando) de realizar um autoteste no drive. Mesmo assim, tentei usar gsmartcontrol
e foi isso que consegui:
E se eu tentar realizar um autoteste usando esta ferramenta, recebo este erro.
usando a versão de linha de comando, a execução sudo smartctl /dev/sdb -a
deve 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.
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.