Bug 1342533

There's little useful that could be done with monitoring a UPS in the installer environment, so this is not something that anaconda should nor can handle.

Good morning David
The /dev/usb  shows three drivers therein.

The Fedora23 apc* software works just fine, so does centos, etc.

Its Fedora24.   

I have no way to know if the terminal mode functionalty exists.

Usually Gnome, xfce, mate (Fedora23) show UPS status.

Something has changed for F24. 

How can I tell if the drivers are loaded?

Hi there

The problem is manifested with the command line


upower -d   

Try it with Fedora 23

Reboot and try it with Fedora 24.

upower talks / communicates with the drivers.

*** Bug 1324567 has been marked as a duplicate of this bug. ***

lsusb shows the UPS as being present.  

The problem is more likely with information that upower cannot obtain or is blocked from viewing.

Using Fedora 24, I recompiled upower and this recompiled version works fine in F23, but not F24.

Please CONFIRM that this bug is NOT a blocker. 

If we are running a server, for obvious reasons, the server must have communication with the UPS. Low UPS voltage and no mains voltage should trigger a controlled shutdown of the computer.

If this communication is not present, who can run a server with no power outage protection?

this is not a blocker

I can't test this bug now, because my testing APC UPS died recently and I have to get a new one

Fedora 23 output
Device: /org/freedesktop/UPower/devices/ups_hiddev0
  native-path:          /sys/devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.0/usbmisc/hiddev0
  power supply:         yes
  updated:              Thu 16 Jun 2016 08:53:17 AM EDT (26 seconds ago)
  has history:          yes
  has statistics:       yes
  ups
    present:             yes
    state:               fully-charged
    warning-level:       none
    time to empty:       2.0 hours
    percentage:          100%
    icon-name:          'battery-full-charged-symbolic'

