[DK2000]

Ja, das ist ja das Problem, was ich mit offizieller Dokumentation meinte.

Für was ist der Ordner wirklich gut?

[OEMBootFiles] ist z.B. ausschließlich für OEM HALs, MassStorageDrivers und F6 Bootdisketten gedacht. Andere Treiber dürfen da nicht rein.

Bei den geposteten Logs versucht der gute mensch Treiber für die Grafikkarte zu installieren, und das scheint wohl zu scheitern. An der Kompriemierung dürfte es nicht liegen, da die Dateien dekomprimiert werden:

Zitat

#-336 Copying file "C:\OEM\nvcpl.dl_" to "C:\WINDOWS\system32\nvcplins.dll" via temporary file "C:\WINDOWS\system32\SET1C5.tmp".

Das ist bis hier normal. Aber aus irgendeinem Grund ist er nicht in der Lage, die Registryeinträge zu schreiben, da er offensichtlich keinen flüchtigen/löschbareb Key mag:

Zitat

#E008 Setting registry value HKLM\Software\NVIDIA Corporation\Global\NvSvc\OemConfigurations\LoadLimitedSID
#E033 Error 1021: Cannot create a stable subkey under a volatile parent key.

Dadurch bricht der Geräte Installer oder besser der Geräteklassen Installer natürlich die Installation ab:

Zitat

#E154 Class installer failed. Error 0xe0000203: There is no driver selected for the device information set or element.

Besteht natürlich der Verdacht, das [OemInfFiles] eine vergleichbare Funktion wie [OEMBootFiles] hat und nur für bestimmte Geräteklassen gedacht ist.

Muss mir mal das Driver DDK anschauen, ob da etwas über diese Einträge stehen.

Dieser Beitrag wurde von DK2000 bearbeitet: 15. Juli 2005 - 11:56

[Fernando]

@ DK2000:
Meine Vermutung, dass man die TXTSETUP.SIF überhaupt nicht ändern muss, wenn man die richtigen NVIDIA Sata/Raid-Treiber mit nLite (v. 1.0 b4) trotz Warnmeldung als TEXTMODE-Treiber einbindet, hat sich inzwischen in mehreren Tests bestätigt.
Getestet habe ich übrigens auch, ob sich die angeblich WHQL-zertifizierten Sata/Raid-Treiber aus dem Paket 6.66 ohne die [OemInfFiles]-Hintertür korrekt einbinden lassen. Ergebnis: Endlos-Reboots.

@ Alle:
Das macht die Integration dieser widerspenstigen x64-Treiber natürlich noch einfacher.
Um den Interessenten zukünftig die offenbar unnötige Mehrarbeit zu ersparen, habe ich meine Anleitung (siehe Sticky Thread) inzwischen angepasst.

CU
Fernando

Dieser Beitrag wurde von Fernando bearbeitet: 15. Juli 2005 - 16:34

[Fernando]

Zitat (DK2000: 15.07.2005, 00:49)

Irgendwo muss es doch Informationen zu [OemInfFiles] geben. Der Eintrag kann doch nicht so geheim sein, dass es nichts offizielles dazu gibt.
<{POST_SNAPBACK}>

Nuhi, der "Macher" von nLite, hat sich dazu im nLite-Forum unmittelbar nach der Veröffentlichung der neuen nLite-Version 1.0 Beta5 wie folgt geäußert:

Zitat (nuhi: Jul 16 2005, 01:56 AM)

as far as I remember in changelog states that x64 raid is not fixed.
Yeah that's the thing, thanks to Fernando 1 for it.

Fernando 1, yeah, based on that proven method which is officially recommended by MS I'll try to make it generic so you can choose which method to use in Textmode integration since it's obvious x64 doesn't like the old style.

Aus seinem Beitrag geht hervor, dass diese Methode zur "zwangsweisen Installation" widerspenstiger Treiber von Microsoft ausdrücklich empfohlen wird und er (Nuhi) sie daher in die nächste nLite-Version einbauen werde.

