UPS tools / usbfs error

[Bill Rosenberg]

I have a DNS-323-B1 and just last week flashed from stock firmware + ffp to Alt-F RC4. It was pretty easy to get everything reconfigured except I cannot get the Alt-F Network UPS Tools package to work under this firmware. (I did have it working previously through ffp.) I have to admit my Linux skills are basic but here is what I have been able to figure out.

I have an APC BackUPS product which uses the usbhid-ups driver. When trying to load the driver via the "upsdrvctl start" command I get the error:

No matching HID UPS found

Driver failed to start (exit status=1)

By raising the debug level with "export USB_DEBUG=2" I can get additional info.

usb_os_init: No USB VFS found, is it mounted?
USB error: couldn't opendir(): No such file or directory

From what I have been able to find via Google, it looks like the driver (or maybe it's libusb) is expecting a usbfs mount at /proc/bus/usb which does not exist.

# mount
rootfs on / type rootfs (rw)
tmpfs on /rootmnt type tmpfs (rw,relatime)
/rootmnt/dev/loop0 on /rootmnt/ro type squashfs (ro,relatime)
aufs on / type aufs (rw,relatime,si=6bceb318)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime,size=162816k)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/sda4 on /mnt/sda4 type ext2 (rw,relatime,errors=continue)
/dev/md0 on /mnt/md0 type ext2 (rw,relatime,errors=continue)
/dev/sdb4 on /mnt/sdb4 type ext2 (rw,relatime,errors=continue)

At this point I am stuck but think I am on the right track for why the driver fails. Is there a way to get the desired mount point? I do see other posts where this mount point exists so perhaps I am doing something wrong.

Thanks.

Bill

[João Cardoso]

On Saturday, July 5, 2014 10:46:04 PM UTC+1, Bill Rosenberg wrote:

I have a DNS-323-B1 and just last week flashed from stock firmware + ffp to Alt-F RC4. It was pretty easy to get everything reconfigured except I cannot get the Alt-F Network UPS Tools package to work under this firmware. (I did have it working previously through ffp.) I have to admit my Linux skills are basic but here is what I have been able to figure out.

I have an APC BackUPS product which uses the usbhid-ups driver. When trying to load the driver via the "upsdrvctl start" command I get the error:

No matching HID UPS found

Driver failed to start (exit status=1)

By raising the debug level with "export USB_DEBUG=2" I can get additional info.

usb_os_init: No USB VFS found, is it mounted?
USB error: couldn't opendir(): No such file or directory

From what I have been able to find via Google, it looks like the driver (or maybe it's libusb) is expecting a usbfs mount at /proc/bus/usb which does not exist.

It does not exists because usbfs (/proc/bus/usb) has been removed from linux-3.x.

Install the  usbutils pckages and try 'lsusb -tv'.

You might have to load some kernel modules first. USBHID is builtin in the kernel, it is not a separate loadable module. You might have to unload the usblp module, 'modprobe -r usblp'.

# mount
rootfs on / type rootfs (rw)
tmpfs on /rootmnt type tmpfs (rw,relatime)
/rootmnt/dev/loop0 on /rootmnt/ro type squashfs (ro,relatime)
aufs on / type aufs (rw,relatime,si=6bceb318)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime,size=162816k)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/sda4 on /mnt/sda4 type ext2 (rw,relatime,errors=continue)
/dev/md0 on /mnt/md0 type ext2 (rw,relatime,errors=continue)
/dev/sdb4 on /mnt/sdb4 type ext2 (rw,relatime,errors=continue)

At this point I am stuck but think I am on the right track for why the driver fails. Is there a way to get the desired mount point? I do see other posts where this mount point exists

Yes, on Alt-F-0.1RC3, which is based on linux 2.6.x, not 3.10.x, it existed.

 

so perhaps I am doing something wrong.

Perhaps the network UPS tools mailing list or forums? The most important is referring the 3.10.32 kernel (USBHID builtin), nut-2.6.1, uclibc-0.9.30.3, libusb-0.1.12, usbutils-0.87...

I'm afraid that I can't help more, but if you find a solution please report back.

 

Thanks.

Bill

[João Cardoso]

Of course you can install ffp under Alt-f (use the webUI) and see if NUT works.

If it doesn't work then the issue is kernel related, otherwise it is a compilation or libusb version issue.

In any case please report back .

[Bill Rosenberg]

I tried installing ffp-0.5 and the NUT package that worked before, and still get the same error. So I'm guessing this is a kernel issue. I decided to use another box as my UPS master, so other than some time to reconfigure everything it wasn't that big an inconvenience. I really like Alt-F and will continue to use it. Thanks for all the work!

[Glenn Farrell]

Yesterday I upgraded my DNS-323-B1 to Alt-F RC4.  I now have the exact same problem that Bill encountered, but I don't have another box to setup NUT as the master and would like to get it up and working again in RC4 if at all possible.  To me it looks like the usbhid-ups driver is looking for the usb devices in the old location and an updated version is required.

On Sunday, July 6, 2014 10:51:48 AM UTC+10, João Cardoso wrote:

 

Install the  usbutils pckages and try 'lsusb -tv'.

[root@xxxxxx]# lsusb -tv
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=print, Driver=usblp, 12M
        |__ Port 3: Dev 6, If 0, Class=HID, Driver=usbhid, 1.5M
        |__ Port 4: Dev 5, If 0, Class=hub, Driver=hub/4p, 480M
 
