In my newly build computersystem with ASUS M2A-VM HDMI motherboard,
the BIOS provides two ways to change the boot sequence.

By pressing F8 it provides a BIOS boot menu,
from which one can select a temporary desired boot device.
The USB-stick is seen as second Harddisk and can be selected as boot device.
This is usefull for booting from USB-stick Puppy Linux, BartPE or MS-DOS,
but it is not usefull for Windows XP Setup from USB-stick !

For Windows XP Setup from bootable USB-stick it is necessary to enter BIOS Setup by pressing [Del]
and change Boot settings more permanent so that Harddisk is used as first Boot device type
and USB-stick is seen as first Harddisk. In this case everything works very well.
In Windows Setup from USB-stick it is essential that also after Restart for the GUI-mode of Setup,
booting occurs again from USB-stick and that USB-stick remains to be seen as first harddisk = rdisk(0).
After Setup has completed, binifix4.cmd will make the necessary correction in boot.ini on computer harddisk
by changing rdisk(1) in rdisk(0).

More INFO:
http://www.911cd.net/forums//index.php?sho...=19731&st=7

Regards,

wimb

Hi all,

I succeeded to install XP using wimb's usb_prep2 package.

1- Due to lack of real hardware, I used qemu with two disk images, one image simulating the USB key, the other is is the hard disk to install XP to.
So I have to comment out one line (vdk remove) in the usb_prep2.cmd otherwise it would close my USB key (vdk) drive during USB stick preparation!

2- In my system (and also under QEMU), disk with fat32 formatted with XP cannot be booted (disk error, press any key to restart), so I have to use
grub4dos grldr loading directly the boot loader. Adapting grub4dos menu.lst to get equivalent to boot.ini entries is not a problem, this has already been
used at the first topics of this thread.

3- During text mode setup, the hard disk to install XP to is seen as D: (which is normal, since under QEMU the USB key is set as first hard disk).
Upon reboot after first text mode setup, I do not have to select GUI setup, curiously (fast timeout?) it chains automatically to GUI setup.

4- Then at later reboots, if I keep the USB key as first hard disk, no problem. I see that on D: (second hard disk) there is no boot.ini/ntldr/ntdetect.com
on the root, so I copy them from USB stick, with modification to boot.ini for correct rdisk(0). Afterwards I change QEMU config so there is only one disk:
the XP installed HDD (so it is equivalent to remove the USB stick). The systems boots OK.


If I understand things correctly, normally after text mode setup, we should remove the stick, then the GUI set would take place on the HDD where XP
will be installed? Is it correct? In my simulation, there is no real USB stick so that probably the ntldr/boot.ini/ntdetect.com are not copied to the root of the disk.
Which could be a problem.

Your statement is wrong. In the normal situation for install of Widows XP from real bootable USB-stick, the stick remains all the time connected and can only be removed after first logon of Windows XP, when setup has completely finished.

I have no experience with the use of QEMU, but it seems to me that the use of real hardware is preferred and will make things less complicated.

Hi,

Thanks for the feedback

Have you checked menu.lst timeout? In some of the earlier posts default entry is changed dynamically using "savedefault XX" command, 1-st boot TXT, next boot will be auto dafaulted to GUI.



Using QEMU doesn't simulate real scenario with USB boot.
Windows TXT Setup writes boot files (boot.ini, ntldr, ntdetect.com) to the first hard disk, first active partition, that was your SOURCE disk, not the destination one.
With USB sticks, seen as removable (not fixed as USB hard disks) despite the fact USB stick was first on boot, it's seen as SECOND when TXT Setup detects hard disks to install on. Boot files are saved to 1st disk (IDE or whatever).
If destination hard disk is SATA and IDE device is present, IDE must be disconnected or controller disabled for the proper order, this has been discussed several times already.
Boot.ini on destination hard disk is wrong, rdisk(1) instead of (0). Binifix.cmd corrects that, rdisk(z) gets rdisk(z-1). Thanks to jaclaz for his scripts, guidance, and willingness to help

Setup could be installed from 3 media types, Setup detects that and adjusts accordingly - CD/DVD, hard disk, RIS. For CD source folder must be I386, for hard disk $win.nt$.~ls and .~bt. Leave RIS alone.
For hard disks folders $win.nt$.~ls and .~bt are considered as TEMPORARY, as such are being deleted on a few stages- some files when TXT part copies (moves) them, all are from ~LS folder, at GUI T-1 both folders are deleted completely.
What we do is to write-protect USB device during TXT mode via MIGRATE.INF (many thanks to cdobfor that ), and temporarily rename source folders during GUI mode, so Setup cannot find them and delete. On first logon they are renamed back, that's why USB stick MUST be leaved plugged until after first logon.

You used QEMU, source disk was NOT write-protected. I bet you couldn't do another install from the same disk unless using the original image again, some source files were deleted (from the ~LS folder only, but not all files). GUI trick saved the rest, but many files are deleted, the ones which are copied (moved) during TXT part.
Wimb has spent a lot of time to test, added other features and polished the initial usb_prep.cmd.
Now I am waiting someone to help with dummydisk.sys in order to use USB hard disks.

Thats briefly what is happening.

ilko

@ilko_t

Cannot remember if we talked about this :
http://www.911cd.net/forums//index.php?showtopic=19422

Can you (or someone else) test it with USB hard disks?

Or it has been already tested and it does not work?

jaclaz

Umm...that's what we use, what cdob suggested to write-protect USB during TXT mode.
It does work for USB hard drives, but those are seen as first hard disk during detection, Setup tries to put boot files there, it's write-protected and Setup aborts with "disk is corrupted".
Remove write protection, boot files go to USB disk, and source files are being deleted during TXT mode. Catch 22.
Get a new (waiting for that on few forums-no responses so far) from dummydisk.sys to force USB fixed disks to be seen as removable, source should not be listed as first disk, boot files go on destination hard drive, exactly how it works with USB sticks. Tests needed, and a way to load dummydisk.sys early.

ilko

Thank wimb, ilko_t, jaclaz and all.

It is true that using QEMU does not reflect real USB condition (removable, USB etc...).
And after verification it is true that some files have been deleted in $WIN_NT$.~LS and 3 other files
modified :
\$WIN_NT$.~BT\migrate.inf
\$WIN_NT$.~BT\winnt.sif
\$WIN_NT$.~BT\migrate_inf_org.txt

Question:
migrate.inf
before installation:
uniqueid="C:\WINDOWS\CON"
after installation:
uniqueid="C:\WINDOWS\MOI"

Is it normal this change ? Or only due to USB key simulated not protected under QEMU (since it is not a real USB key).

Also in migrate.inf I have a change in:
Language=00000409
to country specific code (choice of language).

Congratulations for all your effort to put a working solution for USB key. It remains as ilko_t said to complete for USB hard disk.
For your information, another interesting experimentation direction is to get XP install ISO on the USB key which appears as
a real CD (CDFS) like U3 USB key:

http://ubcd4win.com/forum/index.php?showtopic=9333

My preferred way (but not fulfilled now) that grub4dos can (as bcdw currently can) boot directly iso file
from the USB key. This will probably open lot of new possibilities. grub4dos (and syslinux) has already the capability
to boot diskette images, now they lack booting CD image (ISO). Maybe some developers are on the way? :-)

These 3 files are modified by usb_prep.cmd. Not sure where this one came from:
as I believe that should be in winnt.sif (typo?) and (the entry) is created/changed by winnt32.exe. If winnt.sif exist in your source folder it's used, if doesn't winnt32.exe creates a generic one.

Same applies for language=....

Thanks for the info about U3, I found it interesting

That would be sooo nice You are not the only one wanting it, I think Jaclaz keeps himself very well informed in that matter and would ring the bells if there is something new.

ilko

@ilko_t
Thanks for the clarification, I lost myself a few posts ago.

So, next step is to find a way to "reverse" the logic of the dummydisk.sys.

@lilas
Unfortunately the CDFS trick implies fiddling with the USB controller firmware (actually the U3 is an "already fiddled with" firmware) I have found at least one controller (and it's manufacturer utilities) that allow setting the USB Flash mamory as a CD, but this would only apply to that model, and to this you add, if they were not enough the peculiarities of the various BIOSes.


@All
The problem with grub4dos booting from .iso is a non-problem, I am afraid.

Though most probably this feature will eventually be added to grub4dos, we already have ISOEMU, but the limit it has (being able to boot DOS and Linux images, but NOT 2K/XP/2003 ones) will remain in grub4dos.

The problem, AFAIK, is not in grub4dos code, but rather in the way NTDETECT.COM works.

The solution will be when (and if) someone will find a way to use a disk image driver (like filedisk, VDK or Imdisk) instead of the RAMDISK driver, or when (and again if) someone will write a "monolithic" "miniport" USB driver, that can be used as NTBOOTDD.SYS.

Or maybe when the guys at tinykrnl.org or at reactOS.org will produce a new "compatible" set of loader files.

Here we are in a real CATCH-22 situation:
Anyone interested in this has not the knowledge/experience to write this code.
Anyone who is capable to write such a code is not interested in this.

jaclaz

@ilko_t
Yes, it was a typo. It is winnt.sif.

For the U3, it seems (I may be wrong) that some articles talk about converting/simulating plain USB key to U3, so
that it presents a CDFS interface on the first partition. And the mentioned article is only to hack this process to get bigger partition
to host bigger ISO like BartPE or XP install.

@jaclaz
I agree with the file disk driver instead of RAM disk driver.
By the way how does bcdw code work since it can boot iso files (it is already in CD so probably this must be easier).
In some posts I remembered you said bcdw author does not leave source code and remains unreachable. It is really a waste!

@wimb

I found 2 minor glitches in the procedure:

1. Some addons for Nlite place their files in \I386 and/or in subfolders in I386. This is not reported in dosnet.sif and/or txtsetup.sif, thus winnt32.exe doesn't copy those files/folders, which causes errors during setup. We need a final check when copying files to the virtual drive, like copy all from I386 to I386, including subfolders, do not overwrite if file/folder exist.
This way we won't need the option for XP/Tablet, folders will be copied anyway.
Actually dealing with winnt32.exe on anything but an original source is such a pain...

2. I had a custom $OEM$ folder with NLite cmdlines, and this was overwritten by the batch, put some prompt or check if such folder exist.

This could be helpful- put in boxes with the default values like drive letters etc. [currently: none], then [currently K:] or something like that, what do you think?
The other thing was marker file for BTS mass storage, did you change that already? Can the drive letter be typed without : ? Would be easier.

If you have the time could you look at these, if not I will try during the weekend.

Regards,
ilko

I have a conflict between UBCD4Win and Install XP from USB.
I have a multiboot USB key using grub4dos.

UBCD4win uses:
title Ultimate Rescue USB key for Windows
find --set-root /minint/setupldr.bin
chainloader /minint/setupldr.bin


The XP install uses:
title Phase 1 Install XP from USB key (text mode)
find --set-root /setupldr.bin
chainloader /setupldr.bin

Before XP install, I do not have in the root the file txtsetup.sif and UBCD4Win works well.
Now with this file, /minint/setupldr.bin invokes same thing as XP install, so I lose UBCD4Win.
How can I manage to have both functions ?

@ilko_t
I was not aware of the two problems when using NLite,
because I was using RyanVM Integrator for integrating Updates in XP.
But I think that the changes that you proposed for the usb_prep2.cmd file can solve the problems with NLite
and I will try to make an updated version.

I noticed also that for some cardreaders (ICIDU) the valdid drive check for USB-stick in undoren.cmd results in an ERROR Alert, which can be overuled by clicking Continue for each cardreader drive.
This might be overcome by limiting the range of valid driveletters for USB-stick e.g. that the valid range is M-Z,
so that the probable range where cardreaders might occur is excluded.

@lilas
Your problem in combining UBCD4Win and XP Install in a MuliBoot USB-stick corresponds to what occurs for BartPE.
I found in this case a nice solution by using a small Hexedit of peldr as described here:

http://www.911cd.net/forums//index.php?showtopic=20089


I think a corresponding solution will be possible for MultiBoot USB-stick with UBCD4Win
by a similar Hexedit of setupldr.bin in minint folder.

Regards,

wimb

@winmb

The hexedit of /minint/setupldr.bin as mentioned works perfectly. Thank you!

As I see it, 99.99% of users of this method will normally use on their PC's, at one time or another, a PE of some kind, and of those 99.99% will use a SP2 build, so we can make the drive letter X: as fixed, and that will cover in 99% of cases, then provide an easy way for the remaining 1% to change letter manually.

jaclaz

I have today the opportunity to test the XP install procedure on real hardware. The USB key is prepared with usb_prep2.cmd.
Internal drive IDE empty, but already NTFS formatted.

Got 3 missing files that I solved incrementally by copying from source ISO (i386 directory). My ISO is French one, with SP2 integrated.

1)
\$WIN_NT$.~BT\vgaoem.fon could not be loaded. The error code is 14.
2)
\$WIN_NT$.~BT\c_437.nls could not be loaded. The error code is 14.
Setup cannot continue. Press any key to exit.
3)
cannot load kbdus.dll (missing).

So looks like although it is French installation, the 3 above files are still needed.

After putting those 3 files (vgaoem.fo_, c_437.nl_, kbdus.dll), so far so good, I got to the screen to select the hard drive (C:),
but then I hit a big problem:
4)
In file .sif used by setup corrupted or missing:
Value 0 at line of section [SourceDisksFiles] with the key "SP2.cab".

Setup cannot continue. Press F3 to quit.

I do have a file \$WIN_NT$.~LS\I386\sp2.cab

I do compare txtsetup.sif between root of USB key and in \$WIN_NT$.~BT\ and they differ only by new 3 lines present
only in \textsetup.sif (root):
[SourceDisksFiles]

