driver unable to connect to CyberPower UPS using usbhid-ups driver

Bug #1099947 reported by Simon Déziel
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
nut (Debian)
Fix Released
Unknown
nut (Fedora)
Fix Released
Medium
nut (Ubuntu)
Fix Released
High
Unassigned
Trusty
Invalid
Undecided
Unassigned
Xenial
Invalid
Undecided
Unassigned

Bug Description

[Impact]

 * Plugging in a USB controlled UPS solution does fail to execute the udev
   rules; Due to that the permissions are not set correctly

 * Fix is a backport from upstream which only changes the numbering on the
   rule to execute at the right time.

[Test Case]

 * Install nut-server
 * Plug in a usb controlled UPS of your choice
 * The device node created should be mode 664 and group "nut", but it is
   not.
 * Install the proposed package
 * (It also fixes but 1540008, so no need to replug anymore to test if
    successful)
 * it should now be created with proper permissions.

[Regression Potential]

 * If people with the old set up have created something that would not be
   able to access anymore that could cuase issues, but before it was
   root:root and now nut:root; the group permission didn't change (was 6
   before) - so anything before could only access with root and they still
   can - therefore I consider this of low/no risk, yet in some obscure
   setups it might be one.

[Other Info]

 * n/a

---

I hooked my new CyberPower UPS: CP685AVR-G on my Lucid server and got this error:

  Jan 15 12:06:33 xeon upsd[5441]: Can't connect to UPS [cyberpower] (usbhid-ups-cyberpower): No such file or directory
  Jan 15 12:06:38 xeon upsmon[5445]: Poll UPS [cyberpower@127.0.0.1] failed - Driver not connected

After trying many things, I found https://bugzilla.redhat.com/show_bug.cgi?id=488368 that hint me in the right direction. The required change was to rename the udev rule like this:

  mv /lib/udev/rules.d/{5,6}2-nut-usbups.rules

Now, everything works well, without requiring "user = root" in /etc/nut/ups.conf because the udev rule now ensures the device file is owned by the group "nut":

  # find /dev/bus/usb/ -ls
  1536 0 drwxr-xr-x 10 root root 200 Jan 15 12:40 /dev/bus/usb/
  1579 0 drwxr-xr-x 2 root root 60 Jan 15 12:40 /dev/bus/usb/008
  1580 0 crw-rw-r-- 1 root root Jan 15 12:41 /dev/bus/usb/008/001
  1573 0 drwxr-xr-x 2 root root 60 Jan 15 12:40 /dev/bus/usb/007
  1574 0 crw-rw-r-- 1 root root Jan 15 12:41 /dev/bus/usb/007/001
  1567 0 drwxr-xr-x 2 root root 60 Jan 15 12:40 /dev/bus/usb/006
  1568 0 crw-rw-r-- 1 root root Jan 15 12:41 /dev/bus/usb/006/001
  1561 0 drwxr-xr-x 2 root root 60 Jan 15 12:40 /dev/bus/usb/005
  1562 0 crw-rw-r-- 1 root root Jan 15 12:41 /dev/bus/usb/005/001
  1555 0 drwxr-xr-x 2 root root 60 Jan 15 12:40 /dev/bus/usb/004
  1556 0 crw-rw-r-- 1 root root Jan 15 12:41 /dev/bus/usb/004/001
  1549 0 drwxr-xr-x 2 root root 80 Jan 15 12:40 /dev/bus/usb/003
  2163 0 crw-rw-r-- 1 root nut Jan 15 12:49 /dev/bus/usb/003/002
  1550 0 crw-rw-r-- 1 root root Jan 15 12:41 /dev/bus/usb/003/001
  1543 0 drwxr-xr-x 2 root root 60 Jan 15 12:40 /dev/bus/usb/002
  1544 0 crw-rw-r-- 1 root root Jan 15 12:41 /dev/bus/usb/002/001
  1537 0 drwxr-xr-x 2 root root 60 Jan 15 12:40 /dev/bus/usb/001
  1538 0 crw-rw-r-- 1 root root Jan 15 12:41 /dev/bus/usb/001/001

Generic information:

# lsb_release -rd
Description: Ubuntu 10.04.4 LTS
Release: 10.04

