How can I re-partition a hard drive connected by a USB enclosure when my system won't recognize it's connected?
January 5, 2012 10:37 PM   Subscribe

How can I re-partition a 1.8" hard drive, connected to my laptop via a USB enclosure, when I can't get my computer to recognize that it's there at all?

Background: I had an old 20gb Cowon iAudio X5 hard drive-based MP3 player that would act as a USB mass storage device when plugged into a laptop via a specialized dock. You'd turn it on, the player's firmware would load and start running, and a few moments later it would kick into USB storage mode.

By a freak accident that I don't have a good way of explaining, I managed to remove the existing FAT32 partition, but I didn't wipe or reformat the drive. After that, when turning on the player, the screen would just be blank. Without a partition, it couldn't seem to find its firmware and boot up, and therefore couldn't enter USB storage mode, so I couldn't do anything with it.

Now: I opened up the player and removed the Toshiba 20-pin hard drive from the player. I ordered a USB hard drive enclosure and installed the drive. When I plug it into my laptop, the enclosure's green LED lights up and I can hear the platters start spinning inside.

BUT: ...that's all that happens. My computer never recognizes that a USB mass storage device has been plugged in. I've googled for all the help I can get, but nothing seems to work. I have a Macbook with OSX 10.6 on one partition and Windows 7 on the other. The disk doesn't show up in either Disk Utility on OSX, or in Disk Management on Windows 7, so I can't figure out a way to repartition it.

I had a lot of old music and photos that had sentimental value on this hard drive and I'm dying to find some way to recover them without having to pay thousands of dollars for a recovery service, but I'm at my wit's end. The hard drive physically works, and it's connected - does anyone have any idea how I can partition it again?
posted by cobra_high_tigers to Computers & Internet (23 answers total) 3 users marked this as a favorite
 
On your Mac, open the Terminal application WITHOUT the drive connected. Enter the following:

ls /dev/disk*

Then connect the drive, wait a few seconds and repeat the command

If you get an extra entry (or entries) the second time around, you can format the disk < href="http://www.ehow.com/how_1000631_hard-drive-linux.html">through the command line.

If no new devices appear, that means that the drive is getting power but there is an issue with the data connection.
posted by fearnothing at 10:49 PM on January 5, 2012 [1 favorite]