binifix4.cmd = 100,,,,,,_x,2,0,0
undoren.cmd = 100,,,,,,_x,2,0,0
ren_fold.cmd = 100,,,,,,_x,2,0,0

Do you have any idea to solve this? Thank you.

Edit: it looks like that the error was due to missing some files win51, win51ip, win51ip.sp2. They were deleted by previous install (?).
With those files, the file copy by setup is OK.

OK I just do an install XP from scratch, all it worked ! Except two points:
1)
the boot.ini on the installed (C:) disk still invokes rdisk(1) which is bad once I unplug the USB key.
I believe somewhere there is an automatic procedure to do this rdisk(z-1) ?

2) After successful install, the directories
$WIN_NT$.~BT
$WIN_NT$.~LS
are changed (renamed) on the key to
WIN_NT.BT
WIN_NT.LS

(no $ nor tilde). So the key cannot not be reused as is for another install, unless to rename the 2 above directories.
Apparently there is a problem somewhere ?

Did you leave stick plugged in until after the first logon?
At first logon binifix.cmd and undoren.cmd should fix BOOT.INI to Z-1 and rename the 2 folders back, there is also txtsetup.sif renamed.

@ilko_t
Maybe I missed something, but on USB key boot (boot.ini), I got either text mode or GUI mode setup.
First I select text mode, then install in text mode.
On first reboot, I select GUI setup and install in GUI mode;
On second reboot, if I do not unplug the key, I will have only the same two choices: text and GUI setup.
Or GUI setup is already done. So which choice I had to ? This is why I have to unplug the key then found
a mean to edit the c:\boot.ini on the HDD to manually fix the z-1 order.

Sorry but probably I missed some step apparently.

Another question: in
\$WIN_NT$.~LS\$OEM$\CMDLINES.TXT
I add another call to another .cmd file:
"useraccounts.cmd"
"install.cmd"

Each cmd above has its own exit as last line. Is this correct? Or only the last .cmd has to have "exit" line?

@lilas


After GUI Setup leave stick plugged, on next reboot windows will be launched. The default entry in BOOT.INI on USB stick applies for both GUI Setup and normal launch.
So your first normal launch (after GUI mode) should be made from the stick again, then on the first logon files will be fixed- boot.ini to Z-1 and the 2 folders + txtsetup.sif renamed back to their original names.
Once you complete your first login you may remove stick.

You raise makes sense- the entry "GUI Setup" in boot.ini is a bit misleading. May be rename it to "GUI Setup and First logon" or something like this.


About cmdlines- without being an expert at all in cmd I think EXIT should not affect the other CMD files listed, I may be wrong, somebody with better experience should comment on that.

I am glad it worked for you, seems just a few minor fixes should be made.

Regards,
ilko

@ilko_t

OK thank you for your explanations. So maybe for real newbie and clearer presentation, boot.ini could be like this:



The user will understand that there are 3 steps, each step is done after a reboot, step 3 is final step.
I don't know whether value could be hard-coded as is, but if yes, then maybe no more need for dynamic substition with z-1.

I redo a full install again and all works well. The missing 3 files I mentioned in previous post were most probably due only to a wrong USB key
(I have two USB keys to experiment with). So you can ignore this problem.

For the "exit" in cmd file, I was afraid that it could cause the following cmd file not to be executed. Maybe somebody could confirm/infirm this.
In the meanwhile, to be sure, I merge the content of useraccounts.cmd with my install.cmd, leaving only one "exit" at the end of file.

Thank you for all of you for creating a beautiful working procedure on this passionating subject of XP install from USB key.
See all of you soon,

hi lilas,

The boot.ini entry for GUI and normal start is no different, hard drive is still seen as rdisk(1), USB stick is still rdisk(0). If GUI setup is not performed yet it will be, if it's completed a normal start will occur when using the second entry. So the boot.ini should look like this:



We should also put a clear message somewhere not to unplug stick until the first logon has completed.

Regards,
ilko

@ilko_t
OK I understand and agree with you. My separate Step 3 entry in boot.ini of the key is useless since the key as you said will still be rdisk(0).

Note that the logon is important to rename and change the ini entry to z-1. Since in my installation after GUI setup I do not see any logon, I
access directly to the desktop (maybe with a default user ?). So after checking that boot.ini and folders are not changed/renames, I do a manual
close session and then logon as administrator. And then I did verify that c:\boot.ini is well changed (z-1), and the two folders on the USB key
are renamed back correctly.

Question: is it really z-1 or hard coded to zero (since z=1?). What happens if I install to another partition then the first partition? also maybe on another disk
than the first disk, e.g. HDD2 (USB key, HDD1, HDD2) ? Could you confirm that these cases are covered ?

