USB Hard Drive not recognized by Sheevaplug

Relatively new, but I've already spent about 12 hours trying to find the solution on my own to no avail, so I thought I'd try my first ever forum post.

I've recently installed Arch Linux ARM install on a Sheevaplug and it seems to be running well for the most part. Arch Linux ARM install is based on Arch, but has been modified to run on ARM architecture, which is used by the Sheevaplug. The plug boots from an SD card. Prior to installing Arch Linux ARM install, I had been running Ubuntu on the plug with a USB hard drive without issues for about a year and a half. On to the problem ...

So far, I have been unable to get Arch to recognize my USB hard drive. This is more than just a simple mounting issue; there is no /dev/sda* created after plugging in the USB hard drive. I have done a bit of testing to help try and pin down the problem. I don't think this is a problem with the drive because it was working fine until I changed the OS. Further, this isn't an issue with the Sheevaplug USB plug, as it recognizes the thumb drive I used to install the OS.

After searching various forums for some time and reviewing some of my log files, I have a couple of ideas as to what may be cause. First, I have found that there may be an issue with my USB modules. lsusb returns the following:
$this->bbcode_second_pass_quote('', 'd')vader ~ $ lsusb
unable to initialize libusb: -99

[kmihelich]

Have you done a full system upgrade (pacman -Syuf) and reboot afterward?

[MrBurns]

I have done a full system upgrade and rebooted. No effect.

[jd1]

lsusb is working for me, but i have huge logs with $this->bbcode_second_pass_quote('', 'a')larm udevd[362]: unable to receive ctrl connection: Function not implemented

[MrBurns]

jd1 - you can (ideally) fix the offending errors, which will eliminate the log messages. If you just want to turn off or filter the log messages you can install Syslog-ng and edit /etc/syslog-ng/syslog-ng.conf. The .conf file allows you to either filter log messages or turn them off all together.

You may also choose to edit /etc/logrotate.conf and have it rotate your logs more frequently or archive/delete logs over a specified size. I updated my logrotate.conf file to rotate my logs daily and rotate any log larger than 20MB.

After editting your logrotate.conf, you'll need to run:
$this->bbcode_second_pass_quote('', 's')udo logrotate -f /etc/logrotate.conf

$this->bbcode_second_pass_quote('jd1', 'l')susb is working for me, but i have huge logs with $this->bbcode_second_pass_quote('', 'a')larm udevd[362]: unable to receive ctrl connection: Function not implemented

[MrBurns]

Slycat,

Thanks for the response. To confirm, fdisk -l returns the following:
$this->bbcode_second_pass_quote('', 'D')isk /dev/mmcblk0: 7948 MB, 7948206080 bytes
4 heads, 16 sectors/track, 242560 cylinders, total 15523840 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

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 16 7871 3928 83 Linux
/dev/mmcblk0p2 7872 15523839 7757984 83 Linux

[slycat]

The udev rule you posted allows udev to automount drives when they are connected (as per the rules you have, standard to the Arch Linux ARM, would mount in /media/). But you're fdisk yields no other drive besides the SD.

I reread that you had an issue with lsusb. I guess there may be some issue with how your sheeva handles the usb port. So i believe you when you say the drive works, but wouldn't hurt to check. If that isn't it, then try this page
https://bbs.archlinux.org/viewtopic.php?id=113163
They had a similar problem with error 99 from libusb. I couldn't recreate the error on my pro so if this doesn't help, I'm not sure what it may be.

Heaven forbid its nothing hardware.

[kmihelich]

It may be a power issue with the Sheeva. Thumb drives require a relatively low amount of power compared to a hard drive, which self-powered needs most of what USB is spec'd to provide. Components, including those in plugs, do tend to fail mysteriously. My guess is an externally-powered USB hard drive would get enumerated.

[MrBurns]

I think I may have good news. Slycat, after I saw your post, I nearly concluded I would need to switch to Debian, which is something I'd rather not have to do. I had seen that post in my research and it did not provide a solution for me. Further, Kmihelich, my USB hard drive is externally powered, so I didn't think it could be an issue of under-powering by the Sheevaplug.

So the good news? Well, I unplugged the hard drive from the Sheevaplug, so that I could bring it across the room to test it by plugging it into my desktop. As I suspected, it worked flawlessly and automounted in Ubuntu without issue. So, I went back to plug it into the Sheevaplug. I thought I'd do one last test before giving up entirely. I FIRST plugged the USB plug into the Sheevaplug and SECOND plugged the powercord for the hard drive into the socket. Holy smokes it worked! The Sheevaplug automounted the external hard drive and fdisk -l now shows:
$this->bbcode_second_pass_code('', 'Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
4 heads, 16 sectors/track, 242560 cylinders, total 15523840 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

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 16 7871 3928 83 Linux
/dev/mmcblk0p2 7872 15523839 7757984 83 Linux

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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: 0x68366a93

Device Boot Start End Blocks Id System
/dev/sda1 63 976768064 488384001 83 Linux
')

I've tried rebooting and the drive continues to fail to be recognized.

My hypothesis is that the failure to recognize is due to a timing issue. Perhaps hard drive doesn't spin-up fast enough to be recognized by the Sheevaplug when the USB cord is plugged in, but plugging in the powercord second gives the hard drive a bit more time to spin up and be recognized by the Sheevaplug.

I would still like to fix this issue. Does anyone know how I can manipulate the timing of the Sheevaplug to give my hard drive more time to spin up? Alternatively, am I headed down the right path? Does my hypothesis hold water?

I have hope again!