# apt-cache policy nut
nut:
  Installed: 2.4.3-1ubuntu3.2
  Candidate: 2.4.3-1ubuntu3.2
  Version table:
 *** 2.4.3-1ubuntu3.2 0
        500 http://archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
        500 http://archive.ubuntu.com/ubuntu/ lucid-security/main Packages
        100 /var/lib/dpkg/status
     2.4.3-1ubuntu3 0
        500 http://archive.ubuntu.com/ubuntu/ lucid/main Packages

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: nut 2.4.3-1ubuntu3.2
ProcVersionSignature: Ubuntu 2.6.32-45.102-server 2.6.32.60+drm33.26
Uname: Linux 2.6.32-45-server x86_64
Architecture: amd64
Date: Tue Jan 15 12:43:46 2013
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: nut

Revision history for this message
In , Russell (russell-redhat-bugs) wrote :

Description of problem:
I have an MGE Ellipse Pulsar 500 UPS (USB ID 0463:ffff), connected via USB, and since upgrading to F10 from F8, usbhid-ups will not start.

Version-Release number of selected component (if applicable):
[root@detritus ~]# rpm -qa | grep ^nut
nut-client-2.2.2-4.fc10.x86_64
nut-2.2.2-4.fc10.x86_64
[root@detritus ~]# uname -r
2.6.27.15-170.2.24.fc10.x86_64

How reproducible: Every time

Steps to Reproduce:
1. Configure a UPS with driver = usbhid-ups
2. Attempt to start ups service

Actual results:
[root@detritus ~]# service ups start
Starting UPS driver controller: [FAILED]
Starting upsd: [ OK ]
Starting UPS monitor (master): [ OK ]

Expected results:
Service should start successfully

Additional info:
[root@detritus ~]# lsusb -d 0463:ffff
Bus 003 Device 002: ID 0463:ffff MGE UPS Systems UPS
[root@detritus ~]# usbhid-ups -DDDDD -a mge -x vendorid=0463 -x productid=ffff
Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2)

debug level is '5'
upsdrv_initups...
[snipped checking other USB devices here]
Checking device (0463/FFFF) (003/002)
- VendorID: 0463
- ProductID: ffff
- Manufacturer: unknown
- Product: unknown
- Serial Number: unknown
- Bus: 003
Trying to match device
Device matches
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 USB device, trying 1 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 USB device, trying 0 more time(s)...
detaching kernel driver from USB device...
failed to detach kernel driver from USB device...
trying again to claim USB device...
Unable to get HID descriptor (error sending control message: Operation not permitted)
i=0, extra[i]=09, extra[i+1]=21
HID descriptor, method 2: (9 bytes) => 09 21 00 01 21 01 22 14 02
HID descriptor length 532
Unable to get Report descriptor: Operation not permitted
[snipped checking other USB devices here]
No appropriate HID device found
No matching HID UPS found

This looks very similar to bug 461374, but that was apparently fixed. The documentation tells me that this is definitely the correct driver to use (I think I could use mge-shut if I used a serial cable instead, but my serial port is in use for something else).

Revision history for this message
In , Michal (michal-redhat-bugs) wrote :

could you try check if

usbhid-ups -u root -DD -a <name>

works? <name> is name of your ups in ups.conf - in square brackets

also, do you have any selinux denial messages?

do you see any messages in /var/log/messages related to this?

Revision history for this message
In , Russell (russell-redhat-bugs) wrote :

"usbhid-ups -u root -DD -a mge" is successful.

When I start usbhid-ups on its own, without "-u root", /var/log/messages doesn't contain anything (and just a "Connection refused" message when I try to start NUT via the initscript), and I don't see any selinux messages.

Adding "user = root" to ups.conf seems to allow it to start OK but (having amended my config to use IPv4, as upsd doesn't seem to want to listen on IPv6) upsd still can't connect until I fix a socket permission problem:
[root@detritus ~]# ls -l /var/run/nut/usbhid-ups-mge
srw-rw---- 1 root root 0 2009-03-14 18:44 /var/run/nut/usbhid-ups-mge
[root@detritus ~]# chmod o+rw /var/run/nut/usbhid-ups-mge

After doing this (after NUT startup) everything works, but obviously this is a dirty hack - but I imagine the problem will go away once we get to the bottom of why usbhid-ups needs to run as root in order to work.

Revision history for this message
In , Michal (michal-redhat-bugs) wrote :

First, I've got the same errors when starting ups service. Then I've fully configured it and it works for me now without any errors.

could you upload all your nut config files in this bz?
/etc/sysconfig/ups
/etc/ups/ups.conf
/etc/ups/upsd.conf
/etc/ups/upsd.users
/etc/ups/upsmon.conf
/etc/ups/upssched.conf

Revision history for this message
In , Russell (russell-redhat-bugs) wrote :

Created attachment 335613
Config files as requested

Here's my config files. Nothing unusual here I don't think.

Revision history for this message
In , Michal (michal-redhat-bugs) wrote :

Your config files looks ok. I've tried to use your config files and it works for me (I've just replaced vendor and product ids)

