Jump to content

theUtmost

Member
  • Posts

    13
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    New Zealand

About theUtmost

Profile Information

  • OS
    Windows 10 x64

theUtmost's Achievements

0

Reputation

  1. @bobpaul I've only had a brief play with the Unattended project, before going back to plain old DOS network installs. Simply because I know nothing about *nix or Perl scripting, and i wanted to customise too many settings from the default Unattended project settings. Anyway, as far as WinXP setup goes, the requirements for the two are much the same. You are effectively running winnt.exe from DOS. You need to follow the directions for setting up the DriverPacks, which involves running the batch files that come with the DP "Base" installer. The biggest thing you need to be aware of is that with launching from DOS, some of the files involved with the DriverPack setup do not comply with 8.3 naming conventions. Have a look here: http://www.msfn.org/board/index.php?showtopic=71011 I used the simple batch file outlined by JSe, and it seems to work ok. As he says, you need to run it manually after doing the driverpack integrate. Speaking of the DP integration, I used "method 2" from the Base install, and it seemed to work ok, except that if my machine contains the Realtek HiDef Audio chipset, I have to browse for the appropriate file on the HDD at t-39 mark. If you want the gory details look here: http://www.msfn.org/board/index.php?showtopic=69975 I should really test Methods 1 and 3 to see if they fare any better... But I digress. Bashrat the Sneaky is busy working on the new version of DriverPacks, which looks very promising, and he has agreed to make it fully 8.3/winnt.exe friendly, which is great news for the likes of us Meantime, if you want to give it a go, that first link should give you all the info you need, and don't forget to add: OemFilesPath = "\$OEM$" To your unattend.txt file, since the driverpacks assume the $OEM$ folder structure is in the same directory as i386 (ie CD-style directory) instead of inside i386 (as is used for network-based installs). Cheers, tU
  2. I too have this problem. The message I'm getting is: The file 'hdaudbus.sys' on Microsoft UAA Bus Driver for High Definition Audio. Installation Disk #1 is needed. Setup is looking for the file in C:\$WIN_NT$.~LS. It seems happy when I point it to the compressed version (hdaudbus.sy_) which I can find in C:\$WIN_NT$.~BT. I am using DP Base v6034 and v603 for all the actual driver packs. The driver packs are slipstreamed using Method 2, and I am keeping the drivers on HDD. I have NOT used nLite, or update packs of any sort, the ONLY modification to the source files has been done by DP Base setup. I am installing from a distribution share on a network. I boot from DOS on a CD, wipe the HDD, repartition, format FAT32 and then launch WINNT.exe from the distribution share. I have completely re-setup my WinXP source files with SP2 slipstreamed at the distribution point several times, just to make sure I didn't do anything silly with $OEM$ folder contents or anything. The only customisation I've done is to use $$rename.txt in the $OEM$\$1 folder to rename all files under that folder to 8.3 format so that WINNT.exe setup will copy them across the network ok. I'm currently trying to install onto a hp Compaq dc7600 machine. It has additional PCI cards: Promise FastTrak TX4 RAID controller, and also a PCI multi I/O card that gives you an extra 2x COM ports. The latter is made by 'Sunix'. I have made my own driver pack for this. Everything works fine, except for setup not being able to find 'hdaudbus.sys' as described above! I've attached the hwids from the dc7600 machine. hwids.txt I can CONFIRM that the .\i386\SVCPACK\KB888111.ca_ file exists in my source. If anyone has any suggestions or hints on what to look for they will be gratefully received Cheers, tU
  3. @ruudboek Would you consider posting details of your DOS menu and how you've specified the machinename? I'd be particularly interested in how you are inserting a DOS env variable into the unattend.txt file in appropriate place. If you'd rather not post that, then that's fine. I'm reasonably familiar with DOS batch files, so could probably figure it out (eventually!) myself. There must be a DOS utility for writing lines into .inf files with section headers that could be used. Maybe Kixtart or similar? Anyway, cheers for the reply and I very eagerly await the new Autoit version of Driverpacks! tU
  4. @ruudboek, thanks for your reply, but I'm confused, since previously you've said: You then went on to extol the virtues of installing from DOS (all of which I agree with BTW !) And then in your more recent post: Maybe I'm stupid, but I do not understand the distinction there... Do you mean you start winnt from DOS, which just happens to have been booted off a CD? That's how I do it. If so, I would have though as far as DOS is concerned, it doesn't know or care where it's booted from... Please elaborate. The line you added into the [unattended] section: OemFilesPath = "\$OEM$" Is functionally equivalent to the one I used: OemFilesPath = "X:\$OEM$" So that answers THAT question at least ta. Just to be clear, the problem with the BTS driverpacks as they currently stand (without JSe's script) is that the files copied during textmode are truncated to 8.3 format, so that setup at T-39 shows an error to the effect that it cannot find files with long names like: WatchDriverSigningPolicy.exe? TIA for the clarification. Cheers, tU
  5. Me too please! I too use a DOS boot method to source files on a network share and run Winnt.exe. My reasons for using network share are primarily: SpeedEase of editing/changing files, especially for new drivers and mods for post setup installation of programsI've also been working on the distribution share for quite a while and have only recently started lurking around here for an answer to what I'm sure is one of the commonest problems: RAID MassStorage drivers during TEXTMODE setup. I have wasted weeks now trying to get Promise FastTrak SATA-150 drivers into the TEXTMODE setup stage in my XP distribution share, and despite following all the guides, I am still getting errors like: "File caused an unexpected error (0) at line 2166 in d:\xpsprtm\base\boot\setup\oemdisk.c. Press any key to continue." Now it actually DOES continue, and installs successfully, but that's hardly pretty, let alone genuinely "unattended". From searching I see I'm not the only one with exactly the same problem, although there doesn't seem to be an easy solution. I CAN get it installing using numerous guides from CD, but that's just not flexible enough for me I was really really excited to find out about the BTS driverpacks from this forum. Alas, giving it a go today I've encountered what I assume to be the same problem as those above. Question for ruudboek, TaiPan007 and JSe: Since the "slipstream" batch files for integrating the BTS driverpacks all assume a CD-based $OEM$ folder structure instead of network-based structure, how did you guys get around that for having the source on the network? Did you A Modify your unattend.txt to include a line like: [Unattended] OemFilesPath = "X:\$OEM$" This would be used to tell Winnt.exe that the $OEM$ is NOT under the i386 folder for instance. I'm guessing here that you'd rename the Winnt.sif file which was modified by BTS batch files to be unattend.txt before launching say: X:\I386\winnt /s:X:\I386 /u:X:\I386\unattend.txt Or does the following work equally well: X:\I386\winnt /s:X:\I386 /u:X:\I386\winnt.sif The other alternative B Is to MOVE the $OEM$ folder so it sits inside i386, but I hazard a guess this would create a small "dependency crisis" of sorts. Which batch files would need editing, and where? And do any of the executables like: SetupCopyOEMInf.exe WatchDriverSigningPolicy.exe have hardcoded paths since they were primarily designed for CD-based use? Any answers to any questions gratefully received! Thanks for all your work on these driverpacks Bâshrat the Sneaky, they are simply amazing! I know most people use CDs, but I think if your DriverPacks could be bent slightly to make them Winnt / Network-install friendly then even more people will want to use them It's possible that also more people will want to try a network-source install too
  6. @Rahbas Excellent, thanks heaps for that I will give it a go! @03GrandAmGT The HARD FACTS as you put them depend a lot on your network environment. I've posted here simply "what I use". If TCP/IP is working for you then stick with it and ignore anything I've said I don't have any definitive timings to compare between NetBEUI vs TCP/IP, since I have not had much luck with DOS-TCP/IP boot disks in my particular network environment. If anyone else has the time, the tools and the inclination, I too would be interested in knowing the relative speeds of file transfer between: Dos client with TCP/IP <-> Win32 server with TCP/IP Win32 (BartPE or WinPE) client with TCP/IP <-> Win32 server with TCP/IP Dos client with NetBEUI <-> Win32 server with NetBEUI Win32 (BartPE or WinPE) client with NetBEUI <-> Win32 server with NetBEUI Personal anecdotal evidence suggests that my DOS NetBEUI boot disk goes from power on to "file copy phase complete" quicker than my DiegoStarted BartPE disk running TCP/IP, but I have not actually timed either. Further, I should point out that this may simply be a result of the BartPE environment taking a lot longer to boot, then load network drivers etc. It may be that once the BartPE Win32 environment is fully loaded, that the ACTUAL file copying phase is quicker than my DOS NetBEUI boot disk, even if my DOS NetBEUI boot disk starts copying files sooner. However, that's not really the comparison you've asked about, since I can only really compare #2 above with #3, which is a bit like comparing apples and oranges. Really we need to compare #1 with #3 and #2 with #4. My gut feeling is that under a full end-to-end Win32 environment, NetBEUI will be slower than TCP/IP, assuming there are no Name resolution issues etc. When you throw DOS into the mix though, who knows? I think any difference is likely to be minor though, and we might end up quibbling over very small percentages in terms of the total time of the unattended build. Bottom line: use what works for you.
  7. @clivebuckwheat Please advise the exact directory structure under your $OEM$ folder. Also, I know this sounds crazy, but try installing with MsDosInitiated = 0 In your unattend file
  8. @Djé Pleased to hear you got your DOS boot disk working ok. They can be a bit of a scum to get working. I'm not sure exactly of the differences but i think the fact that your "server" with the distribution source files is running XP Home may not have helped with your networking issue. Unless you know something I don't (and please share if so!), then you should remember that XP Home can only use "simple file sharing". XP Pro can also support the "classic" file sharing model with full "Access Control Lists" which becomes important when you're trying to remotely access files on a disk with NTFS permissions. Now, if you've shared a folder from your XP Home "server", then Everyone should be able to see it. But, not everyone may necessarily be able to access it. This will depend in part on the username/passsword you connect with and also a couple of settings in your "server" Local Security Policy. There is quite a lot of info about these sort of networking issues on the web, and it's explained a lot better than I can. Just in case it helps you or anyone else out, I've posted all my settings for doing a NetBEUI boot here: http://www.msfn.org/board/index.php?showtopic=72102 It didn't seem quite relevant putting it all in this thread... Longish post sorry, so be ye warned!
  9. I'm putting this here in the hope it will help someone, somewhere, someday save some time. It is partially in answer to a query from someone (=Djé), but really wasn't relevant to the overall thread discussion at the time. Just in case it helps anyone else out, I'll list here my autoexec.bat file which I use to connect to my "server" which is running XP Pro, and which has NetBEUI installed. It is based on the MS standard WinME boot disk: @ECHO OFF path=c:\windows;c:\windows\command \hibinv.exe call \checksr.bat IF "%config%"=="QUICK" GOTO QUICK set EXPAND=YES SET DIRCMD=/O:N set LglDrv=27 * 26 Z 25 Y 24 X 23 W 22 V 21 U 20 T 19 S 18 R 17 Q 16 P 15 set LglDrv=%LglDrv% O 14 N 13 M 12 L 11 K 10 J 9 I 8 H 7 G 6 F 5 E 4 D 3 C cls call setramd.bat %LglDrv% set temp=c:\ set tmp=c:\ path=%RAMD%:\;a:\;a:\net\;%path%;%CDROM%:\ copy command.com %RAMD%:\ > NUL set comspec=%RAMD%:\command.com copy extract.exe %RAMD%:\ > NUL copy readme.txt %RAMD%:\ > NUL :ERROR IF EXIST ebd.cab GOTO EXT echo Please insert Windows Millennium Edition Startup Disk 2 echo. pause GOTO ERROR :EXT %RAMD%:\extract /y /e /l %RAMD%: ebd.cab > NUL echo The diagnostic tools were successfully loaded to drive %RAMD%. echo. IF "%config%"=="NOCD" GOTO QUIT IF "%config%"=="HELP" GOTO HELP LH %ramd%:\MSCDEX.EXE /D:mscd001 /L:%CDROM% ::If MSCDEX doesn't find a drive... IF ERRORLEVEL 1 SET CDPROB=1 :: GOTO QUIT :HELP LH %ramd%:\MSCDEX.EXE /D:mscd001 /L:%CDROM% ::If MSCDEX doesn't find a drive... IF ERRORLEVEL 1 SET CDPROB=1 cls call help.bat :: GOTO QUIT :QUIT call fixit.bat rem clean up environment variables set CDPROB= set CDROM= set LglDrv= GOTO QUICK :QUICK echo. choice /C:yn "Would you like to load Smartdrive " if errorlevel=2 goto END if errorlevel=1 goto LOAD :LOAD smartdrv echo Smartdrive has been loaded GOTO NET :END cls echo Smartdrive has NOT been loaded. echo If you would like to load it, type "smartdrv" echo. :NET net init netbind net start /verbose /yes @echo on echo. call mapme010 echo. call redir The only real changes I've made there are to include the "a:\net" to the path statement which contains the contents of an ancient (NT4) MS client boot floppy. I've also used the "choice.com" so the end user can decide whether or not to load smartdrv, but this step is largely a waste of time (as you always should if doing an unattended install). The "mapme010.bat" file looks like: [menu] menuitem=HELP, Help menuitem=CD, Start computer with CD-ROM support. menuitem=NOCD, Start computer without CD-ROM support. menuitem=QUICK, Minimal Boot menudefault=HELP,30 menucolor=7,0 [HELP] device=oakcdrom.sys /D:mscd001 device=btdosm.sys device=flashpt.sys device=btcdrom.sys /D:mscd001 device=aspi2dos.sys device=aspi8dos.sys device=aspi4dos.sys device=aspi8u2.sys device=aspicd.sys /D:mscd001 devicehigh=ramdrive.sys /E 2048 device=a:\net\ifshlp.sys [CD] device=oakcdrom.sys /D:mscd001 device=btdosm.sys device=flashpt.sys device=btcdrom.sys /D:mscd001 device=aspi2dos.sys device=aspi8dos.sys device=aspi4dos.sys device=aspi8u2.sys device=aspicd.sys /D:mscd001 devicehigh=ramdrive.sys /E 2048 device=a:\net\ifshlp.sys [NOCD] devicehigh=ramdrive.sys /E 2048 device=a:\net\ifshlp.sys [QUICK] [COMMON] NumLock=On files=50 buffers=10 dos=high,umb stacks=9,256 lastdrive=z device=display.sys con=(ega,,1) country=044,850,country.sys install=mode.com con cp prepare=((850) ega.cpi) install=mode.com con cp select=850 The only changes there are adding the "device=a:\net\ifshlp.sys" entries so that the net bind type steps work. Also, I have set the default boot menu entry to "HELP", so that if after kicking off an unattended install i get distracted and forget to remove my boot cd, it won't get stuck in an endless loop of doing the TEXTMODE portion of setup. Instead, it will get stuck in the WinME Help screen. So I can just remove my boot cd, reboot and let my unattended win setup continue. That's not unattended! I hear you say. True, but i'm new to this, so it's a first step. I'd love to find a way of getting the "press any key to boot off the CD..." message on my boot disk (like a real Win CD, or BartPE) so if anyone has ideas I'm listening. Next one is the "system.ini" [network] filesharing=no printsharing=no autologon=yes computername=Lane1 lanroot=A:\NET username=user workgroup=WORKGROUP reconnect=no dospophotkey=N lmlogon=0 preferredredir=full autostart=full maxconnections=8 [network drivers] ;netcard=elnk3.dos ;netcard=pcntnd.dos netcard=b57.dos transport=ndishlp.sys,*netbeui devdir=A:\NET LoadRMDrivers=yes [Password Lists] *Shares=A:\NET\Shares.PWL Note that this example is specific to the Broadcom NetXtreme Gigabit Ethernet driver "b57.dos", so replace with whatever DOS/NDIS driver your network card requires. Make sure to put whatever default username you are going to connect with in here. The last file (really) is the "protocol.ini": [network.setup] version=0x3110 netcard=ms$b57,1,MS$B57,3 transport=ms$ndishlp,MS$NDISHLP ;transport=tcpip-32l,MSTCP32 ;transport=tcpip,TCPIP ;lana0=ms$pcntn3,1,tcpip-32l ;lana0=ms$b57,1,tcpip lana1=ms$b57,1,ms$ndishlp [protman] DriverName=PROTMAN$ PRIORITY=MS$NDISHLP [MS$NDISHLP] DriverName=ndishlp$ BINDINGS=MS$B57 ;[MSTCP32] ;BINDINGS=MS$B57 ;LANABASE=0 [MS$B57] DriverName=B57$ LED1=0x0 [B57] Adapters=MS$B57 ;[tcpip] ;NBSessions=6 ;DefaultGateway0= ;SubNetMask0= ;IPAddress0= ;DisableDHCP=0 ;DriverName=TCPIP$ ;BINDINGS=MS$B57 ;LANABASE=0 [NETBEUI] DriverName=Netbeui$ SESSIONS=10 ncbs=12 BINDINGS=B57$ LANABASE=0 Notice I have commented out the sections to do with TCP/IP, since I'm using NetBEUI. Again this example is for the Broadcom driver B57.dos Note that in some places, it is lowercase and others uppercase. I'm not sure how critical this is, but I think that at least some lines matter. What i do if I'm changing this file to use a different driver, is use wordpad to do a "Find/Replace all" and make it CASE SENSITIVE, so I replace twice, once for lower case and once for upper case. I hope that helps somebody out there and hasn't sent too many ppl off to sleep. I suspect I could tidyup my batch files a bit and reduce the number of refs to A:\, since I do get a couple of errors saying things like "error writing to drive a: Abort, Retry, Ignore?" If anyone can tell me the likely lines causing that I'd be grateful. It seems to pop up just after accepting my password and saying "the command completed successfully". Sorry for such a long post. tU
  10. @clivebuckwheat I've replied to your other post about problem installing apps from $OEM$. It seems you have gone through exactly the same process as I have done recently. Like you, I wanted a simple and elegant way of booting from a DOS boot disk, loading NIC drivers, mapping a drive and then running setup from source files on the distribution share. I quickly found there are dozens of different ways of doing an install from a distribution share. Because everyone does things slightly differently, different peoples advice and help may not always get you what you want. Also, all of the higher-level useful guides and tutes (which are very well written and helped me lots, so cheers to all! ) seem to focus almost exclusively on cd/dvd-based installs. Only by lurking for a long time (we are talking months here) on these forums and others was I finally able to get my network based installs (mostly) working. I need to post a few questions of my own to get the bugs ironed out. Anyway, there are a couple of points I should raise here: * Installing from DOS is harder, simply because DOS doesn't natively know anything about NTFS format partitions. So you need to use 3rd party tools like the "eXtended FDISK" or AEFDISK to manage that part of the process. Also, you need to work a reboot into your setup somehow, so that DOS can find your newly partitioned and (FAT32) formatted drive. * Also with DOS, you have slightly more work involved with your network boot disk. As you're well aware, you'll need to add drivers for any new NIC to your boot disk, which can be a bit tedious. If you are installing from a Win32 Bit environment, like WinPE or BartPE, then you can use something like the DriverPack for network cards put together by "Bashrat the Sneaky" et al. This is a great way of getting drivers for pretty much any peice of hardware you're ever likely to come across. * Another problem with DOS is that the Winnt.exe setup program is more restrictive than Winnt32.exe. A number of switches are available ONLY if you run the 32-bit version. Search MS KB for a comparison. You may or may not require some of the extra switches and that could be the MAJOR deciding factor for you and whether or not you choose to initiate install from DOS. * Don't forget about Linux! There is an excellent open source alternative here: http://unattended.sourceforge.net/ I tried to use this myself and it seemed quite well done - you don't need a linux server to host the source files either Unfortunately for me, I know absolutely nothing about linux, nor abour Perl scripting. I wanted to make a few reasonably significant mods and didn't think it would be worth my while, but your mileage may vary. * The most helpful site I've found for doing a network-based install of windows is here: http://diegostart.dijuremo.org/index.php?title=Main_Page Basically, the "Diegostart" system is a plugin for a BartPE bootcd which is designed around using source files located on a network share. Using this system to troubleshoot/test my network-based install, I was able to (mostly) get my unattended install to a Promise FastTrack SATA-150 RAID controller working. However, despite the fact that the DiegoStart system was very helpful to me for troubleshooting (I used the BartPE cd it creates to boot so I can view the Win install files at various stages on the destination HDD), and despite the fact that I bagged DOS installs to start with, I have gone back to booting from DOS - at least for now. Why? It is faster. A BartPE disk even on a newish fastish system takes a few minutes to load the environment, load the network drivers, map a drive etc and is slower compared to a DOS boot disk on the same machine. To get your DOS boot disk working quickly, of course you MUST load "smartdrv" before running Winnt.exe setup. What may be slightly less common is that in my DOS boot disk, I use NetBEUI. Boo hiss! ! I hear people say. Just try it - DOS NetBEUI is faster than DOS TCP/IP. If any forum mods happen across this post, question for ya: Given that conditions/requirements and aims are quite different for network-based unattended installs compared to cd/dvd-based unattended installs, would it be a good idea to have a subforum for Network-based installs? I note there is already one for RIS. A separate one for Network-based would likely have saved me a bit of confusion.
  11. Ok, please post the contents of your unattend.txt file Remember to comment out any personal info and use the code flags so it looks pretty. Actually if it's a long unattend file, maybe use codebox . Sorry if that's patronising, but i'm new to all this and it wasn't obvious to ME
  12. @ clivebuckwheat I may be slightly off track here, but i think i remember reading somewhere that the $OEM$ folder needs to be in different places depending on where you're installing from. For network-based installs, you should put your $OEM$ folder and all subdirectories INSIDE the i386 folder. Putting $OEM$ folder outside the i386 folder is correct for CD-BASED installs. Hope that helps Cheers, tU
×
×
  • Create New...