Probleme mit apcupsd

ThoSo said:
Ob du den nut client installiert hast….
Überfliege mal das changelog.
Click to expand...
Wenn ich das richtig in Erinnerung habe, NUT und apcusvd geht mit apt nicht gleichzeitig zu installieren.

Da ich die Version von apcusvd ja icht verändert habe, es mit 6-er Kernel funktioniert und auf der selben Maschne mit 7-er Kernel nicht,
glaube ich auch nicht daran, dass es an apcusvd liegt.

Klar könnte das der Entwickler von apcusvd so fixen, das es auch mit dem 7-er Kernel funktioniert, abe ehe das gemacht ist und in Debian und in Proxmox eingepflegt ist, lebe ich sicherlich nicht mehr.
 
Ich habe nun mal eine Kiste neu gestartet, jetzt Kernel 7.0.3.
Bisher keinerlei Auffäliigkeiten.

Ein Aufruf von:
Code: 
root@pve:~# apcaccess status
APC      : 001,027,0648
DATE     : 2026-05-03 20:27:22 +0200
HOSTNAME : pve
VERSION  : 3.14.14 (31 May 2016) debian
UPSNAME  : pve
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2026-05-03 20:00:11 +0200
MODEL    : Smart-UPS 750
STATUS   : ONLINE
BCHARGE  : 100.0 Percent
TIMELEFT : 52.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
ALARMDEL : 30 Seconds
BATTV    : 27.0 Volts
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
STATFLAG : 0x05000008
MANDATE  : 2014-10-11
SERIALNO : AS1441133727
NOMBATTV : 24.0 Volts
FIRMWARE : UPS 09.2 / ID=18
END APC  : 2026-05-03 20:27:22 +0200
root@pve:~# uname -a
Linux pve 7.0.3
liefert aber sogar die Firmwareversion (s.o.). Bei dir aber nicht.
Womöglich ist die APC-Firmware der Übeltäter?
Ich werde es weiter beobachten und auf alle Fälle weiter über Vorfälle aus Lampukistan berichten.
 
Last edited:
TErxleben said:
Ich werde es weiter beobachten und auf alle Fälle weiter über Vorfälle aus Lampukistan berichten.
Click to expand...
Danke.

TErxleben said:
liefert aber sogar die Firmwareversion (s.o.). Bei dir aber nicht.
Click to expand...
Keine Ahnung wie ich an die FW Version komme.
Ich habe aber auch nichts gefunden ob und wie man diese aktualisieren kann.
Ich werde dazu mal bei Schneider anklopfen.

Es gibt noch eine weitere Möglichkeit wie es zum Fehler kommen könnte, die USB Schnittstellen Hardware.
Das würde auch erklären warum es bei mir und nicht bei Dir einen Fehler gibt.
Das wäre aber wieder Kernel Sache.
 
Last edited:
bluesite said:
also ich habe aktuell kernel 7.0.0-3-pve am Laufen und drei apc usv am Server, zwei davon sind für andere Rechner da bzw Geräte
alle drei laufen hier ohne Probleme mit dem Kernel, habe auch apcupsd 3.14.14
2 mal Back-UPS XS 950U und eine Back-UPS XS 1400U, alle drei per USB verbunden
Click to expand...
Bist du dir sicher, dass das Gerät Back-UPS XS 950U heißt? Hast du mal enen Link?
Ich finde nur BX950.
 
Zu früh gefreut...

Jetzt sagt apcupsd dauernd, ich müsse die Batterie wechseln. Ich habe eine neue UPS bekommen, weil die andere UPS einen Defekt hatte. Das Ding ist also quasi neu. Wenn ich das PowerChute auf einer Windows VM laufen lasse, beklagt er nichts. Ich habe schon das Batterie-Installationsdatum auf den aktuellen Monat gesetzt und einen Selbsttest laufen lassen. Da ist der Tool zufrieden und meckert nicht.

Hat jemand eine Idee?

Danke und Grüße,
fant
 
fant said:
Zu früh gefreut...

Jetzt sagt apcupsd dauernd, ich müsse die Batterie wechseln. Ich habe eine neue UPS bekommen, weil die andere UPS einen Defekt hatte. Das Ding ist also quasi neu. Wenn ich das PowerChute auf einer Windows VM laufen lasse, beklagt er nichts. Ich habe schon das Batterie-Installationsdatum auf den aktuellen Monat gesetzt und einen Selbsttest laufen lassen. Da ist der Tool zufrieden und meckert nicht.

