USB Boot file descriptions

[Sulfurious]

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.

[Sulfurious]

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.

[wimb]

Links on Install of XP from USB using USB_MultiBoot_10.cmd

• Tutorial on Install of XP from USB at BootLand Forum - Tutorial
  
• ScreenShots of USB_MultiBoot.cmd - ScreenShots
  
• List of FAQs at MSFN Forum - FAQs
  
• Install XP from USB - Support and Changes USB_MultiBoot.cmd - Support and Changes
  
• Guide for MultiBoot USB-stick with boot.ini Menu - Guide
  
• More Help with Bookmarks is available in the Help_Info Folder in USB_MultiBoot.zip
  

Section C of the Guide can be helpful for you to get a better understanding of the booting mechanism.

SETUPLDR.BIN was Renamed to XPSTP according to the 5-letter limit requirement in NTFS BootSector File XPSTP.bs

The usbflash file has NO meaning for the booting process, it is just a marker file.

The btsec folder contain all the BootSector Files and is the USB-Drive Specific part,

which is renewed together with $WIN_NT$.~BT\migrate.inf

if one uses the USB Content of one stick as Source to make another one.

Booting from USB-stick is as follows:

MBR > Drive BootSector > NTLDR > boot.ini > C:\btsec\XPSTP.bs > XPSTP > txtsetup.sif and $WIN_NT$.~BT\winnt.sif

XPSTP is just the renamed SETUPLDR.BIN (no hex editing).

Default is Unattended Setup using XPSTP as SetupLoader

And for Attended Setup we use XATSP as SetupLoader, where all winnt.sif are replaced by winat.sif

grldr has no function for booting into TXT-mode Setup XP,

but it is used for other boot options DOS + Linux + Vista

For the USB-stick to boot as Harddisk it must have

MBR and partition with NTLDR Type Drive BootSector as made with HP Format Tool and XP as OS.

On the stick there are four files required: NTLDR + NTDETECT.COM + BOOTFONT.BIN and boot.ini

of which BOOTFONT.BIN is NOT essential, but NTLDR is looking for it.

I prefer to format USB-stick with HP tool and NTFS FileSystem so that Files in I386 folder

are easily found in the about 7000 files of I386, so that XP Setup is much faster

When you boot from this USB-stick then it is at that moment harddisk 0 and will get drive letter C:

for evaluating boot.ini Menu.

When you Select TXT-mode Setup XP then the USB-stick will appear in the DriveList of TXT-mode as U:

and your computer harddisk Install Drive will appear as C:

Use Notepad to study boot.ini and winnt.sif and more complicated to study USB_MultiBoot_10.cmd

Use TinyHexer to study MBR(=Sector 0), Drive BootSector and BootSector File XPSTP.bs

The Drive Bootsector is usually for FAT at Sector 63 and for NTFS 16 sectors at Sector 63.

For NTFS especially sector 64 is the interesting part, where in the BootSector File Copy XPSTP.bs

N T L D R has been replaced by X P S T P

The XP BootFolder $WIN_NT$.~BT is made by parsing I386\DOSNET.INF

Alternatively you can also try to use USB_XP_Setup.cmd which is in my opinion an even better approach.

There are no corrections or workarounds needed and it corresponds very well to Install of XP from CD.

http://www.boot-land.net/forums/?showtopic=5306

Regards,

wimb

Edited September 17, 2008 by wimb

[Sulfurious]

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.

[ilko_t]

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.

First way is migrate.inf. Assigning U: or whatever to the USB disk "frees" letter C: for the first hard disk/first primary partition.

Migrate.inf consists the entries from HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices, where each disk connected has own "signature" to say it in short, and corresponding drive letter. Look here for details:

http://www.goodells.net/multiboot/partsigs.htm

Migrate.inf is parsed when Setup enumerates the present disks.

Second way- given USB stick, which is seen as REMOVABLE, and IDE disk with one primary partition, AND booting the Setup from the USB disk will result of internal disk getting letter C, and the USB one- D.

If you boot Setup from USB stick, which is seen as FIXED(BASIC), or a USB hard disk, which is always FIXED/BASIC, Setup will give USB disk/stick letter C, and the internal disk gets D.

Some details about REMOVABLE/BASIC(FIXED):

