Sulfurious

Member
  • Content count

    35
  • Joined

  • Last visited

Community Reputation

0 Neutral

About 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.