i think since you did not copy a graphics driverpack that no .INS files were found and that is the file not found error.

Is it true there are no >ins files in the DriverPacks.net folder?

2,577

(8 replies, posted in Feature Requests)

Your my hero!
I'm sure Wim is going to fall out of his chair when he sees it, it's a pretty rare occurance from what I gather. big_smile

I think this thread is going to get a lot of traffic because I think everyone will agree this is something that must be included in DriverPacks BASE.

You have an Awesome day sir!

Jeff

PS run over and grab you a DONOR's userbar wink

\\%SERVERNAME%\\REMINST\Setup\English\Images\WINDOWS

your share is REMINST

your share should be WINDOWS

Wow...
you guys are my heros!
thanks for all the excellent info...

2,580

(15 replies, posted in Hardware)

http://unattended.msfn.org/unattended.xp/view/web/1/

installing XP for noobs!

nope that should work!

edit the cmd file and rem the @echo off line and tell me which line is comlaining that the file is not found please!

2,582

(8 replies, posted in Feature Requests)

This feature can only be added by Wim... and he does not have time ATM to address recoding the site...
I have presented this request to him and he also sees the need... (he agrees this is important /a priority too!)

If I had that central file for looking them up I could just add the feature to BASE smile
We (the team) do not have permissions to update the main site which is why we add them to the changelogs.
Because that is the part of the site we can update wink

This has been explained already in multiple places and multiple times... Perhaps in less detail.
I do not have the ability to add it without Wim (AKA Bâshrat the Sneaky) personaly updating the website... sorry!
(Perhaps this is a good time to point out that the site might be more of a priority if people donated.
Free work always takes a back seat to real jobs and real life)

Everyone recognizes the blatantly obvious advantages of adding this feature... (myself and Wim Leers included)
Make no mistake that we (Users, Team, Wim) agree that this feature offers everyone piece of mind and the elimination of many related support issues.

I can only add features to DriverPacks BASE...
We will just have to wait for our illustrious leader to have the available free time to get the site updated...
With Bâshrat the Sneaky being a full time college student and haveing to work to make ends meet he has little of that needed free time...

[personal rant]
I think it is a shame that we get a million downloads a week and he has to work to pay his bills.
IE if every user sent in one dollar he would not have to work would he?
It is really sad when you think about how selfish the community as a whole is.
Everyone stops by to download DriverPacks for free...
a few post their problems respectfully and with some apprecieation of how much we work we have done and how much work we have saved them,
even fewer (the ones I get annoyed with) act as if they are the only user we have ever had, (as if they contracted us to write DriverPacks for them alone)
and yet not even one in a thousand will send in even a single dollar...  lets think out loud for a second.

If one in a thousand users sent in one dollar that would be One Thousand dollars a week in Wim's pocket...
Wim would certainly find the time to fix our issues then. (probably the same day)
I don't know for certain but I am willing to bet my bottom dollar that less than one thousand dollars has been donated in the last two years! That makes DriverPacks a liability for him rather than an asset. That is just insane...

PS I would personaly be happy if someone just said 'thank you' to me, or showed a small amount of respect, once in a while! I am sure the team feels the same - The list of names of the people on our team are some of the best in the world in this field I am honored to be on their team and to have Wim loan me the keys to the car. Speaking of the DriverPacks Team we haven't even had more than a handful of people offering to join the team and donate a few hours of their time a month to help us update the packs. - Less than an handful in the entire the five years DriverPacks has been here sad

PSS have you sent in your dollar yet?
[end rant]

If I can wait patiently then so can you! (Meaning all of our users, not you personaly Ben! wink) TIA big_smile

Jeff

PS Thank you Ben, I agree, and I apologise to you personaly for using your excellent request as a platform for my rant...
We are glad you're here. You have been contributing excellent ideas like this one and providing feedback to the forum for years! the above comments are not intended for you! Since this request is popular I belive it will get read by many of our users.

Last edited by OverFlow (Today 11:18:00)

