[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Manuel Wolfshant]

On 06/20/2017 02:27 AM, Charles Lepple wrote:
> On Jun 19, 2017, at 10:45 AM, Manuel Wolfshant wrote:
>> #lsusb -vvv -d 0463:ffff
>>
>> Bus 002 Device 012: ID 0463:ffff MGE UPS Systems UPS
> ...
>>        HID Device Descriptor:
>>           bLength                 9
>>           bDescriptorType        33
>>           bcdHID               1.10
>>           bCountryCode           33 US
>>           bNumDescriptors         1
>>           bDescriptorType        34 Report
>>           wDescriptorLength     549
>>           Warning: incomplete report descriptor
>>           Report Descriptor: (length is 9)
>>             Item(Main  ): (null), data=none
>>             Item(Main  ): (null), data=none
>>             Item(Main  ): (null), data=none
>>
> If I recall, this is equivalent to the usbhid-ups "method 2" approach to retrieving the descriptor.

That's greek to me, I am completely unfamiliar to any of nut ( and its 
drivers ) internals :) But if I can configure usbhid-ups in a different 
manner which I did not spot from the docs, please point me to the 
correct docs.



>>>   or try to roll back the userspace tools to match what was current when the kernel was current.
>>>
>> I am afraid I did not understand this part...
> If there are newer kernels out there, it is possible that some of the userspace tools (usbutils, libusb, etc.) are expecting a newer kernel. Is it possible to downgrade any of them, to test with package versions that were released at the same time as the 2.6.32 kernel?
If you mean the applications/libraries running on that server, I can 
guarantee that every one (minus libusb 1.0.19 -- see below) of them is 
compatible with the running kernel. Everything but nut is stock CentOS 6 
and fully updated. I am 100% positive that libsub0.1 which was used 
until yesterday ( and 1.0.9 which proved to be incompatible with nut ) 
are 100% compatible with the kernel. I cannot guarantee for libusbx 
1.0.19  (which I used instead of 1.0.9) because I built it myself. 
However I am using the very same package on my personal workstation 
(which is also running CentOS 6 but has a whole lot of packages 
installed either from 3rd party repos or built by me  ) since Fri 09 Jan 
2015 (I needed it for heimdall <http://glassechidna.com.au/heimdall/> ) 
and I had zero issues so far.

As of newer kernels: RH does not introduce incompatibilities between 
kernel and userspace. For the whole 10 years of life of a major version 
of a distribution, the major release of the kernel (and of most packages 
-- which is why both libsub and libusb1 aka 1.0.9 are oldish ) is frozen 
to the version used at launch date. It was 2.6.32 4.5 years ago when 6.0 
was launched and it will claim to be 2.6.32 when it will be EOLed 4 
years from now. They do backport stuff into the kernel ( actually the 
current kernel has huge backports from 3.10 ),  but breaking the ABI is 
extremely rare and normally never affects the packages from the distro 
itself because they are tested for months prior to any minor release of 
the distro. The newer kernels that exist and are let's say reputable are 
provided by a 3rd party repository ( ElRepo.org ). Over there there is 
one person who maintains two sets of kernels, the most recent one that 
is available from kernel.org ( "kernel mainline" ) and one long term 
version ( kernel-lt ). The kernel-lt is the one that failed for me.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170620/11aa99c6/attachment.html>