http://www.codeproject.com/KB/system/sovie...;select=1468078

http://www.osronline.com/DDKx/storage/k306_00qa.htm

Now lets make it trickier- USB stick, which is seen as REMOVABLE, SATA disk attached to SATA controller working in SATA mode, with one primary partition and IDE CD ROM. Now Setup flips the order again- USB stick gets C, SATA disk- D. The present IDE device messes with the enumeration. Technical explanation why is beyond my knowledge, it has something to do with the way the disk.sys/partman.sys read info from BIOS, and lets not forget that Setup has never been designed for USB disks and dates back to the days of NT.

In the long initial thread and the links within you can find all kind of information, about the boot process, how Setup sees the disks, the first guides and batch files, which will be much easier to understand, how REMOVABLE/FIXED bit is "flipped" etc. etc.:

http://www.msfn.org/board/How-to-boot-inst...key-t61384.html

[Sulfurious]

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.

[Sulfurious]

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.

[Sulfurious]

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.

[ilko_t]

I guess if we start with the basics it would be easier to understand. Forget for now scripts, PE etc. etc. Lets figure out how Setup works.

BIOS-->MBR on USB disk-->active partition boot sector.

If it is a NT bootsector it will invoke NTLDR, which calls NTDETECT.COM, which enumerates the hardware and return to NTLDR, BOOT.INI is parsed for boot menu.

NTLDR can chainload a bootsector. This is the same NT bootsector saved as a file, but the strings NTLDR are replaced with STLDR, thus it will invoke STLDR (SETUPLDR.BIN renamed) instead of NTLDR.

NTDETECT.COM is recalled. Since it returns it's a hard drive, Setup goes in this mode, searching for $WIN_NT$.~BT folder for the boot files.

Here we must note that SETUPLDR.BIN in ~BT folder can be directly invoked, if using grub4dos as boot loader for example.

title Chainload SETUPLDR.BIN
chainloader /$WIN_NT$.~BT/SETUPLDR.BIN

Lets go back a step. GRUB4Dos can be launched in a various ways:

1. Own MBR code, which searches disk partitions for GRLDR file and loads it.

2. Own bootsector, loading GRLDR from the same partition.

3. Invoked by NTLDR/BOOT.INI:

C:\grldr="Start Grub4Dos"

4. Using the same technique as loading STLDR- just replace the strings NTLDR in NT bootsector with GRLDR. This will fail on FAT16 partitions.

Thanks to cdob and jaclaz for sharing their huge knowledge in this field.

Now we loaded SETUPLDR.BIN using any of the above methods. Since it's in a "hard disk" mode, TXTSETUP.SIF is expected in root of the boot device.

WINNT.SIF is expected and read from ~BT folder.

SETUPLDR.BIN loads the drivers listed in TXTSETUP.SIF, then initializes them at once- "Windows is starting" message.

At that point WINNT.SIF is read. The line MsDosInitiated is critical. If value is 1, then source files are expected in $WIN_NT$.~LS folder.

If value is 0, SetupData section in TXTSETUP.SIF must point to the location where source files are, read for details:

http://www.msfn.org/board/Alternative-loca...en-t119742.html

A) Lets assume MsDosInitiated = 1.

If section Unattended in WINNT.SIF is found, Setup won't prompt where to install Windows on, by default this is the partition/disk where Setup was executed from.

Setup starts copying files from ~LS folder, deleting the compressed ones as they are copied to Windows folder. This is bad for us. To avoid this we write-protect USB drives using MIGRATE.INF. The trick works for Windows XP SP2/3 only. Possibly for SP1 too, not confirmed. Doesn't work for 2000/2003/x64. Thanks to cdob for this brilliant idea.

Thus Setup cannot delete them while copying. I guess this design was made with disk space in mind, since by design those folders ~NT and ~LS are on the disk where Windows is installed to, considered as temporary and the disk space could be limited.

At the end of Text mode Setup boot files (NTDETECT.COM, NTLDR and BOOT.INI) are placed to the disk, where Setup thinks boot will occur from.

In case of Removable disk- it's ignored and files are places on the first active primary partition of the first fixed hard disk.

