Bug 575334 - nut.x86_64 0:2.4.3-1.fc12 upgrade breaks cyberpower 800AVS setup
Summary: nut.x86_64 0:2.4.3-1.fc12 upgrade breaks cyberpower 800AVS setup
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nut
Version: 12
Hardware: x86_64
OS: Linux
low
urgent
Target Milestone: ---
Assignee: Michal Hlavinka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-20 06:47 UTC by Niels Mayer
Modified: 2010-08-19 21:58 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-04-09 01:43:10 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 575875 None None None Never

Internal Trackers: 575875

Description Niels Mayer 2010-03-20 06:47:03 UTC
Description of problem:

The change "cyberpower driver was replaced by the powerpanel driver" also 
breaks a long-working configuration with a cyberpower 800AVR.

What is additionally strange is that lsusb now reports this device as 
'Bus 003 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS' even though it had previously reported it correctly as an 800AVR. The reason why I think this might be an issue is that the 800AVR doesn't work w/ new powerpanel driver, and w/ usbhid-ups, it might not be identified as a the correct device given that productid=0501 (which is the id returned by my 800AVR) is recognized as CP1500AVR.

ups.conf excerpt
[cps]
	driver = usbhid-ups
	port = auto
	vendorid = 0764
	productid = 0501
	bus = 003
	desc = "Cyber Power Systems 800AVR"

Note /lib/udev/rules.d/62-nut-usbups.rules contains:

#  900AVR/BC900D, CP1200AVR/BC1200D  - usbhid-ups
ATTR{idVendor}=="0764", ATTR{idProduct}=="0005", MODE="664", GROUP="dialout"
#  Dynex DX-800U?  - usbhid-ups
ATTR{idVendor}=="0764", ATTR{idProduct}=="0501", MODE="664", GROUP="dialout"
#  OR2200LCDRM2U  - usbhid-ups
ATTR{idVendor}=="0764", ATTR{idProduct}=="0601", MODE="664", GROUP="dialout"

And my group dialout and user/group 'nut' are set correctly. (It all worked prior to upgrade).

usbhid-ups -a cps -u nut 
Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 Using subdriver: CyberPower HID 0.3 libusb_get_report: error sending control message: Operation not permitted Can't initialize data from HID UPS 