(In reply to Michal Hlavinka from comment #7)
> this is not a blocker
> 
> I can't test this bug now, because my testing APC UPS died recently and I
> have to get a new one

I am able to assist you in the testing.   As noted in comment 8, Fedora 23, upower shows the UPS stats.  That same information is not being reported within Fedora24.

If you want my help, email me and  put "Bug 1342533 - No UPS driver" as the subject.

Created attachment 1170353 [details]
upower -d  Fedora 24

upower -d   output shows my logitec mouse but does not show the UPS.

This lack of output is a Fedora 24 bug.

Please note:  Fedora24 is official.  
The UPS problem is not resolved.

One way to test is to have a UPS (APC model 500 U) and compare the output from
upower -d  (Fedora 23)
upower -d  (Fedora 24)   (attachment 1 [details])

I am quite prepared to assist you with debugging. (eg installation of diagnostic files, etc.)

Without a UPS, to protect the home server from power interruptions (UPS controlled shutdown), I and probably othera are not able to move from Fedora 23 to Fedora 24.

REFRESH, IS THIS an APCUPSD problem within Fedora 24?

Repeat.  UPS is visible with:
Centos 7.11
SUSE Tumbleweed
Fedora 23
Scientific Linux

but Not Fedora 24.

Created attachment 1170760 [details]
lsusb.f24  and the upower -d listing from F24

This is the information that shows the problem.  The problem is with changes to the kernel or to some driver or interface which upower accesses.

The attached listing shows lsusb entry with the information that comes from both 
lsusb and upower -d


Found Chapeau release 23 (Twenty Three) on /dev/sde
Found Korora release 23 (XFCE) on /dev/sdb6
Found CentOS Linux release 7.2.1511 (Core)  on /dev/sdc6
Found openSUSE 20160613 (x86_64) on /dev/sdc8
Found Fedora release 24 (Twenty Four) on /dev/sdd6

[09:44 leslie ~/scratch]$ ll lsusb*
-rw-rw-r--. 1 leslie leslie 2619 Jun 22 09:30 lsusb.f23
-rw-r--r--. 1 leslie leslie 1900 Jun 22 09:25 lsusb.f24

Note Fedora 24 is missing information

Created attachment 1170761 [details]
Fedora23/Centos/OpenSuse/Chapeau  Gnome/xfce lsub and upower -d

This is the information that shows the problem.  The problem is with changes to the kernel or to some driver or interface which upower accesses.

The attached listing shows lsusb entry with the information that comes from both 
lsusb and upower -d


Found Chapeau release 23 (Twenty Three) on /dev/sde
Found Korora release 23 (XFCE) on /dev/sdb6
Found CentOS Linux release 7.2.1511 (Core)  on /dev/sdc6
Found openSUSE 20160613 (x86_64) on /dev/sdc8
Found Fedora release 24 (Twenty Four) on /dev/sdd6

[09:44 leslie ~/scratch]$ ll lsusb*
-rw-rw-r--. 1 leslie leslie 2619 Jun 22 09:30 lsusb.f23
-rw-r--r--. 1 leslie leslie 1900 Jun 22 09:25 lsusb.f24

Note Fedora 24 is missing information

When your desktop system is driven by a spinning disk, (7200rpm) and there is a power outage, the system power can take 50ms to drop. That can do damage to the file system that the ext4 or xfs system journal can use for recovery.
But the filesystem is essentially intact.


When the desktop system is SSD based/driven, and there is a power outage, the system power can take 50 ms to drop but the entire SSD can be wiped out in less than one millisecond.  

Using a desktop (server situation) based on my SSD without a UPS backup is too risky and dangerous.  The UPS tells the system to do a "shutdown now" at least two minutes before the battery discharges.

Please raise this bug as a priority, Want "Shutdown now" instead of "reinstall your system"

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I've just taken over this package and am looking through the tickets.

I'm having trouble understanding how this issue could be an apcupsd problem, as the same package built the same way is working on F23 and not on F24.  (Assuming that you have tested with 3.14.14 on both F23 and F24.)  Besides, I don't think that upower talks to apcupsd at all.  It looks to me like it's just doing standard USB calls and talking to the HID device the UPS presents.

So.... why was this assigned to apcupsd?

I have verified that when connected to an F23 machine I have handy, with no apcupsd software in sight, upower -d shows the status of the USB.  When I connect to my F24-running laptop, upower -d doesn't show the UPS at all.

This appears to have absolutely nothing to do with apcupsd, though.  I can install apcupsd on the laptop, start the daemon and query the UPS status without any issues.

At this point I'm just going to reassign this ticket to upower.  Sorry if that's also not the correct place for this; I guess it could be a udev issue, too.

For the record, here's what udevadm has to say about the UPS when connected to the F23 machine:

P: /devices/pci0000:00/0000:00:14.0/usb3/3-13/3-13:1.0/usbmisc/hiddev0
N: usb/hiddev0
E: DEVNAME=/dev/usb/hiddev0
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-13/3-13:1.0/usbmisc/hiddev0
E: MAJOR=180
E: MINOR=96
E: SUBSYSTEM=usbmisc
E: UPOWER_BATTERY_TYPE=ups
E: UPOWER_VENDOR=APC
E: USEC_INITIALIZED=4208384292032

And on the F24 machine, I get a bit less:

P: /devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.0/usbmisc/hiddev0
N: usb/hiddev0
E: DEVNAME=/dev/usb/hiddev0
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.0/usbmisc/hiddev0
E: MAJOR=180
E: MINOR=96
E: SUBSYSTEM=usbmisc
E: UPOWER_VENDOR=APC
E: USEC_INITIALIZED=4317970490

Note the absence of the UPOWER items.

Hi Jason

I am here to help.  I tried to tell the assigned individuals that the problem is neither upower -d or apcupsd.

I have downloaded the upower source and compiled it both for Fedora 23 and Fedora 24

The problems are as I noted in attachments shown, and also as per your findings.

I am ready, willing and able to assist. I program in C and I am looking for an example of how to read from the UPS's usb port.

In the mean time, I will walk through the code of upower, sprinkling fprintf() statements. 

Leslie.
PS. I presume you have my email address. If you want me to work with you on resolving this problem, just send me a note. Leave the subject line to contain the bug number.

On my F24 desktop machine with udevadm

[root@localhost leslie]# udevadm info /dev/usb/hiddev0
P: /devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.0/usbmisc/hiddev0
N: usb/hiddev0
E: DEVNAME=/dev/usb/hiddev0
E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.0/usbmisc/hiddev0
E: MAJOR=180
E: MINOR=96
E: SUBSYSTEM=usbmisc
E: UPOWER_VENDOR=APC
E: USEC_INITIALIZED=11781377

Note the absence of the UPOWER items. ( UPOWER_BATTERY_TYPE=ups)

To be fair, I just wanted to get the ticket at least in the right component (i.e. not filed against the package I just took over) and did enough to verify that apcupsd has nothing to do with this.  Beyond that, I have no real interest besides seeing Fedora become a better distribution.

Yes, it's a pretty obvious bug but aside from verifying that I can see it and potentially testing a fix by dragging a USB cable across my desk, there's not much else that I can or have time to do.

I will, however, add that /lub/udev/rules.d/95-upower-hid.rules doesn't appear to have changed between F23 and F24.  The F24 version should still set ENV{UPOWER_BATTERY_TYPE}="ups" for my UPS (vendor 051d, product 0002).

So perhaps the problem is down in the depths of udev somewhere.  I've certainly no idea.

Jason, my ups has (vendor 051d, product 0002)         --- same VP as yours..(MY APC = model 500 U)

Mine:

> apcaccess
APC      : 001,038,1001
DATE     : 2016-06-23 19:04:55 -0500
HOSTNAME : epithumia.math.uh.edu
VERSION  : 3.14.14 (31 May 2016) redhat
UPSNAME  : epithumia.math.uh.edu
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2016-06-13 20:38:28 -0500
MODEL    : Back-UPS BR1500G
STATUS   : ONLINE
LINEV    : 120.0 Volts
LOADPCT  : 2.0 Percent
BCHARGE  : 100.0 Percent
TIMELEFT : 515.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
SENSE    : Medium
LOTRANS  : 88.0 Volts
HITRANS  : 147.0 Volts
ALARMDEL : 30 Seconds
BATTV    : 27.2 Volts
LASTXFER : Automatic or explicit self test
NUMXFERS : 1
XONBATT  : 2016-06-15 09:28:49 -0500
TONBATT  : 0 Seconds
CUMONBATT: 9 Seconds
XOFFBATT : 2016-06-15 09:28:58 -0500
LASTSTEST: 2016-06-15 09:28:50 -0500
SELFTEST : NO
STATFLAG : 0x05000008
SERIALNO : 4B1110P21896
BATTDATE : 2011-03-04
NOMINV   : 120 Volts
NOMBATTV : 24.0 Volts
NOMPOWER : 865 Watts
FIRMWARE : 865.L2 .D USB FW:L2
END APC  : 2016-06-23 19:04:56 -0500

apcupsd is of course working fine.

[14:47 root /home/leslie]# apcaccess
Error contacting apcupsd @ localhost:3551: Connection refused

[14:51 root /home/leslie]# apcupsd -V
apcupsd 3.14.13 (02 February 2015) redhat
This post and comment 25 are produced using F24

Hi Jason

I would like to get this issue resolved as !without the UPS recognized, I am holding back from moving over to F24.  Are the rules stuff part of the 99.4 upower clone?



Sorry, I did not cancel anything  review the message I got about cancelling.



Leslie Satenstein <lsatenstein> has canceled Leslie Satenstein
<lsatenstein>'s request for Fedora Extras Quality Assurance
<extras-qa>'s needinfo:
Bug 1342533: No UPS driver -- can't detect status of UPS Battery condition.
https://bugzilla.redhat.com/show_bug.cgi?id=1342533

My email is lsatenstein, I would prefer to work via email and then summarize the findings here). We area already up to comment 26 and my UPS is only available with F23.

