You are not logged in. Please login or register.
Count me in for XP-32 bit, and Vista 32/64 bit testing.
Of course I'll be 'out of pocket' for a while.
any progress on a cheat sheet "learning pains" for graphics... he asks with baited breath...
I feel pretty comfortable with doing it, or assisting with it, but... you are the "master"
Vista compatible driverpacks are being discussed at this moment on these links:
http://www.boot-land.net/forums/index.p … mp;p=31341
http://www.boot-land.net/forums/VistaPE … t3992.html
The NT5 driverpacks have been used and slipstreamed into WinPE 2.x but this also brings some incompatibilities so NightMan began collecting NT6 specific drivers for the hardware not supported by driverpacks.
I'll ask him what is the status of his collection and hopefully it can be used as a good research to this project.
----
btw: Probably you already know this but you can make Vista run much faster in your current XP machine if you disable some of the memory hungry services and then it should work much better. Was enough to make my 1Gb laptop fly when these redundant services were disabled.
Now that is what I'm Talking About!!!!
I don't intend to run Vista as my primary OS i just need to be able to install and test it efficiently.
Hi
the main reason current NT5x (aka 86-32 DriverPacks) have so few vista in them is that a LOT of pruning was done in folders, and also X64 was often removed for they was seen as "unwanted" bloat.
The vista pack should not drop X64. Never.
The reason I say that is because the 2008 releases will use the vista drivers when they cannot detect the hardware in the upper levels of the OS install. (The Kernel of server manager 2008 sits on X64 metal, the "driver repository" partition is at a higher level and can be populated with third party.) (There is a X32 version of server 2008, but X32 won't have server manager. X32 is more or less a client and can be remotely managed with the manager tool in a X64 version.)
Last edited by Jaak (2008-03-21 11:55:05)
Hi Jaak!
I completely subscribe your opinion, my laptop uses a Vista x64 and I guess that these installs are far more popular than XP x64 ever was.
any progress on a cheat sheet "learning pains" for graphics... he asks with baited breath...
I feel pretty comfortable with doing it, or assisting with it, but... you are the "master"
I'll work on it over the weekend. The XP side is pretty straight-forward. I'm playing with the vista tool Muiz posted to see where everything goes. It's main limitation is no 'finisher' for executing exceptions.
Working on it too... and reading a lot...
If you was not aware or it, I will say it.
kernel 2008 is pure X64. It sits on the metal, or won't. Period.
(yep, period. ??? My understanding is that 2008 will not even TRY to install if the basic IO in hardware is not compliant.)
I will reword that...
The Kernel of server manager 2008 sits on X64 metal and the "driver repository" partition is at a higher level and can be populated with third party.
There is a X32 version of server 2008, but X32 won't have server manager.
X32 is more or less a client and can be remotely managed with the manager tool.
The manager is a "role" of server 2008 and that role cannot install if the machine is not fully 64bit compliant.
If you was not aware or it, I will say it.
kernel 2008 is pure X64. It sits on the metal, or won't. Period.
(yep, period. ??? My understanding is that 2008 will not even TRY to install if the basic IO in hardware is not compliant.)
That's good (and bad).
No legacy code means a tighter kernel and more stability (and performance).
It also means slower adoption rates since businesses will need to wait for the next hardware upgrade cycle before deployment.
Sorry OverFlow ,.....
I will ask Jan if he gives the source code.
But till now the tool works fine , maybe there are still some options missing.
Maybe a future request list would be a good start.
I would like to see a progress bar/status instead of the hide the command option.
So that you can see whats going on instead of all the command screens popping up.
More languages would be nice.
And a mount the boot.wim option.
And a read info from install.wim option so when you select image 4 it says : Vista Ultimate.
And a select compress future , so you can select /compress max for example.
And if you select a x86 wim that it says : Vista x86 version xxxxxx, or x64 xxxxxx
better look.
More good ideas?
I will update the driverpack asap
i am getting my head wrapped around the idea...
Bought 2 gig of ram for my machine, that should help with everything 
.
Hi guys,
since I was just "joined" to the Testing Team I would like to kindly ask why you are not simply using the "$WinPEDriver$ folder feature" ? This works with Vista SP1 (not before) and W2K8. I have successfully dropped all drivers for my hardware into this folder on my unattended Vista DVD and they were all used. (There was a problem with Intel massstorage drivers though -> they stopped the unattend process but I am sure that is the exception).
Here is an excerpt from this guide:
http://download.microsoft.com/download/ … deploy.doc
In Windows Vista, the driver injection during Setup depends solely on the Unattend answer file during the WinPE phase of Setup. There is no automatic pulling of drivers from a $OEM$ directory, as existed in Windows XP, due to changes in the Windows Setup model.
However, because many server systems ship without a preinstalled operating system, Windows Server Longhorn requires support to automatically search for predetermined directories on the system to look for drivers. During WinPE the system looks for the directory named $WinPEDriver$ at the root of all visible drivers given a drive letter of C or greater. If this directory exists, the module then adds this path to the list of paths that it maintains to search for driver packages. When this operation is complete, the module continues to scan the answer file, if present, for additional driver paths.
Because of this operation, drives that contain a WinPEDriver$ directory in the root cause Setup to recursively search this directory for driver packages to be imported into the image during the WinPE phase. This includes hard drive partitions and removable media like floppy disk drives and flash drives. Type-27 hidden partitions are assigned a driver letter during the WinPE phase of Setup and are also searched.
Drive letters A and B are not searched during this operation. These drives are considered to be reserved for floppy disk driver media and, due to potential error conditions, are omitted from the search algorithm.
This enables scenarios in which a server system is shipped without an operating system and allows OEMs more flexibility in provisioning boot storage and other drivers to enable Setup on these systems. One potential consequence is a situation in which WinPE cannot access the hard drive that contains the $WinPEDriver$ directory because the storage driver has not yet been loaded in WinPE. This dilemma can be solved in one of the following ways:
• Boot to a customized WinPE image that already has the storage driver installed.
• Place drivers on an embedded flash drive that is accessible from WinPE.
• Place drivers on removable media such as flash or CD Rom. (Floppy disk drives are not supported.)
In my opinion this is MUCH easier compared to injecting drivers into the wim image, and it does not change the image. Whar do you guys think ?
Bye,
Alex
Damn fine idea Alex! Welcome to the team BTW! 
So this method should work for all our DriverPacks except MassStorage.
Good thing M$ standardized the method for us eh?
Awesome!
dare i wish for such an easy path...
It does seem to be the case for vista sp1 (windows 6 and higher).
however boot time (mass storage) drivers will need to be "injected" (a slipstream by any other name is still...)
I noticed they are pushing the DPInst utility method too. and apparently PDInst is a redistributable file. Hmmm... PDInst is also backward compatable to XP... hmmm seems like a drivers only disk would be a lead pipe cinch at this point. thoughts???
as i look at my test runs i realize that M1 is really obsolete except for createing a drivers only cd.
(If you were createing a DVD you would not care if they were cab compressed - why take the time to cab them)
so i was considering adding a method three 'M3' where the drivers were extracted to the OEM folder (instead of 7zipped)
(perhaps even name the folder $WinPEDriver$ instead of OEM)
They could be used without copying them to the local HDD at all (unless KTD was selected)
DPInst could be easily used with the disk and a default xml file could be generated as well.
Now since DPInst is also supported by vista and 2003 it would stand to reason that a universal drivers disk could be generated. One that supported XP - 2k8 server, that is a very cool thought.
so thinking out loud we could sliptream mass storage then have extracted drivers on our install media then use DPInst to install drivers and run the finisher to get the results we have always enjoyed.
I would consider this method three and believe it can be made to work for win NT5 and above. - feedback?
so i was considering adding a method three 'M3' where the drivers were extracted to the OEM folder (instead of 7zipped)
(perhaps even name the folder $WinPEDriver$ instead of OEM)
They could be used without copying them to the local HDD at all (unless KTD was selected)
DPInst could be easily used with the disk and a default xml file could be generated as well.
That's actually a VERY good idea!
The DPBase could be coded in such a way to detect the OS type (which it does), then use the $WinPEDriver$ path in the correct manner for each OS type (XP, Vista, Server, etc.)
I never use M1, but I'm beginning to like the idea of your M3. That would save a lot of file-copy time. For XP, can the pathway be declared for driver detection, then re-declared back to default (if KTD isn't used) to keep from pointing to the install disk? Registry entries after-the-fact?
That sounds brilliant!
These are excellent news!!
Welcome to the testing team!
well by useing DPInst we would not need to specify a path for windows because dpinst uses its own XML file for the path.
DPInst is a stand alone program and runs independently of windows setup.
the potential stumbleing block here is the xml file would need to be generated each time since we can't guarantee that the dvd drive letter will be the same each time it is run, but that is not a show stopper, it will require a little creative thinking.
Only thing is when you drop all drivers in a folder, its very big.
Slipstreaming them is alot smaller.
So i prefer slipstreaming them.
and would therefore choose method two (M2) ?
i think the same theory will work, just applying M2 methodology;
simply extract the 7zipped packs to %systemdrive%\$WinPEDriver$
given the ability to put almost 9 gig on a DVD I think method two will become obolete just as M1 has.
although i can clearly see the advantage of compressed packs for network based installs (or other non local source uses).
with dvd rom's at $20 each and dual layer blanks under a dollar space is not as big of a concern as it used to be.
this will be more and more true with time.
I dont intend to abandon m1 or m2 installs.
I am simply considering adding a third method that takes advantage of the latest methods offered.
Keep the feedback flowing...
Hi guys,
glad you (mostly) liked the $WinPeDriver$ folder idea. Actually it should even work for massstorage drivers, at least the article by MS suggests this. I did find out today however, that this won´t work for WDS Server deployments (Windows Deployment services). I am just experimenting with this at work right now and it looks great however, the boot image residing on the WDS server (boot.wim - WinPE) obviously needs network drivers and those would have to be injected using the Peimg /inf command.
Maybe a future DP Installer could be used for various scenarious ... WinXP, Vista from DVD, WDS etc.
As for the size issue, Overflow ...
I am not entirely sure that size won´t be an issue for most people. Here in Austria a Dual Layer DVD is still much more expensive compared to a single layer DVD and there is no rewriteable Dual layer technology which is bad for experimants. BlueRay is still very expensive so it may be better to compress drivers as much as possible.
On the other hand, injecting drivers is much less flexible. Once they are in the image you cannot remove them or even update them (at least thats what I heared) so you would have to start with a fresh image all the time.
I guess I am just not sure yet what the best way would be .. :-)
Bye,
Alex
agreed...
that is why were discussing it
PS even a 4.7 will hold a whopping install
Someone has created a tool that can actualy slipstream SP1 into Vista.
Thought it was impossible, but i tested it and it works.
I hope he wants to share it with us
http://rapidshare.com/files/102097902/V … 3.rar.html
source :
http://www.msfn.org/board/Vista-Update- … 14365.html
And about the driver slipstreaming, just keep a backup of your install.wim without drivers.
So you can always slip new drivers into it.
I've checked his tool but it was coded in .NET 3.5
Using my Vista x64 wasn't possible to run unless I downloaded the whole .NET framework.
---
Also asked if he would be available for an open source solution but no reply back from Albert (the author)
Please consider coding a tool non-depending on .NET
I really don't understand why people keep pushing .NET when it's so heavy, slow and creates all sort of obstacles to work right.
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
[ Generated in 0.024 seconds, 10 queries executed ]