your mapping is not correct... as this thread documents.

is there an OEM or $OEM$ folder on the HDD?

Ghost has changed the SID since like version 3, maybe 4 (late 90's)... if it did not ghost would never have worked for corporate customers wink 
- Ghost Walker for single copies -  and is automatic if multicast is used...

we used to use it at the phone company, at that time we were supporting over 3000 desktops with it. smile ( and we did not use sysprep tongue )

Ghost was introduced in 1996 by Binary Research. It initially supported only FAT filesystems directly, but it could copy but not resize other filesystems by performing a sector copy on them. Ghost added support for the NTFS filesystem later that year, and also provided a program to change the Security Identifier (SID) which made Windows NT systems distinguishable from each other. Support for the ext2 filesystem was added in 1999.

http://en.wikipedia.org/wiki/Disk_cloning

the SID is also changed when a machine joins a domain (in most cases)...

Ok so if i am following you it is neccessary to add the registry entries directly and bypass sysprep.inf
have you or someone else documented the entries that must be updated to bypass sysprep.inf?

Or is my idea of createing a custom INF similar to the SCSI.inf valid...

TY Galapo... you da man!

So we could script devcon to update the  (ACPI) PC "driver" and reboot fixing/updateing the HAL
(and totaly re-enumerating the machine on the next reboot)...

Wait a minute - that is brilliant...

we could script detecting and updateing the HAL... why not?

select basic hal that is fully compatable with all platforms then script detection and updateing...

In fact i seem to remember seeing a script that does this somewhere...

we're getting somwhere now... we can call it the "DriverPacks SysPrep Alternative"

well if you set the HDD controller to standard IDE before you shutdown
then when the system boots it will use txtsetup.sif to install the correct txtmode drivers
then SAD will be used to upgrade those to the full blown drivers. wink
HAL we will have to explore options for but MySysPrep has been suggested...

Yeah baby - talk to me guys!

How many of you guys use ghost - that totaly eliminates the SID issue...

here is what stumps me...

regulare windows setup and bartpe use txtsetup but not sysprep...
it uses a totaly different mechanisim that continues to elude me...
IDK why the standard method of adding drivers to txtsetup.sif fails for sysprep... it makes no sense to me.

perhaps i am attacking this the wrong way... I'm attempting to work with sysprep...
what if we could get the same result without it...
IE reset the SID (Ghost does this... why can't we...)
Set the HAL and HDD drivers to generic.
(windows will load and then we could set them correctly - HAL i understand is more difficult
but setting standard IDE will work...)
Then what would we lack of duplicateing the SysPrep experience?

LOL... My reputation seemingly proceeds me.

Just because I personaly hate it does not mean I will abandon you guys!
I certainly will not! Quite the opposite.
I have put you guys at the top of my todo list, and ATM I have some spare time.
I have offered you my hand please take it wink
- I have recieved little or no feedback on the sysprep alpha...
I put the ball in your (SysPrep Users) court to test and report on my code.
To make suggestions, to point out my failings - what an opening that is! wink
To show me what works, and what does not, and WHY!


What do you think about updating KTD to remove DoPNF and adding the DPIT (DP_Install_Tool) ...
from the post i linked too...

outline

OffLine sysprep for adding mass (or if you help me, finish mass in base)
DPIT on first run
KTD - possably if upgraded...

Will this be a viable solution?

Perhaps i have gone about Mass all wrong...
maybe can use devpath with the mass drivers and skip sysprep.inf? seemingly no...
but perhaps i can generate a custom inf similar to SCSI.INF...
and use that to load the mass storage textmode drivers?
This should get around the duplicate helper files that sysprep attempts to preload...
the textmode drivers do not need them (as proven by the BartPE Plugin).
then the drivers can be loaded by dpinst.exe. I will need to see how i can call a 'fake setup" for mini-setup...

This is not to say i will not continue with adding mass through BASE.
But without you guys telling me if it is working / viable or not I can't proceed.
I even tried to test it - and it just reminded me why I walked away from it so many years ago...
For those of you with more patience than me... test and report, I will code. ("If you build it, they will come")

tongue big_smile

related post http://forum.driverpacks.net/viewtopic. … 755#p29755

Well I learned somthing that I did not know...  the finisher does not use DevPath... LOL

It has a function internaly that writes the path... apparently devpath is a retired file.

perhaps KTD needs to be updated to eliminate dopnf and have DP_Inst_Tool added... sounds like a feature request if you ask me.
If dopnf was eliminated then mute would also no longer be neccessary...

so i could forget sysprep as a platform?
IE you would use offline sysprep for Mass Storage
and then you guys could just use a SAD M1 or M2 for the remaining drivers
and perhaps if needed run DevPath on a SAD M1 folder if a 'KTD' type setup was required?

Did you try enclosing the %ktd% in quotes "%ktd%" ?

Aaaah the old demon RUM... wink and sleep deprivation, that would make a difference tongue.
No harm no foul! - Clean slate awarded big_smile

Keep us in the loop on your progress!

Have a great day & best of luck!

you need to add the F6 drivers into a subfolder of the \Drivers\ folder and let the builder add them for you wink
manualy adding them will not work

much better... thank you for updateing your post,  let's try to move forward

I can not explain why the issue appears in 8.12.3 and not 8.12.4
- the source files that were compiled are bit for bit identical... The SVN server we use can attest to that, all changes are logged.
   the possability exists that the version of Autoit that I used to compile them was different...
     and I admit I have seen Autoit make changes in the compiler that surfaced in the object code before.
       Saying I snuck a quick fix in there without documenting it is taking a personal shot at me wink  understand... OK?

I already answered your question in my first reply and you did not read it - or you did not understand it.

Camelot_One wrote:

As an alternate solution to my entire problem, is there a switch/ini file setting to tell finisher not to delete the extracted local driverpacks, but without going through all the functions (makepnf, devpath, etc) of KTD that cause issues? Even if I have to run the DP_Install_Tool.cmd each time a new device is connected, thats fine. But I'd like to avoid having to a.) use a separate disc for the driver source, or b.)re-extract the zips each time. Disc space isn't an issue.

from my first response - "the best thing to do is to create a SAD M1 folder and run DevPath.exe"

M1 does not use the 7zip archives it uses cabbed drivers - to save space - windows natively will work just fine with cabbed drivers. cabbing saves over a gig of HDD space verses the fully extracted drivers. if you really don't care then you can save the time of cabbing them and simply extract them. However I recomend you use Base to create a M1 folder structure with a small pack first (Say DriverPack CPU) to create the folder structure and extract the needed files. createing an example for you to use as a template wink. then you can simply extract the rest of the packs you desire into the \D\ folder.  please remember cabbing saves you over a gig of space if you do decide to use M1 be absolutely sure you enable QSC so you will not have to cab them a second time wink it caches the cabs big_smile - if as you say burning two gig of space is no issue then skip the cabbing OK. A M1 source will not be deleted by the finisher if it is called from the  DP_Install_Tool.cmd  (Hint Hint - look at the finisher INI after the tool is run wink ).
copy devpath to the path\driverpacks.net\ folder and run 'devpath path\driverpacks.net\D' this WILL populate the device path in the registry (ktd) however if you do not run the finisher many drivers will fail and things like the ATI control panel will not be installed.

I can't make it any easier than that - had you listened to me the first time it would have save us both grief... wink

PS in case it had not occured to you you can leave the SAD folder on the machine wink I recomend a network share but whatever...

PSS PLEASE take the TIME to use the SEARCH feature of our forum [IMP] Option to skip driver removal with DPsFnsher EVERYTHING you want to know is WELL documented here!~

2,600

(14 replies, posted in DriverPack Chipset)

Thanks for the update... it's excellent news this issue has been put to rest.

In the future please remember posting your HWID(s) is quite helpful to being able to resolve conflicts 

have a great day.