126 Reply by Galapo

(29 replies, posted in Installation Platforms)

OverFlow wrote:

it seems to me that offline sysprep is useful for moving a drive to a new system in wich case you will only need to "add" one driver and then not have a problem.

Yes, that has been my own primary aim from the beginning ... then people started suggesting adding all the drivers...

if it is your desire to create / modify an image that could be loaded onto multiple machines (the true intent of sysprep) then the better way to go would be to use a driverpacks slipstreamed source to begin with (one of the few times KTD is useful). in that way all of the mass storage drivers would always be available.

Yes, I think you are indeed correct. Other methods -- at least with xp -- will encounter the memory issue at some stage. Version 2 of OfflineSysPrep will allow for injection of user-provided driver(s) via their .inf(s) with peimg. This in addition to the option of injecting the DP driver(s). I think it will be a good way of moving a full install onto newer hardware in the case of replacing the motherboard etc. Inject the DP driver for the detected hardware, or supply driver files yourself and inject.

Regards,
Galapo.

Go to forum: Installation Platforms

127 Reply by Galapo

(29 replies, posted in Installation Platforms)

Yes, with this method whatever drivers get injected all get loaded. With the injection method internal to OfflineSysPrep it is only the main driver files, no secondary drivers. Full PNP after first boot is probably mandatory. Injecting with peimg is a different matter as the installation is directly via the .inf, so whatever drivers there that are references get injected and consequently loaded. With the setup routine there will be far less services running so that no memory limit is currently breached, but it seems injecting drivers into an already installed system that limit can be reached, at least under the conditions and methods I've tested here.

Regards,
Galapo.

Go to forum: Installation Platforms

128 Reply by Galapo

(29 replies, posted in Installation Platforms)

Jaak wrote:

Each little mistake would make it quite flaky and the work was "iffy" at best..

I agree. But it was good of you all to make such a test available for a while. My opinion is to stick with what worked previously, ie do not go with the temporary name changes we had in 8024 and 8025.

@OverFlow
Sorry, the 911cd forums we down for a little while it seems. Link should again we working to read cdob's post.

Regards,
Galapo.

Go to forum: Installation Platforms

129 Reply by Galapo

(29 replies, posted in Installation Platforms)

I've edited my post above with how many drivers were injected with each test. To me it seems there's some sort of limit generally in the mid 70's.

cdob's made a helpful post here: http://www.911cd.net/forums//index.php? … p;p=142720

Regards,
Galapo.

Go to forum: Installation Platforms

130 Reply by Galapo

(29 replies, posted in Installation Platforms)

Here's the tests I did. All drivers were injected with OfflineSysPrep into an XP sp2 VMWare machine.

I am not very good at seeing patterns. But it appears to me that whatever combination of drivers chosen, you just can't do TOO many else you're hit with the ntfs.sys error. The "loader error 3" error message I had two time is interesting and I've never seen it before.