Hat jemand eine Idee?

Danke und Grüße,
fant
Click to expand...
Ich würde das tool erstmal in eine Win-VM schieben und weiter beobachten. Dann kannst du eventuelle HW-Fehler eingrenzen.
 
Last edited:
fant said:
Zu früh gefreut...

Jetzt sagt apcupsd dauernd, ich müsse die Batterie wechseln. Ich habe eine neue UPS bekommen, weil die andere UPS einen Defekt hatte. Das Ding ist also quasi neu. Wenn ich das PowerChute auf einer Windows VM laufen lasse, beklagt er nichts. Ich habe schon das Batterie-Installationsdatum auf den aktuellen Monat gesetzt und einen Selbsttest laufen lassen. Da ist der Tool zufrieden und meckert nicht.

Hat jemand eine Idee?

Danke und Grüße,
fant
Click to expand...
ich kann mir nicht vorstellen, dass das mit dem ursprünglichen Problem zu tun hat.
Da ist sicher nicht der Linuxkernel oder die Kommunikation über USB schuld.

Die USV meldet auch bei mir immer mal so Sachen, die nicht ganz richtig sind.
Das kommt aber im Gegesatz zum ursprünglichen Problem, vor der Firmware der USV.

Für die Nachwelt, die also nach dem ursprünglichen Fehler im Internet nach einer Lösung sucht, ist es meist nicht so schön, wenn alle möglichen Fehler die so hin und wieder mal auftreten, in einem Thread stehen.
Zur Lösung und Fehlersuche ist es da meiner Meinung nach besser, einen neuen Beitrag zu öffnen.

VG J.
 
fant said:
Zu früh gefreut...

Jetzt sagt apcupsd dauernd, ich müsse die Batterie wechseln. Ich habe eine neue UPS bekommen, weil die andere UPS einen Defekt hatte. Das Ding ist also quasi neu. Wenn ich das PowerChute auf einer Windows VM laufen lasse, beklagt er nichts. Ich habe schon das Batterie-Installationsdatum auf den aktuellen Monat gesetzt und einen Selbsttest laufen lassen. Da ist der Tool zufrieden und meckert nicht.

Hat jemand eine Idee?

Danke und Grüße,
fant
Click to expand...
Entweder die USV meldet Blödsinn (Firmwarebug) oder die Batterie ist tatsächlich nicht mehr so gut.
Wie alt ist die Batterie? Produktionsdatum und nicht installation.
Was sagt ein Selbsttest der USV?

Das Tool ist doof und gibt nur die Infos der USV weiter und interpretiert nichts. Daher check mal die USV.
 
May 01 16:21:50 pve03 kernel: hid-generic 0003:051D:0002.0085: Event data for report 22 was too short (4 vs 2)
Click to expand...
Ich habe mit einigen APC-UPS Back-UPS CS 500 ähnliche Probleme.

Das Problem entsteht dadurch, dass in neueren Kernei die Länge der tatsächlich empfangenen Daten mit der der angegebenen Länge der jeweiligen ReportID verglichen wird.
Wenn weniger Daten empfangen werden gibt es eine Warning und die Nachricht wird verworfen!
Frühere Kernel haben das einfach ignoriert, daher lief es auch.

Jetzt werden einige Report ID's nicht mehr verarbeitet, das sind bei mir z.B. ReportID 32 und 36, dadurch zeigen jetzt LINEV und LOTRANS immer 0.0 Volts an.

Der Fehler liegt in der jeweiligen APC Firmware, die meldet einfach falsche Längen für ReportID's an.
Das es hier bei manchen USV läuft und bei anderen nicht liegt vermutlich einfach an den unterschiedlichen Firmwareversionen.

Ich bereite gerade einen Patch für den Linux Kernel vor, der korrigiert die Längenangaben wenn ein APC Gerät angelegt wird.

Da ich aber nur Back-UPS CS 500 habe (300 Stück) wäre ich an den Fehlern und descriptor daten anderer Firmwareversionen und/oder anderen APC Modellen interessiert.
Aktuell habe ich Daten für
Back-UPS CS 500:
817.v9.I USB FW:v9
817.v7 .I USB FW:v7
808.q14 .I USB FW:q
808.q10 .I USB FW:q
808.q8.I USB FW:q8

