Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Wie kann man das Konfigurieren?
Post Reply
56kbit
Posts: 19
Joined: October 28th, 2019, 10:50 am

Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Post by 56kbit » November 5th, 2019, 5:07 pm

Hallo.
hier ein neuer Thread zum Thema Test-Upgrade lm-sensors 3.4.0 (@ core 136) auf lm-sensors 3.6.0.
@ UE - Ja, wir sollten mit 64bit starten ...

Release Notes und Latest News https://hwmon.wiki.kernel.org/lm_sensors Grund ist bessere Hardwareunterstützung und diverse nöckelige ITE-Chip-Erkennungen und einige Bugs, Releases seit derzeitiger Version:
  • 3.6.0 October 18th, 2019: Released!
  • 3.5.0 November 23rd, 2018: Released!
  • 3.4.0 (2015-06-25) ( ! default @ FIRE core 136 )
Readme+Changelog bis v3.6.0:

Code: Select all

3.6.0 (2019-10-18)
  configs: Added a number of new configuration files
  fancontrol: AVERAGE env variable can be used to set the number of previous readings to average
  Makefile: The MACHINE variable has been renamed to ARCH
  sensord: Add an option -1/--oneline to print chip and adapter on the same line
  sensors: Fixed a stray comma bug in the JSON output
           Fixed Fahrenheit conversion with raw and JSON output
           Scale voltage and current values in the default output format
  sensors-detect: Add detection of AMD Family 17h, models 30h, 70h
                  Add detection of some AMD Family 15h models
                  Add detection of AMD Family 16h model 30h power sensors
                  Add detection of Hygon Family 18h thermal sensors
                  Add detection of Nuvoton NCT6797D
                  Add detection of Nuvoton NCT6798D
                  Add detection of Nuvoton NCT6112D/NCT6114D/NCT6116D
                  Fix printing CPU info on non-x86 arches
                  Fix printing lm_sensors version
                  Mark Fintek F75387SG/RG as supported by the f75375s driver

3.5.0 (2018-11-23)
  Fixed disappearance of certain hwmon chips with 4.19+ kernels
  Add the find-driver script for debugging
  Various documentation and man page improvements
  Fix various issues found by Coverity Scan
  Fix compilation with the musl C library
  Development version string now contains "+git" instead of "+SVN"
  Updated links in documentation to reflect the new home of lm_sensors
  sensors.1: Add reference to sensors-detect
             Document -j option (json output)
  sensors: Add support for json output
           Add support for power min, lcrit, min_alarm, lcrit_alarm
  sensors-detect: Fix systemd paths
                  Add detection of Fintek F81768
                  Only probe I/O ports on x86
                  Add detection of Nuvoton NCT6793D
                  Add detection of Microchip MCP9808
                  Mark F71868A as supported by the f71882fg driver
                  Mark F81768D as supported by the f71882fg driver
                  Mark F81866D as supported by the f71882fg driver
                  Add detection of various ITE chips
                  Add detection of Nuvoton NCT6795D
                  Add detection of DDR4 SPD
                  Add detection of ITE IT8987D
                  Add detection of AMD Family 17h temperature sensors
                  Add detection of AMD KERNCZ SMBus controller
                  Add detection of various Intel SMBus controllers
                  Add detection of Giantec GT30TS00
                  Add detection of ONS CAT34TS02C and CAT34TS04
                  Add detection of AMD Family 15h Model 60+ temperature sensors
                  Add detection of Nuvoton NCT6796D
                  Add detection of AMD Family 15h Model 70+ temperature sensors
  configs: Add sample configuration files.
  sensors.conf.default: Add hardwired inputs of NCT6795D
                        Add hardwired inputs of F71868A
                        Add hardwired NCT6796D inputs
  vt1211_pwm: replaced deprecated sub shell syntax
              run with bash instead of sh
  pwmconfig: replaced deprecated sub shell syntax
  fancontrol: replaced deprecated sub shell syntax
              save original pwm values
  fancontrol.8: replaced deprecated sub shell syntax
  libsensors: Add support for SENSORS_BUS_TYPE_SCSI
              Add support for power min, lcrit, min_alarm, lcrit_alarm

