ilko_t

Sure it is, first post says so, so does the program option... Using the program? Just wait, if the USB drive is slow, it may look as frozen when copying the large install.wim or any other large files.

1) Most likely not, install drivers afterwards 2) grldr - grub4dos boot loader menu.lst- grub4dos configuration file, boot menus plpbt.bin- PLoP boot manager, used is USB disk is detected as a supefloppy by BIOS or to speed up boot process if BIOS does not support USB 2.0 boot default- grub4dos reads and writes this file to set/determine which boot menu should be auto set as default one, used for unattended setup for example usbdrive.tag - used to determine which disk/partition contains the files needed 3) No, completely different. Vista and above are "Setup from USB" aware, to say so, source is copied unmodified and the only task is to launch bootmgr somehow. 2000/XP/2003 are not and lots of "cheats" are used to make it "USB setup" friendly. Glad you got it sorted and thanks for the feedback.

For some reason Setup fails to make it bootable, the issue doesn't seem to be in grub4dos, or the way it boots the second part of Setup. But why Setup fails at that part? Is it something to do with this specific motherboard or BIOS settings? Try something- add Windows 7 to the USB disk, start 7 setup, delete all partitions, create new primary ones, set active the first one, format in NTFS, quit setup. Do that from diskpart or from within the installer. Now start XP setup, do not touch and format the partitions, leave file system as it is, install on the newly created first partition. Does second part continue now? Other ideas, try them before starting XP setup: 1) Disable UEFI boot in BIOS-->boot menu 2) Disable USB Optimization in BIOS-->boot menu 3) Disable or reduce Hard Disk Pre-Delay in BIOS-->Configuration -> SATA Drives Used this manual for reference, couldn't find one for your motherboard, you may not have some or all options in your BIOS: http://download.intel.com/support/motherboards/desktop/sb/biosglossary_v18.pdf

Try entering second part by booting from the internal disk, rather than the USB one, what happens then? Did you leave only one internal disk? Did you use beta8? Did you install from USB disk?

Are you sure you are following the tutorial to the letter? http://driverpacks.net/docs/beginners-guide-windows-xp And make sure DriverPack Mass Storage text mode is selected.

Lets start clean, not introducing too many changes from confirmed working solution: 1) Leave only one internal disk, the one Windows is to be installed on 2) Use proper, vanilla, unmodified XP source. Integrate SATA drivers yourself. Link is in the post above. 3) Prepare USB disk/stick with this source using beta8 4) During setup, delete all partitions and create new ones and continue 5) This might be 1) actually- ensure hardware is working, test with Ubuntu Live CD for example for a while, WinSetupFromUSB can add such as well

Which drivers did you include?Have you tried BTS mass storage drivers pack with Text mode enabled? http://driverpacks.net/docs/beginners-guide-windows-xp How was the internal disk partitioned? From within Setup? Was it pre-partitioned? Have you tried to delete all partitions during Setup and create new ones? Did you use latest beta8 of the program? What model and capacity is the internal hard disk? Can you elaborate on that? How far did it go? Did it freeze,at what stage, or what exactly?

I have never published beta8 in executable file. The only proper source for beta 8 is from here:http://code.google.com/p/winsetupfromusb/downloads/list The old 0.2.3 was the last one with installer and all those versions do not use usbdrive.tag files at all. Anything else you need help with?

The point is not to find a way around the error, but the source of the error and take care of it. You were told what to try, if you insist on doing it your own way, then is it a dialogue, a request for help, or we are reading a blog with your trials and errors? Usbdrive.tag is copied by the program from \files\winsetup\ folder to the root of the USB drive. If it's not in either or both places, then there is something broken somewhere, ideas in order of probability: 1) You used a program not fully compatible with 7-zip archives. One of them reported is IZArc, it seems to not extract from 7-zip archives 0 bytes files, as usbdrive.tag is. Use 7-zip to handle 7zip archives. 2) You have not extracted all files and folders from the downloaded archive 3) An application or user interfered when preparing the USB stick or afterwards 4) Etc. etc. For troubleshooting reasons, 3 seconds give enough time an user to see the important last messages which developer made to display important information, make a note of them or take a picture and report in case of troubles. If the 2 x 3 seconds added to the total installation time of approximately 12-60 minutes bother you and are of some degree of importance, you could delete the relevant lines with "pause" in them, or simply hit any key to continue without the wait time.

Default Windows behavior is to format unformatted or oalready formatted as superfloppy removable disks (read USB stick) as superflopy- no MBR and partition table. It's quite normal, all kind of tools which operate with and expect MBR and partition table to complain about the lack of such. In other words, how is MBR and partition table to be backed up, replaced and so on if there is no such?! Use an appropriate tool to format new USB sticks if you are going to look for USB boot with them- RMPrepUSB, BootIce, DiskPart (with the appropriate commands) in Vista and above and so on. In WinSetupFromUSB 1.0 beta8 I've added an option for auto-format, mostly for this reason, did you give it a try ?