I found another interesting thing.

First time service ups start is successful, but next time(s) it fails...

please try (as root):
0)remove user=root from ups.conf
1)stop nut : service ups stop
2)check nothing nut related is running : ps aux | grep nut | grep -v grep
3)kill running nut related processes if there are any
4)try to start nut : service ups start

if there is any problem:
repeat steps 1),2),3) and attach output of
usbhid-ups -DD -a mge
you will need to kill it probably, first 10-20 secs is enough
if there is anything in /var/log/messages attach it too

thanks

Revision history for this message
In , Russell (russell-redhat-bugs) wrote :

Output from /var/log/messages (and console) when starting then stopping NUT:

Broadcast message from nut (Wed Mar 18 21:33:14 2009):

Communications with UPS mge@127.0.0.1 lost
Mar 18 21:33:14 detritus upsd[18695]: listening on 0.0.0.0 port 3493
Mar 18 21:33:14 detritus upsd[18695]: Can't connect to UPS [mge] (usbhid-ups-mge): No such file or directory
Mar 18 21:33:14 detritus upsd[18696]: Startup successful
Mar 18 21:33:14 detritus upsmon[18699]: Startup successful
Mar 18 21:33:14 detritus upsd[18696]: Client monmaster@127.0.0.1 logged into UPS [mge]
Mar 18 21:33:14 detritus upsmon[18700]: Poll UPS [mge@127.0.0.1] failed - Driver not connected
Mar 18 21:33:14 detritus upsmon[18700]: Communications with UPS mge@127.0.0.1 lost
Mar 18 21:33:14 detritus wall[18702]: wall: user nut broadcasted 1 lines (44 chars)

Broadcast message from nut (Wed Mar 18 21:33:19 2009):

UPS mge@127.0.0.1 is unavailable
Mar 18 21:33:19 detritus upsmon[18700]: Poll UPS [mge@127.0.0.1] failed - Driver not connected
Mar 18 21:33:19 detritus upsmon[18700]: UPS mge@127.0.0.1 is unavailable
Mar 18 21:33:19 detritus wall[18705]: wall: user nut broadcasted 1 lines (34 chars)
Mar 18 21:33:22 detritus upsmon[18700]: Signal 15: exiting
Mar 18 21:33:22 detritus upsd[18696]: Signal 15: exiting

The output from usbhid-ups -DD -a mge looks the same as my initial report (comment 0) above. Will attach what it looks like with "user = root" re-enabled in a minute...

Revision history for this message
In , Russell (russell-redhat-bugs) wrote :

Created attachment 335770
usbhid-ups -DD -a mge

This is with "user = root" in ups.conf - all appears to work successfully in this case.

Revision history for this message
In , Michal (michal-redhat-bugs) wrote :

sorry for slow response, but I'm little overloaded last few days

all these without user=root in config file

1)please add output of
id nut
id uucp
lsusb
find /dev/bus/usb/ -ls

2)in /etc/udev/rules.d/52_nut-usbups.rules try changing MODE
ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", MODE="664", GROUP="uucp"
to
ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", MODE="666", GROUP="uucp"

if it changes anything (make sure there is nothing nut related running before testing: ps aux | grep nut | grep -v grep )

Change it back to 664.

3)try to change selinux mode to permissive (if you have it in enforcing mode: sestatus)
setenforce 0
try if it changes anything (make sure nut is stopped completely) and change it back to enforcing
setenforce 1

Revision history for this message
In , Russell (russell-redhat-bugs) wrote :