Also is there a project to install Vista from USB key, or is it already covered? As far as I understand, it seems that for Vista it is easier,
since normally you prepare/format the key under Vista (diskpart/bootsect), copy all the files from Vista CD to the key, that's all. Is it true?

@lilas
The ideas of the z-1 came EXACTLY because some people might want to install XP on a non-first disk:
http://www.msfn.org/board/boot_install_USB...html&st=204
http://www.msfn.org/board/boot_install_USB...html&st=240

Latest version:
http://www.msfn.org/board/boot_install_USB...html&st=280
with this amendment:
http://www.msfn.org/board/boot_install_USB...html&st=286

Just open the .cmd in notepad, it should not be too difficult to follow it's way of working.

You might think of the way XP sets arcpaths as a FIFO stack, if you boot off a drive, it will get a z of 0, effectively "pushing" all other arcpaths for (n) drives to z(n)+1, what the batch does is simply to reverse this behaviour for the newly installed system.

Partition numbers w, being "relative" to hard disk number, are unaffected by this inserting the USB stick before normal boot drive.


VERY GOOD WORK
in reporting, we need more feedback as accurate as yours.

jaclaz

NEW RELEASE is Available as usb_prep3.zip file in Attachment.

All necessary changes regarding NLite, boot.ini and Cardreader have been taken into account.

The new release was tested twice with success on different computers.

GOOD LUCK !

Regards,

wimb

@jaclaz
The USB-stick was given already a fixed DriveLetter, but it was during XP Setup that the Drive Check in undoren.cmd was causing problems with Cardreaders, which have been overcome by limiting the range for the Drive Check such that the probable range where Cardreaders might occur is excluded.

Regards,

wimb

@wimb
I tried the usb_prep3.cmd.

Changes observed as looking at source:

\usb_prep3\$OEM$\useraccounts.cmd
no more autologon

\usb_prep3\boot.ini
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="2. GUI Mode Setup Windows XP, Continue Setup + Start XP" /FASTDETECT

\usb_prep3\usb_prep3.cmd + some other changes for nLite
set xp_type=Home / Prof - RyanVM

\usb_prep3\undoren.cmd
\usb_prep3\ren_fold.cmd
take into account drive letter E F G H I J K L

Recommendation:
\usb_prep3\makeBS3.cmd: maybe to upgrade from
::<Release 0.03 ALPHA 05/August/2007
to jaclaz's latest version:
::<Release 0.07 ALPHA 01/October/2007


Now the script usb_prep3.cmd got some problems at execution.



1) Access denied
N: tempdrive
U: USB key
The acess denied is during copy from n:\ntldr to u:\ntldr which already exists in my key (I upgrade
the key by re-executing the script, so no new reformat on the key done). And u:\ntldr has read-only, hidden,
system attributes on it, hence problem.

2) A needed file is missing
ECHO Add entry in BOOT.INI to launch TXT Mode Setup ....
CALL makeBS3.cmd %usbdrive%\setupldr.bin /a "1. TXT Mode Setup Windows XP (Never unplug USB-stick) "

3)
File U:\setupldr.bin is missing

Error 2) and 3) are mysterious, but after some investigation I found out that my USB key does have a drive letter
but do not have a physical drive number (\\.\physicaldriveN in dsfo/dsfi notation). For example ptedit32 did not see the
disk (nor HDHacker of course, nor dsfo/dsfi/mbrfix). So probably MakeBS3.cmd failed due to this.
This situation arrives sometimes on my machine, apparently due to a lot usage of vdk/ImDisk, mount external USB HDD plug/unplug, QEMU, VMware etc...
I have to reboot to get a clean situation where plugging the key does create a new corresponding physical drive letter.



Other remarks:
1)
We probably need a kind of execution log (maybe simply by just capturing all usb_prep3.cmd output (stdout/stderr) with
"tee" (tee.exe under Win32), e.g. usb_prep3.cmd | tee usb_prep.log), so that by browsing the log problems can be spotted
easily (and for audit/history also). Without the log, some script (like MakeBS3.cmd uses cls command so the output is cleared
in the window command prompt, so even if I have a big screen buffer, I cannot use copy-paste to report/indicate needed messages output).

2) (optional) Maybe the script must check for errors (errolevel), mostly in copy/xcopy commands and stop execution on errors.
My mentioned errors above are fatal for me. With the log in point 1), this is less important. But I agree that user of this script
is a normally a technical person so he/she should be aware of those errors, and the script not being a GUI application cannot handle
all error situations.

3) Probably we need to ensure that all important files copied/modified (mostly in root: boot.ini, ntdetect.com, ntldr, setupldr.bin) could already exists with read-only,
hidden, system and hence to handle them correctly (reset all the attributes first).

4) Maybe offer the option to delete the temporary image tempimage.img (after the dialog to accept unmount the temporary drive).