I have tried nut-2.4.1-1 via ffp (previously working on Alt-F RC3):

[root@xxxxxx]# /ffp/bin/usbhid-ups -a APC_UPS
Network UPS Tools - Generic HID driver 0.34 (2.4.1)
USB communication driver 0.31
usb_set_debug: Setting debugging level to 2 (on)

usb_os_init: No USB VFS found, is it mounted?
USB error: couldn't opendir(): No such file or directory

No matching HID UPS found

and also installing nuts 2.6.1-2 via Alt-F:

[root@xxxxxx]# /usr/bin/usbhid-ups -a APC_UPS
Network UPS Tools - Generic HID driver 0.35 (2.6.1)
USB communication driver 0.31
usb_set_debug: Setting debugging level to 2 (on)

usb_os_init: No USB VFS found, is it mounted?
USB error: couldn't opendir(): No such file or directory

No matching HID UPS found

Output from dmesg when unplugging and replugging the UPS usb:

usb 1-1.3: USB disconnect, device number 6
usb 1-1.3: new low-speed USB device number 7 using orion-ehci
hid-generic 0003:051D:0002.0003: device has no listeners, quitting

If you don't have any more suggestions, is it safe to flash back to Alt-F RC3 after installing RC4?

Thanks,
Glenn.

[João Cardoso]

On Monday, September 1, 2014 11:49:17 PM UTC+1, Glenn Farrell wrote:

Yesterday I upgraded my DNS-323-B1 to Alt-F RC4.  I now have the exact same problem that Bill encountered, but I don't have another box to setup NUT as the master and would like to get it up and working again in RC4 if at all possible.  To me it looks like the usbhid-ups driver is looking for the usb devices in the old location and an updated version is required.

On Sunday, July 6, 2014 10:51:48 AM UTC+10, João Cardoso wrote:

 

Install the  usbutils pckages and try 'lsusb -tv'.

[root@xxxxxx]# lsusb -tv
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=print, Driver=usblp, 12M
        |__ Port 3: Dev 6, If 0, Class=HID, Driver=usbhid, 1.5M
        |__ Port 4: Dev 5, If 0, Class=hub, Driver=hub/4p, 480M

Any difference with and without the UPS connected? 

Does the UPS appears there? 

What does 'dmesg | tail' displays right after plugging the UPS?

What are the contents of /dev? Any difference with and without the UPS plugged?

You could try to add -DDD to the 'usbhid-ups' command

You could also try to run 'strace' on 'usbhid-ups'

I could try to compile a newer version of libusb. As I told above, /proc/usb (usbfs) has been deprecated in linux-3.x, and probably some tunning is needed.

 
I have tried nut-2.4.1-1 via ffp (previously working on Alt-F RC3):

[root@xxxxxx]# /ffp/bin/usbhid-ups -a APC_UPS
Network UPS Tools - Generic HID driver 0.34 (2.4.1)
USB communication driver 0.31
usb_set_debug: Setting debugging level to 2 (on)

usb_os_init: No USB VFS found, is it mounted?
USB error: couldn't opendir(): No such file or directory

No matching HID UPS found

and also installing nuts 2.6.1-2 via Alt-F:

[root@xxxxxx]# /usr/bin/usbhid-ups -a APC_UPS
Network UPS Tools - Generic HID driver 0.35 (2.6.1)
USB communication driver 0.31
usb_set_debug: Setting debugging level to 2 (on)

usb_os_init: No USB VFS found, is it mounted?
USB error: couldn't opendir(): No such file or directory

No matching HID UPS found

If you don't have any more suggestions,

Not really. It's a kernel, usbfs issue.

I have to test other USB aware packages, such as CUPS and SANE, for which I own the needed hardware.

 

is it safe to flash back to Alt-F RC3 after installing RC4?

It is safe, but many Alt-F packages will not work (packages which creates/require a specific user/group)

Thanks,
Glenn.

[Glenn Farrell]

João, thanks for your speedy reply and excellent level of support for Alt-F :)

On Tuesday, September 2, 2014 11:53:46 AM UTC+10, João Cardoso wrote:

Any difference with and without the UPS connected? 

Yes, output with UPS disconnected:

[root@xxxxxx]# lsusb -tv

usb_set_debug: Setting debugging level to 2 (on)
usb_os_init: No USB VFS found, is it mounted?
USB error: couldn't opendir(): No such file or directory

1-1.1:1.0: No such file or directory

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 480M

        |__ Port 1: Dev 3, If 0, Class=print, Driver=, 12M

        |__ Port 4: Dev 5, If 0, Class=hub, Driver=hub/4p, 480M

Output with UPS connected:
 

[root@xxxxxx]# lsusb -tv

usb_set_debug: Setting debugging level to 2 (on)
usb_os_init: No USB VFS found, is it mounted?
USB error: couldn't opendir(): No such file or directory

1-1.1:1.0: No such file or directory

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 480M

        |__ Port 1: Dev 3, If 0, Class=print, Driver=, 12M
        |__ Port 3: Dev 8, If 0, Class=HID, Driver=usbhid, 1.5M

        |__ Port 4: Dev 5, If 0, Class=hub, Driver=hub/4p, 480M

Does the UPS appears there? 

Yes
 

What does 'dmesg | tail' displays right after plugging the UPS?