1. enabled all apart from a*, m* = ntfs.sys error = added ~81 drivers
2. enabled all apart from  a*, m*, si3* = success = added ~64 drivers
3. enabled all apart from a*, m*, i*, n* = success = added ~69 drivers
4. enabled all apart from a*, n* = nyfs.sys error = added ~87 drivers
5. enabled all apart from a*, n*, i* = ntfs.sys error = added ~81 drivers
6. enabled all apart from a*, m*, n* = ntfs.sys error = added ~75 drivers
7. enabled all apart from 3*, a*, m*, n* = success = added ~66 drivers
8. enabled all apart from 3*, m*, n* = ntfs.sys error = added ~90 drivers
9. enabled all apart from 3*, a*, n* = ntfs.sys error = added ~78 drivers
10. enabled all apart from 3*, a*, m* = success = added ~72 drivers
11. enabled all apart from a*, m*, h* = ntfs.sys error = added ~90 drivers
12. enabled all apart from 3*, a* = ntfs.sys error = added ~84 drivers
13. enabled all apart from 3*, a*, h* = ntfs.sys error = added ~78 drivers
14. enabled all apart from 3*, a*, c*, h* = success = added ~73 drivers
15. enabled all apart from 3*,a*, c* = ntfs.sys error = added ~79 drivers
16. enabled all apart from a*, c*, h* = ntfs.sys error = added ~82 drivers
17. enabled all apart from 3*, c*, h* = ntfs.sys error = added ~97 drivers
18. enabled all apart from3*, c*, h*, i* = ntfs.sys error = added ~91 drivers
19. enabled all apart from 3*, c*, h* i*, p* = ntfs.sys error = added ~87 drivers
20. enabled all apart from 3*, c*, h*, i*, p*, q* = "loader error 3" error = added ~83 drivers
21. enabled all apart from 3*, c*, h*, i*, p*, q*, r* = success = added ~80 drivers
22. enabled all apart from 3*, c*, h*, p*, q*, r* = ntfs.sys error = added ~86 drivers
23. enabled all apart from 3*, c*, f*, h*, p*, q*, r* = ntfs.sys error = added ~81 drivers
24. enabled all apart from 3*, c*, d*, f*, h*, p*, q*, r* = ntfs.sys error = added ~78 drivers
25. enabled all apart from 3*, c*, d*, f*, h*, p*, q*, r*, u* = ntfs.sys error = added ~75 drivers
26. enabled all apart from 3*, c*, d*, f*, h*, p*, q*, r*, u*, v* = success = added ~84 drivers
27. enabled all apart from c*, d*, f*, h*, p*, q*, r*, u*, v* = ntfs.sys error = added ~81 drivers
28. enabled all apart from c*, d*, f*, h*, i*, p*, q*, r*, u*, v* = success = added ~75 drivers
29. enabled all apart from c*, d*, f*, h*, i*, p*, q*, r* = "loader error 3" error = added ~81 drivers
30. enabled all apart from c*, d*, f*, h*, i*, p*, q*, r*, u* = success = added ~78 drivers

Regards,
Galapo.

Go to forum: Installation Platforms

131 Reply by Galapo

(29 replies, posted in Installation Platforms)

Well, my hope is still that we haven't reached a memory limit as it makes things much more difficult.

We'll see... I'm still running tests on this hoping to find the possible conflict.

Regards,
Galapo.

Go to forum: Installation Platforms

132 Reply by Galapo

(29 replies, posted in Installation Platforms)

OverFlow wrote:

the error they refer to is based on previus experience we have with windows 2000...
this is an easy theory to prove - remove a few dozen drivers and run a test.

ilko's done some "broad" tests on this:

1. Disabling all drivers fitting the following named variables 3*, a*, m*, si3* with everything else enabled results in a booting system.

2. Disabling all drivers and enabling only those fitting the following named variables 3*, a*, m*, si3* results in a booting system.

Two possibilities seem to be evident: either a memory limit being breached, or a some driver conflect somewhere in these broad "groups" of drivers.

Regards,
Galapo.

Go to forum: Installation Platforms

133 Reply by Galapo

(29 replies, posted in Installation Platforms)

OK, test results in: not good, but at least it provides more confirmation that a memory limit is being reached.

1. Injected 8025 mass storage drivers with OfflineSysPrep which added 113 new services -- ntfs.sys error.

2. Injected all 8024 mass storage drivers with peimg which added 129 new services -- nvata4in.sys error, likely due to driver similarities remaining under \m\n.

3. Injected all 8024 mass storage drivers minus \m\n with peimg which added 123 new services -- ntfs.sys error.

4. Injected all 8025 mass storage drivers minus \m\n with peimg which added 123 new services -- ntfs.sys error.

Tests confirm that the "OfflineSysPrep" method of injection may not necessarily be in error as peimg also fails. My earlier tests with peimg likely did not reach this possible memory limit due to driver similarities and so the number of services was within bounds. Ilko's and cdob's guess that some memory limit is being breached seem most likely at this stage.