Summary:
- I will re-experiment after reboot to get physical drive number associated with USB key
- I will temporarily reset ntldr read-only, hidden, system attribute on my key.
- I will re-experiment the script and report here.

OK, after resetting ntldr attribute on my USB key, and after unmount all drives (vdk, ImDisk...) and unplug all drives, and replug USB key,
I got associated physical drive letter.
Then the script executes smoothly without errors and my key is prepared.
So it remains to test in on real hardware, but normally success will be there. Report later.

Edit: I tried this time with hi-speed 8GB key formatted FAT32, but curiously this time the file copy by setup is very slow, much slower
than with 4GB key formatted FAT16 ! So I interrupt the process and rebuild the 8GB formatted with FAT16. Report later.

@lilas
First Format USB-stick is essential for the procedure to succeed !
It seems that all your problems came from not first Formatting the stick.

A log file as you suggests is a good idea for improving the program.
Changing MakeBS.cmd to version 0.07 is OK, but version 0.03 does not give a problem.

Some quick report:
- 8GB key cannot be formatted FAT16.

- Even after reformat with FAT32, 8GB hi-speed key is very slow during setup file copy (5 min to have only 10% copy complete).

- Using low-speed FAT16 4GB key freshly formatted, setup file copy is lightening fast (20 s to get 10% complete, total duration (100% complete) = 5 min) !
No problem in the 3 steps (text mode, GUI mode, logon/start XP). And on third reboot, I did see now the icon user, so a force logon must be done (excellent),
which will update boot.ini on the installed HDD and update the USB key (directory rename etc...).

- \$WIN_NT$.~LS\$OEM$\useraccounts.cmd is modified to add some personalized commands (install extra programs), instead of chaining several .cmd
in cmdfiles.txt. Curiously if I put my commands BEFORE the original lines (user account creation) it works better. Putting them AFTER causing some problems
like gdiplus missing etc... It appears that it is related to user account creation.

- By the way I chain the test with Vista installation from USB key: no problem so far.
The key has to be bootable, with Vista bootmanager (bootsect /nt60 or using diskpart or using grub4dos to invoke bootmgr).
The USB key content is a copy of the Vista DVD (almost 4GB).

Again, congratulations to all the team, I am satified with current function.

@jaclaz
ktp is my other nick on other forum :-).

Some statistics:

XP installation duration: 45 min on my system

On my same system, Vista Installation steps:
Copying Windows files 2 min
Expanding files 16 min
Installing features 0 min
Installing updates 1 min
Completing installation 0 min

Total: 19 min (+15 min on first startup (completing installation)). Apparently the gain over XP is by using the WIM format (install.wim about 2.5 GB), so
less files copied, and file expansion is faster.

Some "semi-random" ideas and suggestions:
@Wimb
if you check my binifix.cmd there is a small routine that checks the ATTRIB status of a file, sets it to writable, visible, non-system in order to allow modifying or overwriting, then resets attributes as before.
You can use it to overcome the reported ACCESS DENIED problem.

@lilas (aka ktp )
An interesting test would be if you could partition (temporarily) the 8Gb key to a smaller size in order to format the partition as FAT16 and see if the speed difference is due to the filesystem rather than to the controller.
See this (now getting old) comparison between different USB Flash drives (read different stick controllers) and their access and transfer speed:
http://www.hardwaresecrets.com/article/321

jaclaz

Using Apacer HT203 1 GB USB-stick and computer with ASUS M2A-VM HDMI motherboard I observed:

Windows XP Setup Ready in 30 minutes, composed of:

2 min - TXT Mode Setup, Loading Boot Drivers + User Interaction
12 min - TXT Mode Setup, Copy of Windows XP files
16 min - GUI Mode Setup Windows XP

wimb

@jaclaz
Thanks for your Info.
At the moment usb_prep3.cmd is not meant to be used for updating an USB-stick,
but may be your routine will be helpfull in future for changing ATTRIB status of e.g. existing ntldr file.

wimb

Found in jaclaz"s binifix.cmd:




Excellent error catching! On real hardware rdisk(-1) would have bad consequences! :-)

Is this problem still persisting?
Do you need to logon as administrator in order to execute binifix.cmd and undoren.cmd? What rights first logged user had?
If yes then we will need to use RunOnceEx.
http://unattended.msfn.org/unattended.xp/view/web/31/








good ideas



I am having similar troubles when ImDsk has mounted drive for too long, unmounting and creating a new one it fixes troubles.
Another thing- boot files position on stick is critical in most cases, a fresh format should be performed prior to using usb_prep.cmd. The script copies those files first.