Yep, correct, copy instead of move, just as the tutorial posted instructs. I might have been more precise if was typing the exact steps and commands to be performed. As for the truism- correct, kinda happens when thinking out loud. As for the safe part: Anyway, I think the OP should now clearly get the idea what is to be done, thanks for the corrections.

NO , the currently active one is the second. ... Jaclaz, you must have missed some bits and pieces from what I posted At that point, if he followed the tutorial posted, the active one should be the third one. http://www.terabyteunlimited.com/kb/article.php?id=409 And, as mentioned, it's to be deleted only when it's confirmed that Win7 boots alright with its partition(third) set as active and boot files copied on it, to stay on the safe side.

What I would do: 1) Move Win7 boot files out of the small partition and put them in hd0,2, that's the third partition and set it active. Do not delete the small partition yet, just in case, if you need you could simply mark it back as active from GParted or DiskPart launched from Win7 setup and get back Win7 boot. http://www.terabyteunlimited.com/kb/article.php?id=409 2) Once you got Win7 working and booted from the third partition which should be already the active one, delete the small one if you haven't yet. 3) Use latest WinSetupFromUSB 1.0 beta8 if you used another version and install XP. You will lose Win7 boot, that's ok. XP boot files should go to now second partition, the small one is deleted prior to XP Setup so it doesn't mess up boot.ini. 4) Once you get XP working, fix Win7 boot: From command prompt during Win7 Setup: bootrec /fixmbr bootrec /fixboot The same can be achieved using BootIce, MBRWiz or similar tool from within XP. Just need to change PBR to NT6 (bootmgr) one on the active partition. 5) When you get back Win7 boot, add and entry for XP (ntldr) in BCD using bcdedit or even easier, with EasyBCD, or BootIce. @Jaclaz Since 1.0 versions WinSetupFromUSB no longer uses the ~BT and ~LS folders and method, it's WINSETUP folder containing all source files.

Can you post the log file produced in program directory?

SteveOC, the grub4dos menu entry starts MBR on the first internal disk, just as BIOS would do, you don't have to dig in it at all. What that MBR does, which active partition it starts if it's a regular NT5/6 type, what is on the active partition is far beyond what WinSetupFromUSB or grub4dos perform. Now back to basics- in NT4/5/6 systems, MBR passes control to the active partition, then: NT/2000/XP/2003 - NTLDR reads its configuration file BOOT.INI and starts Windows or whatever from where BOOT.INI says. Vista and above- BOOTMGR loads its configuration file BCD (boot configuration data) and loads what it says. BCD doesn't have anything to do with MBR. You have messed up BCD entries which you need to fix. The second entry/part from WinSetupFromUSB should do the same as if there is no USB disk or boot is from the internal disk. As it seems it does. If Windows 7 starts, and XP is already installed properly, all you have to do is to use EasyBCD for example and add an entry for XP(ntldr). Or if XP is not yet installed properly, then install it, and once installed, use again EasyBCD or Win7 CD/Setup to recover Win7 startup, then add an entry for XP.

Hmm thanks for the details. I think I had modified the txtsetup.sif in the I386 folder so that might well be the cause of the problem ;-) Txtsetup.sif in I386 is not read and used at all during setup, only the one in the small ISO file is. My idea was simplicity, as much as possible, wider compatibility with all Windows versions, as little as possible modifications to the source, at the same time giving advanced users possibilities to play around at will. At the same time, integration of Firadisk or WinVBlock in Vista and above is not such an easy task, there are issues on some machines with 2003 and XP 64 bits and so on which yet have to be polished. Actually those are the reasons I haven't gone in this direction- Setup from ISO or IMG files, despite all the advantages.

How far did Setup go? When do you see this error? What is the exact error message? Are you installing XP on the internal disk/SSD? Is it confirmed working? I'd also suggest you to use the latest beta version, currently 1.0 beta8, download link is in the first post.

Try integrating WinVBlock using these lines: http://reboot.pro/8168/page__st__375#entry127781 Modify txtsetup.sif in source prior to using WinSetupFromUSB, or edit the one in the small ISO file and make sure you copy the .sys file in I386. I stand corrected Perfect

The machine being Acer reminds me of another issue:http://reboot.pro/10503/#entry117680 Can you try something? Let's check if BIOS behaves differently according to the MBR code. Reformat the USB disk with RMPrepUSB, use NTFS and XP/BartPE for bootloader option, and maybe the "boot as HDD" option. In WinSetupFromUSB in advanced options, mark "Don't check for and install grub4dos MBR". Prepare the disk as usual. When finished, make a copy of the file GRLDR in root and name it NTLDR. Then try again on the work machine.