Got some thinking to do...!

Thanks again for providing what was necessary to conduct these tests.

Regards,
Galapo.

Go to forum: Installation Platforms

134 Reply by Galapo

(29 replies, posted in Installation Platforms)

OK, I'm nearly ready to run some tests with 'DP_MassStorage_wnt5_x86-32_8024nightly.7z'. 'DP_MassStorage_wnt5_x86-32_8025PE_svctest_VIA92.7z' failed with the current injection method throwing up the 'ntfs.sys' error. Likely this is really just an issue with the task I'm putting to the pack, not the pack itself. BartPE plugin itself runs fine.

Some preliminaries on DP_MassStorage_wnt5_x86-32_8024nightly.7z:

1. Similarities remain at: m\h6 -> m\h6s; m\h7 -> m\h7s; m\h9 -> m\h9s; m\ib2 -> m\ib3. Maybe also m\n; m\p*.

2. Line 106 of iastor70.inf required correction.

3. Silicons have various "similar" files between different versions:

SilRemFil.sys v. 1.1.3.0: m\sb2, m\sb3
SilRemFil.sys v. 1.1.4.0: m\s8, m\sc3
SilRemFil.sys v. 1.1.6.0: m\s7b, m\sb4, m\sc4
SilRemFil.sys v. 1.1.7.0: m\s3, m\sb5, m\sc5

SiWinAcc.sys v. 1.0.0.11: m\s3, m\24, m\s7b, m\s7a, m\s7, m\s8, m\s8a, m\sa, m\sa2, m\sb, m\sb2, m\sb3, m\sb4, m\sb5, m\sc, m\sc2, m\sc3, m\sc4, m\sc5
SiWinAcc.sys v. 1.0.0.8: m\s9

siisupp.vxd: md5 4F53C93F9113DC7A867A268D78B7928E: m\s5, m\s7, m\s7a
siisupp.vxd: md5 1E8DD8F6C174B7A3656390E3E41D78AF: m\s4

Regards,
Galapo.

Go to forum: Installation Platforms

135 Reply by Galapo

(29 replies, posted in Installation Platforms)

Hi Jaak,

jtdoom let me know on the 911cd forums about this new testpack, so I've just downloaded and will start some tests after breakfast. Thanks indeed for producing this as it is very helpful to see what is possible.

@OverFlow
Yes, one purpose of my OfflineSysPrep app is to provide injection of drivers for new/current hardware into an image or partition not having these drivers needed for successful boot. However, another purpose is to provide the option of injecting all the BartPE plugin drivers (for the particular OS) as well. I had thought this was working, but lately we've been having an ntfs.sys error occuring which may be suggestive of a memory limit being transgressed. Another possibility is some driver issue/conflict -- hopefully there might be success with the latest testpack. I'll provide feedback either way.

Regards,
Galapo.

Go to forum: Installation Platforms

136 Reply by Galapo

(29 replies, posted in Installation Platforms)

Hi Jaak,

Thanks for taking an interest! I'll take a look shortly at what you've done.

Regards,
Galapo.

Go to forum: Installation Platforms

137 Reply by Galapo

(29 replies, posted in Installation Platforms)

Now sure what question 1 is aimed at: using peimg to inject drivers, or the renaming of service entries. I renamed the Intel ones and they were installed correctly. On the use of peimg see:
http://www.911cd.net/forums//index.php? … p;p=141778
http://www.911cd.net/forums//index.php? … p;p=141825

I'm just wondering if there is any reasoning behind renaming the .sys files without concomitant naming of service entries. My attempted guess was that in some cames the driver may have failed in tests, but maybe there is no explicit reasoning behind the naming other than current convention.

Regards,
Galapo.

Go to forum: Installation Platforms

138 Topic by Galapo

(29 replies, posted in Installation Platforms)

Hi

