Netboot nicht mehr möglich "local variable 'conditionmatch'"

[ma733]

Hallo,

nach dem gestrigen aptitude safe-upgrade können keine Netboot-Produkte mit Hardwareinventur mehr gestartet werden.

Fehlermeldung im boot-log:

Code: Alles auswählen

[7] [Okt 24 08:15:39] Processing class 'COMPUTER_SYSTEM' (Posix.py|2515)
[6] [Okt 24 08:15:39] Condition found, try to check the Condition (Posix.py|2529)
[2] [Okt 24 08:15:40] Traceback: (Logger.py|742)
[2] [Okt 24 08:15:40]      line 1387 in '<module>' in file '/usr/local/bin/master.py' (Logger.py|742)
[2] [Okt 24 08:15:40]      line 126 in '<module>' in file '/tmp/setup.py' (Logger.py|742)
[2] [Okt 24 08:15:40]      line 2483 in 'auditHardware' in file '/usr/lib/pymodules/python2.6/OPSI/System/Posix.py' (Logger.py|742)
[2] [Okt 24 08:15:40]      line 2535 in 'hardwareExtendedInventory' in file '/usr/lib/pymodules/python2.6/OPSI/System/Posix.py' (Logger.py|742)
[2] [Okt 24 08:15:40]      ==>>> local variable 'conditionmatch' referenced before assignment (master.py|1435)
[7] [Okt 24 08:15:40] Backend: <OPSI.Backend.JSONRPC.JSONRPCBackend instance at 0x8aa914c> (master.py|1438)
[7] [Okt 24 08:15:40] ProductId: win7-bbw (master.py|1439)

Netboot Produkt memtest funktioniert.
ein hwinvent von einer boot-cd (Stand 11.2011) funktioniert auch.

folgende Befehle wurden schon ausgeführt:

Code: Alles auswählen

opsi-setup --init-current-config
/etc/init.d/opsiconfd restart
opsi-setup --cleanup-backend

Wir bitten um Unterstützung.

Vielen Dank.
Mike

[d.oertel]

Hi,

wie im Releasehandbuch auch steht:
Die opsi-Produkte (auch die netboot Produkte) müssen auch upgedatet werden.

Code: Alles auswählen

opsi-product-updater -i -vv

gruß
d.oertel

[ma733]

Hallo Herr Oertel,

vielen Dank für die Antwort.

Sie haben natürlich Recht, verschiedene Produkte könnten/müssen ein Update auf unserem Server erhalten.

Dies wird aber noch ein wenig Zeit in Anspruch nehmen, es müssen dann ja die Windows-Netboot-Produkte wieder an das bestehende System angepasst werden
und auch bei den anderen Produkten wie "admin-client-agent" und "winst" haben wir eigene Anpassungen (Design).

Das Problem tritt jedoch auch bei aktuellen Netboot-Produkten und Normal-Produkten auf:

Code: Alles auswählen

hwinvent_4.0-1.opsi - installation not required: installed version '4.0-1' of product 'hwinvent' is up to date
hwaudit_4.0.5-1.opsi - installation not required: installed version '4.0.5-1' of product 'hwaudit' is up to date

Wir konnten nun das Problem mit einer etwas älteren Configurationsdatei die zurückkopiert wurde, beheben.

Code: Alles auswählen

/etc/opsi/hwaudit/opsihwaudit.conf

in der neuen Datei vom 15.10. wurden im Abschnitt "COMPUTER_SYSTEM" diese Daten hinzugefügt:

Code: Alles auswählen

{
         "Type":   "varchar(50)",
         "Scope":  "i",
         "Opsi":   "dellexpresscode",
         "Condition": "vendor=[dD]ell*",
         "Cmd": "#dellexpresscode\dellexpresscode.exe#.split('=')[1]",
         "Python":  "str(int(#{'COMPUTER_SYSTEM':'serialNumber','CHASSIS':'serialNumber'}#,36))"
      }

Mit der Datei vom 15.10. tritt oben beschriebener Fehler auf, mit einer Datei aus der Datensicherung nicht.

Gruß Mike

[ueluekmen]

Hi,