Dieser Beitrag wurde von Fernando bearbeitet: 17. Juli 2005 - 08:45

[DK2000]

Habe das jetzt auch mal mit nlite versucht. nlite geht da interessante Wege und weicht etwas von der klassischen Methode ab, scheint aber effektiver zu sein.

Zitat

Aus seinem Beitrag geht hervor, dass diese Methode zur "zwangsweisen Installation" widerspenstiger Treiber von Microsoft ausdrücklich empfohlen wird

Ist bloss die Frage, wo das bei MS steht. Offiziell habe ich dazu nichts gefunden, nur soweit festgestellt, das Controllertreiber, welche über [OemInfFiles] installiert werden, im Prioritätssystem anders behandelt werden. Allerdings wirklich nur Controllertreiber. Treiber aus anderen Geräteklassen lassen sich darüber nicht installieren.

Axo, [OEMBootFiles] funktioniert nach wie vor nicht, wenn man von CD bootet. Kommt immernoch diese wilde Fehlermeldung mit Zeile 1747 irgendwo im Quelltext des Setup.

Gut, wie auch immer. Mal das ganze jetzt mit den neuen offiziellen Treibern testen: s. hier
Die Treiber sind jetzt offiziel signiert und werden bei nvidia angeboten. Mal schauen, ob sich da etwas geändert hat.

EDIT: Falscher Gedankengang gelöscht.

Dieser Beitrag wurde von DK2000 bearbeitet: 16. Juli 2005 - 12:14

[Fernando]

Zitat (DK2000: 16.07.2005, 12:00)

Axo, [OEMBootFiles] funktioniert nach wie vor nicht, wenn man von CD bootet. Kommt immernoch diese wilde Fehlermeldung mit Zeile 1747 irgendwo im Quelltext des Setup.

Bei mir funzt das einwandfrei!

Zitat (DK2000: 16.07.2005, 12:00)

Mal das ganze jetzt mit den neuen offiziellen Treibern testen: s. hier
Die Treiber sind jetzt offiziel signiert und werden bei nvidia angeboten. Mal schauen, ob sich da etwas geändert hat.

Das habe ich schon probiert. Ohne Verwendung der [OemInfFiles]-Methode lässt sich bei mir auch der lt. NVIDIA voll WHQL-zertifizierte Sata/Raid-Treiber nicht erfolgreich einbinden. Am Ende der Installlation bekam ich wieder die bekannten Endlos-Reboots.

Dieser Beitrag wurde von Fernando bearbeitet: 16. Juli 2005 - 11:27

[DK2000]

Zitat

Bei mir funzt das einwandfrei!

mh? Wie hast Du das hinbekommen. Ich habe das jetzt nochmal mit beiden Windows (32bit und 64bit) getestet, aber lande immer in diese nichstsagenden Fehlermeldung.

Dabei habe ich mich genau an das gehalten, was in der deploy.chm beschrieben wurde und auch mal mit einer selbstgeschriebenen txtsetup.oem (nach Beschreibung im DDK). Egal wie, es klappt nicht, sobald das Setup durch CD Boot gestartet wird. Bei der 32bit Version klappt es aber, wenn ich das Setup über DOS starte, bei der 64bit Version habe ich das nicht getestet.

Mit den neuen Treibern hast Du das also auch schon getestet. Mh? Da ist doch irgendwo der Wurm drin, wenn das auch nicht klappt. Dumm, dass ich das z.Z. nicht mit RAID testen kann.

Dieser Beitrag wurde von DK2000 bearbeitet: 16. Juli 2005 - 11:38

[Fernando]

Zitat (DK2000: 16.07.2005, 12:00)

Wenn ich die Treiber allgemein so vergleiche, glaube ich fast, das Treiber mit dem Namen nvraid.sys/nvata.sys für AMD Platformen sind und Treiber mit dem Namen nvrdx64.sys/nvatax64.sys für Intel Platformen sind. Kann sein, dass die ganzen Probleme nur deswegen zustande kommen. Jedenfalls heißen die offiziellen Treiber für AMD Platformen wieder nvraid.sys/nvata.sys.

