devices not detected -- too many open files

Hm, udev does not have any blkid info for sdb1. What is the output of

  sudo blkid -p /dev/sdb1

? If that doesn't detect a file system, please copy&paste the output of

  sudo BLKID_DEBUG=0xffff blkid -p /dev/sdb1

Thanks!

Dear Martin,

thanks for the answer :
Here are the results :

without sudo :

chris@gaube:~$ blkid -p /dev/sdb1

with sudo :
chris@gaube:~$ sudo blkid -p /dev/sdb1
/dev/sdb1: SEC_TYPE="msdos" LABEL="DISK_IMG" UUID="0035-71D2"
VERSION="FAT16" TYPE="vfat" USAGE="filesystem"

and the later command :
root@gaube:~# sudo BLKID_DEBUG=0xffff blkid -p /dev/sdb1
libblkid: debug mask set to 0xffff.
reseting blkid_probe
ready for low-probing, offset=0, size=522174464
--> starting probing loop [idx=-1]
linux_raid_member: call probefunc()
ddf_raid_member: call probefunc()
isw_raid_member: call probefunc()
lsi_mega_raid_member: call probefunc()
via_raid_member: call probefunc()
silicon_medley_raid_member: call probefunc()
nvidia_raid_member: call probefunc()
promise_fasttrack_raid_member: call probefunc()
highpoint_raid_member: call probefunc()
adaptec_raid_member: call probefunc()
jmicron_raid_member: call probefunc()
vfat: magic sboff=54, kboff=0
vfat: call probefunc()
assigning SEC_TYPE
assigning LABEL
assigning UUID
assigning VERSION
assigning TYPE
assigning USAGE
<-- leaving probing loop (type=vfat) [idx=16]
--> starting probing loop [idx=16]
ufs: call probefunc()
sysv: call probefunc()
<-- leaving probing loop (failed) [idx=49]
returning SEC_TYPE value
/dev/sdb1: SEC_TYPE="msdos" returning LABEL value
LABEL="DISK_IMG" returning UUID value
UUID="0035-71D2" returning VERSION value
VERSION="FAT16" returning TYPE value
TYPE="vfat" returning USAGE value
USAGE="filesystem"
root@gaube:~#

On Thu, Oct 29, 2009 at 8:36 PM, Martin Pitt <email address hidden> wrote:
> Hm, udev does not have any blkid info for sdb1. What is the output of
>
>  sudo blkid -p /dev/sdb1
>
> ? If that doesn't detect a file system, please copy&paste the output of
>
>  sudo BLKID_DEBUG=0xffff blkid -p /dev/sdb1
>
> Thanks!
>
>
> ** Package changed: gvfs (Ubuntu) => udev (Ubuntu)
>
> ** Changed in: udev (Ubuntu)
>       Status: New => Incomplete
>
> --
> Usb Media not automaticaly mounted
> https://bugs.launchpad.net/bugs/463347
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Hm, that looks fine. So please plug it in into exactly the same USB port that you used when originally filing the bug, and copy&paste the output of

  udevadm test /devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.0/host12/target12:0:0/12:0:0:0/block/sdb/sdb1

Thanks!

Here is the result :

root@gaube:~# udevadm test
devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.0/host12/target12:0:0/12:0:0:0/block/sdb/sdb1
run_command: calling: test
udevadm_test: version 147
This program is for debugging only, it does not run any program,
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

