My old laptop died last morning, but the hard drive is still working.
When my brother made the Ubuntu installation, he chose to encrypt the
home folder. So, whenever I try to use the hard drive on another computer, it asks me about the hard drive pass-phrase. I have already asked my brother about it, and he has no clue about where the old pass-phrase is (it's been 3 years).
Is there anyway to clear the hard drive completely or format it in a way that it can be used for another installation?
In case this is not possible, is there any hardware trick or BIOS trick that I can do to unlock the drive?
Some useful information:
If I try the command
sudo mount /dev/sdb /mnt/hd2 it gives me the following error:
mount: /dev/sdb: can't read superblock
If I try to see the partition table using
sudo fdisk -l /dev/sdb I get:
fdisk: cannot open /dev/sdb: Input/output error
I can't tell for sure if there was any BIOS level password.
sudo fsck /dev/sdb command gives the following output:
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?
As far as physical problem go, if I plug in the hard drive, there's no problem on it appearing in
/dev, no clicking noises, and the
dmesg | tail outputs as follows:
[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
I think that most of these errors are related to the fact that the system can't read the partition table of the device, since it is encrypted.
Finally, there is also a Windows partition in this drive, if that makes any difference.
If there's any need of more information, I'll provide gladly. I also can say that recovering personal data is not my priority in this case, it's more related to being able to use the drive again. Also, I apologize for my English mistakes or improper formating.
dd finished, I'm facing a weird problem. The disk, that is a 500GB drive, is showing as 2GB, even after formatting it using
gparted. Also, even after formating it, when I show it in the
gparted GUI, it shows as below:
dd reported that wrote 2GB, which I guess was the boot sector or something similar.
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
The only thing I can guess is that the drive unmounted during
dd and remounted really quick, that messed up something. Still, I don't know exactly what's going on. Should I try to
dd it again?
file /dev/sdb gives me the following output:
I think I may have found something that can be useful in understanding what is happening. Here is a screen shot of
dd with the drive plugged in:
And here, after physically unplugging the drive:
As you can see, there's no error about
/dev/sdb not existing anymore, and it still list in in ls as you can see in the screen shot below:
I also noticed this different color that
sdb appears, it is the same even with the drive plugged in.
As far as I understand, this "ghost" device is the responsible for the
dd problem, is there any way to get rid of it?
rm to delete the "ghost" file, still, I have no clue how it ended up there. Now, if I run
dd, it does not tell me that it wrote 2GB, and as you can see, after a quick run and interruption, the disk is showing up "correctly" in
But even so, opening
gparted is giving me loads of error windows like this:
Similar windows appear if I try to create a new partition table, or create a new partition in the drive. Does that mean that I have to run
dd in the entire device or that the drive has physical damage?
One thing to notice is that I added the option
status=progress on the
dd command, and after some time running(not always in the same size) there is no more progress updates, and I'm not sure if
dd is stuck in a bad sector or something like that. The command I'm using now is
sudo dd if=/dev/zero of=/dev/sdb bs=4M status=progress.
gnome-disks doesn't give me the option(at least is not enabling) to perform a self test on the drive. Nevertheless, I tried using
gsmartcontrol, and this is what I got:
And if I try performing a self test using this tool, I get this error.
by using the command line version, running
sudo smartctl /dev/sdb -a should give me the SMART information, and since the output was quite long, I pasted it on pastebin because I wasn't sure if this post was getting too big.
According to the output, there's a lot of errors, but I'm not sure if they are happening because of the encrypted drive problem.
Since there's a BIOS level password active in the drive, and the old computer is dead, there's nothing more to do, except buy a new drive. I'm marking this post as solved. Thanks to everyone who joined and gave toughts about it.