Das kann ich nicht nachvollziehen. Bei mir finde ich nach dem Entpacken des neuesten und speziell für AMD-Systeme gedachten Paketes 6.66 immer noch die SYS-Dateien mit den Bezeichnungen nvatax64.sys und nvrdx64.sys (wie in den "Intel-Paketen" 7.12 und 7.13).
Die Änderung der Bezeichnung der beiden SYS-Dateien durch NVIDIA hängt wohl eher damit zusammen, dass die ersten 64-bit-fähigen nForce-Treiber (bis v. 6.39) noch abwärtskompatibel zu 32-Bit-Systemen waren.

m

Zitat (DK2000: 16.07.2005, 12:36)

Wie hast Du das hinbekommen. Ich habe das jetzt nochmal mit beiden Windows (32bit und 64bit) getestet, aber lande immer in diese nichstsagenden Fehlermeldung.

Ich habe es exakt mit der von mir beschriebenen Methode unter Verwendung von nLite gemacht - es funzte wie bei allen anderen von mir getesteten Treibern (inkl. 7.13) einwandfrei!

[DK2000]

Was die Treibernamen angeht:

Vergiss, was ich geschrieben was ich dazu geschrieben habe. Habe gerade festgestellt, das ich die 32bit Treiber gezogen und in XP x64 eingebunden hatte. Das ging natürlich voll in die Hose. Die x64 Treiber haben immernoch die bekannten Namen nvrdx64.sys/nvatax64.sys.

Zitat

Ich habe es exakt mit der von mir beschriebenen Methode unter Verwendung von nLite gemacht

Mh? Bin ich blind? Also ich meine jetzt die Methode, die F6 Diskette 1:1 einzubinden, ohne irgendwelche Dateien zu modifizieren (hier für 32bit Windows, ist aber bei 64bit genauso beschrieben):

- Treiberdisette 1:1 nach ~\$OEM$\TEXTMODE

- In der winnt.sif steht dann folgendes:

[MassStorageDrivers]
"NVIDIA NForce Storage Controller (required)" = "OEM"

[OEMBootFiles]
disk1
nvata.cat
nvatabus.inf
NvAtaBus.sys
nvcchflt.sys
nvraid.cat
nvraid.inf
nvraid.sys
txtsetup.oem

Das klappt, wenn man über DOS startet, aber wenn man über die CD Bootet, kommt da ein nichtssagender Fehler:

File txtsetup.oem caused an unexpected error (18) at line 1747 in d:\xpsprtm\base\boot\setup\oemdisk.c.

Dieser Beitrag wurde von DK2000 bearbeitet: 16. Juli 2005 - 12:23

[Fernando]

Zitat (DK2000: 16.07.2005, 13:13)

Mh? Bin ich blind? Also ich meine jetzt die Methode, die F6 Diskette 1:1 einzubinden, ohne irgendwelche Dateien zu modifizieren (hier für 32bit Windows, ist aber bei 64bit genauso beschrieben):

- Treiberdisette 1:1 nach ~\$OEM$\TEXTMODE

- In der winnt.sif steht dann folgendes:

[MassStorageDrivers]
"NVIDIA NForce Storage Controller (required)" = "OEM"
 
[OEMBootFiles]
  disk1
  nvata.cat
  nvatabus.inf
  NvAtaBus.sys
  nvcchflt.sys
  nvraid.cat
  nvraid.inf
  nvraid.sys
  txtsetup.oem

Das klappt, wenn man über DOS startet, aber wenn man über die CD Bootet, kommt da ein nichtssagender Fehler:

File txtsetup.oem caused an unexpected error (18) at line 1747 in d:\xpsprtm\base\boot\setup\oemdisk.c.
<{POST_SNAPBACK}>