The idea is to put all internal disks in the same order as if there was no USB device connected to interfere with ARC paths and creation of boot.ini. In case of 2 internal disks, first goes first, and second goes second. In this case if ones wants to install XP to the second internal disk, boot files will go on first disk, pointing to the second disk with proper ARC path, disk(1) in this case. So it is not only the first disk important, all internal disks should be mapped properly. I have never tried this scenario, have to learn from your experience.What bothers me is that in txtsetup.sif in the small ISO file there are references where boot and source files reside, this is with ARC paths. If those are on a virtual disk mounted by a driver, does the mounted disk have a working ARC path to it? If Setup starts and goes past the file copy stage then all should be fine. For the GUI mode the virtual disk should be mapped prior to launching it ensuring WinVBlock mounts it and makes it available for the Setup, so boot from internal disk is not possible, it should be the USB one again. You may need to modify setup.cmd and amend the tag file, so script sets the virtual disk as a source. As for the 0x7E error- when exactly it occurs? Is it after file copy stage in Text mode? Is it after "Windows is loading/starting" message, when EULA or partition screen is displayed? Have you tried with other WinVBlock version? How is WinVBlock integrated currently? Can you integrate it manually, following Sha0's instructions on reboot.pro?

You may try map /WinSetup.img (hd) map --hookIf you have 2 disks- hd0 and hd1, (hd) will be hd2: http://reboot.pro/12449/#entry109030 It's about properly generating boot.ini by Setup at the end of Text mode. The idea is to shift disk order making the internal disks first, and USB and virtual ones in your case last, just as if Setup was started from CD and in BIOS boot order internal disks are next. Real world example- start Setup from USB disk, it is first in BIOS boot order, that's hd0 in grub4dos, or disk(0) as ARC path. Internal disk, the destination one is hd1, disk(1). Boot.ini will be generated with a path to Windows directory on disk(1). When you remove the USB disk, the internal one becomes disk(0), but boot.ini still points to disk(1). NTLDR can't find Windows directory on disk(1)partition(X) and in case of XP throws HAL.DLL is missing or corrupt or same error for NTOSKRNL.EXE in case of 2003.

Can you give some more details about the machine at work? If laptop- brand, model, if desktop- motherboard model? Do you have an option in BIOS how USB mass storage devices are emulated- USB-FDD, USB-ZIP, USB-HDD etc. ? What is the USB disk, brand, model? Is it a pen drive or USB/eSata hard disk in enclosure? What's its disk space? It's rather how BIOS recognizes the USB disk/flash drive, probably in different way depending how its formatted, hence the different results. Contents of USB disk should be the same no matter what you have used, above Vista it's simply copying the whole source as it is, the only difference are the steps before bootmgr is launched, i.e. what MBR is, how bootmgr is launched- chainloaded by grub4dos, invoked by the bootsector etc. WinSetupFromUSB only adds a few extra debug boot options for Vista/7/8 Setup for some rare machines where Setup may fail at very early stage, or for cases when Setup is confused where to place boot files and USB and internal disks must be swapped.

It would be quite tricky to break functionality in parts. Plus preparing source is not only about migrate.inf, there is a small ISO file with customized txtsetup.sif in it, modified for each setup setup.cmd, a custom setup.exe which launches setup.cmd and so on. How do I break all this in steps? File copying was made as fast as possible in beta8, also ensuring the GUI does not freeze when copying large files such as install.wim, which is AutoIt limitation when using default file copy commands. I've tested excessively all file copy methods available in AutoIt and the one used in beta8 seems to be the fastest one available.

Hi, 1) About the "map --unmap=0:0xff && map --unhook && map --rehook" - they are put to make sure all grub4dos map slots are empty and available, 8 in total, as in case of more internal disks all will might be needed. Some copuld be occupied by previous user attempt, unsuccessful boot etc. etc. Should be relatively safe to delete those lines. 2) Ditto, just delete the lines in question. By the way- how do you make the virtual disk visible for Windows Setup? Do you integrate a custom driver- firadisk, winvblock..., how? In case of a virtual disk I am not quite sure that migrate.inf would work reliably, it may depends how the virtual disk is mounted during Setup. And just to remind- it is not used in Vista and above setups. Here is how migrate.inf is generated, the important part is ParrentID prefix: By the way this is a DriverPacks problem and should have been fixed long ago.... perhaps in the near future ? Thanks for the report in DP forum, hopefully will be fixed soon.

It's not only registry changes, and it's not enumerating internal disk drive letters, but USB ones, which may not be present at all and script takes care in those cases too. What is does: 1) Searches for USB source disk drive letter 2) If not found, mounts \device\harddiskX\partitionY one by one until the needed USB disk is found 3) When disk/partition is found these values are put in $winnt$.inf from where Setup in GUI mode reads where the source is 4) Makes the relevant registry changes if Windows is to be prepared for USB boot or USB disks are still missing as happens on some rare machines If it was possible I'd gladly get rid of that part, but for now, it's still needed.