Output from dmesg | tail before/after unplugging UPS:

[root@xxxxxx]# dmesg | tail
hid-generic 0003:051D:0002.0002: device has no listeners, quitting
usbcore: deregistering interface driver usblp
usblp0: removed

usb 1-1.3: USB disconnect, device number 6
usb 1-1.3: new low-speed USB device number 7 using orion-ehci
hid-generic 0003:051D:0002.0003: device has no listeners, quitting

usb 1-1.3: USB disconnect, device number 7
usb 1-1.3: new low-speed USB device number 8 using orion-ehci
hid-generic 0003:051D:0002.0004: device has no listeners, quitting
usb 1-1.3: USB disconnect, device number 8

Output from dmesg | tail right after plugging in the UPS:

[root@xxxxxx]# dmesg | tail
usblp0: removed

usb 1-1.3: USB disconnect, device number 6
usb 1-1.3: new low-speed USB device number 7 using orion-ehci
hid-generic 0003:051D:0002.0003: device has no listeners, quitting

usb 1-1.3: USB disconnect, device number 7
usb 1-1.3: new low-speed USB device number 8 using orion-ehci
hid-generic 0003:051D:0002.0004: device has no listeners, quitting
usb 1-1.3: USB disconnect, device number 8
usb 1-1.3: new low-speed USB device number 9 using orion-ehci
hid-generic 0003:051D:0002.0005: device has no listeners, quitting

 

What are the contents of /dev? Any difference with and without the UPS plugged?

 

I can give you a full listing if you need it, the differences are highlighted below (file 1-1.3 is removed when UPS is unplugged, timestamp of mdev.seq changes):

[root@xxxxxx]# ls -ltr > /tmp/a.out

***  Unplug UPS  ***

[root@xxxxxx]# ls -ltr > /tmp/b.out
[root@xxxxxx]# diff /tmp/a.out /tmp/b.out
--- /tmp/a.out
+++ /tmp/b.out
@@ -72,5 +72,4 @@
 crw-rw----    1 root     root       13,  64 Sep  1 22:59 event0
 crw-rw----    1 root     root       10,  63 Sep  1 22:59 cpu_dma_latency
 srw-rw-rw-    1 root     root             0 Sep  1 22:59 log
-crw-rw----    1 root     root      189,  10 Sep  2 14:59 1-1.3
--rw-r--r--    1 root     root             5 Sep  2 15:20 mdev.seq
+-rw-r--r--    1 root     root             5 Sep  2 15:21 mdev.seq

You could try to add -DDD to the 'usbhid-ups' command

[root@xxxxxx]# /usr/bin/usbhid-ups -a APC_UPS -DDD

Network UPS Tools - Generic HID driver 0.35 (2.6.1)
USB communication driver 0.31

   0.000000    debug level is '3'
   0.009053    upsdrv_initups...

usb_set_debug: Setting debugging level to 2 (on)
usb_os_init: No USB VFS found, is it mounted?
USB error: couldn't opendir(): No such file or directory

   0.015330    No appropriate HID device found
   0.016751    No matching HID UPS found

 

You could also try to run 'strace' on 'usbhid-ups'

See attached strace_alt-f.txt and stract_ffp.txt for output.

I could try to compile a newer version of libusb. As I told above, /proc/usb (usbfs) has been deprecated in linux-3.x, and probably some tunning is needed.

 That would be much appreciated.

[João Cardoso]

On Tuesday, September 2, 2014 6:44:14 AM UTC+1, Glenn Farrell wrote:

João, thanks for your speedy reply and excellent level of support for Alt-F :)

On Tuesday, September 2, 2014 11:53:46 AM UTC+10, João Cardoso wrote:

Any difference with and without the UPS connected? 

(...) 

Output with UPS connected:
 

[root@xxxxxx]# lsusb -tv

usb_set_debug: Setting debugging level to 2 (on)
usb_os_init: No USB VFS found, is it mounted?
USB error: couldn't opendir(): No such file or directory

1-1.1:1.0: No such file or directory

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 480M

        |__ Port 1: Dev 3, If 0, Class=print, Driver=, 12M
        |__ Port 3: Dev 8, If 0, Class=HID, Driver=usbhid, 1.5M

The UPS, USB bus 1, port 1, device 3 (1.1-3). It might change on plugging/unplugging, always check it before doing any tests.

 

(...)

Output from dmesg | tail right after plugging in the UPS:

[root@xxxxxx]# dmesg | tail
usblp0: removed
usb 1-1.3: USB disconnect, device number 6
usb 1-1.3: new low-speed USB device number 7 using orion-ehci
hid-generic 0003:051D:0002.0003: device has no listeners, quitting
usb 1-1.3: USB disconnect, device number 7
usb 1-1.3: new low-speed USB device number 8 using orion-ehci
hid-generic 0003:051D:0002.0004: device has no listeners, quitting
usb 1-1.3: USB disconnect, device number 8
usb 1-1.3: new low-speed USB device number 9 using orion-ehci
hid-generic 0003:051D:0002.0005: device has no listeners, quitting

What is upsetting me is the  "device has no listeners, quitting" message

 

What are the contents of /dev? Any difference with and without the UPS plugged?

 

(...)

 

-crw-rw----    1 root     root      189,  10 Sep  2 14:59 1-1.3

The created device node /dev/1-1.3. It a major number of 189, a minor of 10. The 1-1.3 name refers to the USB bus, port, device. That can change. 

 

