USB drive is detected, but not assigned device

Bug #16428 reported by Eric Schwartz
12
Affects Status Importance Assigned to Milestone
hal (Ubuntu)
Invalid
Medium
Martin Pitt

Bug Description

This bug really should be on linux-image-2.6.10-686, but for some reason,
bugzilla won't let me enter that into the Package: field-- it keeps telling me
"You must choose a component to file this bug in. If necessary, just guess."
I'll file a bug on that in a minute.

I have a Neuros II "audio computer" (er, okay, whatever). Anyhow, when I plug
it into my Ubuntu box, I get these messages in /var/log/syslog:

Apr 25 00:12:32 localhost kernel: usb 1-1: new full speed USB device using
uhci_hcd and address 4
Apr 25 00:12:32 localhost kernel: scsi26 : SCSI emulation for USB Mass Storage
devices
Apr 25 00:12:32 localhost kernel: usb-storage: device found at 4
Apr 25 00:12:32 localhost kernel: usb-storage: waiting for device to settle
before scanning
Apr 25 00:12:32 localhost usb.agent[21410]: usb-storage: already loaded
Apr 25 00:12:37 localhost kernel: Vendor: NEUROS Model: dig. audio comp.
Rev: 1.00
Apr 25 00:12:37 localhost kernel: Type: Direct-Access
ANSI SCSI revision: 00
Apr 25 00:12:37 localhost kernel: usb-storage: device scan complete

And then nothing happens. Normally I would expect to see a message to the
effect of "this device was assigned /dev/sda", and then pmount would mount it,
and all would be well. Instead, it just kinda sits there. As you can imagine,
this makes it kinda hard to copy my new CDs onto my player. :)

Revision history for this message
Eric Schwartz (emschwar-ericschwartz) wrote :

This also happens with my USB flash drive-- I just get

May 2 21:42:02 localhost kernel: usb 4-1: new high speed USB device using
ehci_hcd and address 4
May 2 21:42:02 localhost kernel: scsi1 : SCSI emulation for USB Mass Storage
devices
May 2 21:42:02 localhost usb.agent[10046]: usb-storage: already loaded
May 2 21:42:07 localhost kernel: Vendor: Fujifilm Model: USB Drive
Rev: 4.70
May 2 21:42:07 localhost kernel: Type: Direct-Access
ANSI SCSI revision: 00

in /var/log/syslog, and no drives are shown, and nothing is mounted.

Revision history for this message
Dmitriy Kropivnitskiy (nigde) wrote :

Same this happens here. I am running breezy. My kernel is 2.6.10-5-k7. My USB
device is an iRiver H140.
The device is recognized, but node is not created.
Here is an excerpt of my /var/log/kern.log after plugging the device in
May 8 15:47:07 localhost kernel: usb 3-3: USB disconnect, address 3
May 8 15:47:21 localhost kernel: usb 3-3: new high speed USB device using
ehci_hcd and address 4
May 8 15:47:22 localhost kernel: scsi1 : SCSI emulation for USB Mass Storage
devices
May 8 15:47:22 localhost kernel: usb-storage: device found at 4
May 8 15:47:22 localhost kernel: usb-storage: waiting for device to settle
before scanning
May 8 15:47:27 localhost kernel: Vendor: TOSHIBA Model: MK4004GAH
Rev: JC00
May 8 15:47:27 localhost kernel: Type: Direct-Access
ANSI SCSI revision: 00
May 8 15:47:27 localhost kernel: usb-storage: device scan complete

Revision history for this message
Matt Zimmerman (mdz) wrote :

It's working for me here (Breezy):

usb 1-2.1.3.2: new full speed USB device using uhci_hcd and address 52
scsi2 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 52
usb-storage: waiting for device to settle before scanning
  Vendor: Generic Model: STORAGE DEVICE Rev: 0119
  Type: Direct-Access ANSI SCSI revision: 00
