forum.opsi.org

Hi,

thanks for your reply.

i just tried 4.0.2-2 from experimental (not x64 but x86, but i guess it's not really important) and it still didn't work.

i also compared logfiles about integrating textmode drivers

new version (4.0.2.x):

#grep -i "textmode" bootimage.log

[7] [Feb 14 18:11:20] Got windows driver: {'hardwareInfo': <AuditHardwareOnHost hostId 'mytoys-0286.ber.mytoys.de', hardwareClass 'PCI_DEVICE', name '7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode]'>, 'vendorId': u'8086', 'buildin': False, 'textmode': True, 'deviceId': u'1E02', 'directory': u'winxppro_neu2/drivers/pciids/8086/1E02'} (WindowsDrivers.py|292)

old version (4.0.1.x):

#grep -i "textmode" bootimage.log

[6] [Jan 21 11:56:31] Trying to integrate textmode driver for storage controller: {'device': u'scsi0', 'vendorId': u'8086', 'hwPath': u'/0/100/1f.2', 'description': u'Panther Point 6 port SATA Controller [AHCI mode]', 'deviceId': u'1E02'} (setup.py|166)
[5] [Jan 21 11:56:31] Integrating textmode drivers (WindowsDrivers.py|317)
[7] [Jan 21 11:56:31] Textmode driver '/mnt/hd/drv/18' supports device {'vendorId': u'8086', 'deviceId': u'1E02'} (WindowsDrivers.py|340)
[5] [Jan 21 11:56:31] Integrating textmode driver '/mnt/hd/drv/18' (WindowsDrivers.py|350)
[6] [Jan 21 11:56:31] Copying from '/mnt/hd/drv/18/iaStor.sys' to '/mnt/hd/$/textmode/iaStor.sys' (__init__.py|257)
[6] [Jan 21 11:56:31] Copying from '/mnt/hd/drv/18/iaAHCI.inf' to '/mnt/hd/$/textmode/iaAHCI.inf' (__init__.py|257)
[6] [Jan 21 11:56:31] Copying from '/mnt/hd/drv/18/iaAHCI.cat' to '/mnt/hd/$/textmode/iaAHCI.cat' (__init__.py|257)
[6] [Jan 21 11:56:31] Copying from '/mnt/hd/drv/18/txtsetup.oem' to '/mnt/hd/$/textmode' (__init__.py|257)
[5] [Jan 21 11:56:31] Registering textmode drivers in sif file '/mnt/hd/$win_nt$.~bt/winnt.sif' (WindowsDrivers.py|374)

nice to see, that there are 2 names for one device : "Panther Point 6 port SATA Controller" and "7 Series/C210 Series Chipset Family 6-port SATA Controller" but both have the same ID 8086/1E02 (based on pci.ids)

i parsed some show_drivers results and removed additional drivers

so it looks pretty good:

[8086:1E02] Intel Corporation : 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode]
/opt/pcbin/install/winxppro_neu2/drivers/drivers/preferred/ahci (textmode capable) <- green highlighted, but still not getting integrated

so, it still do not work at all

greetings

nun habe ich ein händisches rollback auf eine alte miniroot + kernel version für tftpboot durchgeführt

ich nutze nun wieder "miniroot-20120119.bz2" und "vmlinuz-3.2.1", obwohl dies probleme mit windows 7 bereitet

es wäre also schön, wenn "miniroot-20120728.bz2" und "vmlinuz-3.5.2" mit der treiber integration unter windows xp genauso verfährt, wie das alte image

denn derzeitig muss ich mich zwischen windowsxp und windows7 entscheiden und dies ist sehr unpraktisch

danke und gruß

Hi,

das Problem liegt nicht an opsi, sondern an den Intel Chipsatz-Treibern. Die fühlen sich nämlich für gefühlt 1000 Geräte verantwortlich, obwohl Sie keine Treiber zur Verfügung stellen. Intel sagt, aus Gründen der Kompatibilität, muss das so sein.

Ich würde folgendes versuchen, opsi-linux-bootimage: das aktuelle nochmal einspielen.

Den SATA-Treiber über additional oder byAudit integrieren. Dort wird keine Duplikatssuche gemacht. Sollte ich recht haben mit meiner Annahme, dann stören zwei bestimmte inf-Dateien aus dem Chipsatz-Treiber die Installation von Windows XP mit Intel AHCI-Geräten.

mdruve hat geschrieben:nice to see, that there are 2 names for one device

das kommt daher, dass die PCI-Definitionsdatei von Zeit zu Zeit aktualisiert wird. Die bezeichnung des Geräts ist aber nur eine Anzeige, damit die Ausgaben besser lesbar sind, die interne Treiberintegration interessieren diese Bezeichner nicht.

Hi,

