ilko_t

Nice one.

No way, I had been immunized against that form of disease long ago Do NOT select I386 folder, but the parent one, "Новая папка", which consist I386. To stay on the safe side try NOT to use any spaces in paths.Read the tooltips, there are plenty of them for each item in the GUI, just hold the mouse over it for a few seconds. In your case the tooltip says "Select a folder, where I386 can be found", not "select I386 folder". If still isn't clear enough- sorry, I am not native english speaker.

Thanks jaclaz. I've just excluded menu.lst from the files being copied, no matter from what source. This should fix unexpected problems later on, should more and more items included start using grub4dos. Entries in menu.lst to start the various items are added by WinSetupFromUSB anyway. May also add merging menu.lst if found, with the one created by the program.

Can you post your curren menu.lst please?Does VistaPE use menu.lst as well?

Look at the FAQs, Q2/A2:http://www.msfn.org/board/index.php?showtopic=116766 Is it still present in nLite? http://www.howtohaven.com/system/slipstrea...ce-pack-3.shtml C:\Downloads\XPSP3.exe /integrate:C:\XPSETUPCD WMI*:http://en.wikipedia.org/wiki/Windows_Manag...Instrumentation http://msdn.microsoft.com/en-us/library/aa394582.aspx Some programs, VBS scripts etc. make use of WMI, WinSetupFromUSB as well, in order to obtain USB drive properties

Windows 7 would be supported when all other programs used fully support it- AutoIt, grub4dos installer etc. etc. As for the VistaPE- can you create an empty folder SOURCES if doesn't exist, next to folder BOOT. Does it accept it now? Did you use Vista Setup/PE/Recovery ISO field or BartPE/UBCD4Win...? You should use the former one.

Wow! Nice review and thanks for the kind words A few notes: This is fixed in 0.2, which is ready, but I'd have no test rig around for a few weeks. It copies everything in I386 folder to ~LS\I386 + some additional folders (PRINTERS etc.) from Windows CD. ReadMe.txt describes exactly what is copied. Be careful and do NOT select Manual Install and Upgrade for removal. This is critical part.And better off manually slipstream SP3 if needed. It seems some nLite versions break WMI when integrating SP3.thoro To mention a few:http://www.msfn.org/board/index.php?showtopic=111401 http://www.msfn.org/board/index.php?showto...st&p=780004

This should be way better solution for your needs: http://www.msfn.org/board/index.php?showtopic=121446

Yep, not universal, but should do the trick just to reveal if the write cache makes the difference, since there are no write attempts when using it.As for the grub4dos write- I doubt, grub4dos uses BIOS disk numbering, boot disk is hd0. At partition screen the same disk is harddisk1, internal one is harddisk0, even though it's not the first in BIOS boot order. The only semi-logical explanation I found was that disks numbering is in alphabetical order, as per driver name. I.e. disks on ATAPI.SYS get the first numbers, then on DISK.SYS, then SIL3112.SYS for example. Drive letter assignment still depends on BIOS numbering, fixed/removable is taken into account. Compare: http://www.msfn.org/board/index.php?showto...st&p=705697 http://www.msfn.org/board/index.php?showto...st&p=647581 USB disks are at DISK.SYS. I tried to rename it to _isk.sys and amend txtsetup.sif accordingly. This failed, disk.sys is hardcoded and used in other drivers, I did not go further. Thanks for your input, as always you trigger a little brainstorm.

Maybe it's still all about the write cache? Setup attempts to delete the compressed files while expanding them to target directory. USB devices are write protected, but maybe those attempts for deletion are still speeded up by the enabled write-cache triggered by using NTFS:http://www.uwe-sieber.de/usbstick_e.html Seems using NTFS triggers use of write cache even on removable drives.Removing write-protection gives no speed difference in the tests above, write cache still matters. Could this be the explanation? A quick test using this approach (no deleted files during Text mode), may reveal if that's the case: http://www.msfn.org/board/index.php?showtopic=119742 I'll have no test rig around for some weeks, any taker?

This would be very handy for all multibooters, thanks for posting it

BTW you may try replacing the above mentioned driver(s) ONLY in the ~BT folder with those from 2000, keeping the originals in ~LS. During Text mode the drivers in ~BT folder are loaded and used, but not copied to the target Windows being installed. The ones from ~LS folder are copied instead. Will take some tests to determine the proper combination of drivers, if possible at all.

Rename back migrate.inf, it's responsible for U: letter and write-protecting USB stick during Text mode. You may need to rebuild the stick if you started file copy part. Some compressed files must have been deleted. Or simply copy over I386 folder from c:\xpcd\i386 to ~LS\i386 skipping existing files. The program will create autopartition=0 in the next version. Should have spotted that in your first winnt.sif posted

Comment out AutoPartition=1 in ~BT\WINNT.SIF and try again.

This is interesting problem, please keep us informed

