HWAudit - Funktioniert bei bestimmten Rechnertypen nicht

[Franz2000]

Habe mit HW-Audit das Problem dass bei bestimmten Rechnermodellen (OEM-Systeme, kein Selbstbau) praktisch keine Informationen erfasst werden. Am Client-Rechner sieht es so aus als würde das Paket fehlerfrei durchlaufen, im Log findet man jedoch einen "Fatal Error" ohne genauerer Erläuterung. Handelt sich um relativ neue Modelle mit Intel Core CPUs aus der Generation 6 und 7, bzw. Xeon E5. Client-Systeme laufen unter Windows 7 Pro x64 und Windows 10 Pro x64. Hier ein paar Screenshots:

Log-Datei mit dem Abschnitt von HW-Audit:



HW-Audit bei einem Dell Optiplex 3050 mit Intel Core i5-7500T:



HW-Audit bei einer Lenovo ThinkStation P510 mit Xeon E5-1630 v3:



Bei folgenden Rechnermodellen kann ich dieses Problem derzeit beobachten:

Dell:
Optiplex 7450 AiO
Optiplex 3050

Lenovo:
Carbon X1
ThinkStation P410
ThinkStation P510
ThinkStation P710

Jemand eine Idee, bzw. Gegenfragen?

[skoloschin]

Hi Franz2000,
wenn der Fehler auch bei der Speichererkennung auftritt, ist das hier schon dokumentiert:
viewtopic.php?f=6&t=9211
Unsere "HWaudits" sehen bei diesen Rechnern ähnlich unvollständig aus.
Gruß
Sigi

[Franz2000]

Probleme die irgendwie auf den RAM hinweisen finde ich im Log keine. Selbst wenn ich auf Loglevel 9 gehe gibt es keinen Hinweis darauf dass eine bestimmte Hardwarekomponente schuld an meinem Problem sein könnte.

[Hosemacht]

Hallo Franz,

Sigi hat recht unsere HWaudit logs sehen ähnlich aus, schau dir doch bitte mal das HWaudit log am Client
im Opsi Verzeichnis an (C:\opsi.org\tmp\hwaudit.log).

Vielleicht oder wahrscheinlich hast du das selbe Problem wie wir.

MFG
Robert

[n.wenselowski]

Hi,

Jemand eine Idee, bzw. Gegenfragen?

Welche Version von hwaudit wird eingesetzt? Die Anzeige des Configed sieht noch etwas antik aus

Kannst du auf dem Client das Depot des opsi-Servers mounten, auf der Kommandozeile ins hwaudit-Verzeichnis wechseln und dort die hwaudit.exe aufrufen?
Den zugehörigen Befehl sieht man im Log des hwaudit.
Sollte dort bei -p nur confidential zu sehen sein, so setzt dort den Host Key des Client ein. Ausgelesen werden kann der mit folgendem Befehl auf dem Server:

Code: Alles auswählen

opsi-admin -Sd method host_getObjects '["opsiHostKey"]' '{"id": "HIER.FQDN.DEINS.CLIENTS"}' | grep opsiHostKey

Vielleicht gibt es hier ein Problem mit der Bereitgestellten Binary.

Ansonsten würde mich ein hwaudit.log mit Loglevel 8 interessieren.
Lässt sich beim Produkt als Property einstellen.
Kannst du so eines zur Verfügung stellen?


Gruß

Niko

[andré]

Hi Niko,

das Problem mit dem hwaudit haben wir auf unseren Notebooks mit aktuellen Prozessoren auch.

Paket-Versionen:

Code: Alles auswählen

root@opsi:~# dpkg -l |grep opsi
ii  opsi-atftpd                      0.7.dfsg-6                    amd64        advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii  opsi-configed                    4.0.7.5.22-2                  all          OPSI config editor
ii  opsi-depotserver                 4.0.7.1-1                     all          opsi depotserver configuration package
ii  opsi-linux-bootimage             20170508-1                    amd64        opsi bootimage for netboot tasks.
ii  opsi-utils                       4.0.7.7-3                     all          utilites for working with opsi.
ii  opsiconfd                        4.0.7.9-1                     all          opsi configuration service
ii  opsipxeconfd                     4.0.7.5-3                     all          opsi pxe configuration daemon
ii  python-opsi                      4.0.7.40-1                    all          opsi python library

Auf dem Client installierte Pakete:

Code: Alles auswählen

hwaudit	 	4.0.6.1-6
opsi-client-agent	 4.0.7.15-1
opsi-winst		4.11.6.12-1

Ich hätte drei Textlogs:
- Einmal der normale hwaudit mit Loglevel8
- Einmal die Terminal-Ausgabe beim manuellen hwaudit
- Und die erstellte Logdatei vom manuellen hwaudit

Damit sollte echt alles an möglichen Infos vorhanden sein.

An welche Mail-Adresse soll ich das schicken?

Grüße
Andre

[n.wenselowski]

Hi,

dank den Logs von andré ist der Fehler hoffentlich mit python-opsi 4.0.7.43-1 behoben!
Diese Version baut aktuell in experimental. Nach dem Aktualisieren muss einmalig ein opsi-setup --update-mysql ausgeführt. Ich würde auch empfehlen einmal den opsiconfd neu zu starten, dringend notwendig ist das aber nicht.

Ich würde mich über Feedback freuen!


Viele Grüße

Niko

[andré]

Ich habe das bei einem Rechner, bei dem es vorher fehlschlug, getestet und es funktioniert. Danke dir.

Nach dem Update und Aktualisieren kam opsiconfd nicht mehr hoch. Reboot musste ich wegen eines Upgrades machen, hat aber nichts geändert. Nach einem Restart von mysql und ungefähr 10 Minuten warten ging es dann wieder. Ich habe jetzt aber noch nicht nach der Ursache geforscht und auch nicht, ob der myslq-Restart die Lösung war. Mache ich morgen evtl.

[n.wenselowski]

Hi andré,

Ich habe das bei einem Rechner, bei dem es vorher fehlschlug, getestet und es funktioniert. Danke dir.

Das freut mich!

Nach dem Update und Aktualisieren kam opsiconfd nicht mehr hoch. Reboot musste ich wegen eines Upgrades machen, hat aber nichts geändert. Nach einem Restart von mysql und ungefähr 10 Minuten warten ging es dann wieder. Ich habe jetzt aber noch nicht nach der Ursache geforscht und auch nicht, ob der myslq-Restart die Lösung war. Mache ich morgen evtl.

Hier sollte /var/log/opsi/opsiconfd/opsiconfd.log weiterhelfen. Falls du auf ein Problem stößt bitte ein gesondertes Topic aufmachen!


Gruß

Niko

[andré]

Aus irgendeinem Grund hatte der opsiconfd keine Zugriffsrechte mehr auf das repository. Ich erinnere mich, ein opsi-set-rights nach zwei Startversuchen gemacht zu haben, das hat das Problem behoben. Insofern war das einzige Problem, dass die Rechte aus verändert worden sind. Kein Problem, da sich das ja leicht beheben lässt.