ummeegge
Community Developer
Community Developer
Posts: 4981
Joined: October 9th, 2010, 10:00 am

Re: Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Post by ummeegge » November 5th, 2019, 5:34 pm

Halli hallo,
so da hat´s gleich erstmal geknallt. Der collectd meckert

Code: Select all

sensors.c:168:3: error: #error "This version of libsensors is not supported yet. Please report this " "as bug."
 # error "This version of libsensors is not supported yet. Please report this " \
   ^~~~~
sensors.c:172:31: error: 'SENSORS_CONF_PATH' undeclared here (not in a function); did you mean 'SENSORS_MODE_R'?
 static const char *conffile = SENSORS_CONF_PATH;
                               ^~~~~~~~~~~~~~~~~
                               SENSORS_MODE_R
sensors.c:173:1: error: unknown type name 'featurelist_t'; did you mean 'ignorelist_t'?
 featurelist_t *first_feature = NULL;
 ^~~~~~~~~~~~~
 ignorelist_t
sensors.c: In function 'sensors_free_features':
sensors.c:253:2: error: unknown type name 'featurelist_t'; did you mean 'ignorelist_t'?
  featurelist_t *thisft;
  ^~~~~~~~~~~~~
  ignorelist_t
sensors.c:254:2: error: unknown type name 'featurelist_t'; did you mean 'ignorelist_t'?
  featurelist_t *nextft;
  ^~~~~~~~~~~~~
  ignorelist_t
sensors.c:263:18: error: request for member 'next' in something not a structure or union
   nextft = thisft->next;
                  ^~
sensors.c: In function 'sensors_load_conf':
sensors.c:272:2: error: unknown type name 'featurelist_t'; did you mean 'ignorelist_t'?
  featurelist_t *last_feature = NULL;
  ^~~~~~~~~~~~~
  ignorelist_t
sensors.c:275:6: warning: unused variable 'chip_num' [-Wunused-variable]
  int chip_num;
      ^~~~~~~~
sensors.c:274:27: warning: unused variable 'chip' [-Wunused-variable]
  const sensors_chip_name *chip;
                           ^~~~
sensors.c:272:17: warning: unused variable 'last_feature' [-Wunused-variable]
  featurelist_t *last_feature = NULL;
                 ^~~~~~~~~~~~
sensors.c: In function 'sensors_read':
sensors.c:511:2: error: unknown type name 'featurelist_t'; did you mean 'ignorelist_t'?
  featurelist_t *fl;
  ^~~~~~~~~~~~~
  ignorelist_t
sensors.c:511:17: warning: unused variable 'fl' [-Wunused-variable]
  featurelist_t *fl;
                 ^~
At top level:
sensors.c:472:13: warning: 'sensors_submit' defined but not used [-Wunused-function]
 static void sensors_submit (const char *plugin_instance,
             ^~~~~~~~~~~~~~
make[4]: *** [Makefile:3486: sensors_la-sensors.lo] Error 1
make[4]: Leaving directory '/usr/src/collectd-4.10.9/src'
make[3]: *** [Makefile:3941: install-recursive] Error 1
make[3]: Leaving directory '/usr/src/collectd-4.10.9/src'
make[2]: *** [Makefile:4098: install] Error 2
make[2]: Leaving directory '/usr/src/collectd-4.10.9/src'
make[1]: *** [Makefile:511: install-recursive] Error 1
make[1]: Leaving directory '/usr/src/collectd-4.10.9'
make: *** [collectd:111: /usr/src/log/collectd-4.10.9] Error 2
alles klar mal schauen wie´s mit einem Collectd Update aussieht. Schneller Blick ins LFS vom Collectd --> https://git.ipfire.org/?p=ipfire-2.x.gi ... s/next#l75 :-[ ehrlisch herlisch wie man so sagt. Collectd gibt´s derzeit in Version 5.9.s --> https://collectd.org/download.shtml auf dem Fire haben wir derzeit 4.10.9 . Ein Schelm wer denkt das könnte mit den Patches zutun haben... :P :-[ .

OK. Ich mach mir mal ein Bier auf und schau mal einwenig tiefer rein. Kann alles einwenig dauern und wie es aussieht müsste dann auch mehr getestet werden :o .
Sollten wir erstmal zum check die 3-5-0 bauen ?!
EDIT: Nö ist auch nicht so angesagt

Code: Select all

sensors.c:168:3: error: #error "This version of libsensors is not supported yet. Please report this " "as bug."
 # error "This version of libsensors is not supported yet. Please report this " \
Beste Grüße,

UE

EDITs {sagt nochmal}:
@Matthias ich hätte da mal gerne ein Problem :) wenn dir was dazu einfällt wäre toll.
ACHTUNG: Prüfsummen stimmen nicht überein -->
https://storage.googleapis.com/collectd ... .2.tar.bz2
= 764c62767a85885f4856224a30ee1a31
<-- is von der Hompage --> https://collectd.org/ und sieht ranzig aus. tar sagt das ist kein bzip2 !!!
und
https://github.com/collectd/collectd/re ... ectd-5.9.2
= 4ec308f256a3d3575f6c8a2be4338966
mal bescheid geben vielleicht...
Image
Image