Hmm, I am puzzled. A few ideas: Does the machine have USB card readers or any other USB mass storage device, including USB printer with card reader, iPod, etc. etc.? It may "shift" USB disks numbering. Try disabling/removing everything, but the hard disk. What type is the 8GB USB stick? Does it have CD-like part? Try renaming migrate.inf to migrate.inf.bak in ~BT folder. Go only to the partitioning screen in Text mode. What drive letter each device/partition got? Which one is listed first? A picture of that screen may help you have camera around. Try renaming $oem$ to $oem$.bak. Does setup continue?

What are contents of that folder $OEM$\$$, what do you install through it? Does the 8GB stick gives that error when using the source, used for the 1Gb stick? Are the proper drivers integrated in both sources? Is the disk contreoller in AHCI/SATA mode? Did you put back unattended section in winnt.sif, or did the program fail to remove it? Check winnt.sif. Similar problem, reported as solved by integrating BTS mass storage drivers pack: http://www.msfn.org/board/index.php?showtopic=128718

Did you get the idea? Fully unattended Setup during Text mode is not possible using this method. Target disk by default is where our BT and LS folders are, on our USB stick/disk.

If you're wondering what doesn't work, after installation is done and I'm trying to boot without USB it says hal.dll is missing. The problem you describe has nothing to do with the quoted messages, and in other hand, is not related to the program at all Do read the FAQs, look at this thread too: http://www.msfn.org/board/index.php?showtopic=128303 BTW did you miss the numerous topics and FAQs in this subforum about the very same problem? Do read this post and below , just a couple of pages back: http://www.msfn.org/board/index.php?showto...st&p=815523

Yep, during the file copy phase in text mode. When Setup is placing them on the internal disk, Weirdly, non compressed files stay intact, but compressed ones are deleted. The idea is to keep down disk space requirements, as ~BT and ~LS are considered temporary and expected to be in the same partition, where Windows would be installed.

Copy Setup boot files only is just to check boot ability of the flash disk, without having to copy the full source and is not made for multi setup sources. Format the stick, use NTFS when possible, why: http://www.msfn.org/board/index.php?showtopic=125116 Place XP SP3 files. When done select x64 files, choose 'NO to rename them and patch setup and startup files'. When installing x64 keep in mind that Setup will delete some of the compressed files when copying them. This happens with versions different than XP SP2 or 3 as USB write protection via registry entry does not work. After such setup, if you need to start another setup, you will have to run the program again, select x64 source and select "synchronize" at the dialog box in order to copy the missing files. Or just do it manually, with KillCopy or any other similar program, which can skip existing files. Copy from your x64 source folders I386 and AMD64 to USB_drive\$WIN_NT$.~LS\I386 and AMD64 respectably. This behavior is not present in the way of setting up from PE.http://www.msfn.org/board/index.php?showtopic=128659&st=0&gopid=827649

x64 is already supported in WinSetupFromUSB. Start64.exe was for reducing number of boots from USB and avoiding renaming of BT and LS folders twice. I did not have the spare time to implement all the changes I wanted at once, so instead I'll be doing it by piece as next weeks will be less busy with the real work. The method is fine with x64 for one-off installs. If you need to carry an USB stick around and perform setups many times have a look at Wimb's links. x64 and XP SP3 setups can coexist, just put x64 last, and make sure ntdetect.com and ntldr in root of USB are the ones from x64, they can boot 32 bit versions, but not vice versa.

Follow the replies in this topic: http://www.msfn.org/board/index.php?showtopic=128303 If you cannot figure it out, take a picture of the partitioning screen during Text mode and post it along with your present boot.ini.

Did you read and try what is written in the post right above yours?

presetup.cmd is executed by fake setup.exe at start of GUI mode. You need to use txtsetup.sif for the purpose. Setup will add it to Windows as a driver for you, no need to worry for GUI part. Want to play a bit? 1. Here is WinSetupFromUSB.exe with the check for first partition removed. Put it in WinSetupFromUSB folder and use it instead of the original file. 2. Replace rdummy.sy_ in \WinSetupFromUSB\files\winsetup\ with dummydisk.sys cab compressed (makecab /?) and renamed. You may get it from \files\MULTIpartitionUSBstick\ 3. Run \files\MULTIpartitionUSBstick\InstallStartDummyDisk.cmd, partition the USB stick, make the second partition primary and active. Keep dummydisk.sys running. You will need it to create a proper migrate.inf. 4. Prepare the USB stick, selecting the second partition. Make sure force Target disk type radio button is on FIXED. You may now stop dummydisk if no longer need it- StopRemoveDummyDisk.cmd 5. Amend presetup.cmd in USB \$win_nt$.~ls\i386\ and add a few lines to copy BOOT.INI, NTDETECT.COM and NTLDR from the USB drive to C:, or %SystemDrive% if you are not installing in a second partition or disk. Try to install. Does Setup find source files in the second partition during file copy stage? How about when formatting the target disk? This is what I can't remember from my tests.