parse_file: reading '/lib/udev/rules.d/40-gnupg.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-hplip.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-ia64.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-infiniband.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-isdn.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-libfprint0.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-libgphoto2-2.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-libpisock9.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-libsane.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-pilot-links.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-ppc.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-virtualbox-ose-source.rules'
as rules file
parse_file: reading
'/lib/udev/rules.d/40-xserver-xorg-input-wacom.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-zaptel.rules' as rules file
parse_file: reading '/lib/udev/rules.d/45-fuse.rules' as rules file
parse_file: reading '/lib/udev/rules.d/45-kvm.rules' as rules file
parse_file: reading '/lib/udev/rules.d/45-libmtp8.rules' as rules file
parse_file: reading '/lib/udev/rules.d/45-qemu-kvm.rules' as rules file
parse_file: reading '/lib/udev/rules.d/50-firmware.rules' as rules file
parse_file: reading '/lib/udev/rules.d/50-udev-default.rules' as rules file
parse_file: reading '/lib/udev/rules.d/56-hpmud_support.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-cdrom_id.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-alsa.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-input.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-serial.rules' as rules file
parse_file: reading
'/lib/udev/rules.d/60-persistent-storage-tape.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-storage.rules' as
rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-v4l.rules' as rules file
parse_file: reading
'/lib/udev/rules.d/61-gnome-bluetooth-rfkill.rules' as rules file
parse_file: reading '/lib/udev/rules.d/61-mobile-action.rules' as rules file
parse_file: reading
'/lib/udev/rules.d/61-option-modem-modeswitch.rules' as rules file
parse_file: reading
'/lib/udev/rules.d/61-persistent-storage-edd.rules' as rules file
parse_file: reading '/lib/udev/rules.d/64-device-mapper.rules' as rules file
parse_file: reading '/lib/udev/rules.d/65-dmsetup.rules' as rules file
parse_file: reading '/lib/udev/rules.d/70-acl.rules' as rules file
parse_file: reading '/lib/udev/rules.d/70-hid2hci.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-persistent-cd.rules' as rules file
parse_file: readin...

Christophe Sauthier (huats) [2009-10-30 8:31 -0000]:
> unable to open device

Ah, sorry, can you please re-run with sudo?

Actually I ran it with sudo (I was root)... And the same error (unable to open device) happens when I run it with a regular user, or using sudo...

I have also notice that there is no such directory, (/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.0/host12/target12:0:0/12:0:0:0/block/sdb/sdb1) but that there is another one that exists (/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.0/host20/target20:0:0/20:0:0:0/block/sdb/sdb1).

Not sure if it is helpful.

I can confirm USB storages don't automount for me either. Fresh install Ubuntu 9.10 AMD64. Use to work fine in the previous version. Also, on a related note my card reader no longer automounts either.

I have the same problem too. Nothing I plug in shows up. I'm on an Acer Aspire 5515. dmesg shows a device was attached, though.