56kbit
Posts: 19
Joined: October 28th, 2019, 10:50 am

Re: Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Post by 56kbit » November 5th, 2019, 6:40 pm

@UE, Hi
Option A) v3.5.0 ?
Kann ich nicht beurteilen aber wäre evtl der geringste Aufwand - beurteile Du. Kenne collectD nicht gut genug.

Option B) wäre knallhart nur sensors testen -
Wenn ich das richtig versteh muss collectd die Version 3.6.0 supporten, sie ist recht neu - 3.4 wird supported, ist ja bei FIRE dabei.
Irgendwo muss doch collectd die zulässigen Versionsnummern hinterlegt haben, einfach mal plain-text den Eintrag "kompatibel zu 3.4.0" (denn die muss ja gehen, ist ja derzeit dabei) auf 3.6.0 umbenennen? Die neue Version unterschieben und gut? Kaputtgehen kann beim Test nix ...

Option C) - nur Bier trinken - ich grüß prostend temporär grad mal 100 Km nach Osten ... (nene, C) wollen wir nicht)

Nun, je nach Ausrichtung kommt man zukünftig sicher nicht drumherum für den Produktivbetrieb collectd und Anderes zu updaten, also nur eine Frage vom Zeitpunkt, Aufwand oder der Priorisierung (was ich auch nicht zu entscheiden hab und vermag).
Last edited by 56kbit on November 5th, 2019, 7:35 pm, edited 2 times in total.

56kbit
Posts: 19
Joined: October 28th, 2019, 10:50 am

Re: Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Post by 56kbit » November 5th, 2019, 7:28 pm

EDIT
Scheint Komprimierungstool und Inkompatibilität - vermute Entwickler hat da mal 7zip oder Windows genutzt - und die Hashes nicht neu gemacht
Version von Homepage via googleapis : Fileident 7zip ->> ab Adresse 00 = ".7zXZ"
Version aus GIT : Fileident BZ >> ab Adresse 00 = "BZh91AY"

GIT lässt sich entpacken - auf Linux mit bzip _ bzip2 -d ./collectd-5.9.2.tar.bz2.HOMEPAGEgoogle.tar.bz2
Last edited by 56kbit on November 6th, 2019, 1:19 am, edited 5 times in total.

User avatar
FischerM
Community Developer
Community Developer
Posts: 1018
Joined: November 2nd, 2011, 12:28 pm

Re: Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Post by FischerM » November 5th, 2019, 7:29 pm

Hi,
ummeegge wrote:@Matthias ich hätte da mal gerne ein Problem :) wenn dir was dazu einfällt wäre toll.
Mir fällt was ein... ;)
ummeegge wrote:ACHTUNG: Prüfsummen stimmen nicht überein -->
Die Prüfsummen stimmen nicht überein, weil vielleicht bei Dir beim ersten Download-Link...
ummeegge wrote:https://storage.googleapis.com/collectd ... .2.tar.bz2
= 764c62767a85885f4856224a30ee1a31
<-- is von der Hompage --> https://collectd.org/ und sieht ranzig aus. tar sagt das ist kein bzip2 !!!
...irgendwas schiefgegangen zu sein scheint? Komisch. Siehe unten.

