similar to: automatically installing udev rules?

salut Jean-Luc, 2005/10/9, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>: > > Package: nut-usb > Version: 2.0.2-1 > Severity: normal > > Hi, > > The latest version of udev: 0.070-3 conficts with hotplug. > This means that while the new udev includes the hotplug functionalities, > the rules in /etc/hotplug/usb/libhidups and /etc/hotplug/usb/libhid.usermap

Arnaud et al, I have been meaning to collect some of the documentation updates for permission-related errors, and I was wondering if you would mind if we moved the scripts/udev/README and scripts/hotplug/README files out of scripts/ and into the docs/ directory (probably docs/permissions.txt). We could also cover the *BSD /dev/usb* permission issues there, as well. Any thoughts on this? -- -

A lot of recent posts on problems with newhidups, tripplite_usb, etc. have been related to permission errors, and I don't think the current error messages really point users in the right direction: failed to claim USB device, trying 2 more time(s)... detaching kernel driver from USB device... failed to detach kernel driver from USB device... trying again to claim USB device... failed to claim

Hi all, Here's a brief history of my adventure: I purchased a CyberPower 685 AVR and decided to connect it through USB to my Gentoo linux machine running kernel 2.6.22. While the device was detected properly and added to /dev, it was added with the wrong permissions (gid was set to 'usb' instead of 'nut', as it was expected to be according to the rules under

Hi, seems there is one missing change in /trunk/scripts/udev/nut-usbups.rules.in BUS -> SUBSYSTEMS previous change [1] missed this. Now, the latest udev started to complain: > ... udevd[31526]: BUS= will be removed in a future udev version ... 098 udev version (from 2006) is required for this [2], but this is the same version as required for previous SYSFS -> ATTR change. I've

Citeren Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Thu Jan 15 20:02:22 2009 > New Revision: 1734 > > Log: > Freshly generated USB helper files > > Modified: > trunk/scripts/hal/ups-nut-device.fdi.in > trunk/scripts/hotplug/libhid.usermap > trunk/scripts/udev/nut-usbups.rules.in Questions is, should we try

Hi, No patches today, sorry, just three little observations (i'm compiling windows_port branch on Debian GNU/Linux testing with mingw): * missing but required by the configure scripts/augeas/nutupsconf.aug.in scripts/hal/ups-nut-device.fdi.in scripts/udev/nut-usbups.rules.in * it autodetects hal and udev support but (of course) fails to cross-compile it (so i had to use

Thought I would write some notes about how I got an APC BackUPS XS 1500 working with newhidups under Gentoo 2006.0. The specific issue here is the permissions on the device files used that libusb uses to access the USB hardware. I followed Peter Selinger's instructions at http://www.mscs.dal.ca/~selinger/ups/backups.html on getting newhidups going with an APC device. The sticking point for

> Added: > trunk/scripts/hotplug/Makefile.am > trunk/scripts/udev/Makefile.am > Modified: > trunk/ChangeLog > trunk/Makefile.am > trunk/configure.in > trunk/docs/configure.txt > trunk/scripts/Makefile.am > trunk/scripts/hotplug/ (props changed) > trunk/scripts/udev/ (props changed) > trunk/scripts/udev/README > Log: > -

2010/12/22 Arjen de Korte <adkorte-guest at alioth.debian.org> > Author: adkorte-guest > Date: Wed Dec 22 20:31:42 2010 > New Revision: 2777 > URL: http://trac.networkupstools.org/projects/nut/changeset/2777 > > Log: > Don't version generated files > > Deleted: > trunk/scripts/hal/ups-nut-device.fdi.in > trunk/scripts/hotplug/libhid.usermap >

Hello ups-dev Arnaud asked me to add a function upsdrv_print_ups_list the drivers upsdrv_print_ups_list : why This function would print the vendorId and the productId of the UPS supported by the driver (for USB driver at least). It could then be parsed by a tool (that I'll have to make too), whose the goal would be to automagically generate 4 sort of file : - fdi file for HAL - udev rules

Hello Charles, Thank you for your suggestion, however it didn't help. I was running it as root but I went ahead and added the -u root anyways. Nothing changed. So part or all the problem is that I don't have the "libhidups or libhid.usermap" files that the man page talks about: You also need to install manually the legacy hotplug files (libhidups and libhid.usermap,

Hello, The current dependancy on hotplug|udev (>= 0.59) seems bad. As far as I remember, last week, when I tried to install Ralph packages, I got an error from hotplug/udev and I had to use udev from backports.org Anyone know which version of udev/hotplug we will have to depends on ? Maybe we could simply rely on a recent udev dependancy, because afaik udev now provides hotplug. -- Julien

Hello everybody, After succeeded in "tuning" nut-2.0.0's hidups and 2.0.3's newhidups on customized Linux kernels, we are now facing a new challenge : trying to install nut-2.0.5 on a RedHat ES4 which is based on a 2.6.9 kernel. I picked up the 2.0.5 source package and follow the INSTALL doc until step 6. So far so good. RH ES4 is managed by udev, therefore I presume we

I've been testing * on FC3. I have everything compiled and installed. However, when I do 'modprobe wcfxo' (I have an X100P clone), I get the following in /var/log/messages: Nov 24 10:23:40 jfd wait_for_sysfs[3366]: either wait_for_sysfs (udev 039) needs an update to handle the device '/class/zaptel/zaptimer' properly (no device symlink) or the sysfs-support of your

On Jun 13, 2014, at 4:45 PM, Bossard wrote: > No matching HID UPS found > > > Driver failed to start (exit status=1) > > > So I tried 'usbhid-ups -x productid=2010' and received the same error. Same exact error? I suspect it's a permissions error the second time. Add "-u root" to the command line - since this was not a known VendorID:ProductID pair

Hi, I got a centos guest started on fc6 finally by creating the mkinitrd by hand. But the thing is centos seem to hang after the services are started properly and just before the login prompt. I also notice that ''udev'' is failing at the beginning, which could be why mingetty hangs. I am guessing that udev is the service that creates the necessary ttys. So is there something I

Package: xen-utils-common Version: 4.0.0-1 Severity: normal A strange issue, when deploying Xen using Puppet, /etc/udev/rules.d/xend.rules and /etc/udev/rules.d/xen-backend.rules files are empty. Specifically, the symlinks point to ../xend.rules and ../xen-backend.rules respectively in /etc/udev, but neither of those files exist. Manually copying those files from another host that was not

On Feb 18, 2015, at 10:40 AM, Rob Groner <rgroner at RTD.com> wrote: > Does this revolve around hotplug and udev? Yes. (Well, technically hotplug was superseded by udev) > In other words, is the idea that the created USB device will be in the "nut" group, Yes. > and thus I'd be able to tell upsdrvctrl to start if I am user "ups"? Or do ups/nut not

On 12/14/2013 02:06 PM, David C. Rankin wrote: > Charles, > > Setting uid:gid to root:nut on /dev/bus/usb/004/002 seemed to be the issue. > The question now become how to automate this process so that the user isn't > required to manually hunt down the usb dev and change gid to the nut gid? So > far, either manually setting the gid or hand-rolling the udev files to do the