You could also try to run 'strace' on 'usbhid-ups'

(...)

 

open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOENT (No such file or directory)
open("/proc/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOENT (No such file or directory)

The upshid-ups program is trying (using libusb?) to open /dev/bus/usb which doesn't exists.

(then it tries to open /proc/bus/usb, which is deprecated in linux-3.x and doesn't exists)

Then probably it will scan all device nodes there and try to identify them.

But it might follow other strategy. On my system, /dev/bus/usb has subdirectories, organized by USB bus, and the device nodes are named after the USB device.

assuming that 1-1.3 is the device node, as above. Adapt to the current situation, as it can change

A-Taking the easy route:

mkdir -p /dev/bus/usb # create /dev/bus/usb

ln -sf /dev/1-1.3  /dev/bus/usb/foobar # create a link to the device node where it expects to find it. Ignoring the name -- might fail

Now, try running upshid-ups, and if it doesn't work, 

B-A more principled approach:

mkdir -p /dev/bus/usb/001 # create /dev/bus/usb/001

ln -sf /dev/1-1.3  /dev/bus/usb/001/003 # using bus/device instead

Now, try running upshid-ups, and if it doesn't work, more research is needed.

I also need the content of /var/log/hot.log, with the USB attached. That is to try to automate the device node creation, not requiring manual intervention (if the above works)

Worked? which one A or B? both worked? Please post strace output for each case.

[Glenn Farrell]

On Wednesday, September 3, 2014 8:41:24 AM UTC+10, João Cardoso wrote:

What is upsetting me is the  "device has no listeners, quitting" message

That makes two of us!!

 

The upshid-ups program is trying (using libusb?) to open /dev/bus/usb which doesn't exists.

(then it tries to open /proc/bus/usb, which is deprecated in linux-3.x and doesn't exists)

Then probably it will scan all device nodes there and try to identify them.

But it might follow other strategy. On my system, /dev/bus/usb has subdirectories, organized by USB bus, and the device nodes are named after the USB device.

assuming that 1-1.3 is the device node, as above. Adapt to the current situation, as it can change

A-Taking the easy route:

mkdir -p /dev/bus/usb # create /dev/bus/usb

ln -sf /dev/1-1.3  /dev/bus/usb/foobar # create a link to the device node where it expects to find it. Ignoring the name -- might fail

Now, try running upshid-ups, and if it doesn't work, 

This method doesn't work.
 

B-A more principled approach:

mkdir -p /dev/bus/usb/001 # create /dev/bus/usb/001

ln -sf /dev/1-1.3  /dev/bus/usb/001/003 # using bus/device instead

Now, try running upshid-ups, and if it doesn't work, more research is needed.

This method works!! :D
 

I also need the content of /var/log/hot.log, with the USB attached. That is to try to automate the device node creation, not requiring manual intervention (if the above works)

See attached hot.log

 

Worked? which one A or B? both worked? Please post strace output for each case.

Only B worked.

[João Cardoso]

On Wednesday, September 3, 2014 1:36:53 PM UTC+1, Glenn Farrell wrote:

On Wednesday, September 3, 2014 8:41:24 AM UTC+10, João Cardoso wrote:

(...)

 

B-A more principled approach:

mkdir -p /dev/bus/usb/001 # create /dev/bus/usb/001

ln -sf /dev/1-1.3  /dev/bus/usb/001/003 # using bus/device instead

Now, try running upshid-ups, and if it doesn't work, more research is needed.

This method works!! :D

Good!

Now, to automate the device creation/removal on USB plug/unplug, please do:

-stop all NUT processes

-unplug the UPS USB connector from the box

-remove all created device node using 'rm -rf /dev/bus'

-apply the mdev.patch using 'patch -p0 -i /path/to/mdev.patch'

-plug the UPS USB connector into th box

-verify that /dev/bus/usb/BBB/DDD exists and is a character device using 'ls -lR /dev/bus'

-start the NUT processes (please use the Alt-F binaries, not the ffp)

On USB unplugging the device node should be removed

Worked?

PS-please attach logs instead of using them inline, it preserves formating and are easier to read

PS-2: The patch will survive a reboot (as you have Alt-F packages installed).

However, it will not be active at boot time until the Alt-F on disk folder is detected, so you might have to plug/unplug the USB connector.

A better alternative is to create a NUT initscript, and it will only be executed after the Alt-F folder being detected, and the device node can then be programatically fixed.

[Glenn Farrell]

On Thursday, September 4, 2014 7:10:55 AM UTC+10, João Cardoso wrote:

On Wednesday, September 3, 2014 1:36:53 PM UTC+1, Glenn Farrell wrote:

On Wednesday, September 3, 2014 8:41:24 AM UTC+10, João Cardoso wrote:

(...)

 

B-A more principled approach:

mkdir -p /dev/bus/usb/001 # create /dev/bus/usb/001

ln -sf /dev/1-1.3  /dev/bus/usb/001/003 # using bus/device instead

Now, try running upshid-ups, and if it doesn't work, more research is needed.

This method works!! :D

Good!

Now, to automate the device creation/removal on USB plug/unplug, please do:

-stop all NUT processes

-unplug the UPS USB connector from the box

-remove all created device node using 'rm -rf /dev/bus'

-apply the mdev.patch using 'patch -p0 -i /path/to/mdev.patch'

-plug the UPS USB connector into th box

-verify that /dev/bus/usb/BBB/DDD exists and is a character device using 'ls -lR /dev/bus'

-start the NUT processes (please use the Alt-F binaries, not the ffp)

On USB unplugging the device node should be removed

Worked?

Yes, this worked.  I changed the permissions to 666 as I am not running NUT as root.
 

PS-please attach logs instead of using them inline, it preserves formating and are easier to read

Sorry about that, I've cleaned up my previous posts to allow for easier reading.

 

PS-2: The patch will survive a reboot (as you have Alt-F packages installed).

However, it will not be active at boot time until the Alt-F on disk folder is detected, so you might have to plug/unplug the USB connector.

Yes, I need to unplug/plug the USB connector to create the /dev/bus/usb structure after a reboot.

A better alternative is to create a NUT initscript, and it will only be executed after the Alt-F folder being detected, and the device node can then be programmatically fixed.

 
I already have scripts (start|stop|restart|status) for NUT.  However, without the /dev/bus/usb structure at reboot NUT will not start automatically.  So, for now I can simply unplug/plug the USB and run the NUT script manually.

[João Cardoso]

On Thursday, September 4, 2014 2:52:32 AM UTC+1, Glenn Farrell wrote:

On Thursday, September 4, 2014 7:10:55 AM UTC+10, João Cardoso wrote:

On Wednesday, September 3, 2014 1:36:53 PM UTC+1, Glenn Farrell wrote:

On Wednesday, September 3, 2014 8:41:24 AM UTC+10, João Cardoso wrote:

(...)

 

B-A more principled approach:

mkdir -p /dev/bus/usb/001 # create /dev/bus/usb/001

ln -sf /dev/1-1.3  /dev/bus/usb/001/003 # using bus/device instead

Now, try running upshid-ups, and if it doesn't work, more research is needed.

This method works!! :D

Good!

Now, to automate the device creation/removal on USB plug/unplug, please do:

-stop all NUT processes

-unplug the UPS USB connector from the box

-remove all created device node using 'rm -rf /dev/bus'

-apply the mdev.patch using 'patch -p0 -i /path/to/mdev.patch'

-plug the UPS USB connector into th box

-verify that /dev/bus/usb/BBB/DDD exists and is a character device using 'ls -lR /dev/bus'

-start the NUT processes (please use the Alt-F binaries, not the ffp)

On USB unplugging the device node should be removed

Worked?

Yes, this worked.  I changed the permissions to 666 as I am not running NUT as root.

The package install script adds group "nut", perhaps using "root:nut" instead of "0:0" in mdev.conf?

Do you mind attaching a USB hub and simultaneously plugging some USB disk, pen or mouse? I'm looking for possible negative side effects.

 

PS-please attach logs instead of using them inline, it preserves formating and are easier to read

Sorry about that, I've cleaned up my previous posts to allow for easier reading.

 

PS-2: The patch will survive a reboot (as you have Alt-F packages installed).

However, it will not be active at boot time until the Alt-F on disk folder is detected, so you might have to plug/unplug the USB connector.

Yes, I need to unplug/plug the USB connector to create the /dev/bus/usb structure after a reboot.

A better alternative is to create a NUT initscript, and it will only be executed after the Alt-F folder being detected, and the device node can then be programmatically fixed.

 
I already have scripts (start|stop|restart|status) for NUT.

Do you mind sharing it? I could add it to the package.

What are the minimum requirements for a NUT webUI? Do you have any suggestion? Using the KISS Alt-F approach :-)

 

  However, without the /dev/bus/usb structure at reboot NUT will not start automatically.  So, for now I can simply unplug/plug the USB and run the NUT script manually.

Yes, until a new Alt-F release.

[Glenn Farrell]

On Friday, September 5, 2014 8:18:52 AM UTC+10, João Cardoso wrote:

The package install script adds group "nut", perhaps using "root:nut" instead of "0:0" in mdev.conf?

Do you mind attaching a USB hub and simultaneously plugging some USB disk, pen or mouse? I'm looking for possible negative side effects.

I have a 7 Port USB Hub attached that always has a USB Serial Printer cable and the UPS data cable attached.  For testing purposes, I filled the rest of the ports with flash drives and an optical mouse that I had lying around.  With "root:nut" instead of "0:0" I was able to create, read, write, and delete a test file on one of the flash drives and did not have any permission issues reading/writing/deleting the test file on Mac OS X.  Re-inserting the flash drive the permissions came up the same as all other files.  Below are the results of lsusb and the /dev/bus/ directory location:

[root@xxxxxx]# lsusb
Bus 001 Device 056: ID 0930:6544 Toshiba Corp. Kingston DataTraveler 2.0 Stick (2GB)
Bus 001 Device 055: ID 13fe:1a21 Kingston Technology Company Inc.
Bus 001 Device 052: ID 058f:6387 Alcor Micro Corp. Transcend JetFlash Flash Drive
Bus 001 Device 050: ID 0781:5567 SanDisk Corp.
Bus 001 Device 049: ID 05ac:0302 Apple, Inc. Optical Mouse [Fujitsu]
Bus 001 Device 048: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 001 Device 047: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 045: ID 067b:2305 Prolific Technology, Inc. PL2305 Parallel Port
Bus 001 Device 044: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB

[root@xxxxxx]# lsusb -tv

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M

    |__ Port 1: Dev 44, If 0, Class=hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 52, If 0, Class=stor., Driver=usb-storage, 480M
        |__ Port 2: Dev 45, If 0, Class=print, Driver=usblp, 12M
        |__ Port 3: Dev 55, If 0, Class=stor., Driver=usb-storage, 480M
        |__ Port 4: Dev 47, If 0, Class=hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 48, If 0, Class=HID, Driver=usbfs, 1.5M
            |__ Port 2: Dev 49, If 0, Class=HID, Driver=usbhid, 1.5M
            |__ Port 3: Dev 50, If 0, Class=stor., Driver=usb-storage, 480M
            |__ Port 4: Dev 56, If 0, Class=stor., Driver=usb-storage, 480M

[root@xxxxxx]# ls -FlatR /dev/bus/
/dev/bus/:
total 0
drwxr-xr-x    4 root     root          1860 Sep  7 07:40 ../
drwxrwxrwx    3 root     root            60 Sep  5 17:42 ./
drwxrwxrwx    3 root     root            60 Sep  5 17:42 usb/

/dev/bus/usb:
total 0
drwxr-xr-x    2 root     root           220 Sep  7 07:40 001/
drwxrwxrwx    3 root     root            60 Sep  5 17:42 ./
drwxrwxrwx    3 root     root            60 Sep  5 17:42 ../

/dev/bus/usb/001:
total 0
drwxr-xr-x    2 root     root           220 Sep  7 07:40 ./
crw-rw----    1 root     nut       189,  54 Sep  7 07:40 055
crw-rw----    1 root     nut       189,  55 Sep  7 07:40 056
crw-rw----    1 root     nut       189,  49 Sep  6 08:29 050
crw-rw----    1 root     nut       189,  51 Sep  6 08:29 052
crw-rw----    1 root     nut       189,  48 Sep  6 08:29 049
crw-rw----    1 root     nut       189,  47 Sep  6 08:29 048
crw-rw----    1 root     nut       189,  46 Sep  6 08:29 047
crw-rw----    1 root     nut       189,  43 Sep  6 08:29 044
crw-rw----    1 root     nut       189,  44 Sep  6 08:29 045
drwxrwxrwx    3 root     root            60 Sep  5 17:42 ../
 

 

I already have scripts (start|stop|restart|status) for NUT.

Do you mind sharing it? I could add it to the package.

Attached is a test script I created for FFP (pointing to Alt-F binaries), but it can easily be adapted for Alt-F.
 

What are the minimum requirements for a NUT webUI? Do you have any suggestion? Using the KISS Alt-F approach :-)

NUT has CGI programs built in (assuming it was compiled to include them) and these could be used for a webUI.

I just successfully tested the NUT CGI by creating a shortcut on the Alt-F Home Page using Shortcuts... -> Add, then modified the shortcut in /usr/www/cgi-bin/Shortcuts.men to NUT UPS Stats|/cgi-bin/upsstats.cgi, created a link to the FFP NUT 2.4.1 CGI script ln -sf /ffp/lib/nut/cgi-bin/upsstats.cgi /usr/www/cgi-bin/upsstats.cgi (couldn't find an Alt-F version), copied example scripts (hosts.conf, upsset.conf, upsstats.html, upsstats-single.html) from /ffp/etc/examples/nut to /ffp/etc/, and simply added a MONITOR entry to the hosts.conf file for my UPS.

 

[Andrey Suprun]

Now, to automate the device creation/removal on USB plug/unplug, please do:

-stop all NUT processes

-unplug the UPS USB connector from the box

-remove all created device node using 'rm -rf /dev/bus'

-apply the mdev.patch using 'patch -p0 -i /path/to/mdev.patch'

-plug the UPS USB connector into th box

-verify that /dev/bus/usb/BBB/DDD exists and is a character device using 'ls -lR /dev/bus'

-start the NUT processes (please use the Alt-F binaries, not the ffp)

I have done all the above but when I start NUT via web GUI I get this:

Network UPS Tools - Generic HID driver 0.35 (2.6.1)
USB communication driver 0.31

No matching HID UPS found

Driver failed to start (exit status=1)

Network UPS Tools - UPS driver controller 2.6.1

'ls -lR /dev/bus' gives me this:

/dev/bus:
total 0
drwxrwxrwx    3 root     root            60 Dec 26 22:03 usb

/dev/bus/usb:
total 0
drwxr-xr-x    2 root     root            60 Dec 26 22:03 001

/dev/bus/usb/001:
total 0
crw-rw----    1 root     root      189,   9 Dec 26 22:03 010

My D-Link DNS-323 Rev B1 running Alt-F 0.1RC4 and I'm trying to connect APC Back-Ups CS 500 via USB.
Please help me.

[Frank van den Bosch]

Op donderdag 4 september 2014 03:52:32 UTC+2 schreef Glenn Farrell:

 

PS-2: The patch will survive a reboot (as you have Alt-F packages installed).

However, it will not be active at boot time until the Alt-F on disk folder is detected, so you might have to plug/unplug the USB connector.

Yes, I need to unplug/plug the USB connector to create the /dev/bus/usb structure after a reboot.

I have applied the patch with succes, the /dev/bus structure is created when connecting the UPS.

Is there any alternative to do this automatically for now without the need to unplug/plug the USB connection with the UPS (i.e. a script that checks for changes)?  

A better alternative is to create a NUT initscript, and it will only be executed after the Alt-F folder being detected, and the device node can then be programmatically fixed.

 
I already have scripts (start|stop|restart|status) for NUT.  However, without the /dev/bus/usb structure at reboot NUT will not start automatically.  So, for now I can simply unplug/plug the USB and run the NUT script manually.

The rcnut script was unfortunately not working for me. I need to run the driver and the deamon as root. I already made the user/group (upsmon/nut) as suggested and changed the permissions as described. All other tries were unsuccesfull. Only by running the next two commands by hand (with SSH) the UPS is found and then I can read the values by using the GUI (by clicking on configure):

• /usr/lib/nut/drivers/upsdrvctl -u root start
• /usr/sbin/upsd -u root

To help others out. The driver is working if you see the following response or similar:

Network UPS Tools - UPS driver controller 2.6.1

Network UPS Tools - Generic HID driver 0.35 (2.6.1)

USB communication driver 0.31

Using subdriver: APC HID 0.95

The deamon is working if you see the following response or similar:

Network UPS Tools upsd 2.6.1

listening on 127.0.0.1 port 3493

Connected to UPS [APC_UPS]: usbhid-ups-APC_UPS

With "upsc [name of UPS]@localhost" I can also read the UPS values. :-)

Any idea's what I must change to get the commands working without the need to start them as root?

[Frank van den Bosch]

Op dinsdag 5 mei 2015 02:26:59 UTC+2 schreef Frank van den Bosch:

I have applied the patch with succes, the /dev/bus structure is created when connecting the UPS.

Is there any alternative to do this automatically for now without the need to unplug/plug the USB connection with the UPS (i.e. a script that checks for changes)?  

I just ran into this page: https://enc.com.au/2014/02/14/resetting-usb-devices/

I'll try it and report back over here :-) 

Update 1: No luck so far, the script uses "/sys/bus/pci/drivers/ehci_hcd" and that does not exist. Wat does exist is "/sys/bus/pci/drivers/ehci-pci" but the devices don't show op there so the mount/umount of the script does not work.

Update 2: Did some further testing with the UPS. At the moment the NAS does not switch off when the UPS reaches the battery.charge.low value. The UPS does set the LB status:

    [DNS-323]# upsc APC_UPS@localhost | grep "status"

    ups.beeper.status: enabled

    ups.status: OL CHRG LB

However the NAS does not shutdown, while /etc/nut/upsmon.conf does have a valid SHUTDOWNCMD "poweroff" (poweroff works on the command line). Will look into that later.

[João Cardoso]

That depends on your linux knowledge. The script that starts and stops the servers is  /etc/init.d/S22nut (shortcut 'rcnut')  Can you read and understand it?

NUT is a powerful and complex system, fortunately very well documented, use the official documents to understand it:

The manual pages: http://www.networkupstools.org/docs/man/

The user manual: http://www.networkupstools.org/docs/user-manual.chunked/index.html

If you read the initscript you will understand that there are three main modes of operation. What's your? And what are you current configuration files values? The initscript tries to parse them to determine which mode you intend to run and what services to start and how.

Currently, 'upsd' is launched when in "standalone" or "netserver" mode as user ups:nut around line 97:

# should upsd be started as root? it will drop privileges

if ! res=$(RC_PIDFILE=$RUN_DIR/upsd.pid start upsd --chuid $RC_USER:$RC_GROUP); then

   $DRV_DIR/upsdrvctl stop >& /dev/null

 This shouldn't be necessary, as the UPSDRVCTL manual page says:

-u username

If starting a driver, this value will direct it to setuid(2) to the user id associated with username.

If the driver is started as root without specifying this value, it will use the username that was compiled into the binary. This defaults to "nobody", and is far from ideal.

This may be set in ups.conf with "user" in the global section.

But the UPSD manual pages says:

-u user

Switch to user user after startup if started as root. This overrides whatever you may have compiled in with configure --with-user.

The binaries was compiled to use user 'ups'  and group 'nut'.

 

So you might remove the red-highlighted code segment above (it will start as root and drop privileges to ups:nut.

The root of the issue must be accessing the device nodes, which by default are created owned by root:nut, what does 'ls -lR /dev/bus' displays?

The /dev/bus hierarchy is set by 'mdev', launched by the kernel when the UPS is USb attached;  '/etc/mdev.conf' controls device permissions:

$DEVNAME=bus/usb/([0-9]+)/([0-9]+) 0:0 660 =bus/usb/%1/%2

and the /dev/usb device files will be owned by root:root and will have group read/write access.

At device creation one does not know what the device is intended for, so we can't create devices with the appropriate ownership and permissions.

-> So the real solution might be to add user 'ups' to the 'root' group. Or create the device nodes for group sys or disk (0:3 or 0:6) and make the ups a member of these groups instead. Not sure will be the *right* solution. 'right' does not means "works for me", it has to work for everybody else, namely allowing the usage of a USB hub and allowing USHB pens, disks and other peripheral to be used at the same time as 'nut'. 

Please report back you solution, and I'm sorry for being so picky, its my "trade mark" :-(

PS-I don't have a UPS myself and the nut init script was written entirely based on the excellent UPSMON documentation and manual pages. Its reasoning might be wrong!

[Glenn Farrell]

Hi Frank,

The UPS will only shutdown if you give it the command to shutdown in your scripts.  I have the following check in my stop script:

    # Check for POWERDOWNFLAG (UPS on battery shutdown)
    if (test -f /etc/killpower)
    then
        echo "Killing the UPS Power, bye!"
        /ffp/bin/upsdrvctl shutdown
    fi

I have also changed the default "ups.delay.shutdown" variable in my start script to avoid a shutdown race:

    # Change ups.delay.shutdown variable from 20 to 60 (allow time before shutdown of UPS)
    /ffp/bin/upsrw -s ups.delay.shutdown=60 -u <user> -p <password> <ups@server>

My upsmon.conf has the SHUTDOWNCMD and POWERDOWNFLAG as:

SHUTDOWNCMD "/sbin/poweroff"
POWERDOWNFLAG /etc/killpower

Hope this helps.

[Frank van den Bosch]

Thanks for the usefull information. 

I thought that the SHUTDOWNCMD in psmon.conf was enough. As soon as I have a couple of free hours again I will try to further improve my setup with this information and report back over here.

Op donderdag 7 mei 2015 07:49:23 UTC+2 schreef Glenn Farrell:

[Frank van den Bosch]

Thanks for the usefull information. 

My Linux knowledge is quite basic, but I can understand most parts of /etc/init.d/S22nut. I actually already tried to change it, but unsuccesfull so far ;-)

As soon as I have a couple of free hours again I will try to further improve my setup with this information and report back over here. 

Op dinsdag 5 mei 2015 16:51:25 UTC+2 schreef João Cardoso:

[Tom Schmidt]

I know that this is an old thread.  I recently added a APC UPS behind my DNS-327L Alt-F 1.0 NAS (and some other hardware) that I likewise am trying to using NUT on.  After a reboot, the USB connection to the UPS is not seen by NUT unless I unplug the USB cable and plug it back into the DNS-327L.  I am using the NUT package from Entware-ng.

After a reboot, lsusb does see it, but NUT does not:

[root@nas1]# lsusb -tv
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=HID, Driver=usbhid, 1.5M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M

[root@nas1]# upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic HID driver 0.47 (2.8.0)
USB communication driver (libusb 1.0) 0.43
kill: No such process
Driver exited abnormally
Network UPS Tools - Generic HID driver 0.47 (2.8.0)
USB communication driver (libusb 1.0) 0.43
kill: No such process
Driver exited abnormally
Network UPS Tools - Generic HID driver 0.47 (2.8.0)
USB communication driver (libusb 1.0) 0.43
kill: No such process
Driver exited abnormally

[root@nas1]# upsd -u root
Network UPS Tools upsd 2.8.0
kill: No such process

listening on 127.0.0.1 port 3493

not listening on ::1 port 3493
/opt/var/run is world readable
Can't connect to UPS [apcups] (usbhid-ups-apcups): Connection refused

[root@nas1]# ls /dev/[0-9]*
ls: /dev/[0-9]*: No such file or directory
[root@nas1]# ls /proc/bus
input  pci

Unplug the USB and plug it back in and repeat above commands:

[root@nas1]# lsusb -tv
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
    |__ Port 1: Dev 5, If 0, Class=HID, Driver=usbhid, 1.5M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M

[root@nas1]# upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic HID driver 0.47 (2.8.0)
USB communication driver (libusb 1.0) 0.43
kill: No such process
Using subdriver: APC HID 0.98

[root@nas1]# upsd -u root
Network UPS Tools upsd 2.8.0
fopen /opt/var/run/upsd.pid: No such file or directory
Could not find PID file '/opt/var/run/upsd.pid' to see if previous upsd instance is already running!

listening on 127.0.0.1 port 3493

not listening on ::1 port 3493
/opt/var/run is world readable
Connected to UPS [apcups]: usbhid-ups-apcups
[root@nas1]# ls /proc/bus
input  pci
[root@nas1]# ls /dev/[0-9]*
ls: /dev/[0-9]*: No such file or directory
[root@nas1]# upsc apcups
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.date: not set
battery.mfr.date: 2024/11/06
battery.runtime: 1380
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 13.6
battery.voltage.nominal: 12.0
device.mfr: APC
device.model: Back-UPS ES 550
device.serial: 3B1035X57732
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.version: 2.8.0
driver.version.data: APC HID 0.98
driver.version.internal: 0.47
driver.version.usb: libusb-1.0.22 (API: 0x1000106)
input.sensitivity: high
input.transfer.high: 139
input.transfer.low: 92
input.voltage: 122.0
input.voltage.nominal: 120
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: 843.K2 .D
ups.firmware.aux: K2
ups.load: 18
ups.mfr: APC
ups.mfr.date: 2010/08/29
ups.model: Back-UPS ES 550
ups.productid: 0002
ups.serial: 3B1035X57732
ups.status: OL
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.vendorid: 051d

Note that as there is no /dev entry for the USB port, nor is there a /proc/bus/usb/ directory (as expected) since I am running the 4.4.45 kernel.

Has there even been a fix for this other than to unplug and replug the USB port after the Alt-F NAS reboots?

Thanks

Tom Schmidt

Alt-F contributor, running Alt-F 1.0 on DNS-323 and DNS-327L NAS devices

[Glenn Farrell]

Hi Tom, 

Yes, it is an old thread! 

I don't know of any fix for this, but I also haven't upgraded or made any changes to my DNS-323 in a very long time (it's still going strong though).

Cheers,

Glenn.