Um die Daten auszulesen kann man das hier machen.
Code: 
journalctl -b -p4 -g hid-generic.*051d -n 1; hidraw=$(find /sys/class/hidraw/ -lname "*051D*"); /usr/sbin/apcaccess | grep -iE "FIRMW|MAN|MODEL"; ls -l $hidraw; od -v -tx1 $hidraw/device/report_descriptor

Das liefert dann sowas wie hier
Code: 
Aug 06 11:10:07 mrs2-428 kernel: hid-generic 0003:051D:0002.0001: Event data for report 32 was too short (4 vs 2)                                                                           MANDATE  : 2010-12-11                                                                                                                                                                                                                                     
FIRMWARE : 808.q10 .I USB FW:q                                                                                                                                                                                                                             
lrwxrwxrwx 1 root root 0  6. Aug 00:21 /sys/class/hidraw/hidraw0 -> ../../devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.4/1-1.4.2/1-1.4.2:1.0/0003:051D:0002.0001/hidraw/hidraw0                                                                           
0000000 05 84 09 04 a1 01 09 24 a1 02 85 01 09 fe 79 01                                                                                                                                                                                                   
0000020 75 08 95 01 15 00 26 ff 00 b1 22 85 02 09 ff 79                                                                                                                                                                                                   
...
0002240 ff 7f b2 a2 01 c0 05 84 09 16 a1 00 85 51 06 86
0002260 ff 09 24 16 70 00 26 a0 00 95 01 75 08 b1 a2 c0
0002300 c0
0002301

Im journalctl schauen ob nur für eine ReportID Fehler gemeldet werden oder für mehrere
 
Last edited:
  • Like
Reactions: fabian
root@pve03:~# journalctl -b -p4 -g hid-generic.*051d -n 1; hidraw=$(find /sys/class/hidraw/ -lname "*051D*"); /usr/sbin/apcaccess | grep -iE "FIRMW|MAN"; ls -l $hidraw; od -tx1 $hidraw/device/report_descriptor
-- No entries --
lrwxrwxrwx 1 root root 0 Jul 29 12:56 /sys/class/hidraw/hidraw0 -> ../../devices/pci0000:00/0000:00:15.0/usb1/1-4/1-4:1.0/0003:051D:0002.0001/hidraw/hidraw0
0000000 05 84 09 04 a1 01 09 24 a1 00 85 01 09 fe 79 02
0000020 75 08 95 01 15 00 26 ff 00 b1 22 85 02 09 ff 79
0000040 03 b1 22 85 03 05 85 09 89 79 04 b1 22 85 04 09
0000060 8f 79 01 b1 22 85 05 09 8b b1 22 85 0a 05 84 09
0000100 fd 75 08 26 ff 00 65 00 55 00 79 01 b1 22 85 0b
0000120 05 85 09 2c b1 03 75 08 85 0c 09 66 25 ff b1 a2
0000140 09 66 81 a2 85 0d 09 83 75 08 25 64 65 00 b1 22
0000160 85 0e 09 67 b1 22 85 0f 09 68 75 10 27 ff ff 00
0000200 00 66 01 10 b1 a2 85 11 75 08 05 85 09 29 15 01
0000220 b1 a2 85 13 09 d0 15 00 25 01 81 a2 09 d0 b1 a2
0000240 85 14 09 42 81 a2 09 42 b1 a2 85 15 05 84 09 57
0000260 75 10 16 ff ff 26 ff 7f 66 01 10 b1 a2 85 17 05
0000300 85 09 2a 95 01 75 10 27 ff ff 00 00 66 01 10 b1
0000320 a2 85 18 05 84 09 5a 75 08 15 01 25 03 65 00 b1
0000340 a2 09 02 a1 02 85 16 05 85 65 00 75 01 15 00 25
0000360 01 09 44 81 a2 09 44 b1 a2 09 45 81 a2 09 45 b1
0000400 a2 09 d0 81 a2 09 d0 b1 a2 09 d1 81 a2 09 d1 b1
0000420 a2 05 84 09 69 81 a2 09 69 b1 a2 05 85 09 43 81
0000440 a2 09 43 b1 a2 05 85 09 4b 81 a2 09 4b b1 a2 05
0000460 84 09 65 81 a2 09 65 b1 a2 05 85 09 db 81 a2 09
0000500 db b1 a2 95 17 81 01 b1 01 c0 c0 05 84 09 12 a1
0000520 00 95 01 85 20 05 85 09 85 75 10 15 00 27 ff ff
0000540 00 00 81 22 09 85 b1 a2 85 21 05 84 09 58 75 08
0000560 25 06 81 a2 09 58 b1 a2 85 22 05 85 09 66 25 ff
0000600 b1 a2 85 23 09 68 75 10 27 ff ff 00 00 66 01 10
0000620 b1 a2 85 24 09 2a b1 a2 85 25 05 84 09 40 67 21
0000640 d1 f0 00 55 05 b1 22 85 26 09 30 b1 a2 c0 05 84
0000660 09 1a a1 00 85 30 05 84 09 40 75 08 15 00 26 ff
0000700 00 67 21 d1 f0 00 55 07 b1 22 85 31 09 30 75 10
0000720 b1 a2 85 32 09 53 16 8c 00 26 96 00 b1 a2 85 33
0000740 09 54 16 22 01 26 2c 01 b1 a2 85 35 75 08 06 86
0000760 ff 09 61 15 00 25 02 b1 a2 85 36 09 52 25 0d b1
0001000 a2 c0 09 05 a1 00 85 40 09 7c 25 ff b1 a2 c0 05
0001020 84 09 16 a1 00 85 50 09 35 75 08 15 00 25 64 65
0001040 00 55 00 b1 a2 85 52 05 84 09 44 75 10 15 00 27
0001060 ff ff 00 00 66 21 d1 55 07 b1 a2 c0 85 7f 05 84
0001100 09 fe 79 05 75 08 95 01 15 00 26 ff 00 65 00 55
0001120 00 b1 22 85 7e 06 86 ff 09 42 79 07 75 08 95 01
0001140 15 00 26 ff 00 b1 22 85 7d 05 84 09 ff 79 03 b1
0001160 22 85 7c 09 fd 79 01 b1 22 85 7b 05 85 09 85 75
0001200 10 27 ff ff 00 00 b1 a2 05 84 09 02 a1 02 85 7a
0001220 05 85 09 44 75 01 25 01 b1 a2 09 45 b1 a2 09 d0
0001240 b1 a2 09 d1 b1 a2 05 85 09 4b b1 a2 05 85 09 db
0001260 b1 a2 05 84 09 65 b1 a2 95 19 b1 01 c0 85 78 05
0001300 84 09 5a 75 08 95 01 15 01 25 03 b1 a2 06 ff ff
0001320 09 ff a1 02 85 e3 09 ef 75 08 95 07 26 ff 00 15
0001340 00 81 82 09 ef b1 82 c0 c0
0001351
 