Die Datei, die es dort gibt, hat hier die Prüfsumme 4ec308f256a3d3575f6c8a2be4338966 (collectd-5.9.2.tar.bz2 / 1572628 Bytes) und funktioniert hier.
ummeegge wrote:und
https://github.com/collectd/collectd/re ... ectd-5.9.2
= 4ec308f256a3d3575f6c8a2be4338966
Das Archiv von 'github' ist wesentlich größer (1831777 Bytes) und hat logischerweise eine andere Prüfsumme.

Kurz verglichen: die diversen Quelltexte unterscheiden sich in auffälliger Form - mindestens einen Tippfehler habe ich im 'github'-Quelltext gefunden.

Ich würde vorschlagen wollen, beide - lm_sensors und collectd - zu aktualisieren und wenn, dann dieses Archiv zu verwenden. Das kommt von https://collectd.org/download.shtml#source, hat die Prüfsumme 4ec308f256a3d3575f6c8a2be4338966 (s.o.), ist dort als Version 5.7 angesagt, das Archiv ist angeblich eine 5.9.2, das Changelog geht bis 5.8.1 und der o.a. Tippfähler wurde korrigiert. Es ist also alles dabei... O0
mal bescheid geben vielleicht...
Bescheid! ::)

Gruß,
Matthias

P.S.: Ich hatte ein Update dieser beiden auch schon mal angefangen, aber wegen der Patch-Flut von collectd lieber wieder Abstand gehalten. Könnte man aber mal angehen.

56kbit
Posts: 19
Joined: October 28th, 2019, 10:50 am

Re: Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Post by 56kbit » November 5th, 2019, 7:47 pm

mhmm . für produktiven Role-Out sollte man vor Integration auf jeden Fall die Entwickler kontakten.
Nicht das bei denen jemand den Github missbraucht hat ...
Kurz verglichen: die diversen Quelltexte unterscheiden sich in auffälliger Form - mindestens einen Tippfehler habe ich im 'github'-Quelltext gefunden.

ummeegge
Community Developer
Community Developer
Posts: 4981
Joined: October 9th, 2010, 10:00 am

Re: Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Post by ummeegge » November 6th, 2019, 2:40 pm

Halli hallo,
FischerM wrote:
November 5th, 2019, 7:29 pm
Ich würde vorschlagen wollen, beide - lm_sensors und collectd - zu aktualisieren und wenn, dann dieses Archiv zu verwenden. Das kommt von https://collectd.org/download.shtml#source, hat die Prüfsumme 4ec308f256a3d3575f6c8a2be4338966 (s.o.), ist dort als Version 5.7 angesagt, das Archiv ist angeblich eine 5.9.2, das Changelog geht bis 5.8.1 und der o.a. Tippfähler wurde korrigiert. Es ist also alles dabei... O0
das ist alles Ungeheuer... Das Suffix von der 5.9.2er von hier --> https://collectd.org/download.shtml#source stimmt nicht. Die SHA256 Summe ist korrekt aber ein

Code: Select all

tar jxvf collectd-5.9.2.tar.bz2
sagt

Code: Select all

bzip2: (stdin) is not a bzip2 file.
tar: Child returned status 2
tar: Error is not recoverable: exiting now
was aber auch klar ist da

Code: Select all

file collectd-5.9.2.tar.bz2    
collectd-5.9.2.tar.bz2: XZ compressed data
na aber ein XZ Archiv sollte doch eigentlich ein 'tar.xz' Suffix haben ? Jedenfalls geht ein

Code: Select all

tar Jxvf collectd-5.9.2.tar.bz2 
. Die haben auf der Homepage eine andere Kompression und vergessen das Archiv auch so zubennen... {Sollte man vielleicht mal bescheid geben --> also da mein ich LOL :-} .

