Rendre à nouveau utilisable normalement le disque dur précédemment crypté
Mon ancien ordinateur portable est mort le matin dernier, mais le disque dur fonctionne toujours.
Lorsque mon frère a effectué l'installation Ubuntu, il a choisi de chiffrer le dossier home. Donc, chaque fois que j'essaie d'utiliser le disque dur sur un autre ordinateur, cela me pose des questions sur la phrase secrète du disque dur. J'ai déjà demandé à mon frère à ce sujet et il ne sait pas où se trouve l'ancienne phrase de passe (cela fait 3 ans).
Mes questions:
Est-il possible de vider complètement le disque dur ou de le formater de manière à ce qu'il puisse être utilisé pour une autre installation?
Au cas où ce ne serait pas possible, y a-t-il une astuce matérielle ou une astuce BIOS que je peux faire pour déverrouiller le lecteur?
Quelques informations utiles:
Si j'essaie la commande Sudo mount /dev/sdb /mnt/hd2, le message d'erreur suivant s'affiche:
mount: /dev/sdb: can't read superblock
Si j'essaie de voir la table de partition en utilisant Sudo fdisk -l /dev/sdb, je reçois:
fdisk: cannot open /dev/sdb: Input/output error
Je ne peux pas dire avec certitude s'il y avait un mot de passe de niveau BIOS.
Et la commande Sudo fsck /dev/sdb donne le résultat suivant:
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?
En ce qui concerne le problème physique, si je connecte le disque dur, il n'y a pas de problème apparaissant dans /dev, pas de cliquetis, et le dmesg | tail s'affiche comme suit:
[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
Je pense que la plupart de ces erreurs sont liées au fait que le système ne peut pas lire la table de partition du périphérique, car celle-ci est cryptée.
Enfin, il y a aussi une partition Windows dans ce lecteur, si cela fait une différence.
Si vous avez besoin de plus d'informations, je fournirai volontiers. Je peux également dire que la récupération des données personnelles n'est pas ma priorité dans ce cas, mais plutôt que de pouvoir réutiliser le lecteur. De plus, je m'excuse pour mes erreurs d'anglais ou ma mise en forme incorrecte.
UPDATE 1
Une fois que dd est terminé, je suis confronté à un problème étrange. Le disque, c’est-à-dire un lecteur de 500 Go, indique 2 Go, même après le formatage à l’aide de gparted. En outre, même après l'avoir formulée, lorsque je l'affiche dans l'interface graphique gparted, celle-ci s'affiche comme suit:
UPDATE 2
dd a signalé qu'il avait écrit 2 Go, ce qui était, je suppose, le secteur de démarrage ou quelque chose de similaire.
Sudo fdisk -l /dev/sdb sortie:
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 sortie:
lsblk: /dev/sdb: not a block device
Sudo parted /dev/sdb print sortie:
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 sortie:
/dev/sdb:
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
La seule chose que je peux deviner, c’est que le lecteur démonté pendant dd et remonté très rapidement, a gâché quelque chose. Pourtant, je ne sais pas exactement ce qui se passe. Devrais-je essayer de dd à nouveau?
UPDATE 3
Comme demandé, file /dev/sdb me donne la sortie suivante:
/dev/sdb: data
UPDATE 4
Je pense avoir trouvé quelque chose qui peut être utile pour comprendre ce qui se passe. Voici une capture d'écran de dd avec le lecteur branché:
Et ici, après avoir débranché physiquement le lecteur:
Comme vous pouvez le constater, il n’ya plus d’erreur sur le fait que /dev/sdb n’existe plus et il est toujours répertorié dans ls comme vous pouvez le voir sur la capture d’écran ci-dessous:
J'ai aussi remarqué cette couleur différente qui sdb apparaît, c'est la même chose, même avec le lecteur branché.
Autant que je sache, ce périphérique "fantôme" est responsable du problème dd, y a-t-il un moyen de s'en débarrasser?
UPDATE 5
J'ai utilisé rm pour supprimer le fichier "fantôme", mais je n'ai aucune idée de la façon dont il s'est retrouvé là-bas. Maintenant, si je lance dd, cela ne me dit pas qu'il a écrit 2 Go, et comme vous pouvez le constater, après une courte exécution et une interruption, le disque apparaît "correctement" dans gparted:
Mais même dans ce cas, ouvrir gparted me donne beaucoup de fenêtres d'erreur comme ceci:
Des fenêtres similaires apparaissent si j'essaie de créer une nouvelle table de partition ou de créer une nouvelle partition dans le lecteur. Est-ce que cela signifie que je dois exécuter dd dans tout le périphérique ou que le lecteur est endommagé? Une chose à noter est que j'ai ajouté l'option status=progress à la commande dd, et après un certain temps d'exécution (pas toujours à la même taille), il n'y a plus de mises à jour de progression, et je ne suis pas sûr si dd est bloqué dans un secteur défectueux ou quelque chose du genre. La commande que j'utilise maintenant est Sudo dd if=/dev/zero of=/dev/sdb bs=4M status=progress.
MISE À JOUR 6
Donc, gnome-disks ne me donne pas la possibilité (du moins n’active pas) d’effectuer un autotest sur le lecteur. Néanmoins, j'ai essayé d'utiliser gsmartcontrol, et voici ce que j'ai obtenu:
Et si j'essaie d'effectuer un autotest à l'aide de cet outil, j'obtiens cette erreur.
en utilisant la version en ligne de commande, lancer Sudo smartctl /dev/sdb -a devrait me donner les informations SMART, et comme le résultat était assez long, je l'ai collé sur Pastebin car je n'étais pas sûr de savoir si cet article allait arriver. trop grand.
Selon le résultat, il y a beaucoup d'erreurs, mais je ne sais pas si elles se produisent à cause du problème de lecteur chiffré.
MISE À JOUR FINALE
Puisqu'il y a un mot de passe de niveau BIOS dans le lecteur et que l'ancien ordinateur est mort, il n'y a rien d'autre à faire, sauf acheter un nouveau lecteur. Je marque ce message comme résolu. Merci à tous ceux qui ont rejoint le groupe et lui ont donné des conseils.
Donc, chaque fois que j'essaie d'utiliser le disque dur sur un autre ordinateur, cela me pose des questions sur le mot de passe complexe du disque dur.
Lire attentivement. Votre disque dur est crypté. Peut-être que votre dossier personnel Ubuntu est AS, mais le disque dur lui-même est crypté. Normalement, le cryptage peut être activé et désactivé dans le BIOS, si vous avez le mot de passe. Si vous êtes très malchanceux, le lecteur a été crypté via des puces TPM sur l'ancien ordinateur, où vous ne pourrez pas récupérer le mot de passe de toute façon. Lisez la documentation du système, où se trouvait le disque dur.
C'est pourquoi smart réclame tant d'erreurs, chaque commande sata est négligée, car le lecteur souhaite d'abord obtenir une autorisation.