I believe it's the stick which is slow, many of the copied files are too small and in that case slow sticks perform really bad.
Very nice program to test your sticks speed, AFAIK backing up data is not required, but you never know...
http://www.hugesystems.com/supportspace/bench32.exe

Test on many different USB sticks, thread is in bulgarian, but pictures give very clear idea:
http://www.hardwarebg.com/forum/showthread.php?t=92033



At also should work if you use XP/2k bootsector (PEtoUSB, HP format tool...) and just rename BOOTMGR to NTLDR. Jaclaz's makeBS.cmd is also very handy if want to use multiboot with ntldr/boot.ini.


Jaclaz answered already this, just wanted to add a few things:
1. Mixed SATA/IDE devices may break order and how USB disk is seen by TXT Setup- disable or unplug the unnecessary device. Details here:
http://www.msfn.org/board/boot_install_USB...345#entry655345
2. If planning to install in disk/partition other than 0-1 then boot.ini on stick should be amended accordingly.

BTW in my old tests- 341MB source with BTS mass storage and LAN completed in 16 mins. first boot- first working desktop, Barton 2400М @ 2000, 1GB RAM and 400GB SATA disk, motherboard did not support USB2 boot, otherwise a few minutes could have been saved. USB stick- Buffalo FireStix 2GB type R RUF2-R2G-S, it's really fast stick.


To do:
1. Use NTFS compressed temp drive, this should save space, 1GB sometimes could be too much and not possible.
2. Ask to detele tempimage.img when script has completed
3. If needed use RunOnceEx instead of GuiRunOnce to execute binifix.cmd and undoren.cmd. Possibly merge these 2 scripts.
4. USB hard drives- reverse dummydisk.sys logic
5. May be add Vista support too? Shouldn't take much effort.

Regards,
ilko

The problem is solved now, since with usb_prep3.cmd no more automatic logon. You have to manually logon. I used administrator, but maybe UserXP should be OK too.


Yes, maybe mksparse to use at least (quicker).


Possible, but the stick must be > 4GB due to the size of Vista DVD (almost 4 GB) and XP CD (could be bigger than 750 MB due to custom addons, service packs, slipstream etc..)

A tool to test your USB key (speed...):
http://www.flashmemorytoolkit.com/

Personally ImDisk does not cause any problem, it does not create new physical hard drive (no partition).
The problem was with vdk. Even if you close the drive (vdk close 0 e.g.) the associated physical drive remains listed and is seen
by other utilities (vmware, drive snapshot) but they cannot access them (drive not ready). The only clean way is to uninstall vdk
(vdk remove). By this way, all the physical drive descriptors are removed.

16 min - That is very FAST INDEED for Windows XP Install from USB-stick,
most probably due to the very fast Buffalo FireStix USB-stick.

@lilas
Interesting that Install of Vista from USB-stick can be supported in a rather simple way.

@lilas and @ilko_t
Thanks for all the interesting references concerning speed measurements on USB-sticks.

wimb

The idea of a log file is excellent.

Cannot say if it would cause slowness, in the procedure, but before a separate tee.exe, I would try to use the .bat/.cmd version, available on Rob van der Woude's site:
http://www.robvanderwoude.com/tee.html
integrating it in the main batch.

jaclaz

I did some experiments with tee.exe from http://www.robvanderwoude.com/tee.html
using:


The problem with tee from robvanderwoude is that good user interaction fails,
because Answers have to be given before the actual Question appears on screen.
The examples with PERL TEE.PL usbtee.log and REGINA TEE.REX usbtee.log did not work for me,
because PERL ( = renamed tee.exe ) was using TEE.PL as log file, instead of giving usbtee.log
The TEE.BAT Example gives the output on screen after the program has ended,
so that is not so usefull in this form.

Then I tried tee.exe in GnuWin32 Package CoreUtils from http://gnuwin32.sourceforge.net/packages.html
In this case all Questions appear on screen and the usbtee.log file is OK.
However for using the small program tee.exe ( = 24 KB ) there are
two additional large files required ( libintl3.dll = 100 KB and libiconv2.dll = 877 KB)

Maybe TEE.BAT can be integrated in usb_prep3.cmd
Some more experiments are required.

regards,

wimb

@Wimb

Yes, I know it would be a lot of work, but you don't actually need to log really everything, the tee.bat works only for "simple" commands, it needs to be integrated in the batch to work in this procedure.

Also, if you wish, feel free to integrate the "working part" of both binifix and MakeBS into the main batch.

jaclaz

NEW RELEASE is Available as usb_prep4.zip file in Attachment.

The Programm Flow is recorded in LogFile usb_prep.log , without file details
Giving the filecopy details in this logfile, results in losing them on screen, which is unwanted !!

For fedit -add the option -once was used to correct for
multiple entries in [SourceDisksFiles] section.
Thanks to jaclaz for finding this non-fatal error and some other improvements