Wenn ich ein Betriebssystem (W2k, W2k3, XP oder XPx64) installieren will, boote ich immer direkt von der CD.
Mit der Einbindung der nForce 32-Bit-SATA/Raid Treiber hatte ich nie Probleme, weder mit der F6/Floppy-Methode noch mit selbstgestrickten Unattended-Install-CD's.
Meine Schwierigkeiten bestanden darin, dass ich XP x64 unter Verwendung der nativen 64-Bit nForce Raid-Treiber (ab Paket-Version 6.56) lange Zeit überhaupt nicht installieren konnte, zumindest nicht mit der F6/Floppy-Methode. Vermutlich könnte man dieses Problem durch eine Änderung der Datei txtsetup.oem lösen. Damit habe ich mich jedoch bisher nicht beschäftigt.

[DK2000]

Zitat

Mit der Einbindung der nForce 32-Bit-SATA/Raid Treiber hatte ich nie Probleme, weder mit der F6/Floppy-Methode noch mit selbstgestrickten Unattended-Install-CD's.

Ja, damit habe ich ja auch keine Probleme, wenn man das nach der klassischen Methode macht, so wie Du sie auch beschrieben hast. Es funktioniert halt nicht die Methode über ~\$OEM$\TEXTMODE (den MS eigentlich dafür geschaffen hat), wenn man von CD bootet. Das funktioniert über DOS, nur wer will das schon, über DOS zu installieren.

Zitat

Vermutlich könnte man dieses Problem durch eine Änderung der Datei txtsetup.oem lösen. Damit habe ich mich jedoch bisher nicht beschäftigt.

Wenn das Setup mir sagen würde, was ihm an der Datei txtsetup.oem nicht gefällt, dann könnte man das ja fixen. Die org. txtsetup.oem sieht gut aus und meine selbstgeschriebene eigentlich auch. Die funktionieren beide, wenn man von DOS aus installiert, nur bei CD Boot, kommt dieser Fehler.

Aber gut, egal. Das war nur mal so ein Test nebenbei und hat mit dem eigentlichen WinXp x64 Problem nichts zu tun.

Dieser Beitrag wurde von DK2000 bearbeitet: 16. Juli 2005 - 13:45

[Fernando]

Wie ich inzwischen festgestellt habe, gibt es auch bei der Einbindung der 32-Bit NVIDIA SATA/RAID Treiber Probleme mit nLite (trotz Verwendung der neuesten Version, mit der lt. Changelog die Probleme gelöst sind).
Auf meinem Rechner jedenfalls lassen sich diese Treiber nicht erfolgreich mit nLite integrieren. Das Raid0-Array wird zwar in der TEXTMODE-Phase richtig erkannt, aber am Ende der Installation verabschiedet sich das OS mit dem mir bereits bekannten Endlos-Reboot.
Besonders erstaunlich finde ich, dass dies auch mit den (angeblich) komplett WHQL-zertifizierten Treibern aus dem offiziellen AMD-Paket for nForce4-Chipsätze, der Version 6.66, passierte.
Hier ist der Link zu meinem Beitrag im nLite-Forum mit der Antwort von Nuhi, dem "Macher" des Tools:
http://www.msfn.org/board/index.php?showto...ndpost&p=354576

Bis auf weiteres ist also für Nutzer eines NVIDIA Sata/Raid-Systems auch bei Windows XP (als "normale" 32-Bit-Version) Handarbeit angesagt.

CU
Fernando

[DK2000]

Das mit den 32bit Treiber ist da interessant. Habe mit denen jetzt noch keine Installation durchlaufen lassen, aber habe gerade vorhin mal die Treiber auf meinem laufenden System installiert, und, das ging voll in die Hose: Windows konnte sich nicht ganz entscheiden, welche Treiber es nehmen sollte, und hat so versucht, mehrere zu installieren. System wurde sehr instabil, im Gerätemanager waren nach der Installation ein Standardtreiber mit einen gelben ! versehen, der PATA von nvidia hatte keine Signatur, aber die normalen SATA Treiber schienen installiert worden zu sein. Allerdings leif das System deutlich zu langsam, was Festplattenzugriffe anging.

