Hmmm .... It is not a big deal since everything else is running fine.
Here is what rpm reports about the version of NUT that I have:
================
[root@mythtv ~]# rpm -qi nut
Name : nut
Version : 2.8.2
Release : 1.fc40
Architecture: x86_64
Install Date: Sat 04 May 2024 04:03:09 PM CDT
Group : Unspecified
Size : 12792564
License : GPL-2.0-or-later AND GPL-3.0-or-later
Signature : RSA/SHA256, Mon 15 Apr 2024 10:15:03 AM CDT, Key ID
0727707ea15b79cc
Source RPM : nut-2.8.2-1.fc40.src.rpm
Build Date : Wed 03 Apr 2024 05:50:48 AM CDT
===============
I am going to upgrade this system to Fedora 41 today. When that is done
and back to stable, I will report back.
===============
Bill Gee
On 11/10/24 16:11, Jim Klimov wrote:
Great!
Regarding libusb and nut-scanner, I think the *.so (exact) symlinks are
part of *-devel packages.
This was solved in NUT recently (maybe after 2.8.2 release already) by
detecting and stashing the basename of realpath of the library present
during build, so the exact *.so.X.Y.Z would be also tried.
Also, nut-scanner now (in 2.8.2 IIRC) should not suggest the volatile
bus/busport/device numbers by default.
Jim
On Sun, Nov 10, 2024 at 7:42 PM Bill Gee <[email protected]
<mailto:[email protected]>> wrote:
Thanks for the tip, Jim. I just figured out what is going on. The
system is now working. ==> This one is on me. <==
The root cause was the specification of the bus number in the ups.conf
file. Here is what it looks like now:
============
[cyberpower]
driver = "usbhid-ups"
port = "auto"
vendorid = "0764"
productid = "0501"
product = "UPS CP1000AVRLCD"
vendor = "CPS"
# bus = "006"
================
It had been running with the bus= line uncommented. I don't remember
why that was needed, but sometime in the dark past I added it.
Commenting it out and restarting both nut-server and nut-monitor
brought
everything to life.
Charles' reply below had the seed of the answer when he mentioned how
the UPS will appear in the /dev/ directory. I had been looking at
every
other file except ups.conf and so the bus number was not top of mind.
The documentation linked by Jim says that the DEBUG_MIN setting is
supported in all of the .conf files. I changed it in upsd.conf, then
went looking in other files. That is when I noticed the bus number in
ups.conf. A very big DOH slap was promptly administered!
I think the messages about permissions were the result of not having
bus
number 6 at all. There was no /dev device to connect to and that was
interpreted as lack of permissions.
As for the messages about missing libusb ... I am still puzzled over
that. nut-scanner still complains about it. It is hard to argue with
success, though, so that question is now sort of moot. "upsc
cyberpower"
returns valid information and nut-monitor is no longer attempting
restart once per minute.
Thanks everyone for the help.
===============
Bill Gee
On 11/10/24 11:45, Jim Klimov wrote:
> Can you try starting the driver with higher debug verbosity to
see more
> details, e.g. add `debug_min = 6` to the `ups.conf` section, or
stop the
> auto-starting driver attempts and run the driver program with CLI
options?
>
> * https://github.com/networkupstools/nut/wiki/Changing-NUT-
daemon-debug- <https://github.com/networkupstools/nut/wiki/Changing-
NUT-daemon-debug->
> verbosity <https://github.com/networkupstools/nut/wiki/Changing-
NUT- <https://github.com/networkupstools/nut/wiki/Changing-NUT->
> daemon-debug-verbosity>
>
> With `upsdrvctl` driven attempts, you may also be in conflict with a
> generated `[email protected]` instance (although this
is not
> the only problem, as the unit seems to fail starting for you
too), more
> details about such units at:
>
> * https://github.com/networkupstools/nut/wiki/ <https://
github.com/networkupstools/nut/wiki/>
> nut%E2%80%90driver%E2%80%90enumerator-(NDE) <https://github.com/
<https://github.com/>
> networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)>
>
> Jim
>
>
> On Sun, Nov 10, 2024 at 4:47 PM Bill Gee <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> I also am wondering if the message about libusb driver
missing might be
> the real problem.
>
> Checking my system, I see this:
>
> ===================
> [root@mythtv dev]# ll /dev/bus/usb/001
> total 0
> crw-rw-r--+ 1 root root 189, 0 Nov 9 08:21 001
> crw-rw-r--+ 1 root root 189, 1 Nov 9 08:21 002
> crw-rw-r--+ 1 root root 189, 2 Nov 9 08:21 003
> crw-rw-r--+ 1 root dialout 189, 3 Nov 10 09:43 004
> ==================
>
> That looks to me like the udev rule worked.
>
> ===============
> Bill Gee
>
> On 11/10/24 08:38, Charles Lepple via Nut-upsuser wrote:
> > On Nov 9, 2024, at 8:09 PM, Tim Dawson
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
> >>
> >> Check /dev/hidraw6, as noted in your dmesg output (and
any other
> *hid*
> >> devices under /dev). User nut has almost zero privs to
devices
> unless
> >> a udev rule changes the perms on the dev for nut . . .
> >
> > I admit I am not fully tracking the latest NUT
developments, but
> I don't
> > think the current drivers use /dev/hidraw*, especially
when the
> drivers
> > mention libusb. (Once the libusb-based drivers start, they
should
> detach
> > the kernel's HID drivers such that the corresponding /dev/
hidraw*
> device
> > disappears.)
> >
> > You are correct that the udev rules need to change
permissions on
> one of
> > the UPS /dev nodes, though.
> >
> > From Bill's lsusb output:
> >
> > [root@mythtv ups]# lsusb
> > ...
> > Bus 001 Device 004: ID 0764:0501 Cyber Power System, Inc.
CP1500
> AVR UPS
> >
> > The libusb path for this UPS would typically be /dev/bus/
usb/001/004
> >
> > --
> > Charles Lepple
> > clepple@gmail
> >
> >
> >> _______________________________________________
> >> Nut-upsuser mailing list
> >> [email protected] <mailto:Nut-
[email protected]> <mailto:Nut-upsuser@alioth-
<mailto:Nut-upsuser@alioth->
> lists.debian.net <http://lists.debian.net>>
> >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
nut- <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut->
> upsuser <https://alioth-lists.debian.net/cgi-bin/mailman/
listinfo/ <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/>
> nut-upsuser>
> >
> >
> > _______________________________________________
> > Nut-upsuser mailing list
> > [email protected] <mailto:Nut-
[email protected]> <mailto:Nut-upsuser@alioth-
<mailto:Nut-upsuser@alioth->
> lists.debian.net <http://lists.debian.net>>
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
nut- <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut->
> upsuser <https://alioth-lists.debian.net/cgi-bin/mailman/
listinfo/ <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/>
> nut-upsuser>
>
>
> _______________________________________________
> Nut-upsuser mailing list
> [email protected] <mailto:Nut-upsuser@alioth-
lists.debian.net> <mailto:Nut-upsuser@alioth- <mailto:Nut-
upsuser@alioth->
> lists.debian.net <http://lists.debian.net>>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-
upsuser <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
nut-upsuser>
> <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
nut-upsuser <https://alioth-lists.debian.net/cgi-bin/mailman/
listinfo/nut-upsuser>>
>
_______________________________________________
Nut-upsuser mailing list
[email protected] <mailto:Nut-upsuser@alioth-
lists.debian.net>
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
