Bug 178543 - hotplug removed, broken dependencies
hotplug removed, broken dependencies
Product: Fedora
Classification: Fedora
Component: libnjb (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Linus Walleij
Fedora Extras Quality Assurance
Depends On: 178994
  Show dependency treegraph
Reported: 2006-01-21 10:57 EST by Ville Skyttä
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-29 04:21:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
More patching - only /dev/usb left! (803 bytes, patch)
2006-01-24 18:10 EST, Linus Walleij
no flags Details | Diff
Combined libusb patch (1.24 KB, patch)
2006-01-25 14:40 EST, Linus Walleij
no flags Details | Diff

  None (edit)
Description Ville Skyttä 2006-01-21 10:57:14 EST
hotplug seems to be gone in today's Rawhide, initscripts just obsoletes it (no
provides), which breaks this package's dependencies.  This bug report sponsored
by grep through the Extras CVS tree, I'm not actually using the package.
Comment 1 Linus Walleij 2006-01-21 15:11:07 EST
Seems Fedora is going the same way as SuSE, removing hotplug in favor of
just using udev.

Does anyone have a good primer on how to write proper udev rules for custom
(i.e. non standard-class) USB devices?
Comment 2 Ville Skyttä 2006-01-21 15:29:35 EST
hotplug has been actually mostly removed for a while now, but there's been a
package that has "Provides: hotplug" until now.

I don't know of a good primer, but openct in Extras (devel branch) is one
example package where legacy hotplug functionality has been converted to use udev.
Comment 3 Linus Walleij 2006-01-21 15:49:43 EST
Making some thinking aloud.

Yeah I looked into openct in CVS... Perhaps I can use this stuff:

If I supply rules like this for every device in libnjb.rules:

SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4100", MODE="0666"

Add them into the RPM with:

Source1: libnjb.rules

install -Dpm 644 \
  %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/udev/rules.d/60-libnjb.rules

