MantisBT - DriverPacks BASE
View Issue Details
0000511DriverPacks BASEDPs BASE misc.public2009-03-09 09:292009-04-28 14:42
wnt5_x86-32 (Windows XP)
disc (CD/DVD)
0000511: KTD: selected folder where it should be stored is not used--has NOT been resolved
Same as previously described in [^]
(0000343). I've repeated this on over dozen custom xp pro sp3 installations. My method is always 1) nlite mods first (pause before making iso); then 2) driverpacks mods; then 3) finish with nlite iso. Only real difference from 0000343 stated attempt: I try to specify that the driverpacks be cached in the Windows directory itself--to "C:\Windows\Packs".
Although I use the 3rd Party DriverPacks, I do not use the ones with known bugs--these are left out for now. DPsFnshr.ini attached is from the last iso I created to test in VMWare.
No tags attached.
? DPsFnshr.ini (624) 2009-03-09 09:29
Issue History
2009-03-09 09:29nowinscenarioNew Issue
2009-03-09 09:29nowinscenarioStatusnew => assigned
2009-03-09 09:29nowinscenarioAssigned To => OverFlow
2009-03-09 09:29nowinscenarioFile Added: DPsFnshr.ini
2009-03-09 09:29nowinscenarioDestination OS Platform => wnt5_x86-32 (Windows XP)
2009-03-09 09:29nowinscenarioInstallation Platform => disc (CD/DVD)
2009-03-09 09:29nowinscenarioDriverPacks => all
2009-03-09 09:29nowinscenarioDriverPacks Method => 2
2009-03-09 09:29nowinscenarioDriverPacks Finisher Method => GUIRunOnce
2009-03-09 09:35nowinscenarioNote Added: 0000891
2009-03-09 20:29OverFlowNote Added: 0000892
2009-03-09 20:30OverFlowNote Edited: 0000892
2009-03-09 20:34OverFlowNote Edited: 0000892
2009-03-09 20:35OverFlowNote Edited: 0000892
2009-03-09 20:39OverFlowNote Edited: 0000892
2009-03-09 20:42OverFlowNote Added: 0000893
2009-03-09 20:42OverFlowStatusassigned => feedback
2009-03-09 21:08OverFlowNote Edited: 0000892
2009-04-28 14:42OverFlowNote Added: 0000895
2009-04-28 14:42OverFlowStatusfeedback => resolved
2009-04-28 14:42OverFlowResolutionopen => fixed
2009-04-28 14:44OverFlowNote Edited: 0000895

2009-03-09 09:35   
I'm currently building another installation to test; I will upload whatever files are required. I did read the history log, which stated that the issue was addressed, but it did not state exactly what the problem arose from or how it was thus addressed (as far as I could discern). Was it perhaps dropped as a non-issue because there was simply no more comments from the original bug issuer (nor additional comments verifying the problem from other users)?
2009-03-09 20:29   
(edited on: 2009-03-09 21:08)
no the issue was related to a nesting of the d folder ie \D\D\ This issue was fixed in 8.05 as stated... the reason no more reports is because it was fixed ;)

We don't just drop reported issues. Unless they are not repeatable / reproducable. IE if we can't reproduce the issue based on your description. and would be marked as such - "Unable to reproduce the problem"

Please try useing the correct syntax in your finisher.ini "%SystemRoot%\Packs"
(systemroot is c:\windows, most of the time, unless the machine is dual boot, ect... ;)) %SystemRoot% is a more reliable way of refering to a windows folder.
PS SystemRoot is the default ;) so no there is no difference ;) :P

Furthermore KTD is considered a dead function... it has been replaced by SAD.

You did not include the Finisher Log file please do so...

I am going to go out on a limb here and guess the finisher is not being run at all...
That would explain:
1) the fact that the c:\D\ folder still exists...
   If the finisher ran it would have been deleted... ;)
2) KTD was not performed

Is the finisher in the root of the drive still?

2009-03-09 20:42   
BugTracker is for reporting bugs...

In order to be considered a BUG an issue must first be reported in the forum...

So we can determine if it is a bug...
Once it is determined that it is a bug then we report it here.
Not before...
2009-04-28 14:42   
(edited on: 2009-04-28 14:44)
KTDlocation = "C:\Windows\Packs"

Is not a valid entry...

KTDlocation = "%SystemRoot%\Packs"


PS The default location is in the "windows folder" :D