When all output on screen with all file details is desired in a logfile, the solution is:
Download GnuWin32 Package CoreUtils from http://gnuwin32.sourceforge.net/packages.html
Place tee.exe = 24 KB, libintl3.dll = 100 KB and libiconv2.dll = 877 KB in usb_prep4 folder
Use the following command to start usb_prep4


In this case the Dialogue and all File Details appear on screen and in the usbtee.log

Regards,

wimb

I have successfully accomplished this install using the guide.
This is a crosspost from

http://www.msfn.org/board/Install_XP_USB_t...tml#entry701945

As I am not sure whether everyone will get to read this on page 20+.. heh

A few notes,


Stock XP VLK install works seamlessly.
I first attempted using the Grub bootloader, works fine.
Now I am using the extracted bootsector, renamed to skip using GRUB and boot directly from NTLDR into the TXTMODE SETUP.
This process was posted by ilko_t here
http://www.msfn.org/board/boot_install_USB...376#entry671376
Also works fine.

Here's the next problem.
Trying to install a custom XP build. RVM/NLITE/YADAYADA

Addon most of the current hotfixes and extras such as WMP11 and IE7.

Important note about Nlite and RVM customized XPs for USB.
Make sure to use
winnt32 /makelocalsource:all /unattend:winnt.sif /noreboot
The /unattend:winnt.sif makes sure that the nlite version of the winnt.sif is used.
Yes, you still have to edit it and remove the [Unattended] section.
I didn't at first and because it didn't give me the choice of which disk / partition to use,
it said my drive F: (usb disk) was corrupt and unfixable.



First problem - SOLVED
During TXTMODE it asks for the Windows XP SP2 Disc 2 -
This is fixed using /makelocalsource:all
The guide needs to reflect that.
While using this switch, there was a bunch of missing files (for Tablet PC and Media Center? versions.) I skipped those files.

Second problem - SOLVED - but needs some work.

Second problem, during textmode it asks for quite a few dlls and files that are MISSING from the /makelocalsource:all copy.
These files are present in my i386 (nlited and rvmi) source directory.
A few of them are , kbdhc.dll , kbdiultn.dll , kbdnepr.dll and more.
I solved this by copying all of the .dll files from my i386 (nlited and rvmi) source in to the $WIN_NT$.~LS directory on my USB stick. I did not overwrite files.

Then setup gets a bit further and starts to ask for some driver files. Specifically amdk6.sys and amdk7.sys

To fix this I extracted driver.cab and copied the entire thing into my $WIN_NT$.~LS directory as well. Once again I did not overwrite files.

At this point the installation is continuing.
Can someone tell me why these steps are necessary ? Did I do something wrong?
Also I have been following the whole process in all the various threads, I still don't understand what the binifix is for? Can someone explain?

The next step that I am unsure on how to progress is using the DriverPacks.

I just found the prepare_USB.zip which has something in there to assist, but I haven't had a chance to look at the command.

If someone has integrated the Driverpacks with the USB install could they chime in with their steps?

@effgee

All the issues you mentioned were taken care of in usb_prep.cmd and it's last versions, including BTS drivers packs, RVM, Nlite stuff, tablet/media files...

The guides are outdated, still could be used as a very basic start, but most improvements were done in USB_PREP.CMD, which you may want to have a look at to see all steps performed.

binifix.cmd is to set BOOT.INI on destination drive from rdisk(Z) to rdisk(Z-1), because Text mode setup sets it according to the current setup, USB drive is first (you booted from it), IDE hard disk gets second and so on. When you remove USB stick for regular usage, IDE disk becomes first ( rdisk(0) ), but in BOOT.INI you have rdisk(1), that's why binifix.cmd makes it Z-1.

Regards,
ilko

ilko_t

I am still having some problems with installing from usb.

During the txtmode setup process, it asks for some missing files.
kbdbhc.dll


and I'm sure it will also ask about missing driver files.



As in my previous post, these files are not copied when /makelocalsource or /makelocalsource:all is called.
But they do exist my i386 source directory.

My previous fix, to copy the *.dll from the source seems to work, but do you have any ideas what is going on?

I am using the usb_prep4 to setup the usb stick.

Did you select 0 for "MCE / Tablet - NLite", was "currently"... showing this?
Script is supposed to copy all files from source\I386 to $WIN_NT$.~LS\I386, thus eliminating all possible issues with missing files/folders. This happens ONLY when for source type "MCE / Tablet - NLite" is selected in order not to copy unneeded files with not customized sources.

Well, that would be it.
I'm trying it now with a Greek version of XP.

I'll let you know how it goes.

And thanks for yours and everyone else involved hard work!!