Attached scsi removable disk sdb at scsi2, channel 0, id 0, lun 0
Attached scsi generic sg1 at scsi2, channel 0, id 0, lun 0, type 0
  Vendor: Generic Model: STORAGE DEVICE Rev: 0119
  Type: Direct-Access ANSI SCSI revision: 00
Attached scsi removable disk sdc at scsi2, channel 0, id 0, lun 1
Attached scsi generic sg2 at scsi2, channel 0, id 0, lun 1, type 0
  Vendor: Generic Model: STORAGE DEVICE Rev: 0119
  Type: Direct-Access ANSI SCSI revision: 00
Attached scsi removable disk sdd at scsi2, channel 0, id 0, lun 2
Attached scsi generic sg3 at scsi2, channel 0, id 0, lun 2, type 0
  Vendor: Generic Model: STORAGE DEVICE Rev: 0119
  Type: Direct-Access ANSI SCSI revision: 00
Attached scsi removable disk sde at scsi2, channel 0, id 0, lun 3
Attached scsi generic sg4 at scsi2, channel 0, id 0, lun 3, type 0
usb-storage: device scan complete

Send the output of "dpkg -s hotplug" and "lsmod" after connecting the device.

Revision history for this message
GonzO (gonzo) wrote :

Created an attachment (id=2533)
DPKG -s output

Revision history for this message
GonzO (gonzo) wrote :

Created an attachment (id=2534)
Output of LSMOD

Revision history for this message
GonzO (gonzo) wrote :

I'm having the same problem, and I'm pretty sure this was broken in the latest
security patch of the kernel - worked wonderfully before.

Revision history for this message
Matt Zimmerman (mdz) wrote :

