Jump to content

Txtsetup.sif issues when adding drivers..


Recommended Posts

Hi!

So we just got our new Dell PowerEdge x9xx series delievered with the Perc 5/I controller. I am currently trying to add support for them and I am having some problems as well as some progress. Here is what I have done so far.

I have added the following into the txtsetup.sif file for the Windows 2003 installation source (on RIS):

***********************************************************************************

[sourceDisksFiles]

percsas.sys = 1,,,,,,_x,2,0,0

[HardwareIdsDatabase]

PCI\VEN_1028&DEV_0015&SUBSYS_1F011028 = "percsas"

PCI\VEN_1028&DEV_0015&SUBSYS_1F021028 = "percsas"

PCI\VEN_1028&DEV_0015&SUBSYS_1F031028 = "percsas"

[sCSI.Load]

percsas = percsas.sys,4

[sCSI]

percsas = "DELL PERC 5/E Adapter RAID Controller"

percsas = "DELL PERC 5/I Adapter RAID Controller"

percsas = "DELL PERC 5/i Integrated RAID Controller"

************************************************************************************

The information has been extracted from the driver .inf files. When using this on the RIS server, the requesting installing client/server works smoothly with no errors. However, we also use CD/DVD based installations and when trying to add the same info as above into source, the installation will halt at the text mode phase with the following error:

"The file percsas.sys could not be found. Press any key to continue" - Of course, the percsas.sys file (main driver) has been added to the i386 directory and is present but still, on the RIS it works, but not from the CD/DVD based installations ? I have used the same tactic to add the "old" DELL RAID drivers called mardi35x.sys to the installations with the same parameters as specified above, with no problem, either on RIS or on from an unattended CD/DVD based installation.

Any clues?

Edited by Br4tt3
Link to comment
Share on other sites


Oki, first problem that I faced was that the older driver (mraid35x.sys) is an existing driver while this one is a new driver not listed within layout.inf and dosnet.inf. I followed Gosh's TXTSETUP.SIF walkthrough to my best, that is I added the following into my dosnet.inf file, [Files] section;

d1,percsas.sys

once the Winnt32.exe setup kicks off and the machine reboots into text mode phase, I can now verify that the driver file (percsas.sys) is located in the C:\$WIN_NT$.~LS\i386 folder (meaning the file is copied down to installation source I guess). So far so good, one thing less to handle... but still, I get the same error message when booting into the text mode portion of the Win32 setup!

Any thoughts on this one?

Link to comment
Share on other sites

The easiest way I've run across to get new model server builds up and running quicky in unattended installs is to do the following:

1) Boot from the manufacturers supplied deployment kit CD and run through its setup. This typically involves entering some values (such as product key, computer name and such) as well as a cd for your flavor of windows operating system.

2) Once you are to the point in this setup where you would normally reboot the server and let the build to commence, power the server off.

3) Boot the server with BartPE and start to look at the goodies the server setup has left you. While the folder structure left on the hard drive is radically different between manufacturers, they all have to play by windows installation rules. This means you'll find a fully configured unattend.txt file of some sort with all the mass storage entries and drivers pre-packed for you. Along with this will come the post configuration software needed to finalize the server deployment. Just roll this part up into your current software installation scheme and you're goood to go.

