I don't know if this is the right place for a bug in udev, but I couldn't find another place. Under udev-045, I had the following rule in 10-local.rules: BUS="usb", SYSFS{product}="USB Zip 100", KERNEL="sd?", NAME{ALL_PARTITIONS}="zipdrive", SYMLINK="%k" Then I upgraded to udev-056, and it stopped creating the partitions when I plugged in my zip drive. /dev/zipdrive was still created, but not /dev/zipdrive4 for example. Then I changed the rule to this: BUS="usb", SYSFS{product}="USB Zip 100", KERNEL="sd?", NAME="zipdrive%n", SYMLINK="%k", OPTIONS="all_partitions" That caused all the partitions to appear, but I couldn't mount /dev/zipdrive4 anymore like I could before. I can still mount /dev/sda4 with udev-056. But that's not a satisfactory work-around because I want to be able to get around the problem of plugging in the drive without the zip disk in it, which is what using ALL_PARTITIONS is supposed to let you do. It's enough to make me stick to udev-045 until it gets fixed. Reproducible: Always Steps to Reproduce: root>emerge info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.10-gentoo-r6 i686) ================================================================= System uname: 2.6.10-gentoo-r6 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, May 21 2005, 20:42:41)] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks nostrip sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://130.207.108.136/pub/gentoo ftp://130.207.108.134/pub/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X alsa arts avi bash-completion bitmap-fonts cdr crypt cscope cups curl dvd emboss encode fam flac foomaticdb gdbm gif gpm gtk2 imagemagick imlib jpeg kde kdeenablefinal libg++ libwww mmx mp3 mpeg ncurses ogg oggvorbis opengl pdflibperl png ppds qt quicktime readline scanner sdl sqlite ssl tcpd tetex tiff truetype truetype-fonts trusted type1-fonts usb v4l vorbis xml2 xmms xprint xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
This is probably caused by a bug in version 056 of udev which has been discussed on the mailinglist [1]. Maybe a reason to mark udev 058 stable? [1] http://sourceforge.net/mailarchive/forum.php?thread_id=7016902&forum_id=3157
Thanks, that may well be it. Using udev-058 makes it work if I use the OPTIONS="all_partitions" format. I'm still not sure why my original syntax (NAME{ALL_PARTITIONS}="zipdrive") stopped working and still doesn't work in udev-058. I imagine at some point the udev maintainers swtiched to the new format to make things more uniform (a valid decision), perhaps even without any attempt to phase it in so people know about it (not a valid decision).
[1] might be an explanation. Though I couldn't find a sign that support for NAME{} options was already dropped. But according to this logentry OPTIONS="all_partitions" is the preferred format now. [1] http://kernel.org/git/?p=linux/hotplug/udev.git;a=commit;h=fd9efc00a2e477423185c993b8ec4570ef3ee07d
Good, this is fixed then.