jbeck66 said:
root@pve03:~# journalctl -b -p4 -g hid-generic.*051d -n 1; hidraw=$(find /sys/class/hidraw/ -lname "*051D*"); /usr/sbin/apcaccess | grep -iE "FIRMW|MAN"; ls -l $hidraw; od -tx1 $hidraw/device/report_descriptor
-- No entries --
lrwxrwxrwx 1 root root 0 Jul 29 12:56 /sys/class/hidraw/hidraw0 -> ../../devices/pci0000:00/0000:00:15.0/usb1/1-4/1-4:1.0/0003:051D:0002.0001/hidraw/hidraw0
0000000 05 84 09 04 a1 01 09 24 a1 00 85 01 09 fe 79 02
0000020 75 08 95 01 15 00 26 ff 00 b1 22 85 02 09 ff 79
...
Click to expand...

Danke schonmal, allerdings liefert bei dir /usr/sbin/apcaccess keine Firmware oder ManDate Angaben ???
Wenn Ich die Werte aus deinem ersten Post nehme sehe ich nur
MODEL : Back-UPS BX750MI

Bei dem Log von TErxleben sieht man alle drei Angaben.

Das ist merkwürdig, dass bei dir die Angaben zur Firmware/MANDATE nicht ausgegeben werden.
Alternativ kann man es noch hiermit versuchen

Code: 
lsusb -vv -d 051d:0002

Und ich habe einen Fehler bei der Befehlszeile gemacht, dadurch wurden nicht alle Zeilen ausgegeben, vermutlich gab es in deiner Ausgabe Zeilen mit einem einzelnen *, der ist beim Copy&Paste verschwunden.
Daher bitte nochmal mit
Code: 
hidraw=$(find /sys/class/hidraw/ -lname "*051D*"); /usr/sbin/apcaccess | grep -iE "FIRMW|MAN|MODEL"; ls -l $hidraw; od -v -tx1 $hidraw/device/report_descriptor
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back