In the process of playing around with several hard-drives, and hdparm's --security-set-pass
and --security-erase
options, I have a pile of HDDs that are in a "locked" state and I cannot unlock them.
I know what the password is, and I am sure that if I can convince Linux to create my /dev/sdc
block device, I can use hdparm
to --security-unlock
the devices. However, Linux refuses to create that block device. I believe it is attempting to identify the device and, because it is locked, it fails.
Is there any way of convincing the Linux kernel to create the block device even if it can't (yet) talk to the drive? The following are the kernel messages emitted, over and over:
May 10 18:40:02 kernel: [ 480.989385] ata10: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
May 10 18:40:02 kernel: [ 480.989395] ata10: irq_stat 0x00000040, connection status changed
May 10 18:40:02 kernel: [ 480.989401] ata10: SError: { DevExch }
May 10 18:40:02 kernel: [ 480.989414] ata10: limiting SATA link speed to 1.5 Gbps
May 10 18:40:02 kernel: [ 480.989421] ata10: hard resetting link
May 10 18:40:04 kernel: [ 483.216053] ata10: SATA link down (SStatus 1 SControl 310)
May 10 18:40:04 kernel: [ 483.216073] ata10: EH complete
Kernel is 2.6.38-16-generic. Ubuntu. Using a eSATA controller (AHCI drive), but the same thing happens plugged into the motherboard directly. I am yet unable to test this with AHCI disabled. (Will need a different computer for that).
I had the same problem, with roughly the same dmsg errors.
The problem was that although I knew the password the drive rejected it. The problem was a result of trying to unlock a drive which had been locked in the BIOS of one PC with a different PC. Long story short: the PC's BIOS did not send the actual password to the drive, but a 32 char string consisting of the password padded with zeros.
On another occasion this got even worse: the BIOS did some kind of hashing (so I suppose) and sent a totally different password to the drive. I tried several different paddings but without any success. (It was an Acer.) ThinkPads are also known to do this kind of stuff. Look here for an example: http://shackspace.de/?p=1976
So try unlocking the drive in the same PC the password was set with; try different paddings (0x00, 0xFF, ...); try locking a drive with hdparm and see if you can unlock it again.
User contributions licensed under CC BY-SA 3.0