4) decipher their build process and implement it into your existing unattended build network. (ris, winnt32.exe /unattend setups...ect.

I've gotten server builds up and running within a few hours using this method for pretty much all the server hardware I've run across. We switched frome IBM to HP and the transition was pretty seamless.

It's good to know the fundamentals of mass storage drivers and such but once you have that down, why look a gift horse in the mouth. The majors spend a lot of resources to put together this build process so why try to re-invent their wheel.

Link to comment
Share on other sites

Hi and thanks for the input!

However, I already have a build environment that I am satisfied with so I dont think I will change that part. All I wanna know, if there is something missing in the information stated above, on how to intergrate a new device driver.

Link to comment
Share on other sites

Read Gosh's maunal on how to add the file using dosnet.inf ( http://gosh.msfnhosting.com/txtsetup.htm ) and it turns out that the file contains 2 sections, both named [Files], so I put my reference driver (percsas.sys) next to the old driver (mraid35x.sys) which is also referenced in the sections. This will place the percsas.sys file in the $WIN_NT$.~BT folder during text mode, and the inital error is removed and setup continues about 2 more minutes, before it halts with the following error:

"Setup cannot copy the file: percsas.sys"

But I guess, one thing solved, next to go...

Link to comment
Share on other sites

First off, remove the _x if the file is CAB compressed (ends in .sy_). Second, you shouldn't have three listings under the [sCSI] section.

Hi!

Thanks for the input, I will give it a try..... just one thing!

About the three entries in the [sCSI] section, why not? My guess was that there were 3 unique "strings" to match 3 unique PnP values? or am I off track here?

Link to comment
Share on other sites

Hi and thanks for the input!

However, I already have a build environment that I am satisfied with so I dont think I will change that part. All I wanna know, if there is something missing in the information stated above, on how to intergrate a new device driver.

Same here, I understand your point. My suggestion was merely aimed at the idea that you could run thru the manufacturers setup to get the correct mass storage driver entries within the unattend.txt file their process creates and then integrate it into your new build.

Link to comment
Share on other sites

You're assigning three names to the same percsas controller

Still hmmm, dont get it...

These are 3 diffrent physical controller adapters ( that I am sure off ) that are all covered within one driver file (percsas.sys). If I were to keep only one of the strings, for example, "DELL PERC 5/E Adapter RAID Controller", the installation would always present it as a PERC 5/E even if it was not the external controller but the internal one...

I did a test on it and kept just the string listed above, and even if I didn't have the external one plugged in, the driver would present & detect the internal one as a "DELL PERC 5/E Adapter RAID Controller" which is not the case..

@ brainstane - as u said, did it and they (Dell) are using the unattend.sif method to perform the installation [MassStorageDrivers], and the Dell setup does not make any references for the driver to the txtsetup.sif file. Worth a try though!

Link to comment
Share on other sites

See this?

[SCSI.Load]
percsas = percsas.sys,4

Here you're assigning a name to the driver file you're loading (precsas assigned to percsas.sys).

Later you assign three descriptions to that same name (percsas). Look at the sections you're modifying way more closely than you apparently have at this point. You'll see that each controller listed in [sCSI.Load] has exactly one description for it in [sCSI]. The only place multiple items can be associated with one name is the device IDs.

Get it?

Edited by RyanVM
Link to comment
Share on other sites

See this?
[SCSI.Load]
percsas = percsas.sys,4

Here you're assigning a name to the driver file you're loading (precsas assigned to percsas.sys).

Later you assign three descriptions to that same name (percsas). Look at the sections you're modifying way more closely than you apparently have at this point. You'll see that each controller listed in [sCSI.Load] has exactly one description for it in [sCSI]. The only place multiple items can be associated with one name is the device IDs.

Get it?

Not really, but then again... no to bright either! :wacko:

Anyway, I've done as suggested in ur post with no success... I have contacted MS on this one so lets see what they can come up with and I will post it back to this topic. Thanks for the time and suggestions folks!

@ xian7479 - Tried that combo, but with the same result as earlier

Link to comment
Share on other sites

See this?
[SCSI.Load]
percsas = percsas.sys,4

Here you're assigning a name to the driver file you're loading (precsas assigned to percsas.sys).

Later you assign three descriptions to that same name (percsas). Look at the sections you're modifying way more closely than you apparently have at this point. You'll see that each controller listed in [sCSI.Load] has exactly one description for it in [sCSI]. The only place multiple items can be associated with one name is the device IDs.

Get it?

RyanVM - u r most defintly correct about this I guess. I have now succesfully booted and installed one of the new x9xx Dell servers using the following bits and pieces:

Within the TXTSETUP.SIF file I had to add the following info:

[SourceDisksFiles]
percsas.sys=1,,,,,,_4,4,1,,,1,4

[HardwareIdsDatabase]
PCI\VEN_1028&DEV_0015&SUBSYS_1F011028="percsas"
PCI\VEN_1028&DEV_0015&SUBSYS_1F021028="percsas"
PCI\VEN_1028&DEV_0015&SUBSYS_1F031028="percsas"

[SCSI.Load]
percsas=percsas.sys,4

[SCSI]
percsas = "DELL PERC5 RAID Controller Driver (Server 2003 32-bit)"

I then had to add both percsas.sys and percsas.cat (signature file) to source directory (i386), which is really wiered I would say. Cause my WinPE and RIS installations didnt require this file, just the unattended CD/DVD installations. This of course is also true for the entries in the TXTSETUP.SIF file which worked with first post in this thread.... anyway!

Last thing to do:

Add the following into the DOSNET.INF file within the source directory (i386):

d1,percsas.sys

into the following sections: [Files] & [FloppyFiles.2]

Still, it works but I dont know why it works with the other entries in some of the installations and yet not on the other. I have urged MS to provide some feedback on this issue and hand over some documentation, even though I am not convienced they will! :realmad:

Reporting back if they share something with me...

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...