1) Here's your info...
[root@detritus ~]# id nut
uid=57(nut) gid=57(nut) groups=57(nut),14(uucp)
[root@detritus ~]# id uucp
uid=10(uucp) gid=14(uucp) groups=14(uucp)
[root@detritus ~]# lsusb
Bus 002 Device 002: ID 2040:8400 Hauppauge
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 015: ID 05a4:9862 Ortek Technology, Inc.
Bus 001 Device 014: ID 0510:0032 Sejin Electron, Inc.
Bus 001 Device 013: ID 05a4:9837 Ortek Technology, Inc.
Bus 001 Device 012: ID 03f0:c602 Hewlett-Packard Photosmart D7100 series
Bus 001 Device 011: ID 0c45:6242 Microdia PC Camera (SN9C201 + MI1310)
Bus 001 Device 009: ID 04cc:1521 Philips Semiconductors USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 0463:ffff MGE UPS Systems UPS
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
[root@detritus ~]# find /dev/bus/usb/ -ls
  2477 0 drwxr-xr-x 7 root root 140 Mar 31 20:37 /dev/bus/usb/
  3722 0 drwxr-xr-x 2 root root 80 Mar 31 20:37 /dev/bus/usb/002
  3795 0 crw-rw-r-- 1 root vboxusers Apr 3 12:35 /dev/bus/usb/002/002
  3725 0 crw-rw-r-- 1 root vboxusers Apr 3 12:35 /dev/bus/usb/002/001
  3691 0 drwxr-xr-x 2 root root 60 Mar 31 20:37 /dev/bus/usb/005
  3694 0 crw-rw-r-- 1 root vboxusers Apr 3 12:35 /dev/bus/usb/005/001
  2645 0 drwxr-xr-x 2 root root 180 Apr 2 21:49 /dev/bus/usb/001
  9560 0 crw-rw-r-- 1 root vboxusers Apr 3 12:35 /dev/bus/usb/001/015
  9434 0 crw-rw-r-- 1 root vboxusers Apr 3 12:35 /dev/bus/usb/001/014
  9366 0 crw-rw-r-- 1 root vboxusers Apr 3 12:35 /dev/bus/usb/001/013
  9102 0 crw-rw-r-- 1 root vboxusers Apr 3 12:35 /dev/bus/usb/001/012
  8911 0 crw-rw-r-- 1 root vboxusers Apr 3 12:35 /dev/bus/usb/001/011
  8740 0 crw-rw-r-- 1 root vboxusers Mar 31 19:37 /dev/bus/usb/001/009
  2648 0 crw-rw-r-- 1 root vboxusers Apr 3 12:35 /dev/bus/usb/001/001
  2578 0 drwxr-xr-x 2 root root 60 Mar 31 20:37 /dev/bus/usb/004
  2581 0 crw-rw-r-- 1 root vboxusers Apr 3 12:35 /dev/bus/usb/004/001
  2478 0 drwxr-xr-x 2 root root 80 Mar 31 20:37 /dev/bus/usb/003
  2515 0 crw-rw-r-- 1 root vboxusers Apr 3 17:29 /dev/bus/usb/003/002
  2481 0 crw-rw-r-- 1 root vboxusers Apr 3 12:35 /dev/bus/usb/003/001

(not quite sure why all the devices have a GID of vboxusers, which is a group created by VirtualBox - perhaps this is the root cause of my problems?)
[root@detritus ~]# getent group vboxusers
vboxusers:x:506:russ
[root@detritus ~]# rpm -q VirtualBox
VirtualBox-2.1.2_41885_fedora9-1.x86_64

2) Changing MODE appears to make no difference (I unplugged and replugged USB cable).

3) Changing selinux to permissive mode didn't help either :-(

Revision history for this message
In , Michal (michal-redhat-bugs) wrote :

yes, it seems, it's vboxusers group related, because it should be uucp group

could you test what happens if you manually change the group to uucp?

in output of
lsusb
you'll see something like
...
Bus 003 Device 002: ID 0463:ffff MGE UPS Systems UPS

so we need /dev/bus/usb/003/002 to have uucp group:

chmod 0660 /dev/bus/usb/003/002
chown root:uucp /dev/bus/usb/003/002

and try to start nut (without user=root)

If you replug ups to other port, it'll probably be something else than ../003/002, so change the commands accordingly

please add output of
rpm -ql VirtualBox

and attach VirtualBox's files from /lib/udev/rules.d/ and /etc/udev/rules.d/

thanks

Revision history for this message
In , Russell (russell-redhat-bugs) wrote :

[root@detritus ~]# lsusb | grep MGE
Bus 004 Device 003: ID 0463:ffff MGE UPS Systems UPS
[root@detritus ~]# ls -l /dev/bus/usb/004/003
crw-rw-r-- 1 root vboxusers 189, 386 2009-05-25 20:34 /dev/bus/usb/004/003
[root@detritus ~]# chown :uucp /dev/bus/usb/004/003
[root@detritus ~]# ls -l /dev/bus/usb/004/003
crw-rw-r-- 1 root uucp 189, 386 2009-05-25 20:34 /dev/bus/usb/004/003

The ups service now starts successfully without "user = root" in ups.conf!

