Hide Forgot
Description of problem: UPS status information is not being tracked by Fedora24. dnf install apc* will, with previous versions of Fedora, present battery status when clicking on system-->power With previous versions, it would also initiate a controlled poweroff if there was a power failure and the battery was almost discharged. Anaconda needs to also incude the UPS driver. Version-Release number of selected component (if applicable): All daily snapshots and all alpha-beta versions of Fedora24 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: No UPS driver for UPS info, Very risky to use Fedora24 as a server or where data integrity is important.
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.
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@yahoo.com> has canceled Leslie Satenstein <lsatenstein@yahoo.com>'s request for Fedora Extras Quality Assurance <extras-qa@fedoraproject.org>'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@yahoo.com, 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.