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).

My questions:

  • 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.

And the 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.


After 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:

Showing on GUI

Detailed Info of the drive on gparted


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:

 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?


As requested, file /dev/sdb gives me the following output:

/dev/sdb: data


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:

enter image description here

And here, after physically unplugging the drive:

enter image description here

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:

enter image description here

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?


I used 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 gparted:

enter image description here

But even so, opening gparted is giving me loads of error windows like this:

enter image description here

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.


So, 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:

enter image description here

enter image description here

And if I try performing a self test using this tool, I get this error.

enter image description here

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.

command output

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.

  • You can not recover a lost password for encrypted hard drives (except you're the NSA and have lots of time maybe). To make the disk usable again, I suggest to overwrite it with zeroes. This will nuke all data though. Make sure the disk you want to nuke is /dev/sdb (else change it in the command!) and then run sudo dd if=/dev/zero of=/dev/sdb bs=4M. This will overwrite everything on /dev/sdb and destroy all traces of encrypted partitions etc if the drive is writeable in raw mode.
    – Byte Commander
    Sep 9 '16 at 19:42
  • How can I verify if the drive is writeable in raw mode? any different command, or should I just ddit?
    – inblank
    Sep 9 '16 at 19:45
  • Just dd it. If it works, it works and you'll have a seemingly factory-new disk afterwards on which you can create a partition table and partitions which you can format as whatever file systems you like, e.g. using GParted. Else you have a problem.
    – Byte Commander
    Sep 9 '16 at 20:49
  • So I should use dd in the entire disk, like, wait for it t finish running entirely. Am I right to think that?
    – inblank
    Sep 9 '16 at 21:01
  • Yup, that's correct. Possibly it could be enough to just overwrite the first few MBs to destroy boot sectors, partition tables and the first file system superblock, but if you are not super impatient, I'd recommend to let it overwrite everything. It might take a while (up to a few hours) though, depending on disk size and speed.
    – Byte Commander
    Sep 9 '16 at 21:04

So, whenever I try to use the hard drive on another computer, it asks me about the hard drive passphrase.

Read carefully. Your HDD is encrypted. Maybe your Ubuntu home folder is AS well, but the hard drive itself is encrypted, too. Normally the encryption can be enabled and disabled in BIOS, if you have the password. If you're very unlucky, the drive was encrypted through TPM chips on the old computer, where you won't be able to recover the password anyway. Read the docs of the system, where the hard drive used to be.

That's why smart claims so many errors, every sata command is neglected, because the drive first wants authorization.

  • I see, I wasn't sure if there was Firmware level password envolved, Since the computer was never turned off(was like a media center). I'll see if I can find anything about that. Thanks.
    – inblank
    Sep 12 '16 at 19:32
  • 1
    And in the end, there was a BIOS level password, and since the old computer is not working anymore, the only thing to do is buy a new drive. Thanks for appointing that out.
    – inblank
    Sep 14 '16 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.