I tried also from a LiveCD of Karmic and USB drives finally started showing up just because I ran System > Administration > Disk Utility one time (and didn't even do anything in it). However, after that, my Linux partitions and hidden Windows backup partitions stopped showing up. Also, the Disk Utility said half of my internal HD was unallocated. Also, all internal HD partitions, but no USB drives showed up in GParted. Again, that's all on LiveCD, haven't tried either of those programs in my installed Karmic, because I don't want to lose any data (since Disk Utility scared me when it said drive was empty).

bug #466275 seems a similar issue

Is whatever causing this bug the same reason why Palimpsest Disk Utility on my installed Karmic reports my USB drive as "unknown or unused" and my hidden backup Vista partition as unallocated?

Some notekeeping while I debug this with Christophe in IRC:

 - blkid is fine
 - udevadm monitor -> no usb_id/blk_id results in sdb1 node
 - "sudo stop udev" and "sudo udevd --debug" -> everything starts to work
 - things keep working after "sudo start udev"

So it looks related to the first udevd instance started after boot.

For everyone who is affected by this, can you please check if automounting starts to work after a "sudo stop udev" and "sudo start udev"?

I think I got it: With "pidof udevd" I determined the udev subprocess which runs the callouts and rules, straced it, and now see the cause:

9782 open("/sys/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EMFILE (Too many open files)
9782 open("/sys/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/*/uevent", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EMFILE (Too many open files)
9782 socket(PF_FILE, 0x80002 /* SOCK_??? */, 0) = -1 EMFILE (Too many open files)
9782 open("/dev/console", O_WRONLY|O_NOCTTY) = -1 EMFILE (Too many open files)
9782 unlink("/dev/.udev/db/scsi:1:0:0:0") = -1 ENOENT (No such file or directory)
9782 socket(PF_FILE, SOCK_DGRAM, 0) = -1 EMFILE (Too many open files)
9782 socket(PF_FILE, 0x80002 /* SOCK_??? */, 0) = -1 EMFILE (Too many open files)
9782 open("/dev/console", O_WRONLY|O_NOCTTY) = -1 EMFILE (Too many open files)
[...]

That explains why restarting udev cures this. It seems that there is an fd leak somewhere.

/proc/pid/fd/ on Christophes' system:

lr-x------ 1 root root 64 2009-11-02 15:58 1000 -> /dev/.udev/links/dvd
lr-x------ 1 root root 64 2009-11-02 15:58 1001 -> /dev/.udev/links/dvdrw
lr-x------ 1 root root 64 2009-11-02 15:58 1002 -> /dev/.udev/links/scd0
lr-x------ 1 root root 64 2009-11-02 15:58 1003 -> /dev/.udev/links/disk\x2fby-path\x2fpci-0000:00:1f.2-scsi-1:0:0:0
lr-x------ 1 root root 64 2009-11-02 15:58 1004 -> /dev/.udev/links/cdrom
lr-x------ 1 root root 64 2009-11-02 15:58 1005 -> /dev/.udev/links/cdrw
lr-x------ 1 root root 64 2009-11-02 15:58 1006 -> /dev/.udev/links/dvd
lr-x------ 1 root root 64 2009-11-02 15:58 1007 -> /dev/.udev/links/dvdrw
lr-x------ 1 root root 64 2009-11-02 15:58 1008 -> /dev/.udev/links/scd0
lr-x------ 1 root root 64 2009-11-02 15:58 1009 -> /dev/.udev/links/disk\x2fby-path\x2fpci-0000:00:1f.2-scsi-1:0:0:0
lr-x------ 1 root root 64 2009-11-02 15:58 101 -> /dev/.udev/links/dvdrw
lr-x------ 1 root root 64 2009-11-02 15:58 1010 -> /dev/.udev/links/cdrom
lr-x------ 1 root root 64 2009-11-02 15:58 1011 -> /dev/.udev/links/cdrw
lr-x------ 1 root root 64 2009-11-02 15:58 1012 -> /dev/.udev/links/dvd
lr-x------ 1 root root 64 2009-11-02 15:58 1013 -> /dev/.udev/links/dvdrw
lr-x------ 1 root root 64 2009-11-02 15:58 1014 -> /dev/.udev/links/scd0
lr-x------ 1 root root 64 2009-11-02 15:58 1015 -> /dev/.udev/links/disk\x2fby-path\x2fpci-0000:00:1f.2-scsi-1:0:0:0
[...]

On my own system (where stuff works), I also have many repeated fds, but not up to 1024, but to 45 only:

lr-x------ 1 root root 64 2009-11-02 16:01 10 -> /dev/.udev/links/disk\x2fby-id\x2fusb-0204_Flash_Disk_2518140190946614-0:0-part1
lr-x------ 1 root root 64 2009-11-02 16:01 11 -> /dev/.udev/links/disk\x2fby-path\x2fpci-0000:00:1d.7-usb-0:8.2:1.0-scsi-0:0:0:0-part1
lr-x------ 1 root root 64 2009-11-02 16:01 12 -> /dev/.udev/links/disk\x2fby-uuid\x2f33C1-15B4
lr-x------ 1 root root 64 2009-11-02 16:01 13 -> /dev/.udev/links/disk\x2fby-label\x2fUBUINSTALL
lr-x------ 1 root root 64 2009-11-02 16:01 14 -> /dev/.udev/links/disk\x2fby-id\x2fusb-0204_Flash_Disk_2518140190946614-0:0-part1
lr-x------ 1 root root 64 2009-11-02 16:01 15 -> /dev/.udev/links/disk\x2fby-path\x2fpci-0000:00:1d.7-usb-0:8.2:1.0-scsi-0:0:0:0-part1
lr-x------ 1 root root 64 2009-11-02 16:01 16 -> /dev/.udev/links/disk\x2fby-uuid\x2f33C1-15B4
lr-x------ 1 root root 64 2009-11-02 16:01 17 -> /dev/.udev/links/disk\x2fby-label\x2fUBUINSTALL
lr-x------ 1 root root 64 2009-11-02 16:01 18 -> /dev/.udev/links/disk\x2fby-id\x2fusb-0204_Flash_Disk_2518140190946614-0:0-part1

Something is looping here..

If I do "sudo ls -l /proc/<pid>/fd | wc -l", I see that increase by 4 for every "udevadm trigger --sysname-match=sdb1 --action=change" that I do.

Easy reproducer:

$ for p in `pidof udevd`; do sudo ls -l /proc/$p/fd | wc -l; done | awk '{$s += $1} END { print $s }'
14
$ sudo udevadm trigger --action=change --subsystem-match=block
$ for p in `pidof udevd`; do sudo ls -l /proc/$p/fd | wc -l; done | awk '{$s += $1} END { print $s }'
34

I can confirm that sudo stop udev && sudo start udev acts as a workaround for me.

Yes .. that did it :D

Thanks

stop/start udev makes things work again. tested it with a fat usb stick & a ext3+luks usb hd
Thanks!

sudo udevadm control --reload-rules

is enough to fix the pb for me

I think I nailed it down. I uploaded an udev package with a proposed fix to my PPA:

  https://launchpad.net/~pitti/+archive/ppa

With karmic final's duev I can reproduce the leak, and this version fixes it. However, to be 100% sure, I'd appreciate if you all could upgrade to my new udev package and confirm that everything works then? Please also reboot afterwards, since this bug only tends to happen after a clean boot.

Thank you in advance!

Even if it shouldn't be _this_ fd leak, the patch does fix a real fd leak, so I committed it upstream:

  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=495d408

Martin, the fix in your ppa works like a charm !

Thanks a lot, remind me to get you at least a beer next time we met !

Thanks Christope! Marking as fix committed for Karmic, since I committed it upstream, and it will be part of the 147 release (which is planned to happen soon).

Uploaded to karmic-proposed queue, waiting for SRU team processing.

I also included the fix for http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=4daa146b into the SRU. It immediately breaks udev when building with -O0 on amd64. It's purely coincidental that it seems to work with the current .debs (apparently the upper bits of nbytes are usually zero), but it's a disaster waiting to happen, and the fix is obvious.

I stumbled over this myself when I debugged the original problem here, and independently arrived at the same patch.

Accepted into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I'm confused. I don't have any command line experience yet, but I know USB drives never mount for me (unless I use the Karmic LiveCD, and then it's still mounted only sometimes), but the original poster said you can see if you have the bug with this command:
for p in `pidof udevd`; do sudo ls -l /proc/$p/fd | wc -l; done | awk '{$s += $1} END { print $s }'

"If the resulting number is around 1000 or higher, then you have the problem described in this bug report."

The workaround "sudo stop udev" and then "sudo start udev" works for me, but the result I got from the original command was:
$ for p in 'pidof udevd'; do sudo ls -l /proc/$p/fd | wc -l; done | awk '{$s += $1} END { print $s }'
ls: cannot access /proc/pidof: No such file or directory
ls: cannot access udevd/fd: No such file or directory
0

Now, after the workaround, it doesn't say it can't find anything, but it still returns 0.

Is my problem a different one? And, is it related to the fact that (before doing the workaround) Palimpsest Disk Utility never recognized my USB as a known filesystem (and also sometimes half, sometimes all of my other internal HD partitions)? GParted always saw everything find, though.

You have used 'pidof udevd' instead of `pidof udevd`.

Zeniff [2009-11-03 19:02 -0000]:
> $ for p in 'pidof udevd'; do sudo ls -l /proc/$p/fd | wc -l; done | awk '{$s += $1} END { print $s }'

Wrong quotes. You have to use ` ` for the pidof, not ' ' :)

> The workaround "sudo stop udev" and then "sudo start udev" works for me,
> [...]
> Is my problem a different one?

Most probably it's the same one. But don't worry about the complicated
command line above, it was more or less for intermediate notekeeping.
It would be great if you could test the package in -proposed and give
feedback if it fixes the problem for you.

> And, is it related to the fact that
> (before doing the workaround) Palimpsest Disk Utility never recognized
> my USB as a known filesystem (and also sometimes half, sometimes all of
> my other internal HD partitions)?

Yes, it's the very same problem.

> GParted always saw everything find, though.

Also expected, because gparted does its own probing and does not use
udev.

Thanks, Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Wow, thank you for the fast answer! I'm glad you guys are able to fix this so fast (especially since all my stuff is only on USB drives). :)

I noticed the quotes...kind of, but thought it was just a font issue or something on the website. I guess one time must have I copy and pasted it in. Okay...I found out it's the ` under ~ key...sorry, I never used it before. ^^;;;

I'm about to do the -proposed update you mentioned. But do I only install the udev package? There are 3 updates which have your version number, libudev and just udev both mention 147~-6 as the version and libgudev says it's version 1:147~-6.

I also have a question about the device name when it does mount after the workaround. In Jaunty, my USB drive would show up as /media/disk if it didn't have a label. Now it shows up as /media/D466-FF0D Is that a problem or normal? Drives with a label do show the label, though. (Sorry if I shouldn't ask questions here, but I thought it might be related.)

Thanks again!

Zeniff [2009-11-03 21:32 -0000]:
> I'm about to do the -proposed update you mentioned. But do I only
> install the udev package? There are 3 updates which have your version
> number, libudev and just udev both mention 147~-6 as the version and
> libgudev says it's version 1:147~-6.

These are all built by the udev source package, and for testing it's
actually better to install them all (they should not change anything
in theory).

> I also have a question about the device name when it does mount after
> the workaround. In Jaunty, my USB drive would show up as /media/disk if
> it didn't have a label. Now it shows up as /media/D466-FF0D Is that a
> problem or normal?

Well, it's intended by upstream, but at least questionable
usability-wise. This is discussed in bug 390304.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

This bug was fixed in the package udev - 147~-6.1

---------------
udev (147~-6.1) karmic-proposed; urgency=low

  * udev/udev-node.c: Properly close directory handles to fix a major fd leak
    which caused hotplugging to fail entirely. (LP: #463347)
  * udev/udevd.c, handle_inotify(): Fix datatype for FIONREAD ioctl return
    type. It must be an int, not an ssize_t; the latter causes uninitialized
    values and tries to allocate a 15 digit number of bytes, unless the upper
    half of the variable just happens to be zeroed. (Upstream commit
    http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=4daa146b)

 -- Martin Pitt <email address hidden> Mon, 02 Nov 2009 23:47:49 +0100

Copied karmic-proposed to lucid.

Hi Martin,
I have tested your proposed update and it seems to work perfect with 2 of my 3 usb devices. The only exception is a 2,5" usb hd that throws an error when I choose "save remove". See the attachment if you are interested in that issue. However, I am not sure if this is really related to this bug since it does not happen when I choose normal remove. Do you know the difference between a normal and a save remove?

conclusion: Your fix is working! Good Job!

Best regards & thanks,
sektor

sektor [2009-11-04 0:03 -0000]:
> Hi Martin, I have tested your proposed update and it seems to work
> perfect with 2 of my 3 usb devices.

Thanks for testing!

> The only exception is a 2,5" usb
> hd that throws an error when I choose "save remove".

That's unrelated. Due to this bug, the drive wouldn't have been
automounted in the first place.

> See the attachment if you are interested in that issue. However, I
> am not sure if this is really related to this bug since it does not
> happen when I choose normal remove. Do you know the difference
> between a normal and a save remove?

Yes, unfortuantely the right-click menu is an UI disaster in Karmic.
"Unmount" disables just a single partition, but leaves the device
fully powered, so that you can remount it. "Eject" disables all
partitions and disconnects power from the device, so that e. g. iPods
stop whining about "unsafe to disconnect". "Safe eject" additionally
disconnects power from the entire USB controller, which is necessary
for some hardware. However, this breaks for builtin USB controllers,
so it could not become the default yet (a possible solution is being
discussed upstream).

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

The package in proposed fixes the bug I was facing.

Thanks Martin !

I have also run with this version for four days, during which I tortured devkit-disks and udev a lot with my test suite. I also used USB hard disks/sticks a lot, all work fine .

works for me now too.
i suppose that bad name of mount point requires a new bug report :

nicolas@koala:~$ ls /media/
199D-8536 cdrom cdrom0 yD?sstruct_
nicolas@koala:~$

and on nautilius, name are with big square like []

thanks for this fix.

I think there may be more than one cause for this problem. My udev isn't showing mad numbers of fds left open (though the scripted test case to reproduce the problem noted above by Martin Pitt *does* cause an increase in open file handles for udevd).

WRT bug 466275, which has been marked as a potential dupe of this one, I have the same experience -- running palimpsest causes the removable drive, on next insert, to be recognised by gnome / gvfs / whatever is ignoring the drive.

However, inserting the drive *does* produce device nodes -- and it's my understanding that that is part of what udev does? If so, then there's something else which is causing the drive(s) not to appear in the Nautilus places bar. Interestingly enough, other file managers (Dolphin, in particular), *do* see the drive as an unmounted volume which it will mount when the item is clicked.

This bug was fixed in the package udev - 147~-6.1

---------------
udev (147~-6.1) karmic-proposed; urgency=low

  * udev/udev-node.c: Properly close directory handles to fix a major fd leak
    which caused hotplugging to fail entirely. (LP: #463347)
  * udev/udevd.c, handle_inotify(): Fix datatype for FIONREAD ioctl return
    type. It must be an int, not an ssize_t; the latter causes uninitialized
    values and tries to allocate a 15 digit number of bytes, unless the upper
    half of the variable just happens to be zeroed. (Upstream commit
    http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=4daa146b)

 -- Martin Pitt <email address hidden> Mon, 02 Nov 2009 23:47:49 +0100

Perhaps I'm doing something incorrectly, but none of these solutions work for me.

I've tried the stop start udev and that hasn't helped. I'm trying to get my Casio camera to mount when i attach it via USB as well as an external USB hard drive and numerous USB sticks.

I've also notice that in the nautilus computer view there are 4 cd rom drives instead of the two that were in jaunty.

AMD64 Karmic
udev 147 6.1
I would appreciate some help with this.

piratemurray [2009-11-10 14:48 -0000]:
> I've tried the stop start udev and that hasn't helped.

You have a different problem them.

> I would appreciate some help with this.

Please do "ubuntu-bug storage" procedure for your camera.

Thanks Martin. I've followed your suggestion and created a new bug with the ubuntu-bug storage procedure. The bug number is #480131.

fresh karmic install on panasonic cf73 laptop.
on livecd automount worked, after installing and upgrading system is not working anymore
no usb storages are automounted.

Hi~ Sorry it took a while to get back, but I tried the fix, and it seems like it's working for me! Thank you very much!! I also recently clean-installed 9.10 on a desktop, but didn't seem to have this problem at all, so I guess it was specific to certain hardware?

Anyway, thanks again! Have a great day! ^_^

Zeniff [2009-11-12 5:55 -0000]:
> Hi~ Sorry it took a while to get back, but I tried the fix, and it seems
> like it's working for me!

Great to hear!

> I also recently clean- installed 9.10 on a desktop, but didn't seem
> to have this problem at all, so I guess it was specific to certain
> hardware?

It happened pretty randomly, but it was only hardware dependent in the
sense that depending on the number of partitions/drives/etc. and how
long udev had been running you were more or less likely to hit the
maximum number of open fds.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Hi, restarting udev does not work for me.
Also upgrading udev has no effect. Is there another workaroud ?

Thanks

Stitch

Stitch [2009-11-12 15:40 -0000]:
> Hi, restarting udev does not work for me.
> Also upgrading udev has no effect. Is there another workaroud ?

You have a different problem then. Hard to say what the workaround is
without knowing the details.

Hello, I've got the same problem. Usb drives don't automount. I've tried workaround and nothing happens. Here's the output:
mount: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so .
and the dmesg | tail :
[ 343.630427] sd 8:0:0:0: [sdc] Mode Sense: 00 c0 00 00
[ 343.630433] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[ 343.637338] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[ 343.637350] sdc: sdc1
[ 343.660578] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[ 343.660591] sd 8:0:0:0: [sdc] Attached SCSI removable disk
[ 344.956850] FAT: IO charset ANSI_X3.4-1968 not found
[ 344.972328] FAT: IO charset ANSI_X3.4-1968 not found
[ 344.986351] FAT: IO charset ANSI_X3.4-1968 not found
[ 345.042095] FAT: IO charset ANSI_X3.4-1968 not found

Any help would be appreciated. Thanx in advance!

Ragnar

If none of these workarounds have helped, your problem is probably different. Log out and then check the locale settings for your user, probably they have been set to something other than what you expect. Set them to whatever language you normally use and log in again, then try mounting your drive. (i read this bug trying to fix the same problem).

Even after updating to latest udev (147~-6.1), I still have this problem. The "start/stop udev" workaround does work, but how do I get this fixed to avoid the workaround?

deerewright [2009-12-30 16:55 -0000]:
> Even after updating to latest udev (147~-6.1), I still have this
> problem. The "start/stop udev" workaround does work, but how do I get
> this fixed to avoid the workaround?

If you really have this new version and rebooted since then, then you
do not have this problem, but another unrelated bug. Can you please
open a new report and describe the symptoms in detail? Thanks!

Hello, I've got the same problem.
My usb camera had no problem to be mounted with gphoto2 in my Karmic.
When I installed the gnone-volume-manager (Version 2.24.1-3ubuntu1) is doens't mount anymore.
I tried to uninstall gnome-volume-manager, and reinstall udev, gphoto2, libgphoto... and still not working.
Let me give some system informations:
When I plug the camera i have:

>>>> tail -f /var/log/message:
kernel: [183586.411330] usb 2-3: new high speed USB device using ehci_hcd and address 10
kernel: [183586.594509] usb 2-3: configuration #1 chosen from 1 choice

>>>>> udevadm monitor:
KERNEL[1264625537.297637] add /devices/pci0000:00/0000:00:04.1/usb2/2-3 (usb)
KERNEL[1264625537.297876] add /devices/pci0000:00/0000:00:04.1/usb2/2-3/2-3:1.0 (usb)
UDEV [1264625537.310658] add /devices/pci0000:00/0000:00:04.1/usb2/2-3 (usb)
UDEV [1264625537.317801] add /devices/pci0000:00/0000:00:04.1/usb2/2-3/2-3:1.0 (usb)

>>>> udevadm test /devices/pci0000:00/0000:00:04.1/usb2/2-3
run_command: calling: test
udevadm_test: version 147
This program is for debugging only, it does not run any program,
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

parse_file: reading '/etc/udev/rules.d/10-vboxdrv.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-gnupg.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-hplip.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-ia64.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-infiniband.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-isdn.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-libgphoto2-2.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-libibverbs1.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-libpisock9.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-libsane.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-pilot-links.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-ppc.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-usbmount.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-xserver-xorg-input-wacom.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-zaptel.rules' as rules file
parse_file: reading '/lib/udev/rules.d/45-fuse.rules' as rules file
parse_file: reading '/etc/udev/rules.d/45-libmtp7.rules' as rules file
parse_file: reading '/lib/udev/rules.d/45-libmtp8.rules' as rules file
parse_file: reading '/etc/udev/rules.d/45-libnjb5.rules' as rules file
parse_file: reading '/lib/udev/rules.d/50-firmware.rules' as rules file
parse_file: reading '/lib/udev/rules.d/50-udev-default.rules' as rules file
parse_file: reading '/lib/udev/rules.d/56-hpmud_support.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-cdrom_id.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-alsa.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-input.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-serial.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-per...

OK I just booted and plugged in a USB mp3 player (USB Storage) it automounted and opened a window in gnome.
I did this because I tried to do the same just before rebooting and I needed to stop/start udev in order to get the /dev/sdc1 device created. The difference ? .. before the reboot I had been running stress stress -d 100 -i 100 plus other work to create load on my disk (I have a failing seagate 1.5Tb disk). So I have a failing case followed by a working case:

# udevd --version
147

Most recent (working) /var/log/messages:

Feb 13 17:12:43 eddie kernel: [ 482.284514] usb 4-2: new full speed USB device using uhci_hcd and address 2
Feb 13 17:12:44 eddie kernel: [ 482.455130] usb 4-2: configuration #1 chosen from 1 choice
Feb 13 17:12:44 eddie kernel: [ 482.486055] Initializing USB Mass Storage driver...
Feb 13 17:12:44 eddie kernel: [ 482.486275] scsi4 : SCSI emulation for USB Mass Storage devices
Feb 13 17:12:44 eddie kernel: [ 482.486409] usbcore: registered new interface driver usb-storage
Feb 13 17:12:44 eddie kernel: [ 482.486414] USB Mass Storage support registered.
Feb 13 17:12:49 eddie kernel: [ 487.492841] scsi 4:0:0:0: Direct-Access JUNGSOFT MUZIO JM-300 0000 PQ: 0 ANSI: 0
Feb 13 17:12:49 eddie kernel: [ 487.493898] sd 4:0:0:0: Attached scsi generic sg3 type 0
Feb 13 17:12:49 eddie kernel: [ 487.543801] sd 4:0:0:0: [sdc] 1013760 512-byte logical blocks: (519 MB/495 MiB)
Feb 13 17:12:49 eddie kernel: [ 487.629792] sd 4:0:0:0: [sdc] Write Protect is off
Feb 13 17:12:49 eddie kernel: [ 487.767789] sdc: sdc1
Feb 13 17:12:49 eddie kernel: [ 487.911793] sd 4:0:0:0: [sdc] Attached SCSI removable disk

previous:

# grep udev /var/log/messages
Feb 8 18:46:32 eddie kernel: [ 8.961440] udev: starting version 147
Feb 10 08:13:27 eddie kernel: [ 8.928125] udev: starting version 147
Feb 11 18:31:02 eddie kernel: [ 13.560037] udev: starting version 147
Feb 12 19:44:27 eddie kernel: [ 13.585444] udev: starting version 147
Feb 13 12:27:31 eddie kernel: [60199.243449] udev: starting version 147 <------ this is me doing stop/start
Feb 13 17:05:02 eddie kernel: [ 8.832194] udev: starting version 147

From start of day ... (I guess popularity-contest ignores my proxy settings :-) )
Feb 13 08:03:45 eddie popularity-contest: unable to submit report to http://popcon.ubuntu.com/popcon-submit.cgi.
Feb 13 08:03:45 eddie popularity-contest: unable to submit report.
Feb 13 12:06:47 eddie kernel: [58955.212026] usb 4-1: new full speed USB device using uhci_hcd and address 2
Feb 13 12:06:47 eddie kernel: [58955.387137] usb 4-1: configuration #1 chosen from 1 choice
Feb 13 12:06:47 eddie kernel: [58955.532833] Initializing USB Mass Storage driver...
Feb 13 12:06:47 eddie kernel: [58955.533249] scsi4 : SCSI emulation for USB Mass Storage devices
Feb 13 12:06:47 eddie kernel: [58955.533853] usbcore: registered new interface driver usb-storage
Feb 13 12:06:47 eddie kernel: [58955.533858] USB Mass Storage support registered.
Feb 13 12:06:50 eddie kernel: [58958.448047] usb 4-1: USB disconnect, address 2
Feb 13 12:07:50 eddie kernel: [59018.244527] usb 4-1: new full speed USB device using uhci_hcd and address 3
Feb 13 12:07:...

hi i have fresh ubuntu 9.10 install i updated and upgraded everything using synaptic. its about 200 mb of data after update i get udev ver 147 6.1 and my usb 8 gb flash is recognised. the problem i got is that there is high cpu usage in around 40% non-stop.
i checked and found that when i downgrade udev to version 147 6.0 then cpu usage is around 0 to 3% max. but with version 147 6.0 usb flash is not recognised. so i got choice use udev 147 6.0 and dont use usb flash drive or use udev 147 6.1 and kill my cpu. my laptop spec msi gt 725. it have q9000 quad core 2Ghz ddr2 4gb hdd 500gb graphic ati hd 4850 sound intel acl1200+ati hdmi. is there any solution for it?

For as long as I can remember, going back several Ubuntu versions, I've been able to plug in my external USB backup drive and it has automatically mounted on /media/Backup and opened a Nautilus window. However, about 2-3 weeks ago this just stopped working and I have had to manually mount my external USB backup drive or reboot my laptop to get auto-mounting working again. Having found this bug report, running the "sudo udevadm control --reload-rules" seems to get auto-mounting working again.

Oops. I forgot to say that my laptop is running Ubuntu 9.10.