ich habe die ganzen Treiber für den PC (HP Compaq Pro 6000) als additional integriert. Er findet ihn ja auch, aber er wird nicht integriert, genauso wie der Rest.
Es gibt von HP sehr schön fertige Treiber (INF) Pakete, die man einfach nur runterladen und in additional packen muss, um sie zu benutzen.
Das hat auch bis zum Update für verschiedene HP Geräte problemlos geklappt.
Seit dem Update wird der AHCI Treiber bei keinem Gerät mehr geladen bzw integriert.
Gefunden werden sie aber.
Dafür sprechen in meinen Augen auch meine Logauszüge oder?

Ich ändere nichts an den Einstellungen für das netboot packet, ich ändere auch nicht die Treiber.

Es reicht einzig und allein die Änderung des bootimages und des kernels, um die Integration zu gewährleisten.
Somit liegt es in meinen Augen nicht an den Treibern, sondern an der geänderten Art Treiber zu integrieren.

1. winxppro 4.0.1-3 Windows XP professional - x86 - deutsch
2. winxppro_neu 4.0.2-1 Windows XP professional - x86 - deutsch
3. winxppro_neu2 4.0.2-2 Windows XP professional - x86 - deutsch

das 1. nutze ich für das alte bootimage, 2 und 3 habe ich zusätzlich für das neue bootimage getestet, als das 1. nicht mehr funktionierte
die treiber liegen alle an den selben orten

ls -la /opt/pcbin/install/winxppro/drivers/drivers/additional/6300sff/
insgesamt 40
drwxrws--- 10 opsiconfd pcpatch 4096 31. Okt 15:26 .
drwxrws--- 18 opsiconfd pcpatch 4096 14. Feb 10:48 ..
drwxrws--- 4 opsiconfd pcpatch 4096 31. Okt 15:25 driver - audio
drwxrws--- 3 opsiconfd pcpatch 4096 31. Okt 15:25 driver - chipset
drwxrws--- 4 opsiconfd pcpatch 4096 31. Okt 15:25 driver - graphics
drwxrws--- 3 opsiconfd pcpatch 4096 31. Okt 15:25 driver - keyboard, mouse and input devices
drwxrws--- 5 opsiconfd pcpatch 4096 31. Okt 15:25 driver - network
drwxrws--- 3 opsiconfd pcpatch 4096 31. Okt 15:26 driver - security
drwxrws--- 3 opsiconfd pcpatch 4096 31. Okt 15:26 driver - storage
drwxrws--- 3 opsiconfd pcpatch 4096 31. Okt 15:26 driver - system management

ls -la /opt/pcbin/install/winxppro_neu/drivers/drivers/additional/6300sff/
insgesamt 36
drwxrws--- 9 opsiconfd pcpatch 4096 14. Feb 17:22 .
drwxrws--- 3 opsiconfd pcpatch 4096 14. Feb 16:40 ..
drwxrws--- 4 opsiconfd pcpatch 4096 14. Feb 11:09 driver - audio
drwxrws--- 4 opsiconfd pcpatch 4096 14. Feb 11:08 driver - graphics
drwxrws--- 3 opsiconfd pcpatch 4096 14. Feb 11:08 driver - keyboard, mouse and input devices
drwxrws--- 5 opsiconfd pcpatch 4096 14. Feb 11:08 driver - network
drwxrws--- 3 opsiconfd pcpatch 4096 14. Feb 11:08 driver - security
drwxrws--- 3 opsiconfd pcpatch 4096 14. Feb 11:08 driver - storage
drwxrws--- 3 opsiconfd pcpatch 4096 14. Feb 11:09 driver - system management

^^ hier habe ich sogar schon chipsatz treiber komplett entfernt, weil die sich ja auch manchmal für den AHCI part verantwortlich fühlen, aber keinen textmode haben,
ist aber bei der alten variante sogar egal, da prefered vor additional herangezogen wird, so wie es der name auch aussagt, preferred = bevorzugt

ls -la /opt/pcbin/install/winxppro_neu2/drivers/drivers/preferred/ahci
insgesamt 536
drwxrws--- 2 opsiconfd pcpatch 4096 14. Feb 17:31 .
drwxrws--- 3 opsiconfd pcpatch 4096 14. Feb 17:30 ..
-rw-rw---- 1 opsiconfd pcpatch 8744 16. Aug 2012 iaahci.cat
-rw-rw---- 1 opsiconfd pcpatch 4905 16. Aug 2012 iaahci.inf
-rw-rw---- 1 opsiconfd pcpatch 7954 16. Aug 2012 iastor.cat
-rw-rw---- 1 opsiconfd pcpatch 3410 16. Aug 2012 iastor.inf
-rw-rw---- 1 opsiconfd pcpatch 470808 16. Aug 2012 iastor.sys
-rw-rw---- 1 opsiconfd pcpatch 22644 16. Aug 2012 license.txt
-rw-rw---- 1 opsiconfd pcpatch 5617 16. Aug 2012 txtsetup.oem

^^ sind mit winxppro identisch

ich bin gerne bereit verschiedenste dinge zu testen
ich habe sogar die additional treiber schon komplett weggelassen und nur unter prefered den ahci gehabt -> kein erfolg, obwohl trotz show_drivers.py die Treiber gefunden wurden

