similar to: Minor problem with yum-cron

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 . . . On November 9, 2024 1:25:29 PM EST, Bill Gee <bgee at campercaver.net> wrote: >Nut should be running as user nut. As far as I can tell, the udev rules have not changed. And the system IS

Nut should be running as user nut. As far as I can tell, the udev rules have not changed. And the system IS seeing the UPS at a low level. I looked through /dev/ but did not see a device that jumps out as the UPS. ===================== [root at mythtv rules.d]# dmesg | grep -i 0764 [ 2.021485] usb 1-1.8: New USB device found, idVendor=0764, idProduct=0501, bcdDevice= 0.01 [ 2.049515]

Did the upgrade by chance install/alter any udev rules causing the UPS devices to now have incorrect permissions? And what user is nut running as? On November 9, 2024 9:58:57 AM EST, Bill Gee <bgee at campercaver.net> wrote: >Running NUT version 2.8.2 on Fedora 40. NUT installed from the Fedora package. CyberPower CP1000AVRLCD connected by USB. > >I updated the system yesterday

Running NUT version 2.8.2 on Fedora 40. NUT installed from the Fedora package. CyberPower CP1000AVRLCD connected by USB. I updated the system yesterday with all the latest Fedora packages. Now NUT will not run. Chasing the issue through the layers, I come to this: ===================== [root at mythtv rules.d]# upsc cyberpower Error: Driver not connected [root at mythtv rules.d]#

Look in the startup logs and see where itnis starting. I'm not at a RH system at the moment, but at work, I have had to do this, so can look there,mor perhaps put Nut on the test RH8 VM I spun up for other rrasons on Friday and work out the syntax. Not sure if the systemd file you are using came in the RPM or not, but if it did, it's almost a crime that this critical detail was overlooked.

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

OK, looking at this on my RH8 test image . . . The first thing that I note, is that the *only* thing that needed to be set to "enabled" in systemctl (IE "systemctl enable ....") is the nut.target entry. All else here are disabled, and "drug along" by nut.target which ensures that they come up in sequence. In nut.target I added to the "After" and

I've had fun with nut on RH systems, these are my notes to get it working: Create /usr/lib/tmpfiles.d/nut-client.conf:D? ? /run/nut 0770 root nut - ...the file did not exist, and so the PID folder/file was not getting generated. Then the driver would start. Also had to setup enabled services (still not 100% confident that this is totally correct):[root at emp80 ups]# systemctl list-unit-files

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 =

Hello everyone - I am trying to use virt-viewer to connect to KVM virtual machines running on a CentOS7 host. It works great when running directly on the host, but I have not been able to figure out the magic connection string to make it work from another computer. On the host, I set selinux to "permissive" and stopped the firewalld service. No change, so it is not related to

On Tue, Dec 30, 2014 at 9:58 AM, Marcelo Roccasalva < marcelo-centos at irrigacion.gov.ar> wrote: > On Tue, Dec 30, 2014 at 11:46 AM, Bill Gee <bgee at campercaver.net> wrote: > > > Hello everyone - > > > > I am trying to use virt-viewer to connect to KVM virtual machines running > > on a > > CentOS7 host. It works great when running directly on

On Tue, Dec 30, 2014 at 4:08 PM, Bill Gee <bgee at campercaver.net> wrote: > > Thanks! I changed the qemu.conf file to listen on 0.0.0.0. That works - > I can > connect to the virtual machines using a VNC client. > Listening on 0.0.0.0 listens on all network interfaces. Mark's comment is not a major concern unless your KVM host is directly connected to the Internet (no

On Tue, Dec 30, 2014 at 11:46 AM, Bill Gee <bgee at campercaver.net> wrote: > Hello everyone - > > I am trying to use virt-viewer to connect to KVM virtual machines running > on a > CentOS7 host. It works great when running directly on the host, but I have > not been able to figure out the magic connection string to make it work > from > another computer. >

On Tuesday, December 30, 2014 16:15:45 m.roth at 5-cent.us wrote: > Bill Gee wrote: > > On Tuesday, December 30, 2014 13:01:57 SilverTip257 wrote: > >> On Tue, Dec 30, 2014 at 9:58 AM, Marcelo Roccasalva < > >> > >> marcelo-centos at irrigacion.gov.ar> wrote: > >> > On Tue, Dec 30, 2014 at 11:46 AM, Bill Gee <bgee at campercaver.net>

Hi Bill, On 2016-05-30, Bill Gee <bgee at campercaver.net> wrote: > > By luck I saw the beginning of a reboot on the server console. Normally I have > other systems up on the KVM switch. It appears to have dumped core. I don't > know where to look for the core dump files. They are not in /root. One place you might check is under /var/lib. I think there may be a

On Tue, Jul 30, 2024 at 7:10?AM Bill Gee <bgee at campercaver.net> wrote: > I wonder if this will get Rick's system running?? > Tim/Bill, I removed the nut pkg and deps, deleted the nut*.d dirs created in /etc/systemd/system, then reinstalled nut. I added the two network objects to Wants and After in system.target, restored confs in /etc/ups, rebooted, and sure enough upsd and

On Tuesday, December 30, 2014 13:01:57 SilverTip257 wrote: > On Tue, Dec 30, 2014 at 9:58 AM, Marcelo Roccasalva < > > marcelo-centos at irrigacion.gov.ar> wrote: > > On Tue, Dec 30, 2014 at 11:46 AM, Bill Gee <bgee at campercaver.net> wrote: > > > Hello everyone - > > > > > > I am trying to use virt-viewer to connect to KVM virtual machines

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-verbosity With `upsdrvctl` driven attempts, you may also be in conflict with a generated `nut-driver at

> Am 05.03.2018 um 15:34 schrieb Bill Gee <bgee at campercaver.net>: > > > On Monday, March 5, 2018 7:23:53 AM CST Leon Fauster wrote: >> Am 05.03.2018 um 13:04 schrieb Nicolas Kovacs <info at microlinux.fr>: >>> Le 28/02/2018 ? 22:23, Nicolas Kovacs a ?crit : >>>> So far, I've only been able to filter HTTP. >>>>

Has this been solved? Is there a bug report I can follow? Thank you for letting me know, Val?re Binet On Wed, Nov 16, 2022 at 2:23 PM Bill Gee <bgee at campercaver.net> wrote: > On the other hand --- I just upgraded one of my CentOS7 systems to > 3.10.0-1160.80.1 today. With that kernel it will not run any KVM guest. > The system hangs - HARD - within one or two seconds of