wir haben fest gestellt, dass es bei einigen Computer-Modellen Probleme gibt, wenn man das Bootimage über USB für den UEFI-Boot probiert. Uns ist noch nicht aufgefallen, dass so etwas auch über den normalen Legacy-PXE-Boot vom opsi-linux-bootimage passiert. Wir arbeiten momentan an einem Fix für dieses Problem. Allerdings sind wir momentan noch am anaylisieren. Diesen Fehler können wir beheben, allerdings ist die Ursache des Problems noch nicht klar definiert. Da das Hardwareinventory an der Stelle nicht sauber läuft (wahrscheinlich die Ursache), können wir momentan einen Folgefehler in der Treiberintegration nicht ausschliessen. Für uns wäre folgendes sehr interessant:

Tritt dieses Problem bei jedem Client auf? Welche Modelle werden eingesetzt? Hersteller und Modell würden uns weiterhelfen.

Wenn man das Feature dellexpresscode nicht benötigt, ist das zurückspielen einer älteren opsihwaudit.conf ein gangbarer workarround, bis ein Fix erscheint. Für den Fix bitten wir um etwas Geduld, wir werden uns melden, sobald ein neues Bootimage mit dem Fix zur Verfügung steht.

Grüße
e. ueluekmen

[ma733]

Hallo Herr Ueluekmen,

Danke für die Rückmeldung.

Das Problem tritt nur bei PXE Boot auf (hwinvent, W7-x86-install), ein UEFI Boot wird nicht genutzt.
- bei allen getesteten Clients
- Hardware jeweils unterschiedlich, Mainboard immer Intel, (Sound, Grafik, Lan on Board), individuell Systeme von verschiedenen Lieferanten, keine Dell PC's im Unternehmen.

- nur Windows 7 x86 Clients werden mit OPSI genutzt.

Mit freundlichen Grüßen
Mike

[tmausch]

Hallo Herr Ueluekmen,

Danke für die Rückmeldung.

Das Problem tritt nur bei PXE Boot auf (hwinvent, W7-x86-install), ein UEFI Boot wird nicht genutzt.
- bei allen getesteten Clients
- Hardware jeweils unterschiedlich, Mainboard immer Intel, (Sound, Grafik, Lan on Board), individuell Systeme von verschiedenen Lieferanten, keine Dell PC's im Unternehmen.

- nur Windows 7 x86 Clients werden mit OPSI genutzt.

Mit freundlichen Grüßen
Mike

Sieht bei uns genauso aus, nur das wir Win7 x64 einsetzen.

[ueluekmen]

Hallo,

dieses Problem hängt nicht am eingesetzten Betriebssystem. Wir haben nach wie vor keine Erklärung, warum das bei eingen Hardware-Modellen auftritt.

Auch diesem Grund haben wir einen Quick-Fix veröffentlicht, der zumindest in diesem Fall nicht abbrechen sollte. Allerdings sollte man, wie ich schon weiter oben angedeutet habe, diese Clients genauestens checken, ob die Treiberintegration dort läuft. Denn wenn die Hardwareinventarisierung nicht richtig läuft (Hauptursache für das Problem) kann die Treiberintegration davon negativ beeinflusst werden, weil diese auf die Hardwareinventarisierung angewiesen ist. Einzige Ausnahme ist das klassische additional Verfahren über Product-Property, dieses Verfahren ist nicht direkt mit der Hardwareinventarisierung gekoppelt.

Es gibt ein neues opsi-linux-bootimage im Experimtal-Bereich mit der Version 20121024-1, dieses kann man über das Experimental-Repository manuell runterladen:

http://download.opensuse.org/repositori ... erimental/

Damit sollten die Installation weiterlaufen. Über eine Rückmeldung würden wir uns sehr freuen.

[s.winter]

Hallo,
wir haben das gleiche Problem (Windows-XP-Netboot-Produkt per PXE), jedoch auch nur bei Rechnern mit Intel DG33BU-Motherboard. Halte mich an den Vorschlag von Mike: Entferne ich die Zeile

Code: Alles auswählen

{
         "Type":   "varchar(50)",
         "Scope":  "i",
         "Opsi":   "dellexpresscode",
         "Condition": "vendor=[dD]ell*",
         "Cmd": "#dellexpresscode\dellexpresscode.exe#.split('=')[1]",
         "Python":  "str(int(#{'COMPUTER_SYSTEM':'serialNumber','CHASSIS':'serialNumber'}#,36))"
      }

aus der Datei

Code: Alles auswählen

