[Nut-upsuser] nut vs ups fail

[Charles Lepple]

On May 7, 2019, at 9:09 AM, Gene Heskett wrote:
> 
> On Tuesday 07 May 2019 08:38:44 am Charles Lepple wrote:
> 
>> On May 7, 2019, at 5:06 AM, Gene Heskett wrote:
>>> New testing install(stretch)
>>> pulled in nut stuff from repo.
>>> copied old wheezy configs to /etc/nut, overwriting the resident
>>> files can't talk to ups, missing usbhid-ups file
>> 
>> Gene,
>> 
>> What do you have in /etc/nut/ups.conf? (There shouldn't be any
>> passwords in that one if you're using a USB-connected UPS, but check
>> to be sure. Also, I don't need any of the lines starting with "#".)
> [myups]
> driver=usbhid-ups
> port=/dev/ttyUSB0
> offdelay = 120
> ondelay = 150

The usbhid-ups driver ignores the port, but NUT requires something there, so the usual recommendation for the usbhid-ups driver is  "port = auto". If nothing else, "port = auto" is less confusing to the poor developer trying to figure out what is going on :-)

However... is this UPS truly a HID UPS? Which make and model is it? If it's still the Belkin you asked about in November 2014, then it is a HID UPS, and "driver=usbhid-ups" (+ "port=auto") is correct.

If the kernel creates a /dev/ttyUSB0 node when you plug in the UPS, it's probably a USB-to-serial adapter wearing a funny hat. From the NUT driver perspective, if the UPS is on /dev/ttyUSB0, it is considered a serial UPS (despite the physical USB cable).

That said, other serial devices may show up as /dev/ttyUSB0. If this is, say, LinuxCNC, be sure that you aren't configuring NUT to send UPS commands to a motor controller or something.

> Should I put the full path to it in that driver= statement, Charles?

No, not necessary.

> But this kernel might not like it, its for 32 bit i386's according 
> to "file". I don't know if the 32 bit i386 stuff is in this rt kernel.

See below - it's not a kernel module. 64-bit kernels can run both 64- and 32-bit user-space programs (like NUT drivers). 32-bit on 64-bit does require some extra packages, but that really shouldn't be the case here.

The i386 stuff is worrisome. What are the first three or so lines from "apt-cache show nut-server"? Also, does "file /lib/nut/usbhid-ups" really say "i386", or does it say "ELF 64-bit LSB shared object, x86-64"?

>>> Found it in /lib/nut, doesn't modprobe, not in
>>> /lib/modules/kernelversion tree.
>>> 
>>> I need to fix this, how do I proceed? A direct address path
>>> in /etc/modules? Doesn't work..
>>> 
>>> I did try this:
>>> 
>>> root at coyote:etc$ insmod /lib/nut/usbhid-ups
>>> insmod: ERROR: could not insert module /lib/nut/usbhid-ups: Invalid
>>> module format.
>>> 
>>> Is this telling me I need to get the nut src and compile it for 64
>>> bit?
>> 
>> NUT "drivers" are user-space programs, not kernel modules. The Debian
>> packages of NUT should be able to find the drivers in /lib/nut without
>> any problems. (For instance, when you have "driver = usbhid-ups"
>> listed in /etc/nut/ups.conf, "upsdrvctl start" will combine the
>> default driver path "/lib/nut" with "usbhid-ups" to start
>> /lib/nut/usbhid-ups.)

^^^ if you are using the stock Debian stretch packages, "driver = usbhid-ups" (no /lib/nut) should be sufficient. If it is a Frankenstein install (e.g. some components built from source), all bets are off (see comment below).

>> We only recommend mixing repo packages and source builds in certain
>> cases (for debugging, and supporting new hardware), and there's a
>> procedure on the GitHub wiki to make the source build match the .deb
>> packages. Let's try to make the Debian stretch packages work first.