[root@detritus ~]# rpm -ql VirtualBox | grep udev
[root@detritus ~]# ls -l /etc/udev/rules.d/*-vboxdrv.rules
-rw-r--r-- 1 root root 208 2009-04-03 17:47 /etc/udev/rules.d/10-vboxdrv.rules
-rw-r--r-- 1 root root 208 2009-01-22 20:20 /etc/udev/rules.d/60-vboxdrv.rules
[root@detritus ~]# cat /etc/udev/rules.d/10-vboxdrv.rules
KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600"
SUBSYSTEM=="usb_device", GROUP="vboxusers", MODE="0664"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GROUP="vboxusers", MODE="0664"
[root@detritus ~]# cat /etc/udev/rules.d/60-vboxdrv.rules
KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600"
SUBSYSTEM=="usb_device", GROUP="vboxusers", MODE="0664"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GROUP="vboxusers", MODE="0664"

Revision history for this message
In , Russell (russell-redhat-bugs) wrote :

Created attachment 345352
Output of "rpm -ql VirtualBox"

Revision history for this message
In , Michal (michal-redhat-bugs) wrote :

ok, try this (as root):
1) move nut rule to later position
mv /etc/udev/rules.d/52_nut-usbups.rules /etc/udev/rules.d/62_nut-usbups.rules
2) reload udev
udevcontrol --reload_rules
3) stop nut
4) re-plug your ups
5) start nut
6) check permissions of /dev/bus/usb/XXX/YYY as in comment #11

virtualbox is the broken one here, but because fedora doesn't ship virtualbox, we can't fix it.

This moves nut's udev rules after the virtualbox. In udev, later rule overwrites the prev one (if special keywords are not used).

If this work, I'll change this in nut package

Revision history for this message
In , Russell (russell-redhat-bugs) wrote :

Just tried that, works a treat!

[root@detritus ~]# ls -l /dev/bus/usb/004/004
crw-rw-r-- 1 root uucp 189, 387 2009-05-31 20:40 /dev/bus/usb/004/004

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

nut-2.4.1-6.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/nut-2.4.1-6.fc11

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

nut-2.2.2-5.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/nut-2.2.2-5.fc10

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

nut-2.2.2-5.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update nut'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-5921

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

nut-2.4.1-6.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

nut-2.2.2-5.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
Simon Déziel (sdeziel) wrote :
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Marking confirmed based on the fedora report. THe Makefile.am in raring still shows:

./scripts/udev/Makefile.am: udevrules_DATA += 52-nut-usbups.rules
./scripts/udev/Makefile.am: udevrules_DATA += 52-nut-ipmipsu.rules

so I doubt it has been fixed there.