what is the path (link) in comment 22  (/lub/udev/rules.d/95-upower-hid.rules)?


Here is apcaccess from the same computer but using Fedora23 
[15:42 root /home/leslie]# apcaccess
APC      : 001,017,0438
DATE     : 2016-06-27 15:43:00 -0400  
HOSTNAME : Chapeau.Linux
VERSION  : 3.14.13 (02 February 2015) redhat
CABLE    : Custom Cable Smart
DRIVER   : APC Smart UPS (any)
UPSMODE  : Stand Alone
STARTTIME: 2016-06-27 15:42:52 -0400  
STATUS   : 
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
STATFLAG : 0x05000000
END APC  : 2016-06-27 15:43:00 -0400  

I am also checking the /etc/hosts. There is a difference between F23 and F24

F24 /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
F23 /etc/hosts
127.0.0.1		localhost.localdomain localhost
::1		localhost6.localdomain6 localhost6

Another remark about upower and Fedora 23.

If the UPS is fully charged, and between upower sampling the UPS, there is no change in the UPS, the UPS is showing up as empty.

I removed power to force the UPS to click in, and after 1 minute, restored power. Now upower -d shows the charge percent and charging.

From beta1-6 (May) to 7July is more than 5 weeks.  Is this problem going to be resolved before Fedora 25? 

