-
-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
usbhid-ups driver: Not working on VMware Flings' ESXi ARM edition #1004
Comments
Update:
● nut-driver.service - Network UPS Tools - power device driver controller Apr 09 10:49:29 ubuntuserver02 upsdrvctl[990]: No matching HID UPS found |
Thank you for this report, unfortunately at the moment I am a bit at a loss: during the past few weeks we had several reports of issues with different generations of Raspberry Pi and various OSes and USB UPSes. So far my two main guesses were that there can be something flaky with the hardware (USB chips involved), after all low price was a hard goal, or bitness especially in older Pi generations which I think were 32-bit (and/or also OS bitness). In one report specifically there was a logged attempt to fit IIRC 256 bytes into a 255-byte buffer. In your report, the varied HID descriptors and length mismatches look fishy; given that this is a pass-through of USB into a VM on hardware family that is already implicated in other issues even bare-metal, I am currently not sure what to state so would refrain. The rest looks logical, with the NUT driver failing to start, the corresponding service fails and upsd server has no driver to talk to and represent to upsmon client. @aquette: do you have a chance to check about Eaton hardware involved? And/or with a Raspberry and varied OSes on that? |
Thank you for your answer. In my case I can report that everything works smoothly on the same Raspberry Pi 4 when installing it bare metal on a Raspberry Pi OS. It's only not working when using the Raspberry Pi 4 in an ESXi ARM virtual environment. In the meantime I have tried a couple of more virtual ARM based OS'es on the Raspberry Pi 4 ESXi ARM host, unfortunateliy without success:
Like already mentioned on a generic x86 server PC with ESXi x86 virtual environment everything works as it should in my case. |
Any news on this? |
I'll try to check from work on a real PC tomorrow (not a phone). In the meantime, could you send the debug output level 5 (-DDDDD) |
Sure. Here you are:
Network UPS Tools - Generic HID driver 0.41 (2.7.4) |
@aquette Let me know if you need anything else. Edit: Not sure if this helps but the following issue seems to be very similiar to mine: The difference compared to my issue is that in my case the issue is only occurring on ESXi ARM. On my two ESXi x64 systems, everything works fine, with the same virtual setup, as already mentioned above. |
@aquette Did you find out something about my issue? |
@aquette Tried VMware Flings' ESXi ARM Version 1.4 which was released yesterday but unfortunately still no luck. The behavior is still the same. |
sorry, had no time to check. crazy life. |
Network UPS Tools - Generic HID driver 0.41 (2.7.4) @aquette That seems not to make a big difference of the output, does it? |
You got fooled by exporting before sudoing 😉 |
@aquette Oops, got that now:
Network UPS Tools - Generic HID driver 0.41 (2.7.4) |
@aquette Did you find anything within the logs? It doesn't seem to provide much more than without |
No news on this? |
sadly, had no time to check / think more about this. and vacations tomorrow. |
@aquette That would be awesome. Just let me know in case I can provide something to help. |
Yes, plz provide the same command output, but on a working system (x86 Linux) 😉 for me to check the desc len thing |
@aquette I'm in holidays right now until the end of July without possibility for accessing the infrastructure. I will provide it when I'm back ASAP. |
@aquette Came back from holidays and my x64 ESXi host crashed somehow. Not sure when I will be able to set all up and running again. Very frustrating situation. Will you be able to do your tests anyway? |
@aquette Any news on this? Were you able to try this out? Any hope for the next nut release this is going to work? Or is it really a USB only issue of Raspberriy 4 in general? |
Looking at issue labels, Raspberries of different models were implicated in
USB issues rather often.
Recent changes to NUT master branch now include support for libusb-1.0
which might be more stable by itself than 0.1 before it - and it is a large
milestone, getting us nearer to a new release.
IIRC some reports indicated issues with interrupts on some platforms, so
`pollonly` option might help too.
…On Wed, Jan 19, 2022, 07:20 GrandmaBetty ***@***.***> wrote:
@aquette <https://github.com/aquette> Any news on this? Were you able to
try this out? Any hope for the next nut release this is going to work? Or
is it really a USB only issue of Raspberriy 4 in general?
—
Reply to this email directly, view it on GitHub
<#1004 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMPTFCZSUS5Z5LSSW773XDUWZJ3DANCNFSM42NEDM5A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Thanks for the hint. Tried the |
It seems to me that it is more of a general issue affecting devices using passthru to on ESXI. Below info is pulled from Ubuntu 20.04 server nut-scanner --usb_scanSNMP library not found. SNMP search disabled. /etc/nut/ups.conf content: Above setup has been working before on all of our servers. USB_DEBUG=3 /lib/nut/usbhid-ups -DDDDD -a eaton -u rootNetwork UPS Tools - Generic HID driver 0.41 (2.7.4) |
@Rimers Yes, I mentioned this too on both of my x86 systems when I tested it again recently. Running vSphere 7, so it's not only vSphere 6 related I guess. |
I just noticed the same Running Home Assistant OS, with the NUT addon on a VMware ESXi 7 U3d, used to work... now the driver wont start:
I think it started after updating my ESXi yesterday from 7 U1 to 7 U3d as I can see statistics from before the time I started the update procedure. |
For vendorid 0x0463 in particular seems there were "usb quirks" in some
linux kernel versions which can be related to the issue and only were
useful for some firmware versions.
Otherwise general suggestions about devfs permission (udev rules etc.)
Jim
…On Tue, May 3, 2022, 12:34 Marcel ***@***.***> wrote:
I just noticed the same
Running Home Assistant OS, with the NUT addon on a VMware ESXi 7 U3d, used
to work... now the driver wont start:
[s6-init] making user provided files available at /var/run/s6/etc...exited
0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] nut: applying...
[fix-attrs.d] nut: exited 0.
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 00-banner.sh: executing... Add-on: Network UPS Tools
Manage battery backup (UPS) devices Add-on version: 0.10.0
You are running the latest version of this add-on.
System: Home Assistant OS 7.6 (amd64 / qemux86-64)
Home Assistant Core: 2022.4.7
Home Assistant Supervisor: 2022.04.0 Please, share the above information
when looking for help
or support in, e.g., GitHub, forums or the Discord chat. [cont-init.d]
00-banner.sh: exited 0.
[cont-init.d] 01-log-level.sh: executing...
[cont-init.d] 01-log-level.sh: exited 0.
[cont-init.d] nut.sh: executing...
[12:32:59] INFO: Setting mode to netserver...
[12:32:59] INFO: Connected USB devices:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 005: ID 0403:6001 Future Technology Devices International,
Ltd FT232 Serial (UART) IC
Bus 002 Device 004: ID 0463:ffff MGE UPS Systems UPS
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
[12:32:59] INFO: Generating /etc/nut/upsd.users...
[12:32:59] INFO: Configuring user: ups
[12:32:59] INFO: Password is NOT in the Have I Been Pwned database! Nice!
[12:33:00] INFO: Configuring Device named myups...
[12:33:00] INFO: Starting the UPS drivers...
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
No matching HID UPS found
Driver failed to start (exit status=1)
Network UPS Tools - UPS driver controller 2.7.4
[cont-init.d] nut.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] 99-message.sh: executing...
Oops! Something went wrong.
We are so sorry, but something went terribly wrong when
starting or running this add-on.
Be sure to check the log above, line by line, for hints.
[cont-finish.d] 99-message.sh: exited 0.
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
—
Reply to this email directly, view it on GitHub
<#1004 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMPTFDL6FEOCLZCWJMVX2DVID6KZANCNFSM42NEDM5A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Does this also count when |
udev rules apply to NUT driver daemons that talk to HW. roots used for
other daemons are not related to that and serve other purposes (e.g.
shutdown from upsmon), note it usually forks a non-root part and that
suffices.
…On Mon, Jun 13, 2022, 09:57 Grandma-Betty ***@***.***> wrote:
Otherwise general suggestions about devfs permission (udev rules etc.)
Does this also count when RUN_AS_USER root is configured within
upsmon.conf?
—
Reply to this email directly, view it on GitHub
<#1004 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMPTFCQ3AM5ASGEWJOMBFTVO3SXFANCNFSM42NEDM5A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Thanks for clearing things up. |
I see the same issue on an Intel NUC running VMware ESXi 7 and Debian 11 with the nut-packages upgraded to testing (bookworm) as this contains nut 2.8.0 (2.8.0-5). So I've tried to setup nut with my Eaton 5P1550iR:
and
but the UPS seems to be available and recognized properly:
Can you see where this is going wrong and why I get the "[D1] nut_libusb_open get iManufacturer failed, retrying..." etc. errors? I was also thinking about setting up a new VM with debian testing so any interdependencies between stable/testing packages could be ruled out. |
@Andr3asB This is sad to read as I was really hoping to get this issue fixed with nut 2.8.0 as soon as it gets officially released for Ubuntu. |
Just wanted to confirm if it is not about a conflict with another running driver instance (e.g. the new
I do remember seeing the pattern with three retries and lack of basic entries recently, but can't well put my memory index on it... possibly during NUT for Windows experiments and some lack of low-level libUSB driver on that system. Virtualization pass-through has its quirks, but one thing to rule out is that the host system is not grabbing the device for itself (more probable for HID) and honestly is passing that through. Also check if the driver run-time user (built-in or in settings) matches what is in udev.rules (or newly udev.hwdb) file. Though that would probably manifest in explicit |
I see the same issue on EXSI 7.0 update 2.0. I create a VM with OMV 5 and passthru the USB device (Santak TG BOX 850) to the VM. I can see the device with Then I passthru the whole USB controller ( which is "Interl 200 Series/Z370 Chipset Family USB 3.0 xHCI Controller" in my case)to OMV. The NUT works fine. I believe @Rimers was right. It seems a general issue of EXSI and passthru the whole USB controller might solve the problem. |
I solved my issue by updating to ESXi 8.0 (U1) and installing a new Debian 12 server. For the setup I used this quick guide: https://justit.eu/quick-setup-network-ups-tools-nut-server-on-debian-10/ |
I can confirm it working again after updating ESXi U3g to U3o |
I was running nut server all the time without any issues inside an Ubuntu Server 20.04 VM running on a VMware ESXi 7.0 host (x86 architecture) with the "Eaton 5P650IR" UPS' USB port passed through the VM.
Since VMware has released its free ESXi ARM edition for the Raspberry Pi 4 it was obvious to me to set up a new VM to run nut server as a VM on the Raspberry Pi 4 (8GB RAM version) with the same VM settings.
I have tried all the way upside down to get this to work, unfortunately without success.
Here is what I did:
Ubuntu Server (minimal installation with just OpenSSH server installed):
Logged in with default user and did the following steps, step-by-step:
$ sudo apt-get update && sudo apt-get dist-upgrade
$ sudo reboot now
$ uname -a
(Which gives the following oputput:Linux ubuntuserver02 5.4.0-70-generic #78-Ubuntu SMP Fri Mar 19 13:29:32 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux )
$ sudo apt-get install nut
$ sudo cp /lib/udev/rules.d/62-nut-usbups.rules /etc/udev/rules.d/
Now I have configured the nut config files like this (left all settings on default but only added content):
/etc/nut/nut.conf:
MODE=standalone
/etc/nut/ups.conf:
/etc/nut/upsd.conf:
LISTEN localhost 3493
/etc/nut/upsd.users:
/etc/nut/upsmon.conf:
MONITOR ups@localhost 1 monuser 1234 master
Finally I executed the following commands:
$ sudo systemctl enable nut-monitor.service
$ sudo systemctl enable nut-server.service
$ sudo systemctl start nut-monitor.service
$ sudo systemctl start nut-server.service
$ reboot now
Now when executing the following command:
$ lsusb
It gives back the following output:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 005: ID 0463:ffff MGE UPS Systems UPS
Bus 002 Device 004: ID 0e0f:0006 VMware, Inc. Virtual Keyboard
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
When executing the following command:
$ nut-scanner
It gives back the following output:
SNMP library not found. SNMP search disabled.
Neon library not found. XML search disabled.
IPMI library not found. IPMI search disabled.
Scanning USB bus.
No start IP, skipping NUT bus (old connect method)
[nutdev1]
driver = "usbhid-ups"
port = "auto"
vendorid = "0463"
productid = "FFFF"
bus = "002"
So this indicates the UPS is definitely being recognized.
Now whenever the following command is being executed:
$ sudo systemctl status nut-server
It gives back the following error(s):
● 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 2021-01-12 15:55:01 UTC; 2min 17s ago
Process: 930 ExecStartPre=/bin/sleep 15 (code=exited, status=0/SUCCESS)
Process: 943 ExecStart=/sbin/upsd (code=exited, status=0/SUCCESS)
Main PID: 946 (upsd)
Tasks: 1 (limit: 2233)
Memory: 2.0M
CGroup: /system.slice/nut-server.service
└─946 /lib/nut/upsd
Jan 12 15:54:47 ubuntuserver systemd[1]: Starting Network UPS Tools - power devices information server...
Jan 12 15:55:01 ubuntuserver upsd[943]: fopen /run/nut/upsd.pid: No such file or directory
Jan 12 15:55:01 ubuntuserver upsd[943]: listening on localhost port 3493
Jan 12 15:55:01 ubuntuserver upsd[943]: listening on localhost port 3493
Jan 12 15:55:01 ubuntuserver upsd[943]: Can't connect to UPS [ups] (usbhid-ups-ups): No such file or directory
Jan 12 15:55:01 ubuntuserver upsd[943]: Can't connect to UPS [ups] (usbhid-ups-ups): No such file or directory
Jan 12 15:55:01 ubuntuserver upsd[946]: Startup successful
Jan 12 15:55:01 ubuntuserver systemd[1]: Started Network UPS Tools - power devices information server.
So the nut service is stuck somewhere and somehow but I was not able to figure out why.
When executing the following command as root user:
$ /lib/nut/usbhid-ups -DDD -a ups
It gives back the following output:
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
0.000000 debug level is '3'
0.002398 upsdrv_initups...
0.049019 Checking device (0463/FFFF) (002/005)
0.236934 - VendorID: 0463
0.236994 - ProductID: ffff
0.237005 - Manufacturer: unknown
0.237035 - Product: Eaton 5P
0.237045 - Serial Number: G114L21147
0.237054 - Bus: 002
0.237063 - Device release number: 0202
0.237072 Trying to match device
0.237351 Device matches
0.237500 nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0)
0.286503 HID descriptor, method 1: (9 bytes) => 09 21 10 01 21 01 22 55 08
0.286557 HID descriptor length (method 1) 2133
0.286574 HID descriptor, method 2: (9 bytes) => 09 21 10 01 21 01 22 25 04
0.286602 HID descriptor length (method 2) 1061
0.286612 Eaton device v2.02. Using full report descriptor
0.286622 Warning: two different HID descriptors retrieved (Reportlen = 2133 vs. 1061)
0.286632 HID descriptor length 2133
2.335596 Unable to get Report descriptor: Invalid or incomplete multibyte or wide character
2.335701 Checking device (0E0F/0006) (002/004)
2.335783 - VendorID: 0e0f
2.335827 - ProductID: 0006
2.335837 - Manufacturer: unknown
2.335846 - Product: unknown
2.335855 - Serial Number: unknown
2.335864 - Bus: 002
2.335873 - Device release number: 0100
2.335882 Trying to match device
2.335905 Device does not match - skipping
2.335929 Checking device (0E0F/0002) (002/003)
2.335995 - VendorID: 0e0f
2.336011 - ProductID: 0002
2.336020 - Manufacturer: unknown
2.336030 - Product: unknown
2.336039 - Serial Number: unknown
2.336048 - Bus: 002
2.336057 - Device release number: 0100
2.336066 Trying to match device
2.336082 Device does not match - skipping
2.336110 Checking device (0E0F/0003) (002/002)
2.336171 - VendorID: 0e0f
2.336190 - ProductID: 0003
2.336199 - Manufacturer: unknown
2.336209 - Product: unknown
2.336218 - Serial Number: unknown
2.336226 - Bus: 002
2.336235 - Device release number: 0102
2.336244 Trying to match device
2.336258 Device does not match - skipping
2.336283 Checking device (1D6B/0001) (002/001)
2.336461 - VendorID: 1d6b
2.336500 - ProductID: 0001
2.336510 - Manufacturer: unknown
2.336519 - Product: unknown
2.336528 - Serial Number: unknown
2.336537 - Bus: 002
2.336546 - Device release number: 0504
2.336555 Trying to match device
2.336570 Device does not match - skipping
2.336599 Checking device (1D6B/0002) (001/001)
2.337068 - VendorID: 1d6b
2.337108 - ProductID: 0002
2.337117 - Manufacturer: unknown
2.337126 - Product: unknown
2.337135 - Serial Number: unknown
2.337143 - Bus: 001
2.337152 - Device release number: 0504
2.337161 Trying to match device
2.337176 Device does not match - skipping
2.337198 No appropriate HID device found
2.337211 No matching HID UPS found
For virtual machine settings in VMware ESXi I have also tried between virtual USB2.0 and virtual USB3.1 controller and for both controllers I have tried to switch the UPS USB-connection from the Raspberry Pi's physical USB2.0 and USB3.1 ports but all combinations ended with the same behavior.
What I have also tried is to add the following line:
ExecStartPre=/bin/sleep 15
on top of the the [Service] section inside the following file:
/etc/systemd/system/multi-user.target.wants/nut-server.service
and did a system reboot but that also did not help.
I hope you can comprehend everything in this topic.
Of course -if you need more informations- I can send you all the log files you will ask for.
I have also tried the same on a CentOS ARM system but the behaviour was exactly the same.
Thank you many times for your appreciated help in advance. It would be so nice to run nut-server successfully on a ESXi ARM VM.
The text was updated successfully, but these errors were encountered: