Meu velho 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 pasta home . Então, sempre que tento usar o disco rígido em outro computador, ele me pergunta sobre a frase secreta do disco rígido. Eu já perguntei ao meu irmão sobre isso, e ele não tem idéia de onde está a velha frase secreta (faz 3 anos).
Minhas perguntas:
-
Existe alguma maneira de limpar completamente o disco rígido ou formatá-lo de maneira que possa ser usado para outra instalação?
-
Caso isso não seja possível, há algum truque de hardware ou truque de BIOS que eu possa fazer para desbloquear a unidade?
Algumas informações úteis:
Se eu tentar o comando sudo mount /dev/sdb /mnt/hd2 , será gerado 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 , obtenho:
fdisk: cannot open /dev/sdb: Input/output error
Não sei ao certo se havia alguma senha no nível do BIOS.
E o comando sudo fsck /dev/sdb 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 haverá problema em aparecer em /dev , nenhum ruído de clique e as dmesg | tail serã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 de o sistema não poder ler a tabela de partições do dispositivo, já que ele está criptografado.
Finalmente, há também uma partição do Windows nesta unidade, se isso faz alguma diferença.
Se precisar de mais informações, fornecerei com prazer. Eu também posso dizer que recuperar dados pessoais não é minha prioridade neste caso, está mais relacionado a poder usar a unidade novamente. Além disso, peço desculpas pelos meus erros de inglês ou formatação inadequada.
UPDATE 1
Depois de dd terminar, estou enfrentando um problema estranho. O disco, que é uma unidade de 500 GB, está mostrando como 2 GB, mesmo depois de formatá-lo usando gparted . Além disso, mesmo depois de formatá-lo, quando o mostro no gparted GUI, ele mostra como abaixo:
UPDATE 2
dd relatou que escreveu 2 GB, que eu acho que foi o setor de inicialização ou algo semelhante.
sudo fdisk -l /dev/sdb output:
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 output:
lsblk: /dev/sdb: not a block device
sudo parted /dev/sdb print output:
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 output:
/dev/sdb:
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
A única coisa que posso imaginar é que a unidade desmontou durante dd e remontou muito rápido, o que estragou algo. Ainda assim, não sei exatamente o que está acontecendo. Devo tentar dd novamente?
UPDATE 3
Conforme solicitado, file /dev/sdb me fornece a seguinte saída:
/dev/sdb: data
UPDATE 4
Acho que encontrei algo que pode ser útil para entender o que está acontecendo. Aqui está uma captura de tela de dd com a unidade conectada:
E aqui, depois de desconectar fisicamente a unidade:
Como você pode ver, não há mais nenhum erro sobre /dev/sdb não existir e ele ainda é listado em ls, como você pode ver na captura de tela abaixo:
Eu também notei essa cor diferente que sdb aparece, é a mesma coisa mesmo com a unidade conectada.
Tanto quanto eu entendo, este dispositivo "fantasma" é o responsável pelo problema dd , existe alguma maneira de se livrar dele?
ATUALIZAÇÃO 5
Eu usei rm para deletar o arquivo "fantasma", ainda assim, não tenho ideia de como ele foi parar lá. Agora, se eu executar dd , ele não me diz que escreveu 2 GB e, como você pode ver, depois de uma execução e interrupção rápidas, o disco está sendo exibido "corretamente" em 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ção ou criar uma nova partição na unidade. Isso significa que tenho que executar dd em todo o dispositivo ou que a unidade tenha danos físicos?
Uma coisa a notar é que adicionei a opção status=progress no comando dd e, depois de algum tempo em 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 ruim ou algo parecido. O comando que estou usando agora é sudo dd if=/dev/zero of=/dev/sdb bs=4M status=progress .
ATUALIZAÇÃO 6
Portanto, gnome-disks não me oferece a opção (pelo menos não está habilitando) para realizar um autoteste na unidade. No entanto, tentei usar gsmartcontrol e é isso que recebi:
E se eu tentar executar um autoteste usando essa ferramenta, recebo esse erro.
usando a versão da linha de comando, executar sudo smartctl /dev/sdb -a deve fornecer as informações SMART e, como a saída foi muito longa, colei-a no pastebin porque não sabia se essa postagem estava ficando muito grande.
saída de comando
De acordo com a saída, 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 no nível do BIOS ativa na unidade e o computador antigo está inativo, não há mais nada a fazer, a não ser comprar uma nova unidade. Estou marcando este post como resolvido. Obrigado a todos que se juntaram e deram um jeito.