Jump to content

Sulfurious

Member
  • Posts

    35
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by Sulfurious

  1. Thank you gentlemen for your assitance. For now I have used WinBuilder and the Win7RescuePE project. The other methods will have to wait awile yet for testing. I have used grldr.mbr on my boot drive and added that to the BCD as a boot option. This in turn lets me boot from the win7rescuePE.iso file that resides on the hdd. It takes me through 2 grub menus (one to boot the .iso, and one that is within the .iso). I have not yet dug any deeper to see if the BCD is capable of booting this type of PE natively, and right now am too busy to do so. But, I have what I need. A PE that is loaded into RAM from the boot drive, allowing me to restore an image to the c: drive. A quick an convenient method. Thanks again for the help. Sul.
  2. Hi Jaclaz. Maybe you did not make the .sif file, but you did make a script that made maybe a bootsect? It was over on boot-land. It made RMLD1, ramx1.sif and inside directory btsec it made RMLD1.bs. I will restructure the question, as 2 days later I have a better idea. In XP, I made a standard BartPE ISO that used the ramdisk files from 2003. I think it was Wimb's method, that also included your script I believe, that made it possible to rename (I think) the .iso into .img. The projects name was I think USB_XP_Setup. Anyway, using this project allowed the bartpe.img file to be included into a standard XP boot.ini in this fashion C:\btsec\RMLD1.bs="Bart PE - Boot BartPE.img from RAMDISK" This worked out really well for me. In the BartPE image I had all my drivers as well as the Macrium Reflect PE plugin. Once I made an image of my hdd, I stored it on another hdd. When I wished to restore my c: back to an image, I simply used the boot.ini option to load BartPE into RAM. The BartPE.img lived on the c: root. Once it was loaded into RAM, I could overwrite c: with a Macrium image using the Macrium Restore Tool from BartPE that was loaded in RAM. I understood this well enough that I had multiple .img options in my boot.ini file. I set up countless people with the ability to make disk image backups and restore very easily. Since the BartPE.img and associated boot.ini options were in the images themselves, whenever you restored an image it was all still working just as normal. Now, I have updated to Win 7 Ultimate. I am of course imaging with Macrium. I have a working version of Win7RescuePE built with WinBuilder, simply because it is so easy to use. I have this on a CD, and it works as expected. However, I am now seeking to re-create a boot option, preferably one in the BCD that is similar to the boot.ini option I had in XP. This option is to boot, into RAM, a PE image that is on the root of the primary boot partition. I have had success in vmWare by using grub4dos. You helped me out immensely years ago with your little EZCD script, which I have make literally hundreds of XP UACDs with. With grub4dos v0.4.4, I am utilizing the iso boot option to boot the Win7RescuePe.iso file. It does work, but I am unable to use the --mem parameter. It is due I think to the fact that the iso is already a RAM disk boot image. I have it working with the (hd32) and the (0xff) parameters. I find that since win 7 likes to create the 100/200mb boot partition, just paying attention to whether to use (hd0,0) or (hd0,1) is faster than using the find function. Honestly though, using the --ignore-floppies and --ignore-cd parameters means there is not much speed difference in the find command. Anyway, I am still interested in a method that utilizes the BCD to do this. Actually, the whole wim and vhd thing is quite different than what I have become accustomed to, and I enjoy learning new things. Thanks for the time Jaclaz. Sul.
  3. Hello. Been some time since I have needed to mess with UACDs or PEs. I recently stepped up to 7 ultimate from XP Pro. My XP machine was very tweaked after years of use. I have been using Macrium Reflect to make images and restore them for a few years now. Macrium makes a plugin for BartPE. I have made some bartPE and LiveXP images that use the ramdisk files. I made them into an .img file and used Jaclazs boot sector script to create the .sif files. I have an entry in the boot.ini for these. Usage is very simple. I choose the boot option from boot.ini to boot into bartPE into ram. Then I can restore my c: by using the Macrium plugin. Now in windows 7 things have changed a bit. I am not sure how to get it to work with bcdedit at all. I have looked all over the web, tried lots of different things. I am not sure if I should be using a vhd or wim or iso or try to get the img method to work. What I am looking to do is this: have an image of a PE environment on the c: that I can boot from the MS boot options. I am open to using grub4dos or grub, as I have used those on many unattended cds. The only requirement is that the PE image must boot into ram so that I can wipe c: where the image actually lives. Is this even possible now? Can anyone supply me with an answer or guide me to where to look? Like I said, I have seen lots of ways to dual boot and edit the bcd, lots of ways to mount wims and vhds, but they look to me like if doing this I could not wipe the c: where those images will live. Is that what is called a 'flat file'. Many Thanks. Sulfurious.
  4. Very interesting. You say then that when I run USB XP .cmd, and I create the source onto the USB, that actually then, the same .cmd file is ran when INSIDE the PE from the USB, and paths chosen then would be source of USB, destination of hdd. Does this then mean that you first run .cmd file to make USB to only be a boot disc, with neither BT or LS on USB, and then when run same .cmd from PE, BT is made (I understand) and that when source is on USB, because of drive letter being not c:, .cmd file edits current txtsetup file to change source location and not create LS because source location exists already on custom path. Tell me then, of a couple things regarding this PE image. First, what are requirements of ram? With bartPE in ramdisk, how much ram plays role in it. Even on my image, 512mb is not really sufficeint for nicely reacting OS (lol, unless that OS IS ReactOS). 1gb suffices ok though. Is the PE .img also constrained? And then there are 4 kits available. I got the one in your link, which is deluxe at 90+mb. I see that I can choose to not install components. Do you have a list of absolute needed to make XP install from USB reality, yet still keeping image size to minimum to also reduce ram amount needed. Remember, I plan to use this to support others, and not everyone has custom machine with ample hardware. Many are on garbage compaq with minimum specs. And last, I have made images with differing components. It is very nice program and not enough can be said about the interface and professional look and feel. However, I find it odd that one one computer, after figuring out how to take bootfiles and make with jaclaz batch file the .bs file, that the image boots fine (and fast from hdd as you say !! ), that lcd screen says 1024x768 @ 60hz not optimal (and indeed, will not display anything). Yet same monitor, with same default resolution settings, on differnet machine, can show fine. Is there an issue with needing any and all drivers (BTS) that one will encounter? So, does this image need updated often to support next generation of hardware. Meaning, I see what are referred to as 'generic' drivers in this Winbuilder, yet perhaps that is not accurate 100%. Thank you for continuing to leak information out. It is most useful already to have both yours and ilko t's thoughts on one page discussing in more detail the differences and how they happen and what the workarounds have become. Not to replace tutorials but to assist. Tutorials are full of information, yet too full, with too many threads concering one aspect or another to be able to absorb all. I like to learn new stuff and understand much, but never have I seen a project so rich with information that is also spead out so far over different threads. It makes even Gosh's fine information a smaller bitesize. And Gosh had some stuff to wrap your mind around when learning .inf structure. IMO anyway. As to say, this bite is more than I can chew at once, and eating faster does not help Sul.
  5. Yes, I have used this. As well mkisofs has options and also cdimage gui as well for doing that. But thanks for the head up. Ah, yes. However, how do you handle getting it on there to begin with? Assume you get new hdd, raw. You start setup and format. So now you must boot into some PE to be able to actually copy the PE image to the hdd in first place, so now you are already in a long boot procecess. If you install the OS and place the PE image on hdd, then subsequent installs can be started via the image from hdd, as long as the hdd is not currupted and cannot read or other strange anomoly. I see your method, and I like it. I think adding it to every source now is a good idea, as this makes your other method very attractive. But can you say, why does booting bartPE from uncompressed directory on dvd take so little time? Is there that much missing from bartPE where LiveXP is so much more? This could explain it. I made the files to USB 4 times last night with differing settings like format etc, and foudn all to be crippled. I thought maybe ntldr and ntdetect were trying to be copied to USB, so booted again and continued. Many files now were giving errer, and even had prompt aksing for path to LS directory, which I could not locate either on c or d (on 1 sata hdd in that machine), nor including $ with LS or not. It was like the directory had gone. I have in machine that makes images 2 drives in raid 0 array, the OS, and 1 storage drive with 2 partitions. The usb .cmd and the source were both on logical drive partition 2, so that is maybe the problem with file copy process. I will retry on active partition or look at those files listed below to see what may come of it. I will look at this. I don't fully understand what you speak of, but will shortly.. Thanks for the time to continue the explanation of more techincal side of this. Sul.
  6. Ok. so here is where I am. I have run USB_MultiBoot_10 on my source for dvd fully done, onto USB stick, using HP format NTFS. Results are BT & LS directory, also OEM via BTS is present. Now I have for trial placed modified setupldr in BT folder as SETUPCD1.BIN. In this is edited winnt.sif to point to wing1.sif, and txtsetup has been left alone for now. I make a chainload entry in grub menu to the modified setupldr. Oh, and have placed the GUIRunOnce values into the modified .sif file same as the winnt.sif and winat.sif values. First to ask questions I see. What is purpose of txtsetup in root, and same txtsetup in BT, only difference being the 3 .cmd batch files. Is root .sif file used to load drivers for txtsetup, and then BT .sif file is used? Ok. Next, when GUIRunOnce is commanded, and 3 batch files go off, I see what they do. And ilko t information made it clear of why and what. However, I do not understand why there is a rename of txtsetup.bak to txtsetup.sif in 2 of them, when I have no .bak file yet made in BT. Is this dynamically done somewhere in setup? Also, what are the effects of adding .bin and .sif file into BT? Are they needing locked via the .inf from being deleted? So, USB source is in place, menu.lst is ready, files good to go. Boot up to USB, goto grub, chainload the modified setupldr. Setup starts with only difference being the accept license page, which normally does not come up when having the [unattended] seciton in .sif file. No big deal. At this point, normal install. Fast file copy, no problems. Until, ntldr and NTDETECT.COM are not found and thus not copied to the hdd. So error on setup (logically) stating that hdd cannot boot. Ok, so examine USB drive, and there are present in USB root, and also present in BT NTDETECT.COM. Also are present in LS\i386 both files. I have not touched any txtsetup file yet, only spawned modded setupldr to point to modded .sif file. I know of past experience, that one file everytime, usbehci.sy_ in source absolutely needs to be in capitals or setup stalls on file copy of that. I always fix that. Is this similar? Should capitlise all? Or, what could be the issue? I have remade it twice now, and repeats both times. More tests to come, but barring the unknown as of yet various txtsetups that exist in root and BT and why the .bak file is not existing yet, I think this should work, unless unforseen switch to different .sif file at some point I am not yet thinking of. So, the file copy problem, I have not seen thread yet. I will keep looking. Anyone seen this one before? I see in ilko t's data that there is a problem with USB drive wanting to have the boot.ini value for it, and change occurs after first logon and 2 reboots via USB. But still if rdummy.sys is not operating, is the the result? Sul.
  7. Yes, that is a very understandable piece of data indeed! Thank you immensely! I understand quite a lot of that. I have modified txtsetup in 2 ways. First, I have the source for corp and retail xp pro. I need both from time to time so I wanted to include both on one dvd. It is known that the difference between the two is only a handful of files. I found them, and created in my corp source a directory in i386 called RETS. However, also I have to make a new tagfile structure, like this and then all the retail files need to change from 1= (or whateve is there) to 111=. This .sif file is called from a modified setupldr.bin file (setupld9.bin) via grub chainloader. Now I have one source with 2 different versions.Next I have used SetupSource when using grub dvd and using bartPE. I make bartPE package, then copy the entire contents of results to folder on root of DVD called BART. Here I reference SetupSource to \BART\ , so when grub chainloads root\bart\setupldr.bin, it has been modified to point to BART as well. Now, grub can launch in i386 any modified setupldr.bin which points to certain winnt.sif files (different keys,settings etc) and also points to any other setupldr.bin modified. Each setupldr.bin points to specific txtsetups or winnt's or both. So you see, I have multiple ways to use one dvd for my use both at work and at home. With inclusion of grub menu.lst entries of 3 types of installs for corp and 3 for retail (normal, semi UA and full UA), my dvd goes with me where I need, and can work on any xp pro machine I find. Add to that the bartPE tool, cmdcons, and other tools, and I have a pretty good tool for use with XP. So you see, my interest in understanding this. The USB boot and install is very nice feature. I will concentrate on that for now, as I have said, including PE environment is ok for me, but my focus is also on family and friends. I make them new source disks, because they stay updated that way, but more I give them custom reg tweaks, installed apps, network settings, better tools, and overall a safer and faster experience. Not to mention when I work on thier rigs I have all my tools at my disposal. So back to your very fine data. I know the BT and LS directories are made during install, as I have booted into floppy image via grub on a fat32 install and seen and manipulated those before. I was unaware of the stipulations though which you have nicely pointed out regarding hdd/cd/floppy nuances. I will study much more on your information for sure. Let me pose a couple things and see if it spurs any thoughts that might be relevant. What I will seek to do is find a method to let this one 'master' txtsetup and winnt do more. Probably with the winnt.sif file, like using winat.sif, I can point setupldr to different ones and also in those, because of omitting unattended info, have to make more custom batch files, or pass parameters. This SHOULD allow me chainload any one of modified setupldr files pointing to modified txtsetup and winnt files, but still maintain the sequence which is needed with the USB drive. Also, as a point that may not have been taken before, I have found that by using Siginets fine integrator, given enough time and hdd space, you can actually integrate say 10 add-ons. You can then copy your txtsetup.sif (and maybe other file, been awhile), then integrate some more and save txtsetup again, and keep going. It must be noted thought that to do this you have to keep your original txtsetup, and replace that with what was just made. In turn also renaming each 'layer' of txtsetup made. This means that I start with raw txtsetup, and integrate 10 apps, then I rename new txtsetup and replace with old one. Now when next integration, must include first 10 'basic' add-ons, as well as additional 10 more 'medium' add-ons. Rename txtsetup and place original. And so on. I was using this to tweak 3 different levels of installs, each from modified setupldr and winnt and txtsetup. As all the add-ons are in setup source, they are there for taking, but only if txtsetup says to. Else they stay on media. This allowed basic, medium and high levels of tools for each install. More menu entries and hexxing, but proved very worthwile. If on a fat/fat32 file system, I was using presetup.cmd to spawn many other nifty tricks as well. I dropped that though in favor of the above txtsetup. But the presetup.cmd gave me the opportunity to change useraccount.cmd and runonce files, more geared aways from one for all. But less and less I use fat32. Also, I had at one time a very complicated routine for putting xp pro corp and retail, and xp home all on same dvd. I found file differeneces and made other directories, and then built scripts to change setup files to point to right directory. It did work, but proved much work and there were some side effects, so I gave that up and just focused on pro or home sources. Actually, other than a few extra reg tweaks or my scripts, the only difference between what I make is the source. Most all is the same. So, I am playing now with the modification of winnt and txtsetup and setuldr files. It is VERY nice to better understand how I need to go about this. THANK YOU. Very much. Sul.
  8. From the USB XP cmd file, I have used winbuilder (via the link to project in that thread) and made the image. Now I take the .img file and simple format usb stick and then use .cmd files to simple add on the .img and boot.ini and grub menu. The file size for image is at 150mb +, so this is a little large, and I took off all but drivers and opera and system tools (regedit, taskmgr etc) to keep size down. Now it takes a very long time to boot from USB stick into ramdisk to get PE. Environment is very sluggish. I have my own bartPE build on my dvd, where I chainload from a subdirectory the bartPE. The bart directory is 156mb, and uses same files from 2k3 source for ramdisk, but it loads, even from dvd, in much faster time, maybe 2 minutes at most to network prompt. I have made same usb stick in past with bart bootable, which is very fast with my bart image. So why is the winbuilder PE so slow? Which would bring up more questons. It is stated that by using a PE, the BT directory can be made to the hdd, and then the .cmd can utilize the xp source files directly from the USB or copy to hdd. In this case, I see that there are some scripts already made to start this process. Could it not also be implemented where you go into PE, use a script to maybe format (or manually if needed), then parse the setup file to get BT on the hdd, then start GRLDR. or a reboot to GRLDR, which in turn now since as stated the winnt.sif files are complete and untouched, now use grub menu to chainload one of my custom setupldr files? Perhaps also, this would need to have the setup source entry modified to point to the USB if that is where the source files exist and not hdd. This requires a bootable USB, to boot into grub, and then the menu in grub should launch the bartPE I have. I can guess that because the PE image is an .img file, it is being extracted, and causing such slowness over my bart PE? My bartPE for my dvd is a subdirectory, where I chainload a setupldr modified to point to BOOT instead of I386, thus it starts the bartPE going. Also I have modified the txtsetup.sif file for bartPE to point to BOOT as a custom directory for it's sources so as not to touch I386 of setup files for installing xp. Confused still, but slowly pulling in more pieces of this very large idea. I wish I had followed it from the beginning. Sul.
  9. So, I have spent a good many hours now pouring over the threads. Really, you guys have come up with a dozen different measures to accomplish the USB installation ! Confusing to say the least. I see that you have strived to create a distributable method that is easy for average joe user to create his own USB installation. Good job. Now, as I am no further than I was 12 hours ago, and I fully intend to continue the study process, perhaps you could advise me and relieve any futile attempts from the start. What method can I use to preferably not boot into a PE and manually format the disc or other methods. With the following thoughts. For my own use is one thing. But I make dvd's for others. I send them a small autoit script in email, they fill it out and email the resulting text file back. This gives me thier full winnt.sif file, completely built to my specs with their info, then I build them an up to date dvd with their keys/apps/settings/etc, with a grub menu and tools that they need. I can include cmdcons this way for them and make many different methods to help themselves before they call me over to fix it. So this is major convenience for all involved. This is what I want to keep. It is effective, the grub menu. They are now trained to be able to insert disc, and press boot key to choose to boot from dvd, and they can naviagate the menu fine and have even helped themselves some. So to keep this existing scenario is of importance. But in USB boot I now see that to get grub is easy, as grldr is on c: and it is USB for first, so boot.ini is easy to make first menu or default to grub if needed. OK. But now, without introducing futher complications to those who don't need any more already, how to proceed. In example, some are so scared of even installing OS from cd, they don't. I give them freedom to have thier own unattended of thier own legitimate copy and key, so they are fully unattended, with exception of choosing to format via the txtmode setup. Then they get a drink and wait for my finishing scripts to start so they can choose which applications to start. To go into PE and do more I am afraid would break this for them. Yet, being able to chainload different modified setupldr files which in turn point to modified winnt and txtsetup files is also to be kept. So, ahem, can there be method to work? To boot to USB, which loads grub menu, which lets them choose which setupldr to boot and use, without manipulation of differing files which seem to break the whole scheme I am using. Or, in simple terms. Is it possible at all to still chainload different setup cofigurations with the USB method? If a PE environment is needed, I will be forced to adapt and overcome, but there is too much data to be had to make this a very quick learning curve at all. Again, thank you for any time and insight you might share. Sul.
  10. Thank you ilko t for that. I will look into those links for sure. I have been looking for at the VERY numerous methods and threads on the topics. I have to admit, I have messed a lot with cd/dvds in the past, and tried many of the methods described in this forum and others. I have messed with PE and RyanVM/BTS/nLite etc. Jaclaz gave me a solution a few years ago to streamline the creation of my .iso's as well as turning be onto Grub4Dos. My current system I have messed with a hundred times, to the point now where I have baseline files in different levels. I then take my xp source, slipstream if needed, update pack it, BTS it, put some addons in, and then run some of my own scripts to customize it for myself and all of my friends and family. The end result has been a grub menu that offers booting into xp pro volume or retail (or an xp home disc) in 3 modes, normal, partially unattended or full unattended in turn, the grub menu lets me use many different winnt.sif files for many computers/users common booting from different hdd/partitons booting into bartPE from grub many tools in the form of floppy images have been incorporated. a custom multi hal boot ini tool I made to alleviate needed boot files when missing or just to try a different hal if needed and other such goodness. I did not start this process of USB to get into such an indepth study I just thought it would be nice to up the install speed a bit and quit burning so many dvd's on every new build, which is about 6 times a year for myself alone. Ah, but now I cannot help myself and must know why and how the whole USB is working, so that I can not only use the system that I have in place, but also be able to keep making my dvd sources, but also use that source on a USB with no hinderances. However, I see many talks of txtsetup or winnt files that things do not go correctly, so some scripts have to be injected at creation to handle this, and then it seems at GUI portion or first login, that things are changed back. There are more .cmd files to be taken into the equation, as to how they are linked and why. Certainly there is much more here than I expected. But then, I have been pumping out the dvd's and have not had to poke around much as I refined my stuff. I think you have a good idea to start on that LONG initial thread though. I was hoping this would have been easier to basically recap with a timeline/step-by-step sort of thing, but I can see that it will be just a little bitty bit more than that lol. Thanks for your time. I do appreciate it. Hopefully I can come to terms with all of the methods and grasp them at the same time. We shall see. later. Sul.
  11. Thank you wimb. That is exactly what I was looking for, a composite set of data for the usb boot process. This explains much. However I have only 1 question now until I can digest more of what you have provided. What is the mechanism to change the drive letter from c:usb to c:hdd ? Is this built in to the setup? Or is it being manipulated by a cmd file or the like. And yes, I have been looking at the files. But to follow the cmd file that makes this possible, it is a very large batch file indeed. Do you know of an ide that allows folding of dos? Like scite does for autoit? For with so much going on in that file it is very hard to follow the goto's with any ease. But, I will continue. Again, very many thanks for taking the time to put that information up. Sul.
  12. Ok, so let me see if I can get this straight. Again, I seriously am struggling to follow the guide wimb has put together because I feel like it jumps and skips a lot. No fault of yours, only mine. So.. Firstly, you create the win BT directory for txtmode. You collect the drivers and I presume here that you have parsed txtsetup.sif and found all the files to be needed and copied/cut them to the BT directory. I have seen this method before. Next, you copy the source structure to win LS, omitting if marked the migration folders. Easy enough so far. I have been looking at your winnt.sif files. How are they different that you place them yourself? If a custom one exists, does it have verything that is needed? Or is this to ensure that some requirements are met for the USB method? Next we come to the good stuff. I see that you have taken setupldr.bin and renamed it now to XPSTP. Can you explain if this has been hexxed and what was hexxed? I see also that potentially an XATSP file is made. Here I assume that you have manipulated it to point to winat.sif. I have done this very same thing, at the expense of some small .sif files and a few 280ish kb .bin files and perhpas a couple half meg txtsetup files, one can easily achieve many different setup options in one grub menu. I have read far enough, this is to the point I strive to understand. Which method you choose to create the usb boot, you now have technically bootable USB. I used the hp and ntfs. At his point now this should show up as a harddrive instead of needing a boot sector for cdrom like other methods. Ok, so we have a USB harddrive emulation could be a correct assesment at this point? Next, we need to have the loader, which in this case is what? NTLDR? It in turn needs NTDETECT and then gives you the boot.ini menu? It looks like this. Now, assume this is correct trail, your option of 1 in boot.ini which is c:\btsec\XPSTP.bs does exactly what? Chainload the renamed setupldr as now XPSTP? Which in turn does what? Looks to custom path? Or custom winnt or txtsetup file? It must, as you have option for both XPSTP and XASTP. Option 4 is for grub. OK, so what tools have you used at this point to achieve getting a root drive path of c: ? Is the BT folder already copied to the hdd at this point? There are many questions still to ask, but for sake of easily understanding, if this USB stick is treated as a harddrive in basics, then the finding of NTDETECT and NTLDR should invoke the boot.ini, but normally I thought a few other files were needed, like ntdll, kernel32,winsrv,win32k and ntoskrnl. Can you explain how the boot process works off the USB stick? So still, you achieve a boot.ini. Options 1 and 5 use the .bs file. What is this doing? Could you not just use a grub4dos loader at this point that resides on the USB? As the menu.lst is capapble of setting root to the drive where grldr exists, could you not do what was done on a cd with g4d? In other words, let us say that I have 2 winnt.sif files, 2 setupldr.bin files and 2 txtsetup.sif files, one of each renamed of course and setupldr is hexxed to point to the renamed others. So now via .lst menu I can say chainload setupldr.bin and it uses defaults, Next I could chainload setupld2.bin and it chainloads, but points to winn2.sif and txtsetu2.sif, which can do what I want but differently. In the past I made .iso with grldr renamed to setupldr.bin, so that the dvd on boot gave grub menu. Then I would chainload a particular renamed setupldr just as I have described. But I knew that I was modifying the files, and what was happening. I see your method uses for instance 3 new .cmd files referenced in the USB root txtsetup.sif that are not in the BT directory txtsetup.sif, and that these .cmd files are searching for the path of particulars and renaming. Can you divulge any more on these matters? In short, I see no reason not to completely understand and fully intend to tweak the whole process and bend it to my usage. Is there not a composite thread somewhere that documents this in detail? Thank you for the time. Sul.
  13. Greetings. I have been making unattended cd/dvd's for a few years. I have a really good method that I have been using that includes both xp pro volume and retail on one disc, for ease of use both at work and for my personal machines. I have multiple winnt.sif files geared to all of my comptuers as well as workstations. I use Grub4Dos (big thanks to Jaclaz for the ezCD method) for my menus which allows the usual, boot to hdd, boot to image, boot to PE, boot to any one of my answer files in either volume or retail. Recently I decided to try out the usb stick install. I got the USB MultiBoot 10 cmd file. A real nice job I must say. However, while I am digesting it, I find it so very full of rabbit trails leading to many different endings. So, is it possible for someone to either put up a sticky or reply to this thread... what files are responsible for what? And I mean on the finished product. For example, in a cd you would take your setupldr and replace it with a renamed grldr. This in turn starts the G4D menu, and then G4D chainloads yet another setupldr, which in my case then points to specific winnt/txtsetup files. On the finished USB stick, I see XATSP and XPSTP and usbflash. I recognize grldr,menu.lst,ntdetect,ntldr and txtsetup. What are the files in the directory btsec? I understand that the $WIN_NT directories are mimicking what happens during an install. I know that the drivers are needed in BT and the full source files are in LS. I have used that method in the past to gather files using Flyakites method. Is there anyway a timeline-like list can be displayed that shows something perhaps like.. BOOTING: c:\btsec\XPSTP.bs > NTLDR (modified to point to root:\txtsetup.sif) > i386\setupldr.bin (modified xx for xxx) rdisk(1)partition(1) > NTDETECT.com > NTLDR (modified to i386\txtsetup.sif) > etc etc So that when learning of what exactly is going on, the answer is in plain sight. The Unattended guide here had real nice timelines as did many posts, so that one could easily depict the sequence of events and decide what might need to be edited etc to achieve new effects. While I am very appreciative of this USB method, I am finding myself swimming in waters that are somewhat murky as to what all I can do with this 'Swiss Army Knife' and just how to achieve all 101 features. I like to understand better, so I look to the USB structure for a default install, and understand why the file layouts are the way, and why certain files have been modified or placed in areas not traditional to other methods. I am not lazy, and have been absorbing. But, I must not be the only one to find a very technical description lacking when seeking to completely understand the role of each file to each method. My end goal is to be able to emulate to some degree what I have been doing up till now, but on USB. I realize I can use a pre-made method, but I learn so much more by tearing down and seing the insides and then building up again. I do not know if what I want will be possible in the manner I may try, so I seek the ones who know this inside out to help with an inclusive material regarding this. Many king regards. Sul.
  14. lol, that is too much. sure enough, I did not have the upper case flag set when I made my images, nor did I burn it as uppercase. Thanks for the link. Sul
  15. lol, you sure would think so. That is how I have done it on many xp UACD's. I made a pretty basic winnt.sif file, put in in i386, made image, installed. Nothing. So then I burnt it and installed on a live box. Nothing. Some googling later shows that it is to be used from a floppy or command line. So, I put it on a floppy, and it works. I figured it would go into i386, but it sure does not. I tried it on 2kpro & 2kadv server. Both do the same thing. This is an SP4 slipstreamed image. So, what now? sul.
  16. Could you expound on how to get the winnt.sif file to work with w2k without a floppy? I have tried it many times, and still cannot get it to work without a floppy involved. I had not thought to add reg.exe. That may be why those were not added. I will try that. Excellent tip. Sul
  17. Greetings. I have made many unattended cd's, using most methods available. All for XP. Now I find myself needing to make 2k images. Not that different, except for the winnt.sif file must reside on a floppy. So, this got me thinking a bit. Follow me here and please give insights. Regarding W2K UACD, the answer file is supplied via a floppy drive. While this is a small drawback, I now see that it is in fact a great advantage. Namely, I can simply change some values in the .sif file, and can then install UACD on any machine with custom winnt.sif. I can see that as being valuable where a network has many machines and I need to customize them. This led me to another idea. Not new though. Bashrat has been supplying driver packs for some time now. I have used them. But, I am trying to do something maybe different, maybe not. I wish to create a UACD with drivers preloaded into the $OEM$ dirs and install them from either the cd source if NOT using and answer file, or from the HDD if I am using an answer file. Now, before you say "Wrong forum dude", this is not entirely a driver thread. Besides I did post in there and have yet to get a reply. Not as busy in there as here. So, lets assume that I have gathered my .inf & .cat files. And that I have placed them into the $OEM$ directory structure properly. At that point then, if I use an answer file, those directories will be copied to the HDD. If there is no answer file, then they exist only on the UACD. Easy enough. Now, let's say I used a driverpath entry in winnt.sif file. No problem, setup will get them from the HDD paths. However, this leaves me with driver capability only if I use a winnt.sif file. Let's assume I do not want to for this install. With no winnt.sif file, how do I get the drivers to install from cd? There are methods, but it would seem that those methods require me to build a cd that only installs drivers from cd, never from HDD. So, I prefer to use, I believe, Pyrons method. I should edit txtsetup.sif. I should add 2 values. I should include presetup.cmd in i386. I should include the driverwatch and setpath files in proper places. This is good. Also one has to extract setup.ex_ and rename and replace with new setup.ex_. A working method. Now, here it gets different. In order to use the UACD for either type of installation, I must have both methods of driver install working. However, while what I have developed, mainly rewriting the presetup.cmd file, there are some issues. So, here is what happens. Install with winnt.sif file, $OEM$ dirs are copied to HDD and drivers are installed. Install without winnt.sif file and drivers are installed from UACD. No the problem. It installs the drivers regardless of if the hardware matches the driver. If I include a via chip driver, an intel chip will use it. I can assume it is because of the WatchDriverSigning.exe portion of the setup. However, I believe there is some knowledge that I am lacking. So, now the questions. The files svcpack.inf, dosnet.inf, txtsetup.sif and others I vaguely recall, why and when do you edit/use them. Some methods are not used with types of install, like guirunonce vs. runonceex. I have used the txtsetup.inf method, and that is the only file I ammended, and only the [sourceDisksFiles] section. Interestingly, besides just putting a wrong driver on, my cmdlines.txt file, when using an answer file, correctly uses a setupAPI.dll call, to install some apps via INF DefaultInstall, but the RunOnceEx.cmd file I have also made (and used in other UACD's successfully) does not introduce itself to the registry key. Now, I do test my installs on both vmware and live boxes. While in vmware, I would expect to see problems installing drivers, as vmware wishes to use it's own drivers. However, I would expect the RunOnceEx.cmd portion to work. Strangely, it works on neither. What is it that I have not included into my process? What other files would I wish to edit to achieve this. Or maybe not even to use txtsetup.sif, but another file instead. Searching through this forum is most definately a time consuming and often fruitless process. There is way too much information to find that needle in the haystack. I have used it a lot in the past as I was learing how to do the basic methods. The magic "phrase to search for" seems to elude me here however. Please excuse my ignorance on things that may be obvious. While I am more than capable of using a xpUACD, the 2k thing is somewhat different, and poses me with new possiblities. Also I apologize that I have not posted a complete repositry of all the files that I have used. Suffice to say that it is all as found in the Unattended Guide, or at uAwiki.org, except for the customized presetup.cmd file. Perhaps this should be in the drivers forum, but I think it is not so much driver specific, as process specific. Thank you for any light you may be able to shed. Regards, Sul
  18. More. Can anyone tell me this. I use presetup.cmd. It for instance extracts file to hdd for drivers, or uses drivers on cd to install. At what point does presetup.cmd get called. Is it before or after the winnt.sif file is parsed? Does it get called only in text mode, or on first reboot, after files copied, does it run again? I believe winnt.sif is parsed first, which says it is unattended and using preinstall oem, and during text mode copy files phase it copies the $OEM$ entries. I know it is accessed again during gui mode to fill in values required. Wondering how the presetup.cmd fits into the sequence of events. sul
  19. Hi. I have some questions. 1) I use txtsetup.sif to install scsi/sata drivers. I put cabbed driver.sy_ into i386. OK. 2) I now wish to install drivers from cd. No unattend.txt here. I make $OEM$ structure. I put in driver files into proper subdirectory. Using Pyrons method, as in the Guide, setup.ex_,presetup.cmd,driversign,devicepath. Also edit txtsetup.sif to include setup.exe = (2 new entries). Works OK. 3) I now wish to copy drivers to hdd, the install. Using unattend.txt, set line for \driver\000_chip\via... etc etc to point to proper path. Use cmdlines.txt, and can use setupapi.dll or runonceex for stuff. This also works OK. 4) I see on uAWIKI that a different method exists. Using OEM\bin\drivers. I understand it. I see additional dosnet.inf entry. I see $OEM$ not the same. I see adding runonceex from presetup.cmd ( i like that ). I see this copies from cd. 5) I see intel plugNplay inf, 'abnormal'. I see make $OEM$\$$\INF for this. So, I wonder, why the difference in install from cd with $OEM$, which works, with no dosnet.inf entry, vs. the OEM with a dosnet.inf entry. They seem to be very similar. Also, what is it with the Intel drivers and the \Inf directory. If I use $OEM$ method, I know where to put the INF dirctory. Where do I put the INF directory using OEM method? Why the inclusion of the dosnet.inf entry. I have tried both methods. Why swith to OEM when $OEM$ works. My thoughts, I use winnt.sif now on floppy. I make good uxpcd, apps, runonceex, cmdlines etc, and (in $OEM$), use them from winnt.sif. I also in the uxpcd, make use of txtsetup.sif and Pyrons $OEM$ drivers from cd method, which then no matter winnt.sif or not, drivers are searched. Works good to have one cd, my choice to unattend or not (great for multi computer, where so much can be handled with winnt.sif, custom per seat) Can I, use $OEM$, with driver from cd, AND if option, also copy over $OEM$ to hdd using unattend, and keep reference to that position for .inf of drivers instead of reference to %cddrive%? Hacked up syntax here. Sorry about that. Too much I could describe of my questions that I tried to paraphrase as much as possible. Suffice, I can make the methods work, but I wish to build hybrid. Both capability to install from cd and with unattend.txt, install from hdd. sul
  20. Greetings. In a nutshell, a registry value can be one of the following types, as seen in a .reg file "string" = REG_SZ dword = REG_DWORD hex = REG_BINARY hex 2 = REG_EXPAND_SZ hex 7 = REG_MULTI_SZ hex 8 = REG_RESOURCE_LIST hex 9 = REG_FULL_RESOURCE_DESCRIPTOR hex A = REG_RESOURCE_REQUIREMENTS_LIST hex B = REG_QWORD Obscurely there is also hex 1 = REG_SZ. This comes into play if you have CR or LF within the REG_SZ value. If you had a .reg entry of "value1"=hex(1):string value in hexadecimal here and merged it into the registry, the REG_SZ value could have CR & LF characters within. I am looking for a way to include this type of REG_SZ into an INF file. 0x00000000 is the flag for a REG_SZ. I have tried many different flags, but have failed to find the correct one. Is there anyone who has ever seen this and knows the correct flag value? Thanks a million to anyone who has, Sul.
  21. I know what is happening. I have read up on how to do it from an unattended setup. I do not want to make any changes to the key I wish to add. I just want to allow the key to be written. If I do it by hand, changing the permissions, it works. But, that is not automation. Key is HKLM\System\CurrentControlSet\Enum\Root -- this is a LEGACY_ entry. The services keys go in fine. I have tried it as admin or not, niether lets me add the key, either from .reg file or .inf file. Same in both xp and w2k. Surely there must be some way to do this. I have read up on the inf section [Copy.Files.Security] "D:P(A;CI;GA;;;BA)(A;CI;GA;;;SY)" but I am under the assumption that this is to set the security descriptor for the key I am adding. I wish to allow for writing, then set back to not allow. Is there an INF pro here who can help me to understand what exactly is needed for this to work? Should mention this is an install of an AV app. I do this to stop that troublsome Ikernel.exe issue that I continually have. Stripped the install away from InstallShield and made an .inf for it. Works great, except for the part where I have to add one last .reg/.inf entry by hand. Later. Sul EDIT: Forgot to mention that while knowing how to do this with a .reg file would be helpful, I really want to know how to make the .inf work.
  22. Greetings. I have a wierd one here. First, get this out of the way Computer 1 static 192.168.1.x no firewall, no av, fresh install xp pro sp2 have network connectivity and all that Computer 2 same thing but ip .xx Computer 3 and 4, xp pro original. static ips. no firewall, av, etc All needed services are running no 'non-default' security policies home environment, using simple file sharing The problem is this. I use windows explorer, share a directory, with read/write permissions on computer 1,2,3,4. Any computer, using run \\computer# can open the resources, and read/write. Here is the catch. On pre service pack computers, I can use the command line 'net share' to make the share, and all 4 computers have read/write. If on the sp2 computers I make a share this way, I get error " i do not have permission". If I del the share, then create the share from explorer, works fine. I have tried the enable guest account, tried various security policy changes, enabled and disabled different services. I have extensively searched the web for some documentation on what exactly sp2 does this for, but no luck. The only documentation is for standard 'net share' options, none of which include actually setting privelages. As per MS website, in sp2, by default, the 'allow users to change files' in simple file sharing has NOT been enabled. And furthermore, they state that using the 'net share' command to create a share will, by default, enable read/write with NO option otherwise. And they state that the guest account must be enabled for this to occur. sp2, by default, does NOT enable the guest account. Although there seems to be 2 guest accounts. One resides in the management console under 'users', and it was NOT disabled. The other, it lives in the 'user accounts' from the control panel. It is disabled by default. Now, why do I care? Because I wish to include in scripts the ability to share what I desire to share. OH, it does create the share, and it is even a resource I can view browsing, or I can even 'net use' as z: or whatever. But, I cannot go into that share, unless it is created from the GUI. Does anyone know what is going on here? I am hoping it is something that I can script up, not a manual fix on every computer. If that is the case then I might as well create the share manually. The reason: I organize the LAN parties that me and a bunch of other gamers like to attend. I have been writing a script to distribute drivers, patches, mods, updates, maps, etc for the games. And part of my script creates shares with the 'net share' command. I am trying to harness the power of the first dozen peeps that come in and make them servers so there are no lines for getting files and most importantly so that one computer is not downloading a file and uploading 2 others at the same time. Kind of makes my super duper fast network not so super or duper. Oh, and not that you were wondering, but just in case you were, torrents are not very fast on a LAN. Max I have seen is about 40% of my 10/100 nic. And they tend to build up speed, and then sort of re-calibrate and start from 0 again. However, if you know something I don't, that would actually be easier than a script. Thanks for any offerings of help. sul
  23. Hmm. Learning more here. As per a post by greenmachine, this is the order runonce run runonceex runex And also this by greenmachine Does this mean that when I use an inf to put the reg entries in runonceex, that they will be used on every boot? I know to look in those areas for rogue apps and stuff. And now I am seeing more mention of using guirunonce. I thought that was the not preferred method. Specifically it was talking about using it to install apps. who would have thought building a simple uA cd could be so full of differences. sul.
  24. Well, after much reading and a little playing, I am still not quite sure of a few things. So, I can use a inf to run my installs of apps like adobe or whatever. Or an inf to add or delete registry settings. One way to call my inf is from cmdlines.txt. But I am missing something. On a typical uA install, after the contents are copeid to the hdd, and I assume before a reboot for the gui portion, is this where anything happens? I have read some bits and pieces that something happens here, but I could not find it again. If nothing happens there, then I am assuming that I want to get as much as I can installed/tweaked during the gui portion of setup, before a first logon. Is this where the inf files are processed? Is this where cmdlines.txt is processed? Is there another way of calling my inf files other than cmdlines.txt. Pardon me, but I have read so many different ways, I am really struggling to piece it together. I understand that as long as it works just go with it and all. But Hmmm. Let's say I have 3 infs. One for reg adds, one for deletes or changing things, and one for installing apps. If I wanted to get these to run before first logon, where COULD I call them from? Now, let's say that I called them from cmdlines.txt. And I think that it does it during gui setup. So, assuming those tweaks and apps are finished, I would now use runonceex? Or runonce? I have seen both. Some stuff led me to believe that runonceex was a inf file that (in this case) put reg entries into the machine so that on first login whatever was there (such as installing an app from an app folder that is on my root, that was installed via the $OEM$ method). And then I am wondering about runonceex. The guide says to use it as runonceex.cmd, and put an entry into cmdlines.txt to start it. Is it the same thing, only being put there via a standard regadd batchfile? And does it do it at the same time? Because it is from the cmdlines.txt file. So, either way, I call it from cmdlines.txt? Again, forgive me. I usually snap this kind of stuff up in me little brain. I just haven't found that one thread that has clarified the processes which are available. I keep thinking, create custom inf--call it from cmdlines.txt--create runonce inf--call from cmdlines.txt But I think I am missing something. Am I, or am I finally really and truly just annoying? Thanks yet again fer any help. sul.
  25. Hmm. RapidShare seems to not like me. I loosed up my web settings all the way, and still not working. Any chance you can attach it like you did with the other file? sul.
×
×
  • Create New...