I've encountered an issue with injecting mass storage drivers into an offline system with peimg due to some inconsistent service naming conventions in inf files. I mention it here: http://www.911cd.net/forums//index.php? … p;p=142608

I've only had a brief look also at some silicon drivers and noticed that some follow the convention of naming the service directly after the sys files. Others such as M\S8 and M\S8A, for example, have the same service name -- ie 'SI3124' -- and so driver injection is not successful.

Can the service in '8ASI3124.inf' be named '8ASI3124' without problems? Likewise the intel drivers? What are the reasons that some services are not named directly after their .sys driver files?

Thanks for your time and help.

Regards,
Galapo.

Go to forum: Installation Platforms

139 Reply by Galapo

(3 replies, posted in Feature Requests)

The program here is better as it can be run from a regular system or from PE:

http://www.911cd.net/forums//index.php? … p;p=138089

It is useful for grabbing a backup of drivers if OS reinstallation is needed and you can't remember where all the original driver files or disks are...

Regards,
Galapo.

Go to forum: Feature Requests

140 Reply by Galapo

(15 replies, posted in Other)

Hi OverFlow,

No I hadn't seen AutoImage until just now and it looks and interesting and useful application.

A few things:

1) My program OfflineSysPrep can work in conjunction with the likes of Ghost etc. (this is my own main use as it stands, although I use different imaging software). A ghost image from a backup of a previous system can be applied to a new one, then running OfflineSysPrep prepares this (generally) unbootable system to be bootable (due to a number of factors, mass storage drivers being the major one). Sysprep doesn't actually have to be used, though, as I have now provided 'advanced' options which duplicate some of sysprep's actions internally. Just this year I had my laptop stolen and was able to apply a backup image to the new machine and get it booting -- meaning I didn't have to reinstall everything to get back up and running.

2) Since mass storage drivers cannot (yet?) be installed with sysprep under PE, I am personally not in need for the DP base to provide additional functionality outside of the BartPE platform. Using the generated BartPE plugin, I have been able to adapt to my needs, so that is currently enough for me.

3) As such, OfflineSysPrep can be thought of as working with base images or complete system images. AutoImage is used on installation files etc to install a new OS. This new OS, however, could be imaged, and, at a later date, injected with newer mass storage drivers etc with OfflineSysPrep to be used when replacing a motherboard etc. in the instance where the motherboard had died and so the relevant driver could not be installed from Windows prior to replacement.

Regards,
Galapo.

Go to forum: Other

141 Reply by Galapo

(15 replies, posted in Other)

Hmmm. So perhaps my current method of injecting drivers and services through OfflineSysPrep might actually still be the best solution rather than still trying to let sysprep accomplish this task via a [SysprepMassStorage] section or 'BuildMassStorage=yes' entry (remembering OfflineSysPrep is a PE front-end for sysprep).

Thanks for pointing this out.

Regards,
Galapo.

Go to forum: Other

142 Reply by Galapo

(15 replies, posted in Other)

Hi OverFlow,

Good to hear from you and thanks.

I am quite interested in developing this further so that processing of the mass storage DP could be accomplished internally to the program. Time is limited, though, since we have a three-week-old baby in our family now and me with phd studies to try to complete. See how we go...

Recently, I adapted my code that processes the BartPE plugin massstorage.inf file to generate a WinBuilder mass storage script so that the latest DP can be included in a LiveXP/nativeEx build:

http://www.boot-land.net/forums/DriverP … t3616.html
http://galapo.boot-land.net/scripts/dri … ers.script

If only I could solve the problem of running sysprep under PE where we currently are unable to include a [SysprepMassStorage] section or 'BuildMassStorage=yes' entry. The solution currently is the couple of 'Advanced' OfflineSysPrep options where either 1) all the mass storage drivers are added to the offline system and registry service entries generated; or 2) to add only the driver for the device detected under PE and registry service entry generated. This is all based on the generated BartPE plugin.