/etc/opsi/hwaudit/opsihwaudit.conf

funktioniert die Hardwareinventarisierung und die Installation.

Mir ist aufgefallen, dass es nur eine einzige Zeile mit einer Python-Anweisung in der opsihwaudit.conf gibt. Und das ist genau die, die Mike und ich auskommentiert haben, um das System zum Laufen zu bekommen. Da liegt doch der Verdacht nahe, dass eingebettetes Python in der opsihwaudit.conf grundsätzlich nicht läuft, oder? Irgendwie würde das auch zu der Fehlermeldung passen. Ich vermute, dass der entfernte Code nur bei den Boards angesprochen wird, die keinen Treffer an früherer Stelle innerhalb der Sektion "COMPUTER_SYSTEM" haben, da die Python-Anweisung er ja am Schluss der Sektion "COMPUTER_SYSTEM" steht.
LG
Stephan

[ueluekmen]

Hallo,

dass eingebettetes Python in der opsihwaudit.conf grundsätzlich nicht läuft

falsch. Das klappt sehr wohl, ansonsten würde das bestimmen des Dell-Expresscode im hwinvent nicht funktionieren. Das ist aber hier gar nicht das Problem, weil der Absturz schon passiert, bevor das ganze läuft. Der Auslöser des ganzen kommt von der Zeile:

Code: Alles auswählen

"Condition": "vendor=[dD]ell*"

Bei der Implementierung waren wir zu gutgläubig. Da wir davon ausgegangen sind, dass im vendor immer etwas erkannt wird. Da an der Stelle sogar VMWare oder KVM-Maschinen einen Eintrag haben. Bis hierhin ist uns in der Inventarisierung nie aufgefallen, dass dieses Feld auch mal leer sein kann, deshalb macht folgendes:

jedoch auch nur bei Rechnern mit Intel DG33BU-Motherboard

einen Sinn. Das Inventarisierungs-Verfahren mit Embedded-Python und Condition wurde umgesetzt, da es nicht immer eine Möglichkeit gibt auf direktem Weg an die Informationen zu gelangen. Im Fall vom dell-Expresscode ist es so, dass es dieser nirgends steht, er wird einfach aus der Seriennummer berechnet, macht aber nur bei Dell-Rechnern sinn. Daher der etwas umständliche, aber flexibel einsetzbare Weg.

Im meinem vorherigen Thread ist ein Link auf ein Bootimage, welches nicht mehr zu dem Absturz führt, aber eine Gewisser Beigeschmack bleibt bei der Sache, wenn dieser Eintrag schon fehlt, ist die Wahrscheinlichkeit hoch, dass noch mehr Informationen im Inventory fehlen.

Grüße
e. ueluekmen

[ehrgeiz]

habe hier genau das gleiche Problem - nur mit Windows XP x86

Code: Alles auswählen

[7] [Nov 06 13:15:11] Processing class 'COMPUTER_SYSTEM' (Posix.py|2515)
[6] [Nov 06 13:15:11] Condition found, try to check the Condition (Posix.py|2529)
[2] [Nov 06 13:15:12] Traceback: (Logger.py|742)
[2] [Nov 06 13:15:12]      line 1387 in '<module>' in file '/usr/local/bin/master.py' (Logger.py|742)
[2] [Nov 06 13:15:12]      line 22 in '<module>' in file '/tmp/setup.py' (Logger.py|742)
[2] [Nov 06 13:15:12]      line 2483 in 'auditHardware' in file '/usr/lib/pymodules/python2.6/OPSI/System/Posix.py' (Logger.py|742)
[2] [Nov 06 13:15:12]      line 2535 in 'hardwareExtendedInventory' in file '/usr/lib/pymodules/python2.6/OPSI/System/Posix.py' (Logger.py|742)
[2] [Nov 06 13:15:12]      ==>>> local variable 'conditionmatch' referenced before assignment (master.py|1435)
[7] [Nov 06 13:15:12] Backend: <OPSI.Backend.JSONRPC.JSONRPCBackend instance at 0x8aa962c> (master.py|1438)
[7] [Nov 06 13:15:12] ProductId: winxppro (master.py|1439)

Alle opsi produkte wurden aktualisiert. Keine Anpassungen, ist eine recht frische OPSI installation. Das Datum das beim Bootem vom opsi Image angezeigt wird ist von Juli glaube ich.