drwxrws--- 3 opsiconfd pcpatch 4096 31. Okt 15:26 driver - storage <- in diesem paket unter additional sind die textmode ahci treiber nochmals enthalten, obwohl sie schon unter preferred liegen

sie wurden also immer über preferred und additional geladen, es sind auch die selben dateien, dennoch werden sie nicht integriert

Danke für die Mithilfe!

Hi,

verkürzen wir das ganze doch mal. Mach am besten einen lauf mit den aktuell vorhandenen Versionen und schicke die bootimage.log mit Referenz auf diesen Thread an info(at)uib.de

Mit Codeschnipseln zu arbeiten ist schwierig, um richtig analysieren zu können brauchen wir die ganze Logdatei. Vielleicht hast du auch recht und es handelt sich um einen Bug. Sowas kann man ohne Analyse nie ausschliessen.

Hi,

danke für das Angebot, die Mail habe ich heute verschickt.
Sie enthält 4 Logfiles aus 4 möglichen Szenarien.

Falls Fragen sind entweder per Mail oder hier.

Danke und Gruß

Wir haben hier das gleiche Problem mit diversen DELL-Rechnern (u.a. derzeit Optiplex 790 und 7010) mit dem Paket winxppro 4.0.1 bzw. einem eigenen, leicht modifizierten Paket.
Die Textmode-Treiber liegen unter den additional_drivers fuer die Rechner und ausserdem unter preferred.
Ergebnis des Installationsversuchs ist der bekannte 7B-Bluescreen.

Bei der Fehlersuche stellt sich heraus, dass die Variable storageControllerInfo in setup.py leer ist und daher wohl kein Textmode-Treiber integriert wird (sofern ich den Mechanismus richtig verstanden habe).

Die weitere Analyse fuehrt dann zu OPSI/System/Posix.py und hier die Funktion getBlockDeviceControllerInfo.
Fuer die Integration des richtigen Treibers wird hier die Ausgabe von lshw geparst. Allerdings liefert das Tool nicht das erwartete Ergebnis, die Funktion liefert somit nichts zurueck.

Auf einem Optiplex 7010 liefert lshw: Fuer das Device scsi0 wuerde hier ebenfalls die Description "Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1E02]" erwartet. Hier liegt nun anscheinend das Problem!
Bei anderen Rechnern als den Optiplex tritt das Problem nicht auf; hier sind die Devices scsi* mit der erwarteten Description versehen und die Treiberintegration gelingt erwartungsgemaess.

Ein moeglicher Workaround waere es die Ausgabe von lshw nach dem Hardware-Path /0/100/1f zu parsen.

Gruesse,
JUB

Hi,

@mdruve: Die Logdateien zeigen, dass bei dir die Duplikatssuche zuschlägt. Welcher Treiber da stört ist aus der Log nicht richtig raus zu lesen. Probiere mal ein show_drivers.py für den Client aus zu führen. Das Windows-Paket muss aber aktuell sein. Die neueren WIndows-Pakete haben ein angepasstes show_drivers.py implementiert. Dort wird nicht nur gezeigt welcher Treiber integriert wird, sondern mittlerweile auch bei Problemen Hinweise auf die Inf-Datei gibt, welche stört.

@jub: Versuche bitte das Bootimage aus Testing. Das Problem welches du beschreibst liegt an einem Bug im lshw, das hast du schon richtig erkannt. Das Problem ist, dass du nicht einfach so nach diesem Hardwarepfad gucken kannst, da dieser Pfad nicht immer der selbe ist. Normalerweise wird versucht heraus zu finden an welchem Controller die Festplatte angeschlossen ist, in einigen Fällen (mir ist ein Intel-Chipsatz bekannt) zeigt lshw an, dass die Festplatte an einem Hardwarepfad hängt, den es nicht geben dürfte. Die neuen bootimages integrieren in solchen fällen den Controller trotzdem, auch wenn kein Gerät daran erkannt wurde.

@jub: Versuche bitte das Bootimage aus Testing. [...]

Witzigerweise entspricht der dirty-hack im Testing-Bootimage fast genau meinem eigenen Hotfix mit dem ich die Posix.py zwischenzeitlich versehen hatte. Insofern funktioniert es damit erwartungsgemäss.

In den Aufruf von lshw hatte ich noch die Option -class storage eingebaut; das beschränkt die Ausgabe auf das Wesentliche.

btw: Auf anderen Systemen (Scientific Linux 6.3 / lshw B.02.14) war die Ausgabe von lshw auf der gleichen Hardware wie erwartet.

Grüsse,
JUB

Hi,

wir haben vor das bootimage komplett zu überarbeiten. Wir werden als erstes auf Precise Upgraden und dann noch mal alle Komponenten einzeln einem Upgrade unterziehen. Das war schon länger geplant, aber es hat vor der Cebit einfach nicht mehr in den Zeitplan gepasst. Wir planen nach der Cebit diese arbeiten zu starten. Einfach den News-Bereich mal im Auge behalten, da kommt noch was...