On Nov 22, 2007 10:09 PM, Michael De Groote <[EMAIL PROTECTED]> wrote: > ok, just some following up on this trail: > > at the moment, i dont think it's stable enough to be useful, at least not in > an environment where you need to install more than one machine. Why? > A) because depending on the situation, it throws errors (on eg win2k, it > complains about some weird "COM error with using DOM" > B) the 'add new hardware wizard' is not suppressed. Author claims it is > being suppressed on his system (as far as i can tell from his posts), but i > haven't experienced that yet => you have to click your way through
Have had problems with this too, by wisely clicking through the wizard it turned out that it was a piece of hardware that I dod not provide drivers for in my custom driver pack. Tomorrow I will re-try the installation. > C) it fracks up something in that wizard, making it act strange when trying > to locate driver files... even tho i point it at the correct file, it still > cant find it, again on win2k. On WinXP it seems to behave better, tho you > still have to click your way thru the wizard > > SO, the way i tried from here is: > 1. unpack driverpacks to /z/drivers > 2. link /z/os/winxp/$oem$/$1/D to /z/drivers/D and do the same for win2k > -> driver will be placed in "C:\D" > 3. generate devicepath using either setdevicepath.exe (from pyron) (can also > be done by using a "find ./ -type d" + some extra commands) and put that in > the file hivesft.inf (it contains a 'key' named DevicePath, and is > apparently used as part of a template for the registry I did that. It becomes a total nightmare if you got some variation in your hardware (lots of directories: the driverpath becomes too long). So the Pyrons method definitely is your only choice. I think I'm past the driver hurdle now; tomorrow or next week I'll also try a more varied range of machines. > 4. install using unattended... seems to work > > At least it works better than without step 3, since i have a gut feeling > that the thing that constructs the devicepath omits any directory that has > subdirectories... which is annoying since there are a lot of drivers in the > driverpacks that have .inf files in their main dir AND in a subdir, but the > .inf files in the main dir are not visible to the setup process since they > are not put in the devicepath value. Also, it seems that (but i need to test > this further) that pregenerating that key and putting it in the hivesft.inf > file bypasses the 4000byte limit for the OemPnPDriverPath thing... I'm not sure about that thing. As I see it, Pyrons method will basically do an equivalent of find -type d and add each of these to the registry (possibly excluding the directories with no .inf files). Anyhow, creating my own DriverPack works fine for me now, I might have a directory for a certain mobo with directories for the lan, audio etc drivers, I'll probably also testing that later. > The reason i think it might remove the restriction is info in the following > link : > http://vernalex.com/tools/spdrvscn/index.shtml > > > > anywayz, typing with an 8-month old is kinda difficult, so i'm gonna leave > it at this :) Cute :) -- Frank Van Damme A: Because it destroys the flow of the conversation Q: Why is it bad? A: No, it's bad. Q: Should I top post in replies to mails or on usenet? ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ unattended-info mailing list unattended-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unattended-info