%config(noreplace) %{_sysconfdir}/udev/rules.d/*libnjb.rules

That should work... Will need a device to do some testing, later this
Comment 4 Ville Skyttä 2006-01-22 03:55:09 EST
mode=0666 does not sound too good to me, but then again, I know nothing about
libnjb.  Maybe you can use udev's pam_console integration to provide more access
to those devices for logged in users only?  I *think* it would be a matter of
dropping in a /etc/security/console.perms.d snippet for those devices (assuming
udev does create them with _some_ permissions).
Comment 5 Linus Walleij 2006-01-23 04:01:29 EST
Using udev for this one is a real pain... Since libnjb access the
device in user-mode using libusb it does not use any kernel modules
and such. This means it access the device thorugh usbfs mounted at
/proc/bus/usb (or /sys/bus/usb) and when the device appears the
current hotplug script change permissions on its node, for example

However udev seems to imply that everything and its mother has a 
kernel driver or is a block device and work from there, making rules 
very hard if not impossible to write.

Any hints?
Comment 6 Ville Skyttä 2006-01-23 11:58:08 EST
No real hints, sorry.  Note however, FWIW, that openct does not have any kernel
modules either, but yet udev can be told to do the right thing with it.  Maybe
ask on the udev mailing list and/or the FC udev maintainer and/or fedora-devel...
Comment 7 Jim Cornette 2006-01-24 07:07:08 EST
I am getting this bug and gnomad seems to be the only required application that
is using this library.
initscripts will not install because of the udev requirement that libnjb requires.

This is probably altogether a different bug case than described. Udev was
removed libnjb requires udev. Should I file a seperate bug report.
Comment 8 Bill Nottingham 2006-01-24 09:27:27 EST
(In reply to comment #5)
> Using udev for this one is a real pain... Since libnjb access the
> device in user-mode using libusb it does not use any kernel modules
> and such. This means it access the device thorugh usbfs mounted at
> /proc/bus/usb (or /sys/bus/usb) and when the device appears the
> current hotplug script change permissions on its node, for example
> /proc/bus/usb/001/001.

See bug 177650 for how we're tracking this for SANE.
Comment 9 Linus Walleij 2006-01-24 16:33:34 EST
Thanks Bill, clears things up a bit. Following your work,
trying on my own.
Comment 10 Linus Walleij 2006-01-24 16:51:52 EST
OK, experimenting on FC4 I put in a rules file like this:

SUBSYSTEM!="usb_device", ACTION!="add", GOTO="nomad_rules_end"

# Creative Nomad Jukebox
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="411e", MODE="660", GROUP="linus",


It executes and the script is run. In this script i have added 
"env > /tmp/foo.txt" so I can see the environment variables:


And the device /dev/usbdev1.42 in this case is correctly created
with the correct permissions.

I have also rebuilt libusb 0.1.11 so I have the patch in that will
supposedly find the device in /dev/usbdev1.42. However libusb does
not pick this up. I have also unmounted /proc/bus/usb, so the problem
is that libusb does not find /dev/usbdev*

Looking at the libusb patch sent in from Debian it seems to expect
a hierarchy to traverse below /dev/bus/usb/ but this is not the
case: there are files *begining* with usbdev really. I think the
former hierarchy may be something Debianesque, or that Red Hat got
things wrong, cannot quite see which one.

Need to look closer at this... Modify libusb some also perhaps.
Comment 11 Bill Nottingham 2006-01-24 16:55:58 EST
I have /dev/bus/usb/XXX devices here. What udev do you have?
Comment 12 Linus Walleij 2006-01-24 17:07:06 EST
0.58 for FC4... OK trying to upgrade udev too... Perhaps I need a
FC5 test2 box in order to really try this out.
Comment 13 Bill Nottingham 2006-01-24 17:10:13 EST
For FC4, try adding the following rule first:

ACTION=="add", SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev}
B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c"

(this is in the FC5t2 udev config)
Comment 14 Linus Walleij 2006-01-24 17:54:10 EST
Well I think its the libusb usb file system detector that is very
simplistic: it will assume there are device files in a dir in case
it contains any valid filedescriptors. So it looks in this order:

/proc/bus/usb  - OK we can unmount that
/sys/bus/usb - this contains subdirs on FC4 so it will stick here

Does /sys/bus/usb contain files on FC5 too? In case it does, libusb
will need some patching to get this to work.
Comment 15 Bill Nottingham 2006-01-24 17:57:49 EST
The patch removes the /sys/bus/usb code, if I'm looking at it right...
Comment 16 Linus Walleij 2006-01-24 18:09:17 EST
I'm confused... There is a patch that mess with some error messages
in the linux.c files in the RawHide package.

This patch however fixes it, but it still won't work for some reason.
Are the device nodes created in /dev/usb not equivalent to /proc/bus/usb
nodes? (Should be?)
Comment 17 Linus Walleij 2006-01-24 18:10:50 EST
Created attachment 123640 [details]
More patching - only /dev/usb left!

Patches out everything apart from /dev/usb
Comment 18 Bill Nottingham 2006-01-24 18:22:24 EST
The patch I'm referring to is in the SRPM in 177650; it's *not* in the rawhide
SRPM. Should be /dev/bus/usb...
Comment 19 Linus Walleij 2006-01-24 18:30:48 EST
Ack, sorry I should pay more attention. However I also altered
the udev macro to put the devices under /dev/usb instead of /dev/bus/usb
and it still does not work.

I will try to get a test2 box up tomorrow (midnight in Sweden now...)
Comment 20 Jim Cornette 2006-01-24 21:06:56 EST
For my nomad I get this output from devices:

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
P:  Vendor=041e ProdID=4100 Rev= 0.01
S:  Manufacturer=Creative Technology
S:  Product=NOMAD Jukebox 2
S:  SerialNumber=F4FF09F61F50020F
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

ls -laZ 002
-rw-r--r--  root     root     system_u:object_r:usbfs_t        002

And then running:
 chown jim:disk 002 from the /proc/bus/usb/001 directory allows gnomad to become
functional. I am not sure what the group should be. I just picked disk.

 ls -laZ 002
-rw-r--r--  jim      disk     system_u:object_r:usbfs_t        002

Comment 21 Jim Cornette 2006-01-24 21:18:06 EST
from the /dev/bus/usb/1 directory, I get 1 and 2 for devices.
 ls -laZ 2
lrwxrwxrwx  root     root     system_u:object_r:device_t       2 ->
shows the link to usb 1.2 on my laptop. Are you using usb2?
Comment 22 Linus Walleij 2006-01-25 02:54:07 EST
Jim, you are using the /proc/bus/usb interface which is deprecated
in FC5.

I don't know it /proc/bus/usb will still exist though: if it does we
can trigger on "usb" events instead of "usb_device" events to change
permissions on eg /proc/bus/usb/001/nnn, but that was strongly 
discouraged in bug 177650.
Comment 23 Linus Walleij 2006-01-25 14:38:43 EST
I finally found the problem:

the new crazy device node creation script seen in comment #13 will create
a device hierarchy below /dev/bus/usb. However it will use hex figures
so the directories and device nodes will have names in the span [0-9A-F]+
whereas libusb will only accept directories and devices names in the
span [0-9]+. (Perhaps is really even [0-9A-Z]+ I don't know for sure,
haven't looked so close at it.)

Two ways to fix it: the attached patch which modified libusb (warning, also
patches out the ability to use anything else than /dev/bus/usb) or
fix the node creator rule.

Bill: which approach is apropriate for Red Hat?

Another question is why there is this problem, as I understood the patch
and the udev rule was created by the same person... Perhaps s/he never
saw anything else than [0-9]+ on his/her machine.
Comment 24 Linus Walleij 2006-01-25 14:40:57 EST
Created attachment 123686 [details]
Combined libusb patch

Fixed to support /dev/bus/usb only, fixed to support hex
[0-9A-F]+ directories and devices in the device tree.
Comment 25 Bill Nottingham 2006-01-25 14:50:34 EST
I *think* fixing the rule might be simpler. But not sure.

So, outside of the changes for the device nodes/libusb itself, what do your udev
rules for libnjb look like?

Comment 26 Bill Nottingham 2006-01-25 14:54:06 EST
Kay, see comments #23/#24 - has this changed upstream since you added this?
Comment 27 Linus Walleij 2006-01-25 15:02:42 EST
I'm contacting upstream to have this resolved.
Comment 28 Linus Walleij 2006-01-25 15:04:30 EST
And right now my libnjb rules file is:

SUBSYSTEM!="usb_device", ACTION!="add", GOTO="nomad_rules_end"

# Creative Nomad Jukebox
SYSFS{idVendor}=="0471", SYSFS{idProduct}=="0222", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox 2
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4100", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox 3
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4101", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4108", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen USB 2.0
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="410b", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen NX
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4109", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen Xtra
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4110", MODE="660", GROUP="jukebox"
# Dell Digital Jukebox
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4111", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen Touch
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="411b", MODE="660", GROUP="jukebox"
# Creative Zen (Zen Micro variant)
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="411d", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen Micro
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="411e", MODE="660", GROUP="jukebox"
# Second Generation Dell Digital Jukebox
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4126", MODE="660", GROUP="jukebox"
# Dell Pocket DJ
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4127", MODE="660", GROUP="jukebox"
# Creative Zen Sleek
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4136", MODE="660", GROUP="jukebox"
# Third Generation Dell Digital Jukebox
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="412f", MODE="660", GROUP="jukebox"


Need to find the apropriate group/security settings to get the device lifted
with appropriate privileges for the current desktop user thoug. Hints?
Comment 29 Bill Nottingham 2006-01-25 15:16:58 EST
Why have the goto there, instead of just matching on SUBSYSTEM=usb_device,
ACTION=add in the rule itself?
Comment 30 Linus Walleij 2006-01-25 15:20:13 EST
Speeds up execution I guess... Came from the script generator found in
Comment 31 Bill Nottingham 2006-01-25 15:28:38 EST
So, for console user stuff, create an
/etc/security/console.perms.d/60-libnjb.perms file that looks something like:


<console> 0600 <nomad> 0600 root

and then change your udev rule so instead of setting user/group/permissions, it
just does SYMLINK+="nomad-%k"

That *should* work.
Comment 32 Linus Walleij 2006-01-25 16:02:44 EST
Hey it works... :-)

I have a working solution the day libusb and the udev rule start
playing well with one another. Will build package for the Fedora
Extras and await further action input from the developer lists of
libusb and linux-hotplug (mail sent).
Comment 33 Kay Sievers 2006-01-25 19:54:49 EST
Huh, why have these buzilla's always to be so confusing. :)
I'll try to summarize:

usbdevfs with the files in /proc should go, cause we want the option to apply
acl's for fast-user-switching to the nodes in /dev.

/proc should not be used for stuff like this anyway.

the new nodes are in /dev/bus/usb/<bus>/<device>

the new nodes should look exactly like the ones in /proc

the new nodes are not expected to contain hex or other chars

I have the following rule, which works fine:
  SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; \
  printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0644"

libusb needs a simple change to look in /dev/bus/usb/ if /proc/bus/usb/
is not found. (That way, you just don't mount usbdevfs and the nodes
in /dev are used. If people run into trouble with broken software, they
can mount usbfs (as long as it is in the kernel) and ulibusb switches
over. I think I sent the libusb patch to Harald long ago.

Does that help? Otherwise please ask back, this should not be an issue, cause
we run this susccessfully for a long time.
Comment 34 Linus Walleij 2006-01-26 03:46:29 EST
Thanks kay, clears things up.

Re: 6 the problem is that Fedora does not have this rule. It has prefixed
    operators with "X" instead of "K" which yields invalid node names.

Re: 7 a patch that makes libusb look into /dev/bus/usb has been merged 
    into libusb. However the udev rule supplied along with this patch
    had the above mentioned problem. All distributions slavishly applied
    this udev rule, resultin in total havoc whenever the characters A-F
    appear in device node names: libusb does not accept those.
Comment 35 Linus Walleij 2006-01-26 03:51:44 EST
Kay has cleared things up on libusb-devel and linux-hotplug-devel.
Device nodes in /dev/bus/usb shall be named exactly as in /proc/bus/usb
the Fedora udev rule creating the nodes was erroneous.

Bug identified in Fedora udev package, Harald Hoyer has fixed it. 

No changes should be needed in libusb. 

Waiting for confirmation that the bug is gone...
Comment 36 Linus Walleij 2006-01-26 05:13:59 EST
Created a libusb bug to make libusb look in the right place
i.e. /dev/bus/usb instead of /dev/usb
Comment 37 Jim Cornette 2006-01-26 18:06:19 EST
Having both the nomad mp3 player and the HP scanner which these two seperate
bugs refer to, is it safe to remove hotplug? (Hung onto because of library
needed by gnomad)
Will the /proc/bus/usb references be removed completely for FC5?

If I am following the report correctly, /dev/proc/usb/ entries should be
identical in format and permissions as the deprecated /proc/bus/usb entries are
with the current setup.
Will I need to make special rules, change device ownerships or will this all be
automated? (hopefully it works without user tinkering)
Comment 38 Linus Walleij 2006-01-27 02:41:28 EST
> is it safe to remove hotplug?

In FC5, and when the patch in bug 178994 has been applied to Rawhide, yes.
Anyway on FC5 yes, because I rebuilt the Extras libnjb package to work 
exclusively with udev and it does not require hotplug anymore...

> Will I need to make special rules, change device ownerships or will this 
> all be automated? (hopefully it works without user tinkering)

It is all automated. PAM rules in /etc/security/ console permissions
give the console user read+write accces to the jukebox.
Comment 39 Linus Walleij 2006-01-27 14:48:33 EST
This should be fixed with current rawhide 
libusb (0.1.11-2) and udev (078-8).

Could someone with a FC5test2 and a nomad/zen/dell dj device using
libnjb please test this and confirm is the package is working as
intended now so we can close this bug?
Comment 40 Jim Cornette 2006-01-27 23:00:52 EST
I'm running FC5T2 and will try the Nomad Jukebox and an HP scanner and report back.
Currently I have the right version of udev but not the same or newer version for

Comment 41 Jim Cornette 2006-01-28 08:39:32 EST
I am still experiencing device permission problems. I have the below permissions
for /dev and /proc versions.

The positive note is gnomad now uses the /dev/bus/usb/001/<usbdev> number. I
changed owner for the device to user:root and gnomad2 would recognize the Jukebox.

Added note: The owner for the device was a problem earlier and the behavior is
not related to the hotplug removal. (I still do have hotplug installed, but not
in the rpm database)

ls -laZ *
crw-------  root     root     system_u:object_r:device_t       001
crw-------  root     root     system_u:object_r:device_t       002
[root@cornette-lt 001]# pwd

[root@cornette-lt 001]# ls -laZ *
-rw-r--r--  root     root     system_u:object_r:usbfs_t        001
-rw-r--r--  root     root     system_u:object_r:usbfs_t        002

Comment 42 Linus Walleij 2006-01-28 16:23:18 EST
Oh. Did you also upgrade to my new libnjb-2.2.4-2 package? (The previous
was libnjb-2.2.4-1.) from the Fedora Extras?
Comment 43 Jim Cornette 2006-01-28 22:14:36 EST
I tested with libnjb-2.2.4-2.fc5 as far as I recall. Testing again to make sure.
I applied updates today and the version might have been the earlier version.

It seems that I did have the earlier version when previously tested. This is
great on the retest. I did not have to mess with any device ownership or
permissions. The Nomad Juxebox 2LX is recognized.

I believe the bug can be closed as resolved. Thanks very much for the fixup for
Nomad operation in Linux.

Comment 44 Linus Walleij 2006-01-29 04:21:51 EST
Happily closing bug, think we helped Red Hat out on this one too, so great
quality benefit from FedoraExtras(TM). :-)

Resolving bug as NEXTRELEASE.

Note You need to log in before you can comment on or make changes to this bug.