ALs ich das ganze wieder Rückgängig machen wollte, landete ich in einer Endlosschleife nach dem ersten Neustart, wo Windows der Ansicht war, die neuen Treiber seinen fertig installiert.

Irgend etwas stimmt da überhaupt nicht mit den Treibern, weder für 32bit noch für 64bit.

Ich werde jetzt erstmal über die x64 Testinstallation alles von der zerschossenen C: Partition retten und dann nochmal einen Clean Installation vornehmen, allerdings glaube ich nicht wirklich, dass das was bringt mit den 6.66 Treibern.

EDIT: Ich habe mir gerade nochmal die Signaturen angeschaut. Allerdings weiss ich jetzt nicht genau, wie das gehandhabt wird. Beim Raid Treiber ist in der .cat eine Datei angegeben (nvraiins.dll), welche aber nicht existiert. Ich weiss jetzt nicht, ob die .cat gegen alle Dateien gecheckt wird und wenn eine fehlt, dass dan das Paket als unsigniert gilt oder ob diese Prüfung nur bei einzelnen Dateien vorgenommen wird und so die fehlende Datei unwichtig ist.

Allerdings wird diese fehlende Datei auch von der .inf gebraucht (also vom GUI Setup) und gehört zum Coinstaller. Ohne diesen werden die Treiber eigentlich nicht vollständig installiert. Anderseits gibt es eine nvraidco.dll, welche nicht im .cat aufgeführt ist, aber ebenfalls in der .inf (gehört auch zum Coinstaller).

Irgendwie glaube ich nicht, dass das Paket so wirklich Signiert und vollständig ist.

Dieser Beitrag wurde von DK2000 bearbeitet: 17. Juli 2005 - 22:21

[Fernando]

Zitat (DK2000: 17.07.2005, 22:38)

Ich habe mir gerade nochmal die Signaturen angeschaut. Allerdings weiss ich jetzt nicht genau, wie das gehandhabt wird. Beim Raid Treiber ist in der .cat eine Datei angegeben (nvraiins.dll), welche aber nicht existiert. Ich weiss jetzt nicht, ob die .cat gegen alle Dateien gecheckt wird und wenn eine fehlt, dass dan das Paket als unsigniert gilt oder ob diese Prüfung nur bei einzelnen Dateien vorgenommen wird und so die fehlende Datei unwichtig ist.

Allerdings wird diese fehlende Datei auch von der .inf gebraucht (also vom GUI Setup) und gehört zum Coinstaller. Ohne diesen werden die Treiber eigentlich nicht vollständig installiert. Anderseits gibt es eine nvraidco.dll, welche nicht im .cat aufgeführt ist, aber ebenfalls in der .inf (gehört auch zum Coinstaller).

Irgendwie glaube ich nicht, dass das Paket so wirklich Signiert und vollständig ist.
<{POST_SNAPBACK}>

Welche Funktion hatte eigentlich der Treiber nvcchflt.sys, der sich bis v. 6.53 in den 32-Bit Treiberpaketen von NVIDIA befand und in den neueren Versionen fehlt?

[DK2000]

Gute Frage, für was genau die nvcchflt.sys macht. In den Dateiinfos steht "NVIDIA® nForce™ Cache Filter Driver". Aber wofür das ganze und wo die geblieben ist, k.a. Taucht allerdings auch in keiner .inf mehr auf, also wird das wohl so i.O. sein, dass die weg ist.

Irgendwie nervt das wieder, das der Endanwender wiedermal als Betatester herhalten muss. Was die 32bit Version angeht, werde ich wohl wieder die IDE Treiber aus dem 6.53 Paket nehmen. Die liefen wenigstens für PATA und SATA.

Dieser Beitrag wurde von DK2000 bearbeitet: 17. Juli 2005 - 22:47

[Fernando]

Danke für die prompte Antwort.

P.S. Es ist schon erstaunlich, wieviele Forenmitglieder sich für unsere Diskussion interessieren (kaum ist ein neues Posting zu sehen - schon 3-4 Viewer!). Das macht doch Freude!