USB flash drive does not mount automatically

There is no bug here, the udev db has sdc1 in it with the relevant details - the problem must be further up the stack (for which you already have a bug open)

Ok, thanks.

There does seem to be an udev problem here:

  HotplugNewDevices: /dev/sdc

That means that /dev/sdc was created by udev, but not /dev/sdc1. The udev monitor log does not even have sdc. (The kernel detects an sdc1). The udev _database_ does have both, though, but it seems it is not sending events to devkit-disks (see the empty monitor log).

Please do the following in a Terminal:

  pull out the USB drive
  sudo stop udev
  sudo udevd --debug > /tmp/udev-debug.log 2>&1
  plug in the drive
  wait for a couple of seconds
  press Control-C
  sudo start udev

and then attach /tmp/udev-debug.log here.

Thanks!

On Mon, 2009-11-09 at 18:36 +0000, Martin Pitt wrote:

> There does seem to be an udev problem here:
>
> HotplugNewDevices: /dev/sdc
>
> That means that /dev/sdc was created by udev, but not /dev/sdc1. The
> udev monitor log does not even have sdc. (The kernel detects an sdc1).
> The udev _database_ does have both, though, but it seems it is not
> sending events to devkit-disks (see the empty monitor log).
>
There is no relevant monitor log attached to this bug.

Are you sure you're not confusing this with a different report?

Scott
--
Scott James Remnant
<email address hidden>

@Scott:

> There is no relevant monitor log attached to this bug.

There is a field "DKDisksMonitorLog" in the description; it's shown inline because it's < 5 lines. Also, the "HotplugNewDevices:" shows which /dev/sd* have appeared for the new device which was plugged in, and it's blatantly missing /dev/sdc1.

@Scott: Oh, and there's an UdevMonitorLog.txt attachment which shows that neither sdc nor sdc1 are sent out as events.

@Giulio,

I don't see errors in the udev log, but /dev/sdc1 simply doesn't appear. May it be that those devices are re-routed to VirtualBox somehow? Some rules match there. Do you have virtualbox running on this machine when trying this? Can you please attach /etc/udev/rules.d/50-virtualbox-ose.rules here?

I also wonder why you still have /etc/udev/rules.d/45-libmtp7.rules, this was moved to /lib/udev/rules.d/ long ago; except if you modified it?

Since the udev debug log isn't enlightening, we need to do that differently:

 - Reboot with the USB drive not plugged in.
 - Open a Terminal and do:

   sudo -i
   for p in `pidof udevd`; do (strace -vvfs 1024 -o /tmp/udev.$p.log -p $p &); done

 - Plug in the drive, wait 10 seconds
 - killall strace

And then attach /tmp/udev.*.log here (should be three files).

On Tue, 2009-11-10 at 07:47 +0000, Martin Pitt wrote:

> > There is no relevant monitor log attached to this bug.
>
> There is a field "DKDisksMonitorLog" in the description; it's shown
> inline because it's < 5 lines. Also, the "HotplugNewDevices:" shows
> which /dev/sd* have appeared for the new device which was plugged in,
> and it's blatantly missing /dev/sdc1.
>
So?

This can simply be a bug in whatever you do to get that information
(e.g. the user doesn't unplug and replug the key while the monitor is
running)

Scott
--
Scott James Remnant
<email address hidden>

Hello, Virtualbox was not running during the tests. There is the possibility inside the application to reroute a specific device to the virtual machine, but I did not do it permanently for this device. I tried right now to attach the device to the virtual machine: I can see the device name, and when I click I see USB activity, but I get no result. Before karmic it worked.

Don't know for /etc/udev/rules.d/45-libmtp7.rules. Maybe I could have touched it when I tried to get working a Palm device, but that was years ago, surely before jaunty, and surely it does not contain any valuable edit. Should I delete it?

Thanks for your help.

Thanks. The strace shows that udev both received and sent the events for /dev/sdc1, and also mknod()ed /dev/sdc1 successfully. So either the problem only happens sometimes, or something went wrong when you inserted the device while reporting the bug initially. So I don't believe the original UdevMonitorLog.txt and DKDisksMonitorLog attachments any more.

Can you please unplug the drive, then open a terminal, and do

  devkit-disks --monitor-detail > /tmp/dkd.log 2>&1 &
  udevadm monitor -e --udev > /tmp/udev.log 2>&1 &
  gvfs-mount -oi > /tmp/gvfs.log 2>&1

then plug in the drive, wait for 20 seconds. Close the terminal, and then attach /tmp/dkd.log, /tmp/udev.log, and /tmp/gvfs.log here.

> gvfs-mount: command not found

ah, too bad. Can you please do "sudo apt-get install gvfs-bin" and do the procedure with gvfs-mount -oi again?

devkit-disks log looks fine, reassigning to gvfs.

Sorry, I did not think I could be useful, so I did not even look at them.

(gvfs-mount:3579): GVFS-RemoteVolumeMonitor-WARNING **: invoking IsSupported() failed for remote volume monitor with dbus name org.gtk.Private.GduVolumeMonitor: org.freedesktop.DBus.Error.Spawn.ChildSignaled: Process /usr/lib/gvfs/gvfs-gdu-volume-monitor received signal 6

Ah, in plain English that means that gvfs has crashed with an assertion. It is likely that this was already reported in bug 435136, but to be sure, can you please do:

killall gvfs-gdu-volume-monitor
/usr/lib/gvfs/gvfs-gdu-volume-monitor

then plug in the USB stick. This should crash the program and leave some screen output. Could you please copy&paste this?

Thanks!

gvfs-gdu-volume-monitor was not running, and I got an error when I tried to start it.

giulio@contraire:~$ killall gvfs-gdu-volume-monitor
gvfs-gdu-volume-monitor: no process found
giulio@contraire:~$ /usr/lib/gvfs/gvfs-gdu-volume-monitor
**
libgdu:ERROR:gdu-pool.c:1253:device_recurse: assertion failed: (depth < 100)
Aborted