In case of Fixed disk- the same rule, but now this happens to be our USB disk. This is bad too. We want them on the internal disk. Hence we use a driver (rdummy.sys) which patches all requests "Are you removable disk" to the USB and returns always "Yes, I am". Thus boot files go to the next disk, which is our internal one.

BOOT.INI is created according to BIOS boot order. Internal disk is seen as second, boot disk(USB) is first.

multi(0)disk(0)rdisk(1)partition(1)\WINDOWS

is created, instead of rdisk(0) which we want.

Text part is done, now time for reboot.

On reboot we can NOT start from the hard disk, as it has incorrect BOOT.INI entry, and we have no means* to adjust it during Text mode. Hence we start the second part, using NTLDR/BOOT.INI on the USB disk again.

*Some "tweaking" is possible by using grub4dos ability to map a disk to another, i.e.

title Phase 1 WinXP Text Mode Setup

map (hd0) (hd1)

map --hook

rootnoverify (hd1)

chainloader (hd1,0)/$WIN_NT$.~BT/SETUPLDR.BIN

This will result in a proper BOOT.INI, but will also add a signature to BOOT.INI entries, since Setup sees strange partitions. This signature Wimb reported that caused delay when booting from the hard disk.

Setup continues with GUI mode. What is interesting for us is at T-1, right before it's completed. Then it will attempt to remove all temporary files and folders. This includes our ~BT and ~LS folders. To avoid that we execute a script (ren_fold.cmd) at T-9, which renames ~BT and ~LS folders. Setup is tricked- can't find and mess with our folders. BOOT.INI is amended again by Setup- timeout entry is made 30, also checks are performed if it's correct. This is bad for us again- cannot make a script, correcting BOOT.INI in this stage.

Time for first boot- since BOOT.INI on hard disk is still with a wrong entry, we have to use NTLDR/BOOT.INI on the USB disk again.

Upon first launch of normal desktop, we correct BOOT.INI with a script (binifix.cmd made by jaclaz), making the default entry from rdisk(Z) to rdisk(Z-1), i.e. from rdisk(1) to rdisk(0). In other words we "remove" the effect the USB disk caused on creating BOOT.INI entries.

At the same time we rename back BT and LS folders to their normal names in order to be ready to be used again.

This much for normal "hard disk" type Setup.

===================================

B ) Now lets go back to this thread:

http://www.msfn.org/board/Alternative-loca...en-t119742.html

This shows us how Setup can be pointed to alternative location of source files, not ~LS folder as expected from hard disk type install.

MsDosInitiated must be 0, Setup will ask TXTSETUP.SIF where source files can be found.

[SetupData]
SetupSourcePath = "\"
SetupSourceDevice = \device\harddisk1\partition1

This would mean folder I386 is expected in \ (root) of \device\harddisk1\partition1 i.e. source files are in \device\harddisk1\partition1\I386

SetupSourcePath could be "\xppro\" or anything like this, so we can tidy up the folders, instead of placing everything in root.

Unfortunately Setup sees USB disk at that stage as harddisk1, instead of 0. This is in case with 1 internal hard disk. If you have 2, USB disk will be harddisk2... A bit restricting.

Anyway, since it's no longer "hard disk" type setup, unattended section in WINNT.SIF would not force installation on the same hard disk without a prompt, also files will not be deleted neither during Text part, nor during GUI part of setup.

Since we booted from USB and ~BT folder is on USB, BOOT.INI on the destination disk will still get wrong entries, rdisk(1) for example, instead of rdisk(0). binifix.cmd is stil needed.

Wimb used this cleverly in another way- boot from USB PE environment (WinBuilder), create the ~BT folder on the destination hard disk, find how many disks are attached and set SetupSourceDevice in TXTSETUP.SIF accordingly (USB disk will be the last one), leaving the "main" source on the USB disk. Next boot is from the hard disk, where Setup is launched from ~BT folder.

Since boot is from the internal disk, BOOT.INI will be created with the proper entries.

A quick note how SETUPLDR.BIN behaves if NTDETECT.COM returns that is executed from CD, Floppy or Hard disk media:

CD- files are expected where SetupSourcePath in TXTSETUP.SIF points to.

Floppy- boot files are read from the floppy (~BT folder), source files are to be found on a CD

