On Sep 15, 2015, at 9:31 PM, Charles Lepple <clepple at gmail.com> wrote:> >> Trying to track down the source of the problem, I checked Yast to make sure I had at least 0.1.8 version for libusb. I saw this (attached photo). Is it then actually using ?compat instead of the ?real? libusb? And is that a problem? > > You're right, both the -compat and real libusb packages will use the same libusb-0.1.so* name.I misspoke. The "real libusb" (0.1) and libusb-compat will both get linked with "-lusb". The package management system is free to implement that with symlinks to the actual files. The confusing part is that openSUSE seems to be adopting the 0.1.1x numbering scheme for libusb-compat so that the package looks newer (0.1.13) than the real libusb-0.1.12: https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.spec?expand=1 Note the changes mentioned in the return codes for usb_detach_kernel_driver_np(): https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.changes?expand=1 Those are the sort of edge cases that haven't been fully tested with NUT. It seems like the path from NUT driver through libusb to the kernel is relatively unchanged with libusb-compat, but that mapping the errors back to root cause will depend on the exact version of libusb-compat in use (and potentially, the kernel version as well). I would recommend retesting with an explicit "killall usbhid-ups" (and anything else necessary to stop NUT background services, otherwise it will pop back up) before switching debug flags on. If that fails to turn up anything conclusive, you might try to install libusb-0.1.12 from source in a separate directory, and explicitly point ./configure to that tree: <remove libusb-compat-devel> install from http://sourceforge.net/projects/libusb/files/libusb-0.1%20%28LEGACY%29/0.1.12/ .../libusb-0.1.12 $ ./configure --prefix=$HOME/local/libusb-0.1 && make && sudo make install .../nut $ ./configure --with-usb-include=$HOME/local/libusb-0.1/include --with-usb-libs=-L$HOME/local/libusb-0.1/lib ... (might need slight adjustments) After that, you can verify that the libusb line in "ldd /path/to/usbhid-ups" points to "$HOME/local/..." -- Charles Lepple clepple at gmail
I'm making some progress, I think. My normal method of installation was to install openSUSE 13.1, and then after install, use zypper to install the libusb libraries. That, of course, pulls them from the online repository. I believe in the last couple months, that version must have changed. So I just did a fresh install off the ISO image, and this time included the libusb libraries in the install. Coming off of the ISO image, they are certain to be older versions than what can be installed today. And it works!....SORT OF. More specifically, I can tell upsdrvctl to shutdown, and it does that. It sends the command to the UPS to shutdown after 20 seconds and then come back up. Awesome. Unfortunately, for some reason, putting that same command into the file that is supposed to be execute automatically upon shutdown isn't working. I'm going to try Roger's alternate "systemd service unit" method to see if it works. Still strange, though, because I had been using the shutdown script method before all this began.... So if I can get it to reliably shutdown the UPS using the service unit, I'm going to say some new version of libusb is to blame. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -----Original Message----- From: Charles Lepple [mailto:clepple at gmail.com] Sent: Thursday, September 17, 2015 9:13 AM To: Rob Groner <rgroner at RTD.com> Cc: Roger Price <roger at rogerprice.org>; nut-upsuser Mailing List <nut-upsuser at lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 15, 2015, at 9:31 PM, Charles Lepple <clepple at gmail.com> wrote:> >> Trying to track down the source of the problem, I checked Yast to make sure I had at least 0.1.8 version for libusb. I saw this (attached photo). Is it then actually using ?compat instead of the ?real? libusb? And is that a problem? > > You're right, both the -compat and real libusb packages will use the same libusb-0.1.so* name.I misspoke. The "real libusb" (0.1) and libusb-compat will both get linked with "-lusb". The package management system is free to implement that with symlinks to the actual files. The confusing part is that openSUSE seems to be adopting the 0.1.1x numbering scheme for libusb-compat so that the package looks newer (0.1.13) than the real libusb-0.1.12: https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.spec?expand=1 Note the changes mentioned in the return codes for usb_detach_kernel_driver_np(): https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.changes?expand=1 Those are the sort of edge cases that haven't been fully tested with NUT. It seems like the path from NUT driver through libusb to the kernel is relatively unchanged with libusb-compat, but that mapping the errors back to root cause will depend on the exact version of libusb-compat in use (and potentially, the kernel version as well). I would recommend retesting with an explicit "killall usbhid-ups" (and anything else necessary to stop NUT background services, otherwise it will pop back up) before switching debug flags on. If that fails to turn up anything conclusive, you might try to install libusb-0.1.12 from source in a separate directory, and explicitly point ./configure to that tree: <remove libusb-compat-devel> install from http://sourceforge.net/projects/libusb/files/libusb-0.1%20%28LEGACY%29/0.1.12/ .../libusb-0.1.12 $ ./configure --prefix=$HOME/local/libusb-0.1 && make && sudo make install .../nut $ ./configure --with-usb-include=$HOME/local/libusb-0.1/include --with-usb-libs=-L$HOME/local/libusb-0.1/lib ... (might need slight adjustments) After that, you can verify that the libusb line in "ldd /path/to/usbhid-ups" points to "$HOME/local/..." -- Charles Lepple clepple at gmail
So far, the systemd service unit is working perfectly. Halleluia!
For reference, here are the libs associated with the usbhid-ups driver:
rtd at linux-fnda:/etc/init.d> ldd /usr/local/ups/bin/usbhid-ups
linux-vdso.so.1 (0x00007fffecd25000)
libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007ff3b841b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff3b81fd000)
libc.so.6 => /lib64/libc.so.6 (0x00007ff3b7e4e000)
libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007ff3b7c3e000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff3b8621000)
librt.so.1 => /lib64/librt.so.1 (0x00007ff3b7a36000)
Rob Groner
Software Engineer Level II
RTD Embedded Technologies, Inc.
ISO 9001 and AS9100 Certified
Ph: +1 814-234-8087
www.rtd.com
-----Original Message-----
From: Charles Lepple [mailto:clepple at gmail.com]
Sent: Thursday, September 17, 2015 9:13 AM
To: Rob Groner <rgroner at RTD.com>
Cc: Roger Price <roger at rogerprice.org>; nut-upsuser Mailing List
<nut-upsuser at lists.alioth.debian.org>
Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
On Sep 15, 2015, at 9:31 PM, Charles Lepple <clepple at gmail.com>
wrote:>
>> Trying to track down the source of the problem, I checked Yast to make
sure I had at least 0.1.8 version for libusb. I saw this (attached photo). Is
it then actually using ?compat instead of the ?real? libusb? And is that a
problem?
>
> You're right, both the -compat and real libusb packages will use the
same libusb-0.1.so* name.
I misspoke.
The "real libusb" (0.1) and libusb-compat will both get linked with
"-lusb". The package management system is free to implement that with
symlinks to the actual files.
The confusing part is that openSUSE seems to be adopting the 0.1.1x numbering
scheme for libusb-compat so that the package looks newer (0.1.13) than the real
libusb-0.1.12:
https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.spec?expand=1
Note the changes mentioned in the return codes for
usb_detach_kernel_driver_np():
https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.changes?expand=1
Those are the sort of edge cases that haven't been fully tested with NUT. It
seems like the path from NUT driver through libusb to the kernel is relatively
unchanged with libusb-compat, but that mapping the errors back to root cause
will depend on the exact version of libusb-compat in use (and potentially, the
kernel version as well).
I would recommend retesting with an explicit "killall usbhid-ups" (and
anything else necessary to stop NUT background services, otherwise it will pop
back up) before switching debug flags on.
If that fails to turn up anything conclusive, you might try to install
libusb-0.1.12 from source in a separate directory, and explicitly point
./configure to that tree:
<remove libusb-compat-devel>
install from
http://sourceforge.net/projects/libusb/files/libusb-0.1%20%28LEGACY%29/0.1.12/
.../libusb-0.1.12 $ ./configure --prefix=$HOME/local/libusb-0.1 && make
&& sudo make install
.../nut $ ./configure --with-usb-include=$HOME/local/libusb-0.1/include
--with-usb-libs=-L$HOME/local/libusb-0.1/lib ...
(might need slight adjustments)
After that, you can verify that the libusb line in "ldd
/path/to/usbhid-ups" points to "$HOME/local/..."
--
Charles Lepple
clepple at gmail
On Sep 17, 2015, at 10:56 AM, Rob Groner <rgroner at RTD.com> wrote:> > So far, the systemd service unit is working perfectly. Halleluia!Good news!> For reference, here are the libs associated with the usbhid-ups driver: > > rtd at linux-fnda:/etc/init.d> ldd /usr/local/ups/bin/usbhid-ups > linux-vdso.so.1 (0x00007fffecd25000) > libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007ff3b841b000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff3b81fd000) > libc.so.6 => /lib64/libc.so.6 (0x00007ff3b7e4e000) > libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007ff3b7c3e000) > /lib64/ld-linux-x86-64.so.2 (0x00007ff3b8621000) > librt.so.1 => /lib64/librt.so.1 (0x00007ff3b7a36000)What I missed before was that you have both "libusb-0.1.so.4" (from libusb-compat) and "libusb-1.0.so.0" (what libusb-compat calls through to). -- Charles Lepple clepple at gmail
Well, I've spent a couple hours on this, unable to figure it out. I removed the libusb-compat-devel package using zypper. And I've downloaded, built, and installed libusb from sourceforge. But trying to configure nut now I get "USB drivers requested, but libusb not found", no matter what I put for --with-usb-libs. Continuing to flog away at it... Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -----Original Message----- From: Charles Lepple [mailto:clepple at gmail.com] Sent: Thursday, September 17, 2015 9:13 AM To: Rob Groner <rgroner at RTD.com> Cc: Roger Price <roger at rogerprice.org>; nut-upsuser Mailing List <nut-upsuser at lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 15, 2015, at 9:31 PM, Charles Lepple <clepple at gmail.com> wrote:> >> Trying to track down the source of the problem, I checked Yast to make sure I had at least 0.1.8 version for libusb. I saw this (attached photo). Is it then actually using ?compat instead of the ?real? libusb? And is that a problem? > > You're right, both the -compat and real libusb packages will use the same libusb-0.1.so* name.I misspoke. The "real libusb" (0.1) and libusb-compat will both get linked with "-lusb". The package management system is free to implement that with symlinks to the actual files. The confusing part is that openSUSE seems to be adopting the 0.1.1x numbering scheme for libusb-compat so that the package looks newer (0.1.13) than the real libusb-0.1.12: https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.spec?expand=1 Note the changes mentioned in the return codes for usb_detach_kernel_driver_np(): https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.changes?expand=1 Those are the sort of edge cases that haven't been fully tested with NUT. It seems like the path from NUT driver through libusb to the kernel is relatively unchanged with libusb-compat, but that mapping the errors back to root cause will depend on the exact version of libusb-compat in use (and potentially, the kernel version as well). I would recommend retesting with an explicit "killall usbhid-ups" (and anything else necessary to stop NUT background services, otherwise it will pop back up) before switching debug flags on. If that fails to turn up anything conclusive, you might try to install libusb-0.1.12 from source in a separate directory, and explicitly point ./configure to that tree: <remove libusb-compat-devel> install from http://sourceforge.net/projects/libusb/files/libusb-0.1%20%28LEGACY%29/0.1.12/ .../libusb-0.1.12 $ ./configure --prefix=$HOME/local/libusb-0.1 && make && sudo make install .../nut $ ./configure --with-usb-include=$HOME/local/libusb-0.1/include --with-usb-libs=-L$HOME/local/libusb-0.1/lib ... (might need slight adjustments) After that, you can verify that the libusb line in "ldd /path/to/usbhid-ups" points to "$HOME/local/..." -- Charles Lepple clepple at gmail
On Sep 18, 2015, at 2:45 PM, Rob Groner <rgroner at RTD.com> wrote:> > Well, I've spent a couple hours on this, unable to figure it out. I removed the libusb-compat-devel package using zypper. And I've downloaded, built, and installed libusb from sourceforge. But trying to configure nut now I get "USB drivers requested, but libusb not found", no matter what I put for --with-usb-libs. Continuing to flog away at it...What's the error message? It might be hidden in config.log, but if you send that, please gzip it first. -- Charles Lepple clepple at gmail