Changed in nut (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Martijn Lievaart (j-launchpad-net-rtij-nl) wrote :

I can confirm this bug in raring. The fix in the originale bug report fixed it for me too.

Revision history for this message
Simon Déziel (sdeziel) wrote :

Still affecting Trusty and the same workaround (mv /lib/udev/rules.d/{5,6}2-nut-usbups.rules) works.

Revision history for this message
Arnaud Quette (aquette) wrote :

Logged upstream, fixed and due with the next 2.7.3 release: https://github.com/networkupstools/nut/issues/140

Changed in nut (Debian):
status: Unknown → New
Revision history for this message
catsem (csc03) wrote :

Also affects Xenial. C'mon please integrate a later upstream version of nut. The bug has been fixed in 2014!

Revision history for this message
Nish Aravamudan (nacc) wrote :

I believe caribou is working on the nut merge in zesty, at which point we can consider this for SRU.

Changed in nut (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I don't even know how much pardon to beg on this one ... a lot for sure.
I'm coming by trying to clear bugs that are dormant for too long - and this one is really way too long :-/

Anyway forget the past and work on it ...

Now this is fixed in Zesty and later due to merging 2.7.4.
Updating tasks and consider backporting https://github.com/networkupstools/nut/commit/040c800efad46ead9670077c9764360802d7aaf5

Changed in nut (Ubuntu Trusty):
status: New → Triaged
Changed in nut (Ubuntu Xenial):
status: New → Triaged
Changed in nut (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Closed the Debian bug as well as it has >=2.7.3 just as we do.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I'd like to SRU that together with bug 1540008 on which we wait for Debian reply.
Since this one over here waited for so long it will survive my PTO which is enough time for Debian to reply (or me to give up).
Then I can SRU both together (as they are related to each other).
I linked them together on my current todo and will revisit either on an update or in approx 3 weeks.

Changed in nut (Debian):
status: New → Fix Released
description: updated
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Uploaded SRU changes for review - branches are linked

Revision history for this message
Chris J Arges (arges) wrote : Please test proposed package

Hello Simon, or anyone else affected,

Accepted nut into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nut/2.7.2-4ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nut (Ubuntu Xenial):
status: Triaged → Fix Committed
tags: added: verification-needed verification-needed-xenial
Changed in nut (Ubuntu Trusty):
status: Triaged → Fix Committed
tags: added: verification-needed-trusty
Revision history for this message
Chris J Arges (arges) wrote :

Hello Simon, or anyone else affected,

Accepted nut into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nut/2.7.1-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Revision history for this message
Simon Déziel (sdeziel) wrote :

For some reason I cannot get the package from xenial-proposed but before doing that I tried to reproduce on Xenial with 2.7.2-4ubuntu1. Turns out that I cannot reproduce so I'm not sure this SRU is worth pursuing. That said, if I somehow get the -proposed package eventually, I'll make sure to test it out.

Here's my current test setup (*without* the -proposed package) unable to repro the original issue:

# tail -n 5 /etc/nut/ups.conf
[cyberpower]
        driver = usbhid-ups
        port = auto
        desc = "CyberPower CP685AVR-G"
        vendorid = 0764

# lsusb | grep Cyber
Bus 003 Device 003: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS

# ll /dev/bus/usb/003/003
crw-rw-r-- 1 root nut 189, 258 Aug 23 10:23 /dev/bus/usb/003/003

Yet, I don't seem to have manually mv'ed the udev file:

# find /lib/udev/rules.d/ -name '*nut*'
/lib/udev/rules.d/52-nut-usbups.rules

So maybe it was fixed in a different way at some point after I reported the problem on Lucid?

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

That is what happens when bugs are dormant for too long :-/.
It still seems to be an issue for Trusty, but you are right without the ability to reproduce we should cancel that bug here from the Xenial SRU.
I have to redo it anyway for Xenial as there is an FTBFS in the fix (that is the reason you don't see it), and on that I'll reduce it to the other bug that was part of the planned SRU.

Thanks for your quick response!
I'm marking Xenial as invalid now - and the follow on upload will revert the change for this bug here.

Do you have a setup to verify the change on Trusty?
Not that this was fixed by e.g. udev changes unknown to us as well without us noticing.

Changed in nut (Ubuntu Xenial):
status: Fix Committed → Invalid
status: Invalid → Fix Released
status: Fix Released → Invalid
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

If there is someone else who can reliably reproduce on Xenial still please ping me or update here.

Revision history for this message
Simon Déziel (sdeziel) wrote : Re: [Bug 1099947] Re: driver unable to connect to CyberPower UPS using usbhid-ups driver

On 2017-08-24 03:45 AM, ChristianEhrhardt wrote:
> Do you have a setup to verify the change on Trusty?

Unfortunately no because I would have verified if the SRU was still
needed there or not :( If you want to pursue the Trusty SRU for other
users, I'll arrange a setup for the validation (if nobody beats me to
it). Thanks Christian!

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Simon,
I'd like to ensure to know on the state of this for Trusty.
But my last UPS device was still serial and died a decade ago.
So if you can spend the HW and time to test there please go for it as you can afford.

P.S. I see a "I need that for work" discussion at home :-)

Revision history for this message
Simon Déziel (sdeziel) wrote :

On 2017-08-24 09:44 AM, ChristianEhrhardt wrote:
> I'd like to ensure to know on the state of this for Trusty.
> But my last UPS device was still serial and died a decade ago.
> So if you can spend the HW and time to test there please go for it as you can afford.

I already have the UPS so it's just a matter of setting up a Trusty
host. I'll get to that next week.

Revision history for this message
Simon Déziel (sdeziel) wrote :

Hi Christian,

Even on Trusty (*without* the -proposed package) I'm unable to repro the original issue:

# tail -n 5 /etc/nut/ups.conf
[cyberpower]
        driver = usbhid-ups
        port = auto
        desc = "CyberPower CP685AVR-G"
        vendorid = 0764

# lsusb | grep Cyber
Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS

# ll /dev/bus/usb/004/002
crw-rw-r-- 1 root nut 189, 385 Aug 25 18:01 /dev/bus/usb/004/002

# find /lib/udev/rules.d/ -name '*nut*'
/lib/udev/rules.d/52-nut-usbups.rules

I will thus mark the Trusty task as invalid as well.

Changed in nut (Ubuntu Trusty):
status: Fix Committed → Invalid
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

So whatever overwrote the privs in the past due to having a too low rules number no more does so.
Thanks for verifying Trusty as well Simon!

Hmm, that SRU was supposed to be so trivial as all was clear yet the lack of the special HW caused me to miss this "already fixed" by whatever third source.

I already feel this comes back one day, but for now keep it invalid and I'll upload an updated SRU that only tackles the remaining issue (which I can test as I don't need the special HW to ensure btw).

Revision history for this message
Charles Lepple (clepple) wrote :

Simon, can you check whether the SYSFS/ATTR comment from the Debian bug applies? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721600#10

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Charles, thank you to chime in!
The current "issue" is that there is no issue left anymore as it seems.
Which is why I have removed that change from the current SRU activity and Simon set invalid on the bug tasks until we know otherwise.

But every check is a good one - so in this case I checked the oldest possible version which is trusty. But even there is no trace of the old SYSFS left.

root@trusty-test:~# grep ATTR /lib/udev/rules.d/52-nut-usbups.rules | wc -l
90
root@trusty-test:~# grep SYSFS /lib/udev/rules.d/52-nut-usbups.rules | wc -l
0

Revision history for this message
Simon Déziel (sdeziel) wrote :

Thanks Charles and Christian. I'll keep the Trusty machine around for a
while so let me know if any more tests would be useful.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Simon,
while we might pursue the reddest herring ever since you have the testbed around you might run in one console. So lets help each other to not over-engineer this, but OTOH it might be interesting to see why it is fixed.

# unplug the device
$ udevadm monitor --subsystem-match=usb
# plug the device

Interested to see if the rules in 52-... (or whatever else) is processed then.

If you want to go "hardcore" (reading as "please don't if you not really want to") you could set up a KVM guest and install from the trusty release ISO (no updates) including nut-server. Then pass through the usb device and see if it is working there as well.

P.S. making +1 on my "spend a beer if I ever see ..." note

Revision history for this message
Simon Déziel (sdeziel) wrote :

On 2017-08-28 09:01 AM, ChristianEhrhardt wrote:
> Hi Simon,
> while we might pursue the reddest herring ever since you have the testbed around you might run in one console. So lets help each other to not over-engineer this, but OTOH it might be interesting to see why it is fixed.
>
> # unplug the device
> $ udevadm monitor --subsystem-match=usb
> # plug the device

$ udevadm monitor --subsystem-match=usb
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[72.829167] add /devices/pci0000:00/0000:00:1a.1/usb4/4-2 (usb)
KERNEL[72.831253] add
/devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2:1.0 (usb)
UDEV [73.022997] add /devices/pci0000:00/0000:00:1a.1/usb4/4-2 (usb)
UDEV [73.031355] add
/devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2:1.0 (usb)

> and install from the trusty
> release ISO (no updates) including nut-server. Then pass through the usb
> device and see if it is working there as well.

I'm downloading 14.04.0 [1] to install it on my physical test box and
will report how it goes without updates.

[1]
http://old-releases.ubuntu.com/releases/trusty/ubuntu-14.04-server-amd64+mac.iso

Revision history for this message
Simon Déziel (sdeziel) wrote :
Download full text (3.5 KiB)

Fresh install of Trusty 14.04.0 with *old* udev:

# apt-cache policy udev
udev:
  Installed: 204-5ubuntu20
  Candidate: 204-5ubuntu20.24
  Version table:
     204-5ubuntu20.24 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
 *** 204-5ubuntu20 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

Plugging CyberPower USB cable:
# udevadm monitor --subsystem-match=usb
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[212.661306] add /devices/pci0000:00/0000:00:1a.1/usb4/4-2 (usb)
KERNEL[212.663416] add /devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2:1.0 (usb)
UDEV [212.861460] add /devices/pci0000:00/0000:00:1a.1/usb4/4-2 (usb)
UDEV [212.863063] add /devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2:1.0 (usb)

Wrong perms:
# find /dev/bus/usb/ -ls
  7329 0 drwxr-xr-x 10 root root 200 Aug 29 16:14 /dev/bus/usb/
  ...
  7336 0 drwxr-xr-x 2 root root 80 Aug 29 16:17 /dev/bus/usb/004
 11406 0 crw-rw-r-- 1 root root Aug 29 16:17 /dev/bus/usb/004/002
  7337 0 crw-rw-r-- 1 root root Aug 29 16:14 /dev/bus/usb/004/001
  ...

Install nut-server
# apt-get install -y nut-server # pulling 2.7.1-1ubuntu1

# lsusb | grep Cyber
Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS

Unplugging/re-plugging the CyberPower:
# udevadm monitor --subsystem-match=usb
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[544.264436] remove /devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2:1.0 (usb)
KERNEL[544.264626] remove /devices/pci0000:00/0000:00:1a.1/usb4/4-2 (usb)
UDEV [544.271603] remove /devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2:1.0 (usb)
UDEV [544.271648] remove /devices/pci0000:00/0000:00:1a.1/usb4/4-2 (usb)
KERNEL[548.024486] add /devices/pci0000:00/0000:00:1a.1/usb4/4-2 (usb)
KERNEL[548.027386] add /devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2:1.0 (usb)
UDEV [548.186083] add /devices/pci0000:00/0000:00:1a.1/usb4/4-2 (usb)
UDEV [548.187851] add /devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2:1.0 (usb)

Notice that nut-server's 52-nut-usbups.rules worked:
# find /dev/bus/usb/ -ls
  7329 0 drwxr-xr-x 10 root root 200 Aug 29 16:14 /dev/bus/usb/
  ...
  7336 0 drwxr-xr-x 2 root root 80 Aug 29 16:23 /dev/bus/usb/004
 12329 0 crw-rw-r-- 1 root nut Aug 29 16:23 /dev/bus/usb/004/003
  7337 0 crw-rw-r-- 1 root root Aug 29 16:14 /dev/bus/usb/004/001
  ...

What's weird in the above is that udev reports it's adding 4-2 but the device is apparently at 4-3:
# lsusb | grep Cyber
Bus 004 Device 003: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS

I did unplug/plug back in the exact same physical slot. Here's dmesg just in case:
# dmesg -T | grep 0501
[Tue Aug 29 16:17:32 2017] usb 4-2: New USB device found, idVendor=0764, idProduct=0501
[Tue Aug 29 16:17:32 2017] hid-generic 00...

Read more...

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Thanks for the extra checks Simon!

We can say - until we have a reproducer/verification-chance this stays as is.

The SRU will only cover the other issue that the install does not retrigger the events to work right away (without e.g. replug) but not this issue here.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

For the sake of passing the SRU process - setting this verification-done.

It really is no more part of the (refreshed) update anymore, but still listed so SRU members might wait for a verification to happen.

Well in some sense the verification was "done", led to new insights and the change was removed from the SRU - so we are not faking the "done" too much :-)

tags: added: verification-done verification-done-trusty verification-done-xenial
removed: verification-needed verification-needed-trusty verification-needed-xenial
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nut - 2.7.1-1ubuntu1.2

---------------
nut (2.7.1-1ubuntu1.2) trusty; urgency=medium

  * Drop d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: this issue
    seems fixed via other updates and is no more reproducible (LP 1099947).

nut (2.7.1-1ubuntu1.1) trusty; urgency=medium

  * debian/nut-server.postinst: The udevd process is called systemd-udevd for
    quite sometimes already, properly detect whether it's running or not, this
    should fix the devices permissions for USB UPS's (LP: #1540008)
  * d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: make udev
    rule apply correctly (LP 1099947).

 -- Christian Ehrhardt <email address hidden> Mon, 28 Aug 2017 08:48:47 +0200

Changed in nut (Ubuntu Trusty):
status: Invalid → Fix Released
Revision history for this message
Chris Halse Rogers (raof) wrote : Update Released

The verification of the Stable Release Update for nut has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nut - 2.7.2-4ubuntu1.2

---------------
nut (2.7.2-4ubuntu1.2) xenial; urgency=medium

  * Drop d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: this issue
    seems fixed via other updates and is no more reproducible (LP 1099947).
    Also fixes a FTBFS on the ongoing SRU of 2.7.2-4ubuntu1.1.

nut (2.7.2-4ubuntu1.1) xenial; urgency=medium

  * debian/nut-server.postinst: The udevd process is called systemd-udevd for
    quite sometimes already, properly detect whether it's running or not, this
    should fix the devices permissions for USB UPS's (LP: #1540008)
  * d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: make udev
    rule apply correctly (LP 1099947).

 -- Christian Ehrhardt <email address hidden> Thu, 24 Aug 2017 09:47:35 +0200

Changed in nut (Ubuntu Xenial):
status: Invalid → Fix Released
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Since this was to get around the entangled SRUs I correct the state back to invalid.
See comment #29.

Changed in nut (Ubuntu Trusty):
status: Fix Released → Invalid
Changed in nut (Ubuntu Xenial):
status: Fix Released → Invalid
Changed in nut (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.