(In reply to comment #6)
> I'm having the same problem, and I'm pretty sure this was broken in the latest
> security patch of the kernel - worked wonderfully before.
>

Which security patch?

The other people experiencing this bug seem to be running the development branch
(breezy).

Revision history for this message
GonzO (gonzo) wrote :

Very recently, the "hoary-security" repository had an update to
linux-image-2.6.10-5-686-smp (which is what I use here). It updated the kernel
from version 2.6.10-34 to 2.6.10-34.1, and the changelog contains a bunch of
security updates.

It is this new kernel that totally ate any automagic mounting for USB devices.
Everything seemed to work fine, but whatever tells pmount to go was just failing
to trigger.

I reverted to the kernel from "hoary" - 2.6.10-34 (without the .1), and
everything is great again.

Revision history for this message
Martin Pitt (pitti) wrote :

CC'ing our kernel guru.

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

(In reply to comment #9)
> CC'ing our kernel guru.

This looks to me the same hotplug problem we fixed a long time ago.

After you insert the key, can you please send us the output of lsmod? and after
can you try to modprobe sd_mod? (scsi disk support) and see the output of dmesg?

Fabio

Revision history for this message
GonzO (gonzo) wrote :

"After you insert the key, can you please send us the output of lsmod? and after
can you try to modprobe sd_mod? (scsi disk support) and see the output of dmesg?"

I no longer run this kernel, and (as I am on a work computer right now) am not
about to install a broken kernel. However, I believe that I can answer the
questions I think you're asking here.

IIRC with the .1 kernal, all of the appropriate modules were loading, and the
kernel was finding /dev/sdX. In fact, the _detection_ phase of the operation
was just about perfect, with dmesg reporting pretty much what it should.

The only problem I could see was that pmount wasn't being asked to run, for
whatever reason. I could type pmount /dev/sdX partname and it would mount
itself just fine, and would even unmount itself if I were to remove the USB key.
 Seemingly, the only breakage was whatever triggers pmount.

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

(In reply to comment #11)
> "After you insert the key, can you please send us the output of lsmod? and after
> can you try to modprobe sd_mod? (scsi disk support) and see the output of dmesg?"
>
> I no longer run this kernel, and (as I am on a work computer right now) am not
> about to install a broken kernel. However, I believe that I can answer the
> questions I think you're asking here.
>
> IIRC with the .1 kernal, all of the appropriate modules were loading, and the
> kernel was finding /dev/sdX. In fact, the _detection_ phase of the operation
> was just about perfect, with dmesg reporting pretty much what it should.
>
> The only problem I could see was that pmount wasn't being asked to run, for
> whatever reason. I could type pmount /dev/sdX partname and it would mount
> itself just fine, and would even unmount itself if I were to remove the USB key.
> Seemingly, the only breakage was whatever triggers pmount.
>

Well clearly this is not a kernel problem. Given that the device is there,
the kernel has already completed its job eons before.

Martin please reassignt his bug to the appropriate package.

Fabio

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #11)
> IIRC with the .1 kernal, all of the appropriate modules were loading, and the
> kernel was finding /dev/sdX. In fact, the _detection_ phase of the operation
> was just about perfect, with dmesg reporting pretty much what it should.

Alright, then this is not a kernel issue.

> The only problem I could see was that pmount wasn't being asked to run, for
> whatever reason. I could type pmount /dev/sdX partname and it would mount
> itself just fine, and would even unmount itself if I were to remove the USB key.
> Seemingly, the only breakage was whatever triggers pmount.

Can you please do the debugging exercise at

  wiki.ubuntu.com/DebuggingRemovableDevices

?

Revision history for this message
Sam Williams (sam-williams) wrote :

(In reply to comment #13)
> (In reply to comment #11)
> > IIRC with the .1 kernal, all of the appropriate modules were loading, and the
> > kernel was finding /dev/sdX. In fact, the _detection_ phase of the operation
> > was just about perfect, with dmesg reporting pretty much what it should.
>
> Alright, then this is not a kernel issue.
>
> > The only problem I could see was that pmount wasn't being asked to run, for
> > whatever reason. I could type pmount /dev/sdX partname and it would mount
> > itself just fine, and would even unmount itself if I were to remove the USB key.
> > Seemingly, the only breakage was whatever triggers pmount.
>
> Can you please do the debugging exercise at
>
> wiki.ubuntu.com/DebuggingRemovableDevices
>
> ?

I have been having the same problem that everyone has reported with the usb
drives being recognized but not being automounted. I wish someone could document
exactly what happens with this sub-system, but no matter. My problem occurred
with Hoary specifically. I found that on user accounts, other then the primary,
I was experiencing this same problem. What I figured out earlier today is that
when a new account is created everything looks like it should work properly.
Subsequent users that are added to the system are not added to the "plugdev"
group. Not sure where this failure occurs. I was a bit puzzled because I was
comparing the Hoary systems to several Fedora systems that performed the task
properly. Fedora also doesn't even use the plugdev group, which made the
exercise even more fun.

My recommendation then is for any account that doesn't get these devices to
automatically mount please save yourself some time and look in /etc/group at the
group called "plugdev", and if necessary add the account(s) manually. The
solution may only fix the problem in a few cases, but it work for me on two
Hoary systems that were exhibiting this problem.

Good Luck!

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #14)
> I have been having the same problem that everyone has reported with the usb
> drives being recognized but not being automounted. I wish someone could document
> exactly what happens with this sub-system, but no matter. My problem occurred
> with Hoary specifically. I found that on user accounts, other then the primary,
> I was experiencing this same problem. What I figured out earlier today is that
> when a new account is created everything looks like it should work properly.
> Subsequent users that are added to the system are not added to the "plugdev"
> group.

This has got nothing to do with this bug. If you create a new user with System
-> Administration -> Users and Groups, you can assign the "Desktop" profile to a
new user which will put him in the "plugdev" group.

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #13)
> Can you please do the debugging exercise at
>
> wiki.ubuntu.com/DebuggingRemovableDevices

No answer for nearly two months, so I'm closing this for now. I will reopen it
if I get this information. Also, do you have the chance to test this with a
recent Breezy live CD?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.