Downgrading to previous versions, everything works again, even though I merged the rpmnew contents w/ /etc/ups/*.conf . 

Version-Release number of selected component (if applicable):

nut  0:2.4.3-1.fc12

How reproducible:

always

Steps to Reproduce:
1. upgrade to latest enhancement upgrade of nut
2. reboot
3. ups not running. machine will not shutdown safely during powerfail.
  
Actual results:

Starting UPS driver controller: [60G[[0;31mFAILED[0;39m]
Starting upsd: [60G[[0;32m  OK  [0;39m]
Starting UPS monitor (master): [60G[[0;32m  OK  [0;39m]

Expected results:

Starting UPS driver controller: [60G[[0;32m  OK  [0;39m]
Starting upsd: [60G[[0;32m  OK  [0;39m]
Starting UPS monitor (master): [60G[[0;32m  OK  [0;39m]

Additional info:

Comment 1 Michal Hlavinka 2010-03-22 09:04:13 UTC
thanks for reporting this, upstream is already aware of this

I'll build new package once the fix is ready

Comment 2 Michal Hlavinka 2010-03-22 17:41:35 UTC
I've pre prepared test packages. Please check if it fixes problem for you. Packages can be found here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2068387

Comment 3 Niels Mayer 2010-03-22 18:16:58 UTC
nut-2.4.3-1.fc12.bz575334.1.x86_64 and nut-client-2.4.3-1.fc12.bz575334.1.x86_64
fix the problem. Now I get:

ROOT-golem-73-~> service ups start
Starting UPS driver controller: [60G[[0;32m  OK  [0;39m]
Starting upsd: [60G[[0;32m  OK  [0;39m]
Starting UPS monitor (master): [60G[[0;32m  OK  [0;39m]

I also installed these latest drivers on the other system with Tripplite_USB
issues. Eventually, I'll see whether they also solve the issues I had with that UPS: https://bugzilla.redhat.com/show_bug.cgi?id=575875

Thanks, Michal, for fixing this so quickly. When this goes to updates-testing, please send me the link so i can give the package positive karma since it tests as "works for me" right now.

Comment 4 Michal Hlavinka 2010-03-23 10:12:43 UTC
Upstream has included the fix in their repository. 

Building updates now

fixed since :
nut-2.4.3-2.fc11
nut-2.4.3-2.fc12
nut-2.4.3-2.fc13
nut-2.4.3-2.fc14

Comment 5 Fedora Update System 2010-03-23 10:38:18 UTC
nut-2.4.3-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/nut-2.4.3-2.fc12

Comment 6 Fedora Update System 2010-03-23 10:38:28 UTC
nut-2.4.3-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/nut-2.4.3-2.fc11

Comment 7 Fedora Update System 2010-03-23 10:38:33 UTC
nut-2.4.3-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/nut-2.4.3-2.fc13

Comment 8 Niels Mayer 2010-03-23 17:19:44 UTC
After updating two systems, one with CyberPower 800AVR UPS, other with TrippLite OMNIVIS1000, with updates from http://admin.fedoraproject.org/updates/nut-2.4.3-2.fc12 :
 nut          x86_64   2.4.3-2.fc12     /nut-2.4.3-2.fc12.x86_64          3.4 M
 nut-client   x86_64   2.4.3-2.fc12     /nut-client-2.4.3-2.fc12.x86_64   186 k

... both systems test as "works for me." Therefore closing this issue.

I'm leaving https://bugzilla.redhat.com/show_bug.cgi?id=575875 open until I can verify that fix -- "reduced size of buffer to maximum size supported by low-speed USB devices, which fixes some recent usbhid-ups problems" -- also relates to tripplite-usb causing total system lockup (at gdm/X server level) sometime after powerfail.

Comment 9 Michal Hlavinka 2010-03-24 07:34:00 UTC
Thanks for testing, but does not change bug status next time, especially when it's in modified or on_qa state. This means bug fix has been built and it's on its way to updates. This is (almost) automated process and should not be interfered. Also, worksforme is used only when there was no bug - nothing was fixed. The best (and safe) way to let bug owner (assignee) know is to leave a comment, for example "this was caused by hw failure, so this bug can be closed". You can close the bug you've filled as notabug or worksforme only when there are no other people leaving comments that they see the same problem and no one has started working on the bug (bug is in NEW state and there are no comments from bug assignee)

Thanks

Comment 10 Michal Hlavinka 2010-03-24 07:40:39 UTC
oh, seems it was closed during the push to testing, it should be ON_QA now

Comment 11 Fedora Update System 2010-04-09 01:43:05 UTC
nut-2.4.3-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Chris Schanzle 2010-04-09 16:29:39 UTC
I noticed this update did not make it out of testing for F12 or 13 in the 4/08/2010 batch of updates.

Comment 13 Niels Mayer 2010-04-10 00:17:22 UTC
After writing https://bugzilla.redhat.com/show_bug.cgi?id=575875#c4 , I noticed that this bug had been closed. Unfortunately, for F12, the previous version of nut (with the bug) is still the latest available:

>Installed Packages
>nut.x86_64                 2.4.3-2.fc12         @/nut-2.4.3-2.fc12.x86_64       
>nut-client.x86_64          2.4.3-2.fc12         @/nut-client-2.4.3-2.fc12.x86_64
>Available Packages
>nut-cgi.x86_64             2.4.3-1.fc12         updates                         
>nut-client.i686            2.4.3-1.fc12         updates                         
>nut-devel.i686             2.4.3-1.fc12         updates                         
>nut-devel.x86_64           2.4.3-1.fc12         updates                         
>nut-hal.x86_64             2.4.3-1.fc12         updates                         
>nut-xml.x86_64             2.4.3-1.fc12         updates        

Therefore this issue still remains for F12, it's only closed for F11.

Comment 14 Niels Mayer 2010-04-10 21:51:08 UTC
After a little prodding in #fedora, today's updates include:
 nut                    x86_64 2.4.3-3.fc12        updates                701 k
 nut-client             x86_64 2.4.3-3.fc12        updates                 83 k

Comment 15 Michal Hlavinka 2010-04-12 13:38:01 UTC
Hi Chris, Neils,

yes, it seems quite odd. 

https://admin.fedoraproject.org/updates/nut-2.4.3-2.fc12

is still in updates-testing, but it should be obsoleted by:

https://admin.fedoraproject.org/updates/nut-2.4.3-3.fc12

which is in updates already. I've manually unpushed it, so it should be ok now, I hope :o)

Comment 16 Fedora Update System 2010-07-26 15:35:08 UTC
nut-2.4.3-5.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/nut-2.4.3-5.fc12

Comment 17 Fedora Update System 2010-07-26 15:35:27 UTC
nut-2.4.3-5.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/nut-2.4.3-5.fc13

Comment 18 Fedora Update System 2010-07-26 15:35:50 UTC
nut-2.2.0-7.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/nut-2.2.0-7.el5

Comment 19 Fedora Update System 2010-08-12 04:07:56 UTC
nut-2.4.3-5.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 20 Fedora Update System 2010-08-12 04:08:58 UTC
nut-2.4.3-5.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2010-08-19 21:58:35 UTC
nut-2.2.0-7.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.


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