4

There is something very wrong with my 160G SSD. It shows up as a 8MB drive in fdisk:

Disk /dev/sda: 8 MB, 8388608 bytes
255 heads, 63 sectors/track, 1 cylinders, total 16384 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
Disk identifier: 0x00000000

Disk /dev/sda doesn't contain a valid partition table

Pretty much everything on there is backed up, but I would like to create an image just to be on the save side. dd seems to only see the 8MB drive:

dd if=/dev/sda of=/home/ubuntu/data/sda.img conv=sync,noerror bs=64K count=160G
128+0 records in
128+0 records out
8388608 bytes (8,4 MB) copied, 0,20943 s, 40,1 MB/s

How can I create an image of the full 160G drive and how do I fix the drive to use it again?

PS: I have read all sorts of Wikis etc. (https://help.ubuntu.com/community/DataRecovery) but none of them seems to deal with the kind of issue I have here.

2
  • Is this an Intel SSD?
    – falconer
    Jan 23, 2014 at 16:12
  • I think so: "INTEL SSDSA2CW160G3"
    – slosd
    Jan 23, 2014 at 16:15

3 Answers 3

5

There was a bug in some intel SSD's firmware which caused this problem. This bug was corrected a while ago but you likely didn't upgraded the firmware to the newer one.

Read about the bug and the new firmware here https://communities.intel.com/thread/24205

Unfortunately your data cannot be recovered, but your drive could be made usable again:

What should I do if I have already experienced this issue?

If you have already experienced a drive failure or encounter this problem before the firmware update was released, please contact your Intel representative or Intel customer support (via web: www.intel.com or phone: www.intel.com/p/en_US/support/contact/phone) for an SSD replacement. An alternative option is to use the Intel ® SSD Toolbox or similar tools to perform a secure erase in order to restore the SSD to an operational state; all data will be erased. After secure erase, update your SSD with the new firmware. The firmware update will not recover user data.

To solve this using linux: (Source and this)

  1. Boot up a live environment
  2. sudo apt-get install hdparm
  3. sudo hdparm -I /dev/sdX

    where sdX is your SSD device. This command will just print out some info about the drive. If you see in the output this: Serial Number: BAD_CTX 00000150 that confirms that you are hit by this bug. If at the Seucrity section it reads frozen you can't continue, you have to use a workaround to eliminate the freeze:

    If the command output shows "frozen" one cannot continue to the next step. Some BIOSes block the ATA Secure Erase command by issuing a "SECURITY FREEZE" command to "freeze" the drive before booting an operating system.

    A possible solution is to simply suspend the system. Upon waking up, it is likely that the freeze will be lifts. If unsuccessful, one can try hot-(re)plug the data cable (which might crash the kernel). If hot-(re)plugging the SATA data cable crashes the kernel try letting the operating system fully boot up, then quickly hot-(re)plug both the SATA power and data cables.

  4. sudo hdparm --user-master u --security-set-pass SOMEPASS /dev/sdX

    Again /dev/sdX is your SSD drive, and SOMEPASS is a password you want to set for the SSD. (This password doesn't lock the SSD or anything similar, it is just needed for these low-level dealing with the SSD.) We will need that SOMEPASS later on, so remember it/write it down. (But after the secure erase this password will be reset anyway so it is not important in the longterm.)

  5. Check the drive again: sudo hdparm -I /dev/sdX

    Now it should say enabled and not frozen at the security section:

    Security: 
        Master password revision code = 65534
                supported
                enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        Security level high
        2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
    
  6. sudo hdparm --user-master u --security-erase SOMEPASS /dev/sdX

    This issues the secure erase command. Again /dev/sdX is your SSD, SOMEPASS is the password set before. The completion of this operation can take a few minutes. After this your SSD should be functional, if not, try again with this command:

    sudo hdparm –user-master u –security-erase-enhanced SOMEPASS /dev/sdX

    This latter command takes much more time (30-40 minutes) and you will have to reset the password (with step 4.) before running it because SOMEPASS is likely already reset by the previous command.

  7. After this check the drive again sudo hdparm -I /dev/sdX . The BAD_CTX thing should be gone and your drive should be functional.

  8. After all this don't forget to update the firmware of our SSD. (refer to intel support on how to update the SSD's firmware.)

4
  • Thanks. "[...] caused by an unexpected power loss under specific conditions. " This happened after rebooting from a Windows update so that doesn't really make sense to me... Do you know what they mean by "similar tools"? Is there something I can run on the Live Ubuntu I'm currently on?
    – slosd
    Jan 23, 2014 at 16:25
  • @slosd Yes. You just have to issue the ATA secure erase command. If you google for it on how to do it on linux you will find a lot of instructions. But I will write one here soon too.
    – falconer
    Jan 23, 2014 at 16:27
  • You are right, there are plenty. For example ata.wiki.kernel.org/index.php/ATA_Secure_Erase
    – slosd
    Jan 23, 2014 at 16:56
  • @slosd Yes. :) Hope you manage to solve it now.
    – falconer
    Jan 23, 2014 at 17:01
1

You may want to try updating the SSD's firmware:

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=18363

0

I found the solution to this problem "Intel SSD 8mb bug Fix"

View on my Github :

https://gist.github.com/s1rv4n/3e2ef662a3d7172b69926b8e4e80cca4

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .