swbchen wrote:

I am doing this UA install DVD for my kids(2). They are currently Intern and Resident (medical), very busy.
They pay much attention and spend almost all the time to Medical problems .
In case(just in case)  the OS corrupts due virus or some either Hardware probems or software bugs. They may quickly get back to their job with a brand new OS.

In that case, an imaging software may be more adequate for the task.
That way, they can easily backup their whole machine (including but not limited to all user data and settings!) and restore it later to the saved state.

Acronis True Image or Norton Ghost are two softwares I'd recommend trying out (especially the former, it's really child's play IMO, boot from the disc, follow the simple GUI and there you go).

If you just reinstall the OS via an unattended disc, how is the user data being backed-up?
How do you manage to re-set all the user settings?
This is something that cannot be done via unattended install and it is not intended to.

It moreso does not replace a proper backup solution and I can only urge you to cover that, too.
The problem with computer malfunctions or virus infections is not the reinstallation (that's a piece of cake compared) but the restoring of user data and settings!

swbchen wrote:

1. In case I buy a new Printer or a new PC (new Drivers) in the future, it needs no necessary to slipstream again ( perhaps it is a happy job) due to these new DP of these new facilities.  All I have to do is that I just put them-these new DP's into the DP-drirectory and burn a new DVD.  Anyone can do these job without slipstream ing (not everyone know-How and Like-to-do).

This already works with slipstreamed drivers.
All you need to do is replace the pack in the source with the updated one and recreate the ISO, there you go.

Of course, you can also re-slipstream the DriverPacks into the same source, BASE will detect and remove and previous packs, then start all over.

You are trying to reinvent the wheel here.

For most PC users, Unattended installation is required and necessary . What they want is to use the PC and they don't care and even don't like to install the OP  (a painful and not necessary process for them).   Instllation of OS is a BlackBox for them . All they want to do is to put the Installation DVD inside Dvd-rom , have a cup of Coffee and wait  for half an hour .Then they will have a brand new OP.  With a TV remote controller in hand, who cares how to build a TV set??? They just wnat to watch the TV shows !!!

Yeah, well, those users certainly do not make up the gros of our user base, that's for sure.
And if you are incapable of (re-)installing a OS, you should ask someone who knows his job rather than relying on a (presumably) pre-made unattended disc.
That way, you are at risk destroying any data that may be left on the system to be reinstalled, plus, you wouldn't know what do to do in case of error or may not even notice when something goes wrong.

Bottom line: An unattended disc can save you a lot of work but it does not replace basic knowledge about how to install an OS and it never was intended to.

Ok, folks, there's an NV version out of this.
Hence, if you have been desperately waiting for this, your prayers ahve been heared! smile

Grab it right here:
http://driverheaven.net/nvmodtool.php

mr_smartepants wrote:

I knew about the inf2cat tool.  It's used by the DriverHeaven Mobility Modder tool.

Speaking of which, I just noticed they released an nvidia version of it!
Just wanted to make sure you were aware of that smile

mr_smartepants wrote:

In Vista, that's a different matter altogether.  Driver-signing is required.

Only with 64bit version of the OS.
Otherwise, I'd be fubar'ed with that Vista laptop sitting right next to me and its HD 2400 GFX...
(thankfully, Mobility Modder saved the day!)

305

(4 replies, posted in DriverPack WLAN)

Yeah, [REQ] means you request a new driver to be added, then, when it has been done, the Team changes that to [IMPL] to reflect that it has been implemented.

It's not down to what programm you use to create the ISO but what ISO engine that program is using!
For instance, with nLite, you can switch between different engines.

If you do not need a GUI, you can easily work from the command line using mkisofs (this is also the official MS ISO engine).

RE: Usage of -RWs:
One should always use verification after burn to make sure at least all bytes are readable.
Of course, -RWs can be somewhat tricky if you have a bad combination of medium, burner and reader, but even with -Rs, verify is a must in my book.

Chrysalis wrote:

If someone has to download and extract drivers to install physx it defeats the purpose of using driverpacks.

That's why you always have the option to include any drivers you are missing via a 3rd party DriverPack all by yourself! smile

Just in case you weren't aware...

Fantastic work (and the changelog's pure joy to read! smile)!

Just a question: Is there any reason you host them on your own site rather than the official 3rd party DriverPack host?
I can move the files over there for you.
I really don't mind using mirrors for the worst case, but all files should at least be present on the official host so we don't accidentally mix up versions etc.

What programme and what ISO engine are you using to create those?

Switching around my help if you experience problems.
Usually, mkisofs should work best.

310

(4 replies, posted in DriverPack WLAN)

HWIDs would be nice (see sig).
And did you put the [IMPL] tag on the thread title or has a team member editited it without giving notice (please, at least uncheck the silent edit option so that it is clear who did it wink).

Thanks a lot!

312

(2 replies, posted in DriverPack Mass Storage)

Without any log files and/or some HWIDs, that will be a bitch to track down, I presume.
Moreso since there are probabaly more than just one SI Raid driver...

Please, if you are doing systems for customers or other persons that you won't have access to later on, at least secure all the necessary log files and grab the HWIDs before you give it back.
Otherwise, troubleshooting will be nigh impossible...

Sounds like a plan! big_smile

DP TV v8.09.08

Updated ATi TV Wonder 550, 600 & 650 drivers to 05/14/2008, 6.14.10.283 (8.8) in \A\6

http://3rdpartydriverpacks.thesneaky.co … 2_80908.7z
Size: 10.9 MB
MD5: FB412A6D262724070538996B0C65F7A4

315

(10 replies, posted in 3rd Party DriverPacks)

DP TV v8.09.08

Updated ATi TV Wonder 550, 600 & 650 drivers to 05/14/2008, 6.14.10.283 (8.8) in \A\6

http://3rdpartydriverpacks.thesneaky.co … 2_80908.7z
Size: 10.9 MB
MD5: FB412A6D262724070538996B0C65F7A4

So, it's not solved then or what?
Shall I revert the edit of the thread title?

Hmhmhm, it doesn't really have much to do with GFX, now does it?
Basically, it's only to support/relief the CPU from physics calculations, so by that definition it would rather fit into DriverPack Chipset than any of the DPGs.

OTOH, it's not really a widespread feature from what I've gathered.
Isn't the idea that only if you use SLI (or more) cards that you can dedicate one for Physx calc?
Are there really any applications other than games that make use of it?
I'd guess that our main user base is sys admins deploying in large companies rather than hardcore gamers.

And last but no least, the driver itself, does it come in the INF/SYS shape?
Last time I was fiddling with these Aegia drivers, there was only an installer but no way to even find out there was an INF, so it's not a driver by the conventional standard.

Anyway, why not include it into a 3rd party DriverPack?
if folks want it they can grab it but it does not bloat up the official packs (where most professional users may not want it anyway).

Camelot_One wrote:

I'm trying to use method 2, with KTD set for C:\Drivers

Everything is working, I'm just trying to speed the install a bit. During windows setup the driver zips are extracted to C:\ , needed drivers installed, then the finisher has to copy all of those extracted drivers to C:\Drivers. I'd like to instead do the initial unzip to the final KTD location, so that the finisher doesn't have to copy the 3+Gb of drivers later.

AFAIK, the driver copying and deletion operation was changed to a simple driver move almost aeons ago (and definitely sped things up by far!

So, what you are trying to achieve has already been done, hence, changing the paths should not gain you a noticeable advantage in speed (moving files on a fresh system with a still small FAT should take an instant).

If you were to include a virus scanner into your installation, it could be that it is already running at that time, thereby scanning each file that is moved, hence noticably slowing down the process.
You might want to tinker with that if you need better speed smile

Or am I looking in the wrong place entirely?

No, it's the propper place alright.

If you use nLite and also plan to use the DriverPacks, for the sake of simplicity, universal HW support and your own sanity, please do keep all original Windows drivers!

It is kind of pointless wanting to remove loads of drivers fro your disc, then use nLite to add loads of drivers again, while none of these are overlapping.
The point of the DriverPacks was to support as much HW as possible, hence it was made with the idea in mind not to include drivers that are already present on the Windows disc, as a user who'd want to add most comprehensive HW support would not remove those.

320

(4 replies, posted in Other)

As you already use nLite, you might as well enable the option (it's under Options|Patches) to disable SFC.
That will remove such messages once and for all.

Basically, if you modifiy some system files (i.e. the TCP patch, a new unsigned theme etc), SFC will kick in wanting to restore the file to it's original content.
Of course, you do not wish that.
You could replace the file from the SFC cache (where the presumably unaltered file resides in and trick SFC into copying the altered version as original), but why bother?

I couldn't name one good thing about SFC, as long as you are literate enough to know what you are doing on your system.
A virus could as well replace the file in the cache, thereby rendering any security pointless.
Best is do to without and live hassle-free smile

Drivers are being installed during the fake setup phase (that is also when the 7-Zip progress bars shows the extraction of these).
The Finisher DOES NOT install/update any drivers, it is only there do run the exceptions (that may be GUIs for the drivers such as ATI CCC and NV CP), do KTD if selected and clean up afterwards!

Apparently, you have still not quite gathered how the DriverPacks work.

Anyway, how did you check for installed/updated drivers?
As your system was already up and running, I would think that all devices already had their drivers (ie no yellow exclamation mark in device manager).
So, did you compare driver version with those provided in the DriverPacks or what?

kwouters wrote:

The only problem is that it is a Win2000 driver and not digitaly signed.

That is not a problem as long as you adjust the signed and unsigned driver polices to simply also accept unsigned drivers during unattended install.

Also, temporarily disabling your anti-virus auto-protect during the process may help speed things up.
Unfortunatly, "FOREVER" doesn't tell us whether you have waited half an hour, half a day or a whole week... wink

krick wrote:

I'm grateful that someone has done the work to make driverpacks possible.  I really don't know what I said in my original post to provoke all the vitriol, but I'd like to put that behind us and make this a useful thread going forward.

That's perfectly fine by me!
It's really not a personal issue when we sound a bit grumpy because some members appear not to hold to certain standards of respect and manners, so do not assume we all hate you now or anything wink

I know you guys think I'm a "noob", but I'm a 38 year old professional software developer and I've been building my own computers since the days of the 286.  I've been making my own slipstreamed CDs since windows 2000, I've done countless repairs, backups, re-installs, upgrades, in-place re-installs, motherboard swaps without a re-install, and every other situation you can imagine.  However, I've only recently started using driverpacks.

That's fine.
The only reason we could ever think "noobish" of you would have been your posts here (and we do not judge by post-count!).
As you said yourself, you were new to the DriverPacks, so, by definition, you'd be a "noob" in that regard smile
While we do not cater for total unattended noobs (and constanly point them to the outstanding guides as MSFN), we do not have a problem with DP noobs - in fact, that's what the tuts are for (albeit most BASE options are self-explanatory).
The only thing we request if you are new to the DriverPacks, is that you do as told.
Most folks have issues that are self-made because they do not stick to the guides, do things their way rather than ours (fine by me, just don't complain) or simply assume things they got no clue of.
Only yesterday, one user claimed we'd install the DriverPacks to C:\Windows even on a 2k system when that uses C:\WINNT by default.
Of course we are smart enough to use %systemroot% to cover all eventualities, so assuming this means he thinks we are noob, and of course that is going to provoke not the friendliest answer.

I understand that driverpacks are intended for an unattended install, and that was how I had been using them in the past.
The problem was that I didn't know that driverpacks changes the functionality of an operating system install disc.

It's not down to the DriverPacks (or not only, because other apps for unattended preparation do it, too, e.g. nLite) but a "feature", MS introduced.
If your winnt.SIF file contains these
UnattendedInstall=Yes
OemPreinstall=Yes
entries, you will no longer be able to press F6 for the MS floppy, you will no longer be able to do a repair install and you will no longer be able to upgrade.
As you can edit the winnt.SIF all by yourself using your most favourite text editor, the DriverPacks only make use of a feature that is already present and would also kick in if no DriverPacks or any other unattended tool was used.

I would consider this well-known among unattended users, but maybe it never occured to you.

I never even considered the possibility that an XP CD with driverpacks wouldn't behave like a normal OS CD when using it to upgrade windows 2000.

A "normal" (as supplied by MS) CD does not contain the unattended entries, that's why.

I know which files are part of a clean OS install.  However, as this was an upgrade, there were a bunch of other files in the root from other badly behaving apps that I had installed over the life of my system.

Hm, ususally, there should be no extra files in the root (unless they are temporary).
That would seem your system was already pretty messy, in which case messing it up even further by the in-line upgrade certainly doesn't help system stability and performance...
Anyway, as I said, system files are marked as such (you can chose not to have these shown in folder options) and hidden.
That should be enough properties to filter them from the rest of the garbage that may be on root.

When I did the upgrade and saw all the loose files in the root of the hard drive, I just assumed that something went very wrong, when in fact, that's completely normal given the way that the driverpacks system works.  I've seen other product installations fail and put all the files in the root of the hard drive, so though I was wrong, I don't think it was out of line for me to make that assumption.

If you have never attended wink an installation with DriverPacks, you wouldn't know, right.
Also, something did go wrong in your case, Finisher did not run.
However, that's nothing too serious, as, you know that by now, you can run it manually.

Also, since I had never needed to run the finisher manually in the past, it was in no way obvious that that was the resolution to my problem and I don't see why it would have been obvious to anyone else in my situation.

Curiousity helps! wink
I had almost the same problem once, but running the file that is named the same as the process that runs during cleanup brought the desired result.
Seemed logical to me at that time...

The other end are people who use an unattended CD that someone else created for them and don't understand anything about how it works.

Yeah, those should ask the persons they got it from rather than post here, IMO.
Ususlly, they are also trying to work with their already modded (sometimes DL off the net as warez) ISOs which is really begging for trouble (plus we do not support warez obviously).
Then, they blame us for their problems when in fact it's them not reading the guides, knowing what they are doing or even using a legit, original CD as source...
But I'm going off-topic.

Like I said before, if it's possible, using a temporary folder to hold all the files before the driverpacks finisher is called would have made the situation much clearer to me.

Well, I suppose the files could be put into the \D folder, however, I don't know how that would work with deleting, ans the Finisher needs to be deleted through the reboot and can obviously not delete the directory it resides in.
Of course, putting anything in root is a bad idea generally, however, if things work as they should, the users wouldn't even notice.

That combined with a "run DP Finisher to complete install" textfile would make it crystal clear.   At least I would have known that the install didn't complete and what the next step was.

Well, you could have simply come here and run a search on that ("files left on root" or something) or post about it asking what to do with the left files - oh wait, you did that and we told you to simply run the Finisher.exe wink tongue

Ah, yes, totally forgot that by default you have to press [ALT] to have the underscores show.
I always pre-tweak that with nLite to always show the letters.
It's kinda dumb, IMO, not to show them.
The underscore does not bother me at all and you can certainly press keys faster than move and click with the mouse.

Also, back in the days of PS/2 or even RS-232, you couldn't connect a mouse on-the-fly (plug'n'play-wise) as with USB.
So if you booted without the mouse or the cable came lose (not going to happen with RS-232, dunno why those retention screws were removed on the newer interfaces) you couldn't use it unless you rebootet.
If the keyboard wasn't connected, the machine wouldn't even boot so you could always be sure that the KB was working, so hotkeys can be God-sent wink

Also, if you are already typing, having to constantly move one hand to the mouse and thereby off the KB can really hamper your workflow.
You'd want to only work with the KB in such cases so we try to ease that as far as possible by providing hotkeys big_smile