Jump to content

EvilBetty

Member
  • Posts

    16
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

Posts posted by EvilBetty

  1. I'd say this pretty much solves the issue in this topic.

    I would not say it solves it. It's a pretty nasty fix. It took me a week to sort through all the extra fonts and sys files that it wanted (beyond the above list) to make this work.

    I would still really like to see this fixed / figured out.

    Try out the alternate fix that I posted above. You don't have to copy any files into sysprep\i386 or anything. Just edit the sysprep.inf file. I'm interested to know if that fix works for others as well.

    Alternate fix works like a champ.

    Unfortunately I do have many source files in my sysprep folder being fired of by sysprep.

  2. I'd say this pretty much solves the issue in this topic.

    I would not say it solves it. It's a pretty nasty fix. It took me a week to sort through all the extra fonts and sys files that it wanted (beyond the above list) to make this work.

    I would still really like to see this fixed / figured out.

    From what I've heard from my employers, Microsoft has no interest in perfecting the sysprep technology for anything but Vista related. So I'd say it's up to us... again... :no:

    Well correct, but this problem is caused by nLite, not by Sysprep.

  3. I'd say this pretty much solves the issue in this topic.

    I would not say it solves it. It's a pretty nasty fix. It took me a week to sort through all the extra fonts and sys files that it wanted (beyond the above list) to make this work.

    I would still really like to see this fixed / figured out.

  4. Nothing wrong with the Ryan pack but if you are stuck you might try without Ryan's pack, integrating kb888111xpsp2.exe with nLite 1.35, and adding the WDM subfolder in the Dell package as driver. Just to see if that works.

    Wow did I leave something out...

    The HDAUDBUS.SYS problem occured ONLY when RyanVM's pack was used w/ nlite. Now I never noticed or not if the SigmaTel splat occured before I began using RyanVM's pack.

    Another thing to test out Monday.

  5. @legolash2o

    I'm sorry...

    Windows XP Professional SP2

    I'm out of the office to try this, but first thing Monday morning I'll try your driver, though it looks awefuly familiar.

    @BikinDutchman

    Actually I'm using RyanVM's latest Update Pack with nLite. AND I have tried it with and without the HDAUD 888111 AddOn FiX.

    http://www.ryanvm.net/forum/viewtopic.php?...hlight=hdaudbus

    ...with no change in either SigmaTel driver functionality, or in suppression the HDAUDBUS.SYS prompt. I had to edit the HDAUDBUS.INF to include the search for the file in the C:\Sysprep\i386 directory.

    Now I'm just stuck trying to straighten out this driver problem.

  6. My Dell D620's and D630's are not loading the SigmaTel HDA audio driver correctly. It shows up in device manager with a nice yellow exclamation mark on it, and no working sound.

    Running Dell's Audio Driver Install setup, will fix the problem.

    First off I realize that this problem may not be a problem of nLite. But, since I'm using this product along with several others I'm unable to pinpoint where the problem is occurring at this time.

    I am building a Universal Image for Dell's business product line. OptiPlex / Latitude.

    I am using nLite, RyanVM updates, DriverPacks finisher, and MySysprep.

    I am using my own custom driver pack.

    I have worked through every issue, except this SigmTel audio driver problem.

    The driver I am using was collected from a Dell D630 with the above mentioned Dell obtained driver loaded, and harvested with Driver Genius Professional. This resulted in a SigmaTel directory and a Microsoft HDA directory. I combined these files into a single audio directory... ./D/06/06_D630

    Snap1.jpg

    These files apparently are not adding correctly, and I don't know why.

    I have also tried the Intel Reference Driver with no success.

  7. I only ever had the problem with the NLS files not being found when I used nLite. So I quit using nLite.

    Right, it's a problem with the path settings being modified by nLite best I can tell. I'm wondering if skinlayers is still having this issue. Copying the i386 directory to my sysprep folder seems like a lousy fix.

  8. Note: I was able to eliminate a lot of my sysprep/imaging issues (including minisetup looking for hdaudbus.sys in the wrong place) by NOT using RyanVM's update packs. In fact, I recommend only using nlite to slipstream SP2 and setup the Unattended section when building a disc. Since you're creating an image anyways, it doesn't hurt to run Windows update manually, and be 100% sure everything is install 'the Microsoft way'.

    skinlayers

    How did you get around using the dreaded "c_20127.nls" during mini-setup?

    http://www.msfn.org/board/index.php?showto...&pid=663325

  9. does anyone know why this is happening, or any way to remedy it? i have about 1000 computers to ghost in the next couple months...

    First off, you can always use this for your service packs and hot fixes:

    http://www.ryanvm.net/msfn/

    Secondly... it seems nuhi is not interested in discussing or working with the enterprise image community. The stance I'm picking up on is that if your getting this error your using sysprep. If your using sysprep, your using this product outside the "personal use" license, and he does not seem to have plans to license this tool otherwise.

    It's too bad I know my company would shell out for something like this, and could prevent a lot of system administrators some heart ache and work.

  10. That's why in the license states "only for personal usage".

    Well crap. I'm positive I could get corp to pay for licensing if you wish, otherwise I'm stuck using something else.

    Do you have any plans to do this? Any plans on working this issue?

    Thanks!

  11. Gonna try soon, thx for reporting.

    What is the status of this issue? I'm still getting the error as of today on v1.3.5. I started from scratch with a clean config and a clean XP-SP2 source.

    Hitting escape gets around it, but beleive it or not I have techs stupid enough to call me every time they see it (after the 3rd email explaining it).

  12. MySysprep sorta works. It does allow changing to the correct HAL, BUT you have to know every model you have specifically. That's a pain, and you have to keep it updated.

    New: Version 1.2: MySysprep can detect the number of a CPU's logical processors. This feature is implemented by using the CPUID instruction to query the vendor ID and the logical processor count (inlcuding Hyper-Threading and multi-core) . To use this feature, a section [CPU] has to be added to MySysprep.inf. The entry name is the vendor ID with a ".MP" or ".UP" suffix. For example.

    [CPU]

    GenuineIntel.MP=mp.inf

    GenuineIntel.UP=up.inf

  13. Seems like I have the same problem... And no one found a sollution yet :s

    NLite causes this. But what part of it... Copy the entire I386 folter would make the image too big I guess :-)

    Me three... Has any headway been made on this or is it still prefered to copy the entire i386 directory over to the sysprep folder?!



×
×
  • Create New...