ilko_t

You should be able to to that, however, using x64 some of the compressed files will get deleted during Text mode. You will need after install to copy AMD64 and I386 folders from your source to ~LS folder, skipping existing files until workaround is found. KillCopy or Volkov Commander are handy for this task. Note when using usb_multibootX.cmd- bootsectors to be HEX edited setupldr.b01 for multiple OS install are in \btsec on stick, NOT SETUPLDR1.bs and SETUPLDR2.bs in root. Credits should go to their place- cdob

I didn't get your question. Txtsetup.sif is parsed by setupldr.bin. Hex edit all occurrences of txtsetup.sif to txtset01.sif and the latter is used. That's for setupldr.b01. For setupldr.b02 use txtset02.sif. Text mode Setup completes fine. GUI part to be tested. There is 1 occurrence in setupdd.sys, may have to be changed too. PE and winnt32.exe have always been an option, mind you, for many users building PE is hard and unknown, they need just a single install off USB. edit: GUI part worked just fine, no need to HEX edit setupdd.sys for txtsetup.sif. Here is the step I forgot in the previous post: In \$win_01$.~ls\I386\ren_fold.cmd change ren %USBDRIVE%\txtsetup.sif txtsetup.bak ren %USBDRIVE%\$WIN_NT$.~BT WIN_NT.BT ren %USBDRIVE%\$WIN_NT$.~LS WIN_NT.LS to ren %USBDRIVE%\txtset01.sif txtset01.bak ren %USBDRIVE%\$WIN_01$.~BT WIN_01.BT ren %USBDRIVE%\$WIN_01$.~LS WIN_01.LS In \$win_01$.~ls\I386\undoren.cmd change ren %USBDRIVE%\txtsetup.bak txtsetup.sif ren %USBDRIVE%\WIN_NT.BT $WIN_NT$.~BT ren %USBDRIVE%\WIN_NT.LS $WIN_NT$.~LS to ren %USBDRIVE%\txtset01.bak txtset01.sif ren %USBDRIVE%\WIN_01.BT $WIN_01$.~BT ren %USBDRIVE%\WIN_01.LS $WIN_01$.~LS Do the same for both files in $WIN_02$.~LS and use $WIN_02$.~*** and txtset02.***

Just a quick check list- to have lets say XP1 and XP2 In root: \$win_01$.~bt \$win_01$.~ls \$win_02$.~bt \$win_02$.~ls ntdetect.com NTLDR txtset01.sif txtset02.sif setupldr.b01 setupldr.b02 Both HEX edited to $win_01$.~bt and $win_02$.~bt and txtsetup.sif to txtset01.sif and txtset02.sif SETUPLDR1.bs SETUPLDR2.bs Both HEX edited setupldr.bin to setupldr.b01 and setupldr.b02 boot.ini [Boot Loader] Timeout=10 Default=multi(0)disk(0)rdisk(1)partition(1)\WINDOWS [Operating Systems] C:\SETUPLDR1.bs="1. TXT Mode Setup Windows XP1, Do NOT unplug USB-Drive Until After First Logon" C:\SETUPLDR2.bs="1. TXT Mode Setup Windows XP2, Do NOT unplug USB-Drive Until After First Logon" multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="2. GUI Mode Setup Windows XP + First Start XP" /FASTDETECT In $win_01$.~bt setupdd.sy_ expanded and HEX edited $WIN_NT$ to $WIN_01$ and re-compressed ( necessary ? ) In $win_02$.~bt setupdd.sy_ expanded and HEX edited $WIN_NT$ to $WIN_02$ and re-compressed ( necessary ? ) Did you miss a step? Did I miss a step ? ilko

Just noticed that actually only compressed files are deleted during Text Mode- txtsetup.sif [sourceDisksFiles] binifix4.cmd = 100,,,,,,_x,2,0,0 <------copied not deleted undoren.cmd = 100,,,,,,_x,2,0,0 <------copied not deleted ren_fold.cmd = 100,,,,,,_x,2,0,0 <------copied not deleted _default.pif = 1,,,,,,,1,2,0 <------copied AND deleted First 3 are not compressed, 4th is. Since write protecting USB does not generate errors while trying to delete nor cause delays, I'd not be surprised if expand functionality in setupdd.sys or wherever it is works the same way as if source is CD, but simply isn't generating errors. I have also tried to rename both ~BT and ~LS folders to 1WIN_NT1.1BT and 1WIN_NT1.1LS hoping that $ triggers deletion, hex editing setupldr.bin and setupdd.sys (thanks cdob) Text Mode install went fine, but files still got deleted

You are installing from USB hard disk, right? Did you select for disk type USB hard disk in USB_multibot6.cmd?

Thanks cdob, very useful info. Have you tested with this line included? SetupSourceDevice = \device\harddisk0\partition1 From the above article edit: Never mind, seems I did: http://www.msfn.org/board/boot-install-USB...730#entry684730 Memory is getting shorter and shorter, I should start again taking the medicine

There is an old MS article for NT, which gives some clues, I have no idea if this could be used for 2000/XP/2003. I did play with these settings in the past without much luck. Didn't test for this particular scenario. http://support.microsoft.com/kb/150497 txtsetup.sif:

The only restriction is that the section [unattended] in winnt.sif cannot be used, all the rest as as usual. If you have any custom scripts/customizations performed from there, find an alternative way. If ALL your customizations were not applied AND you have them in different places, my best guess is that you have used by mistake the supplied generic winnt.sif, coming with the package. Make sure you do NOT use it- select W at menu, then point it to your winnt.sif.

Here you go DOSNET.zip

