these drivers will need PnP entries seeded into in the Hive files.

this has been noted by cdob and little bugger and verified by some others.
so far only only Nvidia and Jmicro have been positively identified as failing if this is not done...
It may be that SAS and other Server drivers also need this to be addressed and could be why we were stumped.
- how can a registry entry be required at textmode... HUH? apparently a hive entry will acomplish this.

many txtsetup.oem files contain registry info but only the few drivers that have discontinued (or never had) support for legacy mode will fail.

And, welcome to DriverPacks.
IF it is a consolation at all, I can tell you that any specific server driver can play h*ll in txtmode script, and we've seen some driver requests for "SAS" we could not implement no matter what we tried.

As a matter of fact, I think the latest testpack in DriverPack MassStorage has one of those unsoluble, or paradoxicals (whatever it is one can call them.)
Consider that when you look at a system file, and look at its OEM and INF, and then try all you can to integrate, and you see that whatever you do, the path or name don't work, that this is not our doing, but some quirk inherent in the systemfile and server security requirements 'most probably" were in the requirements of that file developer's mind.

I just still don't get why it worked before...

EDIT:
Neither outcommenting nor deleting the TAG file helped for slipstreaming.
Only after I deleted all three symmpi files on the source, it would run through.

Currently compiling the ISO and here's hoping TM setup won't complain again!

OK, seems to be working now - phew!

Anyway, the txtsetup.SIF file says:
symmpi   = "LSI Logic PCI Fibre Channel-Hostadapter"

So that's what the file is for.
This entry is already included in the DELL version of the CD, so maybe this is a conflict caused by the fact that a SCSI driver BASE wants to add is already present?

I really don't have any need for that driver (and seeing as it's Fibre Channel, chances that I may stuble across a system sporting this are very slim).
I'd just like to get TM support back up and running, because there is a bunch of drivers I do need for other systems.

I just re-slipped the BASE using the same options as before minus TM support for DPMS (as it isn't needed on this very machine I am setting up atm).
I was using the old, non-working source btw (too lazy to copy from the backup pre-BASE ISO ).
Works so far as getting me to the partition selection screen.
Haven't tried any further yet (did put Ubuntu on it out of despair...), will do so later on.

So I think we really can reduce this one down to DPMS TM...

BTW: $OEM$ only contains cmdlines.TXT

the common denominator is not apparent to me ATM... still thinking about it though...

The Dell OEM CD maybe?

Dunno, just a thought.
Will try later with my Original SP0 slipstreamed to SP2 slipstreamed to SP3 CD...

Anyway, what IS the file good for and if it's not that critical, is there a way to simply ignore it and have textmode setup continue?
Currently, I cannot get this system installed that I would very much like to finish over the weekend.

Obviously, as it only uses a standard IDE controller, I could do without DPMS (or the TM part of it), but I'd still love to solve this one for my UWXPDVD just because, you know...

PS: As for the $OEM$ folder:
I dunno what Dell put inside it but slipstreaming the SP3, nLite offered and was told to do so to remove all 3rd party changes done to the SP2 CD.
I was expecting no difference to an ordinary SP2 CD slipstreamed to SP3.

Anyway, it may include something due to the addons I include, but I have been doing so for over three years straight...

i first thought this may be a permissions issue with vista but helmi was useing XP...
then i thought it might be german source but englebert is obviously useing english US
the common denominator is not apparent to me ATM... still thinking about it though...

all three of us used QSC ON (Please try with qsc off, although this is unlikely to be the problem)
all three of us did not use a clean source (it looked like the $OEM$ folder existed in all three cases)

the mass storage INI is valid... no extra spaces or apparent typos. the smmpi file itself is valid.

I expected to find an extra space for the "TAG" entry in the mass storage INI... but no...

hmmmm...

I now had both the symmpi.SYS as well as symmpi .SYS on the source, yet textmode would still complain about the symmpi.SYS file lacking...

Did you manage to successfully get past TM setup?
I don't know what else I could try for the moment.

Also, yes, the DPMS ini file might be wrong, I guess (because that is the only factor that may have changed between my last successful try and now), however, I have not yet had the chance to take a closer look at it (currently setting up a network printer/scanner...).
Maybe tonight unless someone else from the team beats me to it

Ususally, no files on the source have spaces in them, in fact, most are 8.3 compliant.
I am currently trying a workaround by creating a duplicate file on the source that has the space while leaving the one that has not (I found out that if you simply rename it, Win setup will stall during textmode phase because the file without space is then missing).
Let's see how that works out.

The file ending with the underscore (_) only means it is a CABbed file while files without it are normal (uncompressed) files.
And yes, you should find the one with .SYS because that is about to be CABbed (as the error say).
Afterwards, you'd find the .SY_ file.