I am remaining with Fedora 23 and have tested with the most recent Linux Mint and SUSE Tumbleweed distributions. Upower reports correctly and appears to work with those distributions.

My concern in upgrading to Fedora 24. With using Fedora 24, there is no UPS  signal action detected by upower which in turn, signals the system to perform a normal system shutdown. When there is no electrical power and there is no UPS, I am concerned. In 5 milliseconds a 256gig SSD can be fully wiped out if power is removed without the UPS generated shutdown signal. The UPS signal allows a controlled safer shutdown.

Problem confirmed.

Same deal here.

Created attachment 1177692 [details]
F24  lsusb  -v -s 6:2

To provide developer/maintainer some diagnostic information

https://bugzilla.redhat.com/show_bug.cgi?id=1318845

http://www.spinics.net/lists/fedora-devel/msg220418.html

Comment #18 makes me think this is caused by the missing backport of the fix for trie building in udev:
https://github.com/systemd/systemd/commit/c45606eb95a7171b0dc801e91d35034957ad5e9e

(ohsix in #systemd observed similar seemingly mysterious inability of udev to process simple rules with ATTR{idProduct} and this commit fixed it.)

ohsix filed bug 1357822 requesting the backport.
I'm marking this BZ as a duplicate even though this BZ is the older one. 1357822 is more concise.

*** This bug has been marked as a duplicate of bug 1357822 ***

Michal, Thank you for the action. With this solution in place, I will be migrating from F23 to F24

upower -d 

Device: /org/freedesktop/UPower/devices/ups_hiddev0
  native-path:          /sys/devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.0/usbmisc/hiddev0
  power supply:         yes
  updated:              Wed 31 Dec 1969 07:00:00 PM EST (1469018946 seconds ago)
  has history:          yes
  has statistics:       yes
  ups
    present:             no
    state:               empty
    warning-level:       none
    percentage:          0%
    icon-name:          'battery-missing-symbolic'


Should show 100% and 2.2 hours remaining.

(In reply to Leslie Satenstein from comment #36)
So you actually rebuilt the F24 systemd package with the patch referenced in bug 1357822 applied and this is what upower prints now?
The "updated:" line contains the start of the Unix epoch, so I guess that's upower's way of saying it has not managed to update the data yet. I don't know why.

Hi Michal, 

F23, after 1 hr wait, continues to show above (comment 36) output. However, F23 was working correctly before the patch.  BUT on the F24 scene, all is showing correctly.  The patch broke something with F23, and corrected F24.

I am happy to make time to do specific testing (patches) for you.  I have done so in the past for others working on os_prober, amixer, and for btrfs

The patch should not be needed in F23 and it would not apply cleanly there. So I'm not sure what you did and why.

If you can test systemd-229-9.fc24 and leave feedback at https://bodhi.fedoraproject.org/updates/FEDORA-2016-47bda25e7a , that would be nice, thank you.