Hard disk- boot files are expected in ~BT, source in ~LS folders.

This is pretty much what's happening and why all the mess with the Setup from USB, hope I put it in a understandable way.

[Sulfurious]

This is pretty much what's happening and why all the mess with the Setup from USB, hope I put it in a understandable way.

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

111 = %cdname%,%cdtagfilei%,,\i386\rets

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.

[Sulfurious]

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.

[wimb]

Siginet's Windows XP PowerPacker is a very handy tool to make your MultiBoot DVD's

It automatically makes only one copy of a particular file on DVD, which gives a nice reduction of space.

http://www.siginetsoftware.com/forum/showthread.php?t=151

see my post #14

When using LiveXP PE you should NOT Boot from USB-stick. It will take about 5-10 minutes.

Follow the described procedure for USB_XP_Setup http://www.boot-land.net/forums/?showtopic=5306

and boot in 30 sec with LiveXP from HDD via BootSDI.img file loaded in RAMDISK.

When using USB_XP_Setup.cmd the XP Setup Source Folder must always be

on USB-stick or on partition 1 of ANY Harddisk.

The output of USB_XP_Setup\makebt\MBRWiz.exe /list is file USB_XP_Setup\makebt\dplist.txt and

is used to relate XP Source Drive Letter to harddisk number and so to determine e.g.

SetupSourceDevice = \device\harddisk2\partition1

@ilko_t

Thanks for the nice overview.

It will certainly help a lot of people to understand Install of XP from USB

Edited September 19, 2008 by wimb

[Sulfurious]

Siginet's Windows XP PowerPacker is a very handy tool to make your MultiBoot DVD's

It automatically makes only one copy of a particular file on DVD, which gives a nice reduction of space.

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.

When using LiveXP PE you should NOT Boot from USB-stick. It will take about 5-10 minutes.

boot in 30 sec with LiveXP from HDD via BootSDI.img file loaded in RAMDISK.

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?

When using USB_XP_Setup.cmd the XP Setup Source Folder must always be

on USB-stick or on partition 1 of ANY Harddisk.

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.

The output of USB_XP_Setup\makebt\MBRWiz.exe /list is file USB_XP_Setup\makebt\dplist.txt and

is used to relate XP Source Drive Letter to harddisk number and so to determine e.g.

SetupSourceDevice = \device\harddisk2\partition1

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.

Edited September 19, 2008 by Sulfurious

[wimb]

However, how do you handle getting it on there to begin with? Assume you get new hdd, raw.

..............

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?

For a brand new hdd it is still useful to boot with LiveXP PE from USB-stick,

and then use Acronis Disk Director 10 for the Partitioning and after Quick NTFS Format of the Install Partition

you can use USB_XP_Setup.cmd from USB-stick and proceed with XP Setup as described in the Tutorial.

But for the other more usual cases, booting with LiveXP from HDD is more interesting,

because of the very fast way of Booting into Live XP PE Environment.

Install of the BootSDI.img File as boot option in boot.ini Menu on HDD can be accomplished

by using BOOT_IMG.cmd or you can use Option C in Make_USB.cmd when you prepare your USB-stick.

It is not the difference BartPE versus LiveXP which determines the boottime,

but it is the difference in Boottechnique.

For Live XP we make use of a BootSDI.img Harddisk Image file which is loaded into RAMDISK and

when you do this from USB-stick it will take some 5-10 minutes in time but from HDD it is a few seconds.

The advantage is that when the LiveXP PE is booting from RAMDISK,

you are allowed to make Changes and are FREE from the source disk,

so that you are even allowed to Format the Disk from which you just loaded the Image File into RAMDISK

After loading the Image from DVD or USB-stick, you can remove the DVD or USB-stick,

which is NOT the case for your way of booting BartPE.

On every Harddisk it is interesting to add LiveXP PE booting from RAMDISK

standard as Extra Boot Option to your XP boot.ini or Vista BootManager Menu,

so that you have a FAST 30 sec Boot Escape and are able to perform any Task like

making or Restoring a Ghost Image of the Operating System Partition,

or Remove Viruses or do ANY other interesting task,

which would be forbidden in the Running XP or Vista OS Environment

Edited September 19, 2008 by wimb

[Sulfurious]

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.