On Tuesday 07 May 2019 09:49:47 am Charles Lepple wrote:
> 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"?
Now, after reinstalling from the stretch repo, it claims:
root at coyote:~$ file /lib/nut/usbhid-ups
/lib/nut/usbhid-ups: ELF 64-bit LSB shared object, x86-64, version 1
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
And after numerous restarts:
GNU/Linux 2.6.32, Buiroot at coyote:~$ service nut-server status
● nut-server.service - Network UPS Tools - power devices information
server
Loaded: loaded (/lib/systemd/system/nut-server.service; enabled;
vendor preset: enabled)
Active: active (running) since Tue 2019-05-07 10:40:21 EDT; 9min ago
Process: 12110 ExecStart=/sbin/upsd (code=exited, status=0/SUCCESS)
Main PID: 12111 (upsd)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/nut-server.service
└─12111 /lib/nut/upsd
May 07 10:40:21 coyote systemd[1]: Starting Network UPS Tools - power
devices information server...
May 07 10:40:21 coyote upsd[12110]: fopen /var/run/nut/upsd.pid: No such
file or directory
May 07 10:40:21 coyote upsd[12110]: listening on 127.0.0.1 port 3493
May 07 10:40:21 coyote upsd[12110]: Can't connect to UPS [myups]
(usbhid-ups-myups): No such file or directory
May 07 10:40:21 coyote upsd[12110]: listening on 127.0.0.1 port 3493
May 07 10:40:21 coyote upsd[12110]: Can't connect to UPS [myups]
(usbhid-ups-myups): No such file or directory
May 07 10:40:21 coyote upsd[12111]: Startup successful
May 07 10:40:21 coyote systemd[1]: Started Network UPS Tools - power
devices information server.
May 07 10:45:21 coyote upsd[12111]: Can't connect to UPS [myups]
(usbhid-ups-myups): No such file or directory
ldID[sha1]=835db204083eb2259cb9effccb5dc4e5a636de05, stripped
Thanks Charles
> >>> 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.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>