How about this solution? http://www.msfn.org/board/Disable-Driver-S...4199#entry84199 What is the unsigned driver? I doubt it's anything related to the USB install, it should fail the same way if installing from CD as long as contents are the same. When you lights go off and on this is the part with the hardware detection, which is not only USB. What is your source? Have you integrated custom drivers? How?

Use Hitachi microdrive filter driver, this will patch the query for removable bit on-the-fly. USB sticks are now seen as basic disks, partitioning is allowed. Google for downloadable links. Or use dummy.sys to achieve the same: http://www.codeproject.com/KB/system/sovie...ct_hooking.aspx Use Grub4Dos as boot loader, use it's mapping features to boot from desired partition. Look at read.me for examples.

Files are deleted because ~LS and ~BT folders are considered as temporary by design. During Text mode files are actually moved, not copied. In XP SP2 there is a registry entry, which makes USB storage media read only. Thanks to cdob's idea, this entry is used via migrate.inf. Unfortunately, this seems to works only for XP SP2. If your stick has a read-only hard switch, you should be good to use it. There is not other known/published way, to software write- protect entire USB drive during Text Mode, where you have quite limited functionality, or at least I can't find anything usable. I did a few tests with FBWF and EWF to no avail. Thanks for the feedback.

Seems like StorageDevicePolicies reg. entry works ONLY for XP SP2 32bits. That means for any other windows version in 2000, XP and 2003 families, many files will be deleted from USB stick during Text Mode phase. Everything else would work as usual. In order to reuse the stick for another installation, one would need to make a backup of I386 (and AMD64 for x64) folder(s) on his hard drive once the stick is ready, and copy these two folders back to stick in $win_nt$.~ls folder. I am using KillCopy, and tell it to skip all duplicates. @wimb- you should easily spot the changes made, if haven't done so yet, just search for 'AMD64'. Should be easy to add detection if source is x64 and use the changes needed. Don't have a 2003 x64 to check if structure is the same as XP x64. ilko

Did a few quick changes to USB_multiboot5, would you please test it, if possible until complete install and first logon and report any problems? Just rewrite usb_multiboot5.cmd with the file enclosed. Installing from USB stick, right? edit: a few more changes to the file edit2: got it working, but part of the files on stick were deleted during TXT mode. No SP2 integrated. Seems write-protecting the removable storage reg. entry is not working with it. Going to test with SP2 integrated, will post results later. That reg. entry won't work for windows 2000 too, just read it was introduced for first time in XP SP2 32bits. USB_MultiBoot5.zip

Oops, sorry for misleading you, it won't work. The way dosnet.inf is parsed should be changed, so it can get needed files from both I386 and AMD64 folders. Also the source check should be made for both AMD64/I386 and I386.

It should work just fine with x64 as long as you are not installing from USB hard disk, where rdummy.sys is used. That driver is not compiled for x64, if there is any programmer, willing to rewrite the code for us please don't hesitate to do so

Nope Boot files ntdetect.com, ntldr and boot.ini will go to first partition, where I assume Vista is. Nothing has to be changed in this case.Multiboot Vista and XP when latter is installed second is also easy- use Jaclaz's makeBS.cmd from here: http://www.boot-land.net/forums/index.php?...aded&start= Copy and rename c:\bootmgr to c:\vsldr for example, must be 5 characters for NTFS. Then launch makeBS.cmd c:\vsldr /a "Start Vista" And you get Vista launched from NTLDR/BOOT.INI Of course one can also repair Vista's bootsector and use bootmgr.

Shouldn't be like that, just do NOT select Operating System Options-->Manual Install and Upgrade for removalFinish with Nlite, apply mass storage drivers pack with text mode enabled, use USB_multiboot5 and you should be fine.

Thanks for reporting For the record, what was the hardware you were getting 0x7B on?

Wimb, since winnt32.exe, which is making MsDosInitiated="1" and floppyless="1" is no longer used, it would be good idea to check for these 2 lines and amend/add if necessary.

Are you changing windows folder name? Do you have any other USB mass storage devices plugged in during install? edit: After first phase- Text mode setup, do you choose this entry to continue Setup?

Do NOT unplug the USB stick until after the first normal start in windows has finished. Make sure if you install windows in different folder (i.e. windows123) or partition other than first disk/first partition, you amend BOOT.INI on stick accordingly. For example if you installing in folder WINDOWS123 change this line in boot.ini from: multi(0)disk(0)rdisk(1)partition(1)\WINDOWS to multi(0)disk(0)rdisk(1)partition(1)\WINDOWS123 If it's on partition 3 make it like this: multi(0)disk(0)rdisk(1)partition(3)\WINDOWS If it's on second hard disk, partition 4 should look like this: multi(0)disk(0)rdisk(2)partition(4)\WINDOWS Problem fixed? Please have a look at Help_USB_MultiBoot5.txt, it's all explained in there.

You can use presetup.cmd, it's executed at the beginning of the GUI part, before anything else. Find the registry changes you need to make for your purposes and use REG ..... I don't recall whether regedit was available at that stage, but you can give it a try too.

I would look from Bart PE at setup log files and see the last lines, usually that points which component to look at- \windows\setup*.log

http://unattended.msfn.org/unattended.xp/view/web/13/ : Isn't 8 early enough for your needs? I'd rather not touch presetup.cmd, unless you are aware that and how it is used by BTS drivers pack.I wonder, the subforum is new, here are like 10-15 threads only on a single page, couldn't you see this thread with so informative title? $OEM$ folders aren't being copied to %systemdrive% and the answer here: http://www.msfn.org/board/index.php?act=fi...&pid=734317