Derzeitiger Bearbeitungsstand mit collectd-5.9.2 und lm-sensors-3-6-0:
- collectd 5.9.2 baut nun durch da auf ein wesentliches Begrenzt.
- Alle configure options sind beibehalten allerdings um --enable-openvpn ergänzt und --enable-mysql ist rausgeflogen.
- 'libltdl' gibt es nicht mehr von daher brauchts da auch kein autoreconf.
- Alle Patches sind erstmal auskommentiert umzuschauen ob er überhaupt baut.
- Der autoreconf für das main dir muss abgeschaltet werden ansonsten knallts via --> https://github.com/collectd/collectd/issues/1334 .
- Patches hab ich mir mal grob angeschaut.
0001 --> utils_mount.h gibt es nicht mehr.
0002 --> Kann man nach wie vor abschalten via true <--> false und nicht mehr mittels 0 <--> 1 aber MySQL gibts auf dem Fire nicht mehr von daher kann der eigentlich auch rausfliegen und --> im configure abgeschaltet werden.
0003 --> Der Curl Patch ist derzeit schon sinnlos da er mit 0005 wieder reverted wurde.
0004 --> Brauchen wir FreeBSD-10 support ::) !!!
0005 --> Wie oben genannt zieht der nur den 0003er Patch wieder zurück.
0006 --> network.c wurde komplett dem Erdboden gleich gemacht. Da steht kein Stein mehr auf dem anderen, der alte Patch ist da sinnlos.
0007 --> Der Patch ist drinne --> https://github.com/collectd/collectd/bl ... che.c#L546 .
0008 --> Ist auch drinne --> https://github.com/collectd/collectd/bl ... ork.c#L500 .
0009 --> Sieht so aus als wäre der auf alle Plugins erweitert worden --> https://github.com/collectd/collectd/pull/526 ?! Müsste mal näher gecheckt werden.
0010 --> Ist drinne --> https://github.com/collectd/collectd/bl ... ttp.c#L863 .
0011 --> configfile.c gibt´s nicht mehr.
0012 --> configure.in auch nicht mehr.
0013 --> Wie oben drüber.
0014 --> Ist scheinbar auch drinne --> https://github.com/collectd/collectd/bl ... mp.c#L1697 .
0015 --> Wurde umgeschrieben.








So, weiter bin ich bis jetzt noch nicht gekommen nur mal als potentieller Zeitsparer. Ich lass den jetzt erstmal durchbauen und check mal die Patches einwenig weiter derweil, da ist jede Menge OpenVPN Patchset noch... RRDTool wäre auch noch ein potentieller Stolperstein aber ich habe gesehen da haben wir die neueste Version ^-^ .
56kbit wrote:
November 5th, 2019, 7:47 pm
mhmm . für produktiven Role-Out sollte man vor Integration auf jeden Fall die Entwickler kontakten.
Ich finde das auch, das wäre nett ihnen zusagen das sie ihr Archiv falsch benannt haben, ist klar das ein XZ Archiv kleiner ist als ein bzip2 und das die Prüfsummen auch anders sind ebenso, ich glaub ich mach das mal fix <-- DONE...

Beste Grüße an alle,

UE

P.S. Schön das du da bist Matthias O0
Image
Image

User avatar
FischerM
Community Developer
Community Developer
Posts: 1018
Joined: November 2nd, 2011, 12:28 pm

Re: Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Post by FischerM » November 6th, 2019, 4:39 pm