Regards,
Galapo.

Go to forum: Other

143 Reply by Galapo

(12 replies, posted in BartPE - UBCD4Win - WinPE)

@newsposter

I just tested and the arcsas issue is corrected in the current pack 7.12.1.

The missing final quotation marks I assume will be corrected when a new base version is released.

Regards,
Galapo.

Go to forum: BartPE - UBCD4Win - WinPE

144 Reply by Galapo

(12 replies, posted in BartPE - UBCD4Win - WinPE)

That was quick! Thanks for your work on this.

Regards,
Galapo.

Go to forum: BartPE - UBCD4Win - WinPE

145 Reply by Galapo

(12 replies, posted in BartPE - UBCD4Win - WinPE)

OK, great. I post the report shortly.

I came across the errors because I've written programs which "read" the BartPE plugin inf so any little "issues" are detected as the "reading" has to be automated.

Thanks,
Galapo.

Go to forum: BartPE - UBCD4Win - WinPE

146 Topic by Galapo

(12 replies, posted in BartPE - UBCD4Win - WinPE)

Hi,

I think there may be a couple of corrections needed in the latest mass storage DP when generating the BartPE plugin.

1. The third and fourth last lines of the [SetValue] section of generated MassStorage.inf file read: 

"txtsetup.sif","BusExtenders.Load","VIBUS", "VIBUS.SY_
"txtsetup.sif","BusExtenders.Load","ALIIDE", "ALIIDE.SYS

Final quotation marks are missing.

2. The second last lines of the [SetValue.2600] section reads: 

"txtsetup.sif","BusExtenders.Load","ATIIDE", "ATIIDE.SY_

A final quotation mark is missing.

3. The last line of the [SetValue.3790] section reads: 

"txtsetup.sif","HardWareIdsDatabase","", """ARCSAS"""

A presume a hwid is missing?

Thanks,
Galapo.

Go to forum: BartPE - UBCD4Win - WinPE

147 Reply by Galapo

(15 replies, posted in Other)

Gday Bâshrat,

Thanks for your reply -- and permissions!

Currently I have a working solution where I wrote a quick separate application to grab the files and build a driver database from an installed BartPE plugin. Or for the Winbuilder version, the base is run in silent mode and the files are grabbed afterwards. So currently this is working. If I have to revisit the code in time, I might take up your generous offer of using some of the code from the base to process everything directly.

Thanks,
Galapo.

Go to forum: Other

148 Reply by Galapo

(15 replies, posted in Other)

Hi Jaak,

Like I said:

My hope, though, would be that this would open up just another option in the application and usefulness of the driverpacks and that there might therefore be a larger pool of people using the packs and consequently testing on various hardware.

If I get anyone with problems with drivers, I'll push them this way!

I just released the new version of my app which makes use of the DP mass storage drivers. Injecting of all mass storage drivers into the offline system and creating of necessary registry services is now possible, as well as the option just to inject the driver and service for the device(s) detected under PE (or windows if offline system is being sysprepped from there.

Regards,
Galapo.

Go to forum: Other

149 Reply by Galapo

(15 replies, posted in Other)

Well, I couldn't wait forever as i wanted to release the new version of my app. A week and no response to my email... So for my BartPE version I wrote a 'files gatherer' which gathers files from the installed DriverPacks BartPE plugin. This way I don't have to distribute the files. For the WinBuilder script, the script manipulates 'DPs_BASE_*.exe' and 'DP_MassStorage_wnt5_x86-32_*.7z' directly from a user-specified directory where these files have been downloaded to.

Thanks for your time and assistance.

Regards,
Galapo.

Go to forum: Other

150 Reply by Galapo

(15 replies, posted in Other)

Hi

Just wondering if I should conclude anything from the lack of response. If deliberations on my request are continuing, I'm more than happy to be patient until a decision is reached one way or the other.

Thanks,
Galapo.

Go to forum: Other