(and that's what happens if you type a link while half asleep)
posted by fearnothing at 10:50 PM on January 5, 2012


unfortunately I get the same result both ways, fearnothing. Got any other ideas?
posted by cobra_high_tigers at 11:01 PM on January 5, 2012


I have recovered virtually all data from disks with blown partitions using this, Windows only:

http://www.kerneldatarecovery.com/windows-data-recovery.html

You can download the program and it will show what it can recover. You have to pay for it to actually recover anything. It works for me. I am just a satisfied paid user.
posted by caclwmr4 at 11:09 PM on January 5, 2012


cobra, try the photorec/testdisk utilities. Open Source and cross platform. Read the documentation.

I have recovered many file from many an ill disk. Again, read the documentation first. These are powerful tools... you may blast away whatever remains of the existing partition table... should it exist.
posted by PROD_TPSL at 11:37 PM on January 5, 2012


I think my primary problem is less the partition obliteration and more the fact that I can't get my computer to recognize the HD + enclosure as a USB disk when it's plugged in! I haven't tried testdisk yet, but I tried that Kernel data recovery program and it had the same problem as Disk Utility and Disk Management - it recognizes my physical internal HD and both of its partitions, but not the HD plugged in over USB, so there's nothing I can do to it.
posted by cobra_high_tigers at 11:42 PM on January 5, 2012


but I have to say, PROD, looking at the testdisk documentation, this software looks perfect for restoring the partition table when I finally CAN get the thing some respect
posted by cobra_high_tigers at 11:44 PM on January 5, 2012


UNLESS... this page indicates that on OSX, TestDisk can repair a filesystem not listed by TestDisk. (the examples it gives are like testdisk /dev/mapper/truecrypt0, testdisk /dev/md0, etc.)

I'm weak with *nixen, so I admit I don't know how they mount USB storage devices. Thinking it might show up as some new device with a prefix OTHER than "disk," I tried
ls /dev | wc -l
, noted the number of entries, then plugged in the enclosure and ran it again to see if anything new showed up. Nope, same number.

In a BSD like OSX, do USB devices show up as mount points in /dev/ like disks do? Is there some way to figure out which one corresponds to the enclosure I have plugged in, so I can try to pass it as an argument to testdisk?
posted by cobra_high_tigers at 12:00 AM on January 6, 2012


er, preliminary googling suggests what I should have asked is how to determine the device string for USB devices connected to my system.
posted by cobra_high_tigers at 12:25 AM on January 6, 2012


I don't know OSX, but check /var/log and maybe `fgrep -i usb /var/log/*` to see which logs have USB messages in them and then `tail -f` one of those while plugging in the drive.

For example Linux has junk in /var/log/messages and /var/log/dmesg
# tail /var/log/messages | fgrep -i usb
Jan  6 00:06:47 io kernel: [527548.767509] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan  6 00:06:47 io kernel: [527548.767517] usb 2-1: Product: Generic USB2.0 card 
Jan  6 00:06:47 io kernel: [527548.767522] usb 2-1: Manufacturer: Silicon Motion, Inc.
Jan  6 00:06:47 io kernel: [527548.767528] usb 2-1: SerialNumber: 12345678901234567890
Jan  6 00:06:47 io kernel: [527548.768381] scsi5 : usb-storage 2-1:1.0
Jan  6 00:06:48 io kernel: [527549.769587] scsi 5:0:0:0: Direct-Access     Generic  USB  SD Reader   1.00 PQ: 0 ANSI: 0 CCS

# tail /var/log/dmesg
[527548.628293] usb 2-1: new high speed USB device number 4 using ehci_hcd
[527548.767500] usb 2-1: New USB device found, idVendor=090c, idProduct=6200
[527548.767509] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[527548.767517] usb 2-1: Product: Generic USB2.0 card 
[527548.767522] usb 2-1: Manufacturer: Silicon Motion, Inc.
[527548.767528] usb 2-1: SerialNumber: 12345678901234567890
[527548.768381] scsi5 : usb-storage 2-1:1.0
[527549.769587] scsi 5:0:0:0: Direct-Access     Generic  USB  SD Reader   1.00 PQ: 0 ANSI: 0 CCS
[527549.774020] sd 5:0:0:0: [sdb] 7729152 512-byte logical blocks: (3.95 GB/3.68 GiB)
[527549.774631] sd 5:0:0:0: [sdb] Write Protect is off
[527549.774640] sd 5:0:0:0: [sdb] Mode Sense: 4b 00 00 08
[527549.775511] sd 5:0:0:0: [sdb] No Caching mode page present
[527549.775521] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[527549.781271] sd 5:0:0:0: [sdb] No Caching mode page present
[527549.781281] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[527549.782420]  sdb: sdb1
[527549.786887] sd 5:0:0:0: [sdb] No Caching mode page present
[527549.786896] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[527549.786904] sd 5:0:0:0: [sdb] Attached SCSI removable disk
You may be able to find some strings to help with the searching. It should probably detect a usb device (at least if the enclosure is working) and then decide to use a 'storage' driver on top of the generic usb driver (vs a Human Input Device (HID) driver for a keyboard/mouse). Then some other driver on top of that (Linux uses SCSI emulation for USB Mass Storage Devices) which is the final responsible party for accessing the drive (just reading/writing the raw blocks).

It is a bit surprising that it doesn't at least show up as a /dev/something entry, that sorta sounds like the enclosure is confused enough to not recognize that a HD is present. Double check the enclosure and make sure the drive isn't in upside down or something funny like that.

If you manage to get it recognized as a /dev/something, the best first thing to do would be to make a backup image of the whole disk: `dd if=/dev/something of=/path/to/backup` which will (hopefully) get you a file that you could mess with later, mounting a copy as a block device to try recovery tools on.
posted by zengargoyle at 12:33 AM on January 6, 2012


See if you have `lsusb` utility:
# lsusb 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 002: ID 0b97:7761 O2 Micro, Inc. Oz776 1.1 Hub
Bus 007 Device 003: ID 0b97:7772 O2 Micro, Inc. OZ776 CCID Smartcard Reader
Bus 002 Device 004: ID 090c:6200 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) microSD card reader

posted by zengargoyle at 12:37 AM on January 6, 2012


In a terminal, do this: tail -f /var/log/system.log

Then plug in the device. If nothing happens, it's not being recognized. If it is, check Disk Explorer.

lsusb etc are linux things and won't work on a mac.
posted by joshu at 12:56 AM on January 6, 2012 [1 favorite]


joshu: nothing happened when I plugged in my enclosure. I got some fseventsd and pcscd messages when I plugged in my phone in mass storage mode.

zengargoyle: as joshu mentioned, I don't have lsusb. But I found something similar for OSX: 'system_profiler SPUSBDataType'. Using that command and plugging in my phone, I've figured out which bus the port I've been using is on. Was there some way I could use the info returned by lsusb to figure out the device string for the port I'm using, or did you recommend it just to see if the enclosure would show up in that list?
posted by cobra_high_tigers at 1:10 AM on January 6, 2012


btw seriously thanks for all the help, guys. I know this is a pretty strange and boring problem but it means a lot to me.
posted by cobra_high_tigers at 1:11 AM on January 6, 2012


cobra_high_tigers: I'm not really sure about your usage of 'device string' on OSX vs Linux. The lsusb will show you the Bus and Device number used on the USB system, and the ID is Vendor:Product (i.e. 090c:6200) which you can trace in the kernel messages...
[527548.767500] usb 2-1: New USB device found, idVendor=090c, idProduct=6200
# is on usb bus 2 (hub is device 1)
# pick mass storage gets scsi device 5
[527548.768381] scsi5 : usb-storage 2-1:1.0
# scsi device 5 (sd driver) mapped to /dev/sdb and probed (0:0:0 is some rarely used SCSI logical sub-device identifier)
[527549.774020] sd 5:0:0:0: [sdb] 7729152 512-byte logical blocks: (3.95 GB/3.68 GiB)
# after probing we found a partition
[527549.782420]  sdb: sdb1
That gets us the plugged in device on /dev/sdb (whole disk) and /dev/sdb1 (first and only partition). Also `lsusb -v` will dump tons of info about the devices, and I believe you can get raw USB access through /dev/bus/usb/BUS#/DEV#. Not that any of this will actually help you on OSX :( The enclosure should show up in the relevant Vendor:Product type listing tool on OSX, but it may not map to a 'device string' unless the enclosure can figure out the drive. It seems (from lsusb info at least) that the Vendor:Product information is a part of the 'Device Descriptor' section of the information, but the actual Class information (mass storage/hid/chip|smart card) is part of the 'Interface Descriptor' section. I could imagine the USB part of the enclosure chatting back and forth with the computer and giving the Device Descriptor info and then borking on the Interface Descriptor if it couldn't chat properly with the actual disk.

Hopefully some more OSX or Windows people will turn up.

Those X5s were awesome, I went through 2 Nintendo DS battery hacks extending the life of mine...
posted by zengargoyle at 2:45 AM on January 6, 2012


If literally nothing happens when you plug in the disk+converter thing, I would guess that the converter thing doesn't work, or is incompatible with OSX or the drive.

What happens when you put the drive back into the mp3 player and try the above steps?

I would also try booting your computer with a Linux live CD (do those exist for Macs?) and trying some of the same steps.

The other suggestion I would give you would be that as soon as you can (hopefully) get the drive to be recognized as a device, do a raw copy of the entire drive to a file, and then cppy that file, and run the recovery utilities on the copy.

In linux, if the device is sdc, this would be:

dd if=/dev/sdc of=/filename

This copies the entire contents of the drive to a file called filename, which can be manipulated exactly the same way a file can. This way, you can try multiple recovery techniques without damaging the actual data on the drive.
posted by gjc at 6:39 AM on January 6, 2012


this is kind of stupid, but... do you know the enclosure is getting enough power over usb i.e. are you using a two plug usb cable?

If it's not showing up as a usb device (and it sounds like it isn't) I'm guessing this is a more primitive problem than getting it to mount. I would try this enclosure with a different computer and see what happens...
posted by ennui.bz at 6:50 AM on January 6, 2012


gjc: The enclosure may just not work, yeah. Starting to consider that possibility. (It's not JUST an OSX thing, because it hasn't worked under Windows 7 either.) The MP3 player itself is toast - when you turn it on, the screen just illuminates all white and nothing else happens. I suspect that without the partition, it couldn't load its own firmware from the disk anymore. Previously when I turned it on, there would be a logo splash screen for a few moments, then it would enter USB mode. Just nothing now.

ennui.bz: I also tried it with my work laptop (a Dell Latitude vs. my Macbook) and it doesn't work there either. The enclosure didn't come with a two-plug USB cable, though, so I'm NOT sure that it's getting enough power... but I also don't have a two-plug cable either and there isn't a socket for an AC plug or anything on the enclosure, so I'm kinda boned that way too.
posted by cobra_high_tigers at 8:03 AM on January 6, 2012


1.8" drives should not require any more power than a standard USB connection will provide.

In Mac OS X, if you do not get any USB event logs when connecting the enclosure, this means that the port is not able to establish any communication with the device. Consequently, I would conclude that your enclosure is not functioning correctly.

If you want to confirm the same thing in Windows, do the following:

- open Regedit.exe on a system that has never had this device connected before
- navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB
- make a note of the current USB keys here
- connect your device (you may need to close and reopen regedit to refresh the list)

If there are any new items the second time around, the computer has recognised the presence of a USB device. The subkeys are (usually) unique to the device.

You can also check the file setupapi.log from %SYSTEMROOT% which also stores information concerning devices and when they have been connected or recognised by the computer.
posted by fearnothing at 9:03 AM on January 6, 2012


feanothing: The plot thickens!

I couldn't try the Registry method, since I'd already tried plugging it into all my systems. But I checked out the log files on my Macbook and on my work laptop (which are located at %windir%\inf\setupapi.dev.log in my Windows 7 install btw) and found:

- nothing on the Macbook
- logs on my work laptop indicating that it initiated a device install last night, and the best driver match the system selected was "Unknown Device" from section [BADDEVICE.DEV] of c:\windows\system32\driverstore\filerepository\usb.inf_x86_neutral_2620fd493cad7d41\usb.inf

So for some reason my Macbook's hardware can't establish communication with the device, but my work Dell Latitude could, but still didn't recognize it as a drive.

Anybody know how to get it recognized as a USB mass storage device instead of Unknown Device?
posted by cobra_high_tigers at 10:07 AM on January 6, 2012


I don't know Macs, or how they run Windows.

Try the USB cable on a true Windows machine, without the drive, allowing any driver to install. Then try attaching the drive. Windows won't recognize an unpartitioned drive, and you can force partition it which will make any recovery harder (but mostly and difficultly possible). But, the Kernel program should be able to access the drive and copy everything out even when Windows can't recognize the drive as long as the USB device is recognized correctly.

Alternate plan, attached a working partitioned drive to the USB cable. Allow Windows to sense it and install it as a USB storage device. Then switch the drive on the cable to the unpartitioned drive. Windows probably can't originally recognize the USB cable as a USB storage device without a working partitioned drive. Then try Kernel.
posted by caclwmr4 at 11:34 AM on January 6, 2012


This sounds more and more like the enclosure not talking to the drive. I would check those Windows files/registry and see if there was a mention of an idVendor/idProduct information. This may be what I mentioned above about the enclosure returning the Device Descriptor and then not being able to return the Interface Descriptor (which holds the device class: hid/msd/etc). Windows USB device makers used to employ some trickery in their devices because Windows users were OMGWTF! when asked to provide a new driver. They would have their devices return a Class of Keyboard so that Windows wouldn't have to ask for a driver (but the device wouldn't work), then when you ran the included software setup program, it would instal the driver for the device, then update the special USB override table and add an entry pointing their Vendor:Product ID to the new driver. The next time you plugged in the device, Windows would check that table first and use the special driver instead of continuing to probe and load it as a keyboard. (this is fucked up and backwards and led to Linux having a USB blacklist of a similar nature that tells the OS to ignore the Class of certain Vendor:Product ID because *they lie!*).

The dump of an external USB Mass Storage Device looks something like this, if you can find the place to override things (and your Vendor:Product info is actually found) you would want to set somewhere 'iConfiguration 4;bInterfaceClass 8' to probably tell Windows that it's a Mass Storage Device and to use the regular msd drivers for the device.
Bus 002 Device 002: ID 059b:0370 Iomega Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x059b Iomega Corp.
  idProduct          0x0370 
  bcdDevice            0.00
  iManufacturer          10 Iomega
  iProduct               11 External HD
  iSerial                 5 91F8FFFFFFFF
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 USB Mass Storage
    bmAttributes         0xc0
      Self Powered
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              6 MSC Bulk-Only Transfer
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
can't get debug descriptor: Connection timed out
Device Status:     0x5301
  Self Powered
Really, take the drive out and inspect the connectors on the drive and the enclosure closely. I've spent hours cursing at a known good disk before discovering that one of the pins was a bit off kilter and had been pushed back in the connector (needing to be pulled back out with needle nose pliers and carefully re-connecting while holding it in place to make sure it didn't slide back out again). And many bent pins, especially the ones on the end from wiggling things apart. I've seen many bent pins and un-keyed connectors connected upside down in my work.

You could also try and find the entry for your phone and duplicate it and change the Vendor:Product ID to match your enclosure. But I know even less about Windows than OSX so...
posted by zengargoyle at 4:43 PM on January 6, 2012


cobra, this is a damn fickle problem. No identification at all? So, now we need more information in regards to the hardware itself.

What the the exact make and model of the 1.8" drive and the external enclosure?

I ask this because, in the past, I have manually swapped the controller on a hard disk drive with one of the same make, model, hard version, and firmware revision to then be able to successfully access the disk. Yeah, it took a while to find that savior disk... but it was necessary.

Let's keep at this. There is a solution. Together, we will find it.
posted by PROD_TPSL at 7:46 PM on January 6, 2012


« Older The passing of Eve Arnold has ...   |  Treating strangers, acquaintan... Newer »
This thread is closed to new comments.