Ahmt,
ummeegge wrote:das ist alles Ungeheuer...
Yep. Sehr ... kreativ ... gestaltet.
ummeegge wrote:Derzeitiger Bearbeitungsstand mit collectd-5.9.2 und lm-sensors-3-6-0 ...
Klasse!
Sowas Ähnliches hatte ich auch vor, wäre aber frühestens am Wochenende dazu gekommen. Der Devel baut momentan eh den neuen squid 4.9, ist also leider beschäftigt.
ummeegge wrote:So, weiter bin ich bis jetzt noch nicht gekommen nur mal als potentieller Zeitsparer.
Das ist doch eine ganze Menge! Bin auf Deine Ergebnisse gespannt. 8)
ummeegge wrote:P.S. Schön das du da bist Matthias
Danke, das haben meine Arbeitskollegen heute auch gesagt. Irgendwie waren die letzten zwei Wochen auf der Sonnenuntergangsbank auf dem Utersumer Deich trotzdem gemütlicher. Diese Bank ist eine ernstzunehmende Alternative... *seufz* :-[

Viele Grüße,
Matthias

56kbit
Posts: 19
Joined: October 28th, 2019, 10:50 am

Re: Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Post by 56kbit » November 6th, 2019, 7:56 pm

ui, es geht voran.

Falls Kompiliern bei Euch so rechenintensiv ist - ich hätt bei Bedarf ggf. noch 1 oder 2 19" Rackserver mit 12, 16 oder 24 Kernen zwischen 128 und 196GB über ... muss man ja nicht immer laufen lassen, habe die an der Solaranlage oder im Keller.
... :) Gerne bring ich die auch bis an die Nordsee ...

ummeegge
Community Developer
Community Developer
Posts: 4981
Joined: October 9th, 2010, 10:00 am

Re: Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Post by ummeegge » November 7th, 2019, 3:58 pm

Hallo zusammen,
56kbit wrote:
November 6th, 2019, 7:56 pm
Falls Kompiliern bei Euch so rechenintensiv ist - ich hätt bei Bedarf ggf. noch 1 oder 2 19" Rackserver mit 12, 16 oder 24 Kernen zwischen 128 und 196GB über ... muss man ja nicht immer laufen lassen, habe die an der Solaranlage oder im Keller.
... :) Gerne bring ich die auch bis an die Nordsee ...
Wow was ein tolles Angebot :) . Wie wäre es denn mit einem Buildserver bei dir mit OpenVPN Anbindung ?

Zum Topic:
Build is durchgebaut und Collectd (lm_sensors) starten erstmal fehlerfrei. Da war noch was zumachen was ich erst nach dem ersten Booten von der VM gesehen hab. Collectd hat ein DEP zu libstatgrab was es ja auf dem Fire schon gibt allerdings nur als Paket. Hab das dann mal in den Common eingebaut und starten tut er nun ohne Meckern. Was erstmal noch nicht ging ist der Status von Netzwerk (in + out) und das OpenVPN. Derzeitiger Bearbeitungsstand ist hier --> https://git.ipfire.org/?p=people/ummeeg ... 5dd649fdf3 zufinden. Das ISO für 64bit hier --> https://people.ipfire.org/~ummeegge/collectd_update/ .

Was wäre gut:
- Testen wäre toll @56kbit da findest du auch das upgedatete 'lm_sensors-3-6-0' wenn du in den ROOTFILE im Git schaust findest du auch die Location wie auch für Collectd.
- Patchen der OpenVPN Sourcen ist nicht mal eben gemacht da die openvpn.c auch weitestgehend umgeschrieben ist und der Patchset IPFire spezifisch ist und es hierfür keinen Merge Request gab.

Mal schnell ein paar News, muss gleich weiter wieder (der volle Hustle heut)...

Beste Grüße,

UE
Image
Image

56kbit
Posts: 19
Joined: October 28th, 2019, 10:50 am

Re: Test von lm-sensors 3.6.0 ab core 136 ff / 64 bit

Post by 56kbit » November 7th, 2019, 8:39 pm

Hi, super.
Nehme mir morgen eine VM mit in die Bahn und schaue dort (Bis Morgen/Ü-Morgen unterwegs).

Ja, Buildserver on demand - Grund warum welche über sind: die Solaranlage ist zu weit draussen, ich bekomme leider selber nur eine schlechte 2 Mbit-Wlan-Verbindung über 800 Meter die immer knallt - zu schlecht selbst für sudo apt update... Daher sind die Server ja über ;) (oder daher ist mein Name Programm - viele Windanlagen wählen sich immer noch mit Modem in die Zentrale ein im Jahr 2019 ...)

Post Reply