Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

Install XP from USB without extra tools


  • Please log in to reply
31 replies to this topic

#1
Legorol

Legorol

    Newbie

  • Member
  • 23 posts
  • Joined 20-June 11
  • OS:none specified
  • Country: Country Flag
This is a report of the culmination of my successful adventure. I have been researching the topic of installing XP from USB, and after learning a lot from this and other forums, I set myself a challenge. Based on all the available knowledge, is it possible to install XP from USB using no third party tools, except what's available to me in a standard Windows 7 installation? I realise that there are now lots of good tools available online for a variety of installation scenarios, but there is something satisfying about managing to do this "out of the box".

The scenario. Available to me were:
* Legitimate Windows XP with SP1 setup CD.
* Target computer: has 1 blank Harddisk and can boot from USB. Aim to install XP here. No CD drive.
* "Work" computer: standard Windows 7 installation, used for preparation.
* Blank 1 Gb USB stick.
The restriction was that I could only use whatever tools are included in Windows 7 on the Work machine. No third party applications. In addition, I aimed to make the fewest possible tweaks along the way.

The steps that worked successfully to install XP from USB, exactly as written, from the first to last step. Some additional remarks are at the end.

Steps 1 - 5 are performed on the Work computer.
Steps 6 - 10 are performed on the Target computer.

Step 1) Partition and format the USB stick in Windows 7, which makes it bootable:
Start Command Prompt, start diskpart.
Enter commands: select disk 2, clean, create partition primary, active
Exit diskpart, unplug and replug the stick.
Format the stick via Windows Explorer (I chose FAT32).
Note: the value in "select disk 2" depends on the number of harddisks and other USB storage devices you have! You have to check what value is appropriate for your system (use "list disk"). I have two Harddisks and disconnected all other USB storage devices, hence the value is 2 for me (numbered from 0).

Step 2) Copy contents of Windows XP with SP1 setup CD in whole to the USB stick.

Step 3) Copy these files from \I386 folder to \ on USB stick:
setupldr.bin -> bootmgr (rename), ntdetect.com, txtsetup.sif

Step 4) Edit \txtsetup.sif to add two lines in [SetupData] section:
BootPath = "\I386\"
SetupSourceDevice = "\Device\Harddisk0\Partition1"

Step 5) Use Notepad to create a file named boot.hdd at \ on USB stick with these two lines:
[Operating Systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP" /fastdetect

Step 6) Boot from the USB stick on the Target computer. This starts the text-mode portion of Setup.
Follow the instructions on-screen, creating/formatting a partition on the Harddisk as needed in the process. Make sure to install Windows XP in the first partition, in the WINDOWS directory.

Step 7) When Setup reboots, reboot from the USB stick again and enter Recovery Console. If you try to boot from the Harddisk at this point, you'll get a hal.dll error.

Step 8) Using the Recovery Console, rename c:\boot.ini to boot.bak. Copy \boot.hdd from USB stick to c:\boot.ini

Step 9) Reboot, this time from the Harddisk. This starts the first GUI portion of Setup. Proceed as normal, but you are asked for the location of various files several times along the way. Each time answer with D:\I386, where D is the drive letter of the USB stick at this point. Trial and error works here. Have to do this about 20 times total.

Step 10) When setup reboots again, reboot from the Harddisk. This is the last GUI portion of Setup. Proceed as normal.

Done! This process took me 61 minutes from start to finish, which included 30 minutes for copying the contents of the CD onto the USB stick. The process is non-destructive in the sense that it does not modify the contents of the USB stick in any way.

Remarks

* Using Windows 7, partitioning with diskpart and formatting via Windows Explorer is actually sufficient to create a bootable USB stick. The resulting stick will boot in most modern PCs, and a lot of older ones. When formatting, Windows 7 correctly enters drive number 80h in the BPB of the partition on a USB stick (unlike Windows XP, which enters 00h, leading to issues with bootability). However, creating a bootable USB stick is not always an easy or guaranteed process. It worked for me on my hardware, but your milage may vary.

* Conventionally, setupldr.bin is renamed to ntldr, but I had to use bootmgr instead, because naturally the VBR code placed by Win 7 loads that one.

* As is well-known, XP setup can be performed from a properly prepared local source on the USB stick, using $WIN_NT$.~BT/$WIN_NT$.~LS. What's less known is that setup can be booted and performed from *any* directory, using BootPath and SetupSourceDevice. These two settings are honoured if placed in txtsetup.sif in the current directory next to ntdetect.com. SetupSourceDevice overrides the need for a CD drive.

* The value of SetupSourceDevice can be any valid NT device path. When booting from a USB stick, the stick normally gets assigned as \Device\Harddisk0. The fun thing is that other paths also work, for example "\GLOBAL??\D:", where D is the drive letter assigned to your USB stick when booting from it. (Bit of trial and error needed here). The trick is that all Win32 device paths are actually a subset of all NT device paths, attached under \GLOBAL??. Note that paths other than NT device paths don't work (such as ARC paths, or direct Win32 paths such as "D:" or "\\.\Physicaldisk0".

* There is no need to prepare winnt.sif

* The deal with having to prepare a boot.ini file in advance and copy it over using Recovery Console is because of the ARC path problem arising from booting from USB, which leads to the (in)famous hal.dll error. Sadly Recovery Console doesn't allow file editing, so the correct boot.ini has to be prepared in advance. This issue is well-documented, so just in brief:
When booting from USB under XP (and its setup), the USB stick is assigned multi(0)disk(0)rdisk(0), and the internal harddisks are assigned multi(0)disk(0)rdisk(1) onwards. When booting from the harddisk, it is of course assigned multi(0)disk(0)rdisk(0). Since the setup was started by booting from USB, an incorrect boot.ini file is created on the harddisk (with a multi(0)disk(0)rdisk(1) entry). In order to correct this and allow booting from the harddisk, the boot.ini file on the harddisk needs fixing.

Edited by Legorol, 20 June 2011 - 08:12 PM.



How to remove advertisement from MSFN

#2
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,428 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
Just for the record:

* Conventionally, setupldr.bin is renamed to ntldr, but I had to use bootmgr instead, because naturally the VBR code placed by Win 7 loads that one.


IF you work with windows 7, you can use bootsect.exe /NT52 allright (and have the VBR invoke NTLDR)

* The deal with having to prepare a boot.ini file in advance and copy it over using Recovery Console is because of the ARC path problem arising from booting from USB, which leads to the (in)famous hal.dll error. Sadly Recovery Console doesn't allow file editing, so the correct boot.ini has to be prepared in advance. This issue is well-documented, so just in brief:
When booting from USB under XP (and its setup), the USB stick is assigned multi(0)disk(0)rdisk(0), and the internal harddisks are assigned multi(0)disk(0)rdisk(1) onwards. When booting from the harddisk, it is of course assigned multi(0)disk(0)rdisk(0). Since the setup was started by booting from USB, an incorrect boot.ini file is created on the harddisk (with a multi(0)disk(0)rdisk(1) entry). In order to correct this and allow booting from the harddisk, the boot.ini file on the harddisk needs fixing.


Since you boot anyway to Recovery Console, nothing prevents you to run BOOTCFG:
http://commandwindow...le-commands.htm

You may need a "fake" Windows installation :unsure:, something similar to my "no more CATCH22" trick, though.
Reference:
http://www.911cd.net...pic=20983&st=25

jaclaz

#3
Legorol

Legorol

    Newbie

  • Member
  • 23 posts
  • Joined 20-June 11
  • OS:none specified
  • Country: Country Flag

Just for the record:

IF you work with windows 7, you can use bootsect.exe /NT52 allright (and have the VBR invoke NTLDR)

That is true, but there are a few reasons why I didn't use it. An NT 6.x type bootsector seems to boot setupldr.bin just fine, when renamed correctly. It's also debatable whether my mission restriction (use standard Windows 7) allows the use of bootsect.exe or not, since bootsect.exe is only found on the Windows 7 DVD and isn't installed on the computer by default. What if you don't have the Windows 7 DVD with you? ;-) I also wanted to keep it as short and simple as possible (which is a contradiction, considering I'm trying to install from USB ;-) ), so if it's not necessary, I didn't include it.

There is another consideration as well though. The procedure as I described actually almost works using Windows XP instead of Windows 7. The only snag under XP is that it's not as straightforward to make your USB stick bootable. You would need a third party tool in that case, if only to change the drive letter to 80h in the BPB and optionally change the FAT type to LBA. However, running something like the HP USB Tool to format with instead of Windows Explorer is sufficient. Everything else works as is under XP too, so I didn't want to include the use of bootsect.exe.

Since you boot anyway to Recovery Console, nothing prevents you to run BOOTCFG:
http://commandwindow...le-commands.htm


I tried bootcfg, but there doesn't seem to be a way to actually edit the ARC path. When you add a Windows installation with bootcfg, it constructs an incorrect ARC path just like setup does. Please let me know if I missed an option to bootcfg or something, this would be a good improvement to my procedure :-)

You may need a "fake" Windows installation :unsure:, something similar to my "no more CATCH22" trick, though.
Reference:
http://www.911cd.net...pic=20983&st=25

jaclaz

This is very neat, I will remember this! Luckily this wasn't necessary for me, I was able to access both C:\ and the USB stick and copy a file over. I can see how this trick can be useful though.

#4
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,428 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
I do not remember the problems you describe with simply partitioning/formatting a USB hard disk (i.e. something that is seen as "fixed") with XP, but I may well be wrong. :blink:

I tried bootcfg, but there doesn't seem to be a way to actually edit the ARC path. When you add a Windows installation with bootcfg, it constructs an incorrect ARC path just like setup does. Please let me know if I missed an option to bootcfg or something, this would be a good improvement to my procedure :-)


You may need a "fake" Windows installation :unsure:, something similar to my "no more CATCH22" trick, though.
Reference:
http://www.911cd.net...pic=20983&st=25

This is very neat, I will remember this! Luckily this wasn't necessary for me, I was able to access both C:\ and the USB stick and copy a file over. I can see how this trick can be useful though.


Just a guess, mind you, but if you have a "fake" windows install on the booted USB device (see above), if you use BOOTCFG to add it (and NOT the real one) the ARCpath should be correct:
http://support.micro...kb/291980/en-us

Since you are into experimenting, another thing that you may want to check is whether the use of the debug.exe (that comes with XP) is possible to do some "sector manipulation".
A rough example is here:
http://www.911cd.net...?showtopic=7233
http://www.microsoft...g.mspx?mfr=true

If a batch file is not considered "third party tool" under your "Rules", it may solve the "formatting problem" and/or the "loader name", that is IF debug allows writing to sectors under XP and/or Windows 7. :unsure:

Another option (lame, I know) is to make a copy of SETUPLDR.BIN renamed to BOOTMGR and one renamed to NTLDR and when you run Recovery Console, issue a FIXBOOT command.
But even this "cosmetic" change won't change what I see as the "real" issue, that of Renaming a "basic system file", reasons here:
http://reboot.pro/2362/
http://reboot.pro/5209/page__st__6

jaclaz

#5
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,428 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
Verified. :(
Debug has no direct disk access under any of NT/2K/XP and latrer OS.

I start to think that there is nothing capable of accessing a disk sector in "default" MS OS install :unsure: so, it's a dead end.

jaclaz

#6
Legorol

Legorol

    Newbie

  • Member
  • 23 posts
  • Joined 20-June 11
  • OS:none specified
  • Country: Country Flag
It's a shame that debug doesn't work for sector writing.

The issue under XP is this. As I'm sure you know, a USB stick is seen as removable media by XP, even if it's partitioned like a Harddisk (with MBR etc.). XP can format the drive, which just reformats the existing partition without touching the MBR or partition table. When you do so, XP writes the drive number 00h in the BPB of the formatted partition. This often causes problems when trying to boot the stick, because when booting, the stick is (or should be) emulated as a Harddisk and is accessible by drive number 80h.

I finally understood what your idea was by using a fake installation. So I set one up on the USB stick in a WINDOWS directory, as you describe in http://www.911cd.net...ic=20983&st=25. I proceeded with text-mode setup first, and then booted to Recovery Console. Sure enough it offered me a choice of logging into C:\WINDOWS and D:\WINDOWS, where C was the Harddisk and D the USB stick. I tried both, and tried to use bootcfg. Unfortunately however, bootcfg only offered to add C:\WINDOWS to boot.ini, it didn't see the D:\WINDOWS directory. So this didn't help.

I take your point about not renaming system files, the caution is justified. I think just for the purpose of this project, I was OK. I was envisioning a scenario where you might be stuck with a restricted set of tools, for example because you are out visiting a client site.

#7
Legorol

Legorol

    Newbie

  • Member
  • 23 posts
  • Joined 20-June 11
  • OS:none specified
  • Country: Country Flag
I forgot to mention that I also tried the procedure I describe in the first post by setting SetupSourceDevice="\GLOBAL??\D:", instead of "\Device\Harddisk0\Partition1". This has an advantage.

As you know, the Device paths get assigned depending on what device you boot from: if you boot from USB, then the USB is Harddisk0 and the internal Harddisk is Harddisk1, but if you boot from the internal Harddisk, that is Harddisk0. However, drive letters are always assigned starting with the first partitions of internal Harddisks. So if you just have one internal Harddisk with one partition, and one USB stick, then the internal partition is always C:, and the USB one is D:, no matter how you boot. What this means is that drive letters remain consistent throughout setup.

If you use SetupSourceDevice="\Device\Harddisk0\Partition1" and follow the procedure in the first post, then during the GUI portion of setup, it asks for the location of files a number of times (about 20 in total). This is because for the GUI portion, I was booting from the internal Harddisk, so that is Harddisk0. However, if you use "\GLOBAL??\D:", setup finds the files on the USB stick both during text and GUI portion.

The only thing to watch out for is at the start of the text portion of setup, when you are repartitioning your internal Harddisk. After you are done with that, reboot once and restart setup to make sure the drive letters are assigned correctly.

Edited by Legorol, 22 June 2011 - 07:23 AM.


#8
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,428 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

I forgot to mention that I also tried the procedure I describe in the first post by setting SetupSourceDevice="\GLOBAL??\D:", instead of "\Device\Harddisk0\Partition1". This has an advantage.

This is very nice. :)

The issue under XP is this. As I'm sure you know, a USB stick is seen as removable media by XP, even if it's partitioned like a Harddisk (with MBR etc.). XP can format the drive, which just reformats the existing partition without touching the MBR or partition table. When you do so, XP writes the drive number 00h in the BPB of the formatted partition. This often causes problems when trying to boot the stick, because when booting, the stick is (or should be) emulated as a Harddisk and is accessible by drive number 80h.

Yes, but you see, under XP diskpart or disk management won't allow the partitioning, and you need a third party tool anyway, be it a "RMPREPUSB like" utility or the Cfadisk/dummydisk driver or anyay something "designed" to have the stoopid stick properly partitioned and bootable.
I don't remember having noticed any problem with "drive number" in the BPB, but as said it is perfectly possible that it does create problems.

I finally understood what your idea was by using a fake installation. So I set one up on the USB stick in a WINDOWS directory, as you describe in http://www.911cd.net...ic=20983&st=25. I proceeded with text-mode setup first, and then booted to Recovery Console. Sure enough it offered me a choice of logging into C:\WINDOWS and D:\WINDOWS, where C was the Harddisk and D the USB stick. I tried both, and tried to use bootcfg. Unfortunately however, bootcfg only offered to add C:\WINDOWS to boot.ini, it didn't see the D:\WINDOWS directory. So this didn't help.

That's why I said :

You may need a "fake" Windows installation :unsure:, something similar to my "no more CATCH22" trick, though.

I mean, we do know that in order to set the stoopid variables, the RC needs to access ONLY some very limited parts of the Registry:

Now, it seems like RC "detects" the existence of a XP install on HD by checking for the existence of BOTH:
a. a subdirectory \whatever\System32\config
b. a subdirectory \whatever\System32\drivers
then it connects to the hive SOFTWARE inside \whatever\System32\config\ and reads ONLY the said key in it.

it is very possible that bootcfg looks for "something else".
For testing purposes, try copying a "whole" Registry to the "\whatever\System32\config" directory :unsure: (but probably also some keys in it needs to be changed)

I take your point about not renaming system files, the caution is justified. I think just for the purpose of this project, I was OK. I was envisioning a scenario where you might be stuck with a restricted set of tools, for example because you are out visiting a client site.

Sure :), not at all a problem for this use/purpose of this project, which is anyhow reserved to people that know where their towel is. :thumbup

#9
Legorol

Legorol

    Newbie

  • Member
  • 23 posts
  • Joined 20-June 11
  • OS:none specified
  • Country: Country Flag


I forgot to mention that I also tried the procedure I describe in the first post by setting SetupSourceDevice="\GLOBAL??\D:", instead of "\Device\Harddisk0\Partition1". This has an advantage.

This is very nice. :)

I don't think I have seen this use of SetupSourceDevice anywhere, which is why I posted it. I came up with the idea after reading Naming Files, Paths, and Namespaces. I was reading today about techniques for assigning a fixed drive letter to the USB stick, for example as mentioned in http://www.msfn.org/...ll-xp-from-usb/ . It just occured to me that once you have a fixed drive letter, you can use \GLOBAL??\D: in a predictable way.

Yes, but you see, under XP diskpart or disk management won't allow the partitioning, and you need a third party tool anyway, be it a "RMPREPUSB like" utility or the Cfadisk/dummydisk driver or anyay something "designed" to have the stoopid stick properly partitioned and bootable.
I don't remember having noticed any problem with "drive number" in the BPB, but as said it is perfectly possible that it does create problems.

Yes, you are right. If you don't already have a bootable USB stick, you are stuck under XP. However, when you buy them in the shop, nowadays USB sticks come prepartitioned already, so you are not too far away, and just need to format it. That you can do under XP as well, so the only snag under XP is the "drive number". As for what this snag is, as we discovered over at http://www.911cd.net...showtopic=24395, the VBR code uses the driver number in the BPB to try and load NTLDR. If it's not the correct number, you get a "Disk Error" when trying to boot.

it is very possible that bootcfg looks for "something else".
For testing purposes, try copying a "whole" Registry to the "\whatever\System32\config" directory :unsure: (but probably also some keys in it needs to be changed)

I see, this could work. Unfortunately I won't be trying this due to time constraints. It digresses a bit too much from my original goal, and I would like to do some other experimenting. Maybe later :whistle:

Sure :), not at all a problem for this use/purpose of this project, which is anyhow reserved to people that know where their towel is. :thumbup

Actually, I was kind of hoping to distill a procedure that is as simple as possible and relies on no other tools so that maybe it can be written up as a general guide. I can now install from the USB stick almost like from a CD, with only the following extra steps required:
* Make your USB stick bootable (this could be a bit technical, but is easy under Win 7 by just partitioning/formatting)
* Copy 3 extra files (setupldr.bin, ntdetect.com, txtsetup.sif)
* Edit 2 lines in txtsetup.sif in Notepad
* Create a boot.hdd file with 2 lines in Notepad
* Enter Recovery Console once to copy 1 file
Still a bit on the technical side, but not too bad :D If I can find a (simple) way to avoid having to enter Recovery Console, I would be happy.

#10
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,428 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
No prob whatever, take all the time you need (and more) this is FUN, remember :)

About fixing a drive letter, the reference is "migrate.inf":
http://www.911cd.net...showtopic=19663
http://www.msfn.org/...er-d-and-not-u/
that can be used for other tweaks too.

Still a bit on the technical side, but not too bad If I can find a (simple) way to avoid having to enter Recovery Console, I would be happy.

Sure :yes: , I would say excellent instead of "not too bad" :thumbup

I am thinking about it, but without *ANY* third party tools (and no batches) I think it is hard. :unsure:

And anyway there may a difference between "running Vista :ph34r: or 7 and installing XP" and "running XP and installing XP".

jaclaz

#11
Legorol

Legorol

    Newbie

  • Member
  • 23 posts
  • Joined 20-June 11
  • OS:none specified
  • Country: Country Flag
Fun it is! :thumbup

About fixing a drive letter, the reference is "migrate.inf":
http://www.911cd.net...showtopic=19663
http://www.msfn.org/...er-d-and-not-u/
that can be used for other tweaks too.

I was just reading up on this area. Thanks for the links!

I am thinking about it, but without *ANY* third party tools (and no batches) I think it is hard. :unsure:

It is hard :wacko: Remember, Microsoft didn't intend for us to install XP from USB :angel Batches are technically allowed though, since you can create them in Notepad B) however the aim is simplicity, so a 300 line batch that you have to type in yourself wouldn't work.

And anyway there may a difference between "running Vista :ph34r: or 7 and installing XP" and "running XP and installing XP".

Sadly yes, so for now "running 7 and install XP" or at least "make bootable stick in 7 and do the rest in XP".

Idea: Get an inf-based method to copy boot.ini over from the USB stick to the Harddisk during text-mode Setup. Maybe migrate.inf, maybe txtsetup.sif, it's too early to tell. I wonder what happens, whether Setup would just overwite it at the end of text-mode before the reboot. I will see.

Edited by Legorol, 22 June 2011 - 03:09 PM.


#12
Legorol

Legorol

    Newbie

  • Member
  • 23 posts
  • Joined 20-June 11
  • OS:none specified
  • Country: Country Flag
Sadly this idea didn't work out, thwarted by Setup :no:

Steps:
1) I put a file "test.txt" in the \I386 directory of the USB stick.
2) In txtsetup.sif, in [SystemPartitionFiles], I added a line:
test.txt="\"
3) In [SourceDisksFiles], I added a line:
test.txt = 1,,,,,,_x,1,0,0

I then did Setup as usual. Result: test.txt appeared both in C:\ and C:\WINDOWS, as expected. (Changing the 0,0 to 3,3 would eliminate copy in \WINDOWS).
Instead of test.txt, I repeated the experiment with a boot.ini file with the correct multi(0)disk(0)rdisk(0)partition(1) line. Sure enough, it got copied to \WINDOWS, but the boot.ini in C:\ was still the one normally created by Setup :( It means that Setup creates boot.ini after file copy, and completely overwrites it.

Another idea: try to copy the real NTLDR to the root of the USB stick during text-mode setup, to replace setupldr.bin. Together with a correctly prepared boot.ini, what this means is that when text-mode setup is complete, could just reboot from USB to resume setup. This would be a destructive change, but at least no Recovery Console need. So the aim: get Setup to copy a file to D:\.

Steps are similar to before:
1) Put "test.txt" in \I386 of the USB stick.
2) In txtsetup.sif, in [SystemPartitionFiles], add a line:
test.txt="D:\"
3) In [SourceDisksFiles], add a line:
test.txt = 1,,,,,,_x,1,0,0

To my surprise, test.txt showed up in C:\ instead of D:\ (as well as in C:\WINDOWS, but that's expected). I tried a few alternative paths: "\\.\D:\", "\\.\Physicaldrive0" and "\\.\Physicaldrive1". Each time, test.txt showed up in C:\ :wacko: (Note: I reformat C: each time, so the file wasn't just accidentally left there).

Back to the drawing board!

#13
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,428 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

I then did Setup as usual. Result: test.txt appeared both in C:\ and C:\WINDOWS, as expected. (Changing the 0,0 to 3,3 would eliminate copy in \WINDOWS).
Instead of test.txt, I repeated the experiment with a boot.ini file with the correct multi(0)disk(0)rdisk(0)partition(1) line. Sure enough, it got copied to \WINDOWS, but the boot.ini in C:\ was still the one normally created by Setup :( It means that Setup creates boot.ini after file copy, and completely overwrites it.

This is "strange".
I mean, let's take the case when you ALREADY have an installed 2K or XP on the internal hard disk and you want to install (from a "normal" CD) an "additional" instance.
The BOOT.INI already on root of "C:\" is not overwritten, the entry to the "additional" instrance is added to it. (actually the existing BOOT.INI is first modified to add the temporary entry for the install (after reboot) and then this temporary addition is removed.

Maybe this happens because when you boot the CD the BOOT.INI is ALREADY there? :unsure:
Or maybe some checks (just like the ones for the CATCH22 trick) are performed to verify that another instance of windows is present?
I dont' think the latter applies,
I mean, if I do a dual boot install of DOS (7.1/8.0) and XP (on a FAT32 C:\ drive) then I decide to delete the whole Windos stuff, the "Bootsect.dos" file and the entry pointing to it should not be deleted when I re-install XP.

But yes, the binifix batch was at the time created to solve this issue AFAICR (a lot of time has passed, and my memory is not as good as it used to be :blushing: ), relevant links should be these:
http://www.msfn.org/...y/page__st__373

You will need some time to go through the various steps taken, I cannot even remember if this
http://www.msfn.org/...y/page__st__285
has been added/coorected

jaclaz

#14
Legorol

Legorol

    Newbie

  • Member
  • 23 posts
  • Joined 20-June 11
  • OS:none specified
  • Country: Country Flag
That is an excellent point you bring up about Setup for dual-booting, didn't think of that. So I tested it, and the conclusion is this. If BOOT.INI is present when Setup starts, then Setup will only append to it, but if it is not present at the start, a new one is created, overwriting any that is copied during the Setup itself. Sadly.

I have seen your binifix batch file included in USB_MultiBoot_10.zip at http://www.911cd.net...howtopic=22857. As you say, it is doing the job of correcting the BOOT.INI entry at the end of the GUI Setup.

#15
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,428 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

That is an excellent point you bring up about Setup for dual-booting, didn't think of that. So I tested it, and the conclusion is this. If BOOT.INI is present when Setup starts, then Setup will only append to it, but if it is not present at the start, a new one is created, overwriting any that is copied during the Setup itself. Sadly.

What happens if you boot SETUP twice?
Once to just Partition/Format and start install? Then "break it" at some stage?
Once for actually installing?

Could first round allow copying a BOOT.INI that becomes "base" for additions?

Or somehow add a "fake" (or real) IO.SYS/MSDOS.SYS/COMMAND.COM?
Would in this case setup create a "stable" BOOT.INI with the provision for the DOS (like c:\bootsect.dos or the like)?
Can this be somehow used to our "advantage"?

What does F2 do?
http://support.microsoft.com/kb/295116

Do we know in which order the "text/inf" files in setup are processed?
I mean is there anything that allows the copy of the file or a rename of it just before the reboot?

Mind you just semi-random ideas :ph34r: , let's call it free-no-limit-brain-storming....

jaclaz

Edited by jaclaz, 24 June 2011 - 10:42 AM.


#16
ilko_t

ilko_t

    MSFN Addict

  • Super Moderator
  • 1,722 posts
  • Joined 06-December 06
  • OS:none specified
  • Country: Country Flag
@Legorol

You might find these topics interesting, basically covering most of what you have pointed out, if haven't read them yet:

http://www.msfn.org/...-from-hd-media/
http://www.msfn.org/...aded-small-iso/

There is another glitch you have not encountered yet, described in those topics- USB hard disks and perhaps some card readers not detected, read no valid source during GUI mode of some Windows versions.

Added:
As for boot.ini- it's generated/amended at the very end of text mode. You may try to add another one via txtsetup.sif. Timeout will be reset to 0, or 1, can't recall exactly. User would need to start tapping F8 quickly when booting for GUI mode in order to get to the boot menu and select the custom entry, not the one added by Setup.
Binifix.cmd is always an option too.

As for the drive letter D- this is limitation, user might have another internal disk, or it could be already partitioned, or not partitioned, another reboot is required in the latter case. Fixed letter via migrate.inf works, but there are cases (USB sticks without serial number for example), when it does not, or machines wirh ParentIDPrefix starting with 6, or 8, not the usual 7.

Not criticizing or something, just pointing out the issues we have already been through. Good work of yours so far :thumbup

Install Windows from USB, boot Linux, multiboot and a lot more with WinSetupFromUSB


#17
Legorol

Legorol

    Newbie

  • Member
  • 23 posts
  • Joined 20-June 11
  • OS:none specified
  • Country: Country Flag
@jaclaz: I can hopefully get around to testing some of your ideas, they are interesting.

@ilko_t: Thanks for the links! I have seen the first one already, I used it to my advantage. I realise that what I was doing is not new, and in fact all the issues in it have been fixed long ago :-) There are nice tools out there. I was trying to make sure I have a good understanding of what I read, and to have a go at doing things manually, as simply as possible.

I agree that the drive letter D is a big limitation. It's not too bad if you can predict it beforehand, since Setup assigns drive letters in a documented way, but it can definitely get tricky. I liked the idea of using a drive letter because once you are done partitioning, that doesn't change, whereas ARC path does if you change what you boot from.

#18
Legorol

Legorol

    Newbie

  • Member
  • 23 posts
  • Joined 20-June 11
  • OS:none specified
  • Country: Country Flag
Based on jaclaz's ideas, I tried a few experiments out to get BOOT.INI to have the correct entry, without any success. I concluded that Setup inspects BOOT.INI when it starts (or at least no later than the start of the file copy part), adds an entry to it and then writes an entire BOOT.INI out after the file copy part. Therefore, the contents of BOOT.INI can't be affected by actions during the file copy part.

That was the last remaining avenue I was going to investigate in this topic, so as far as I am concerned I'm finished with this "mission". :-)

Edited by Legorol, 01 July 2011 - 05:41 PM.


#19
wimb

wimb

    Senior Member

  • Developer
  • 679 posts
  • Joined 21-March 07
You can try to add $OEM$\$1 folder structure to your Setup Source and put your boot.ini in the $1 folder

http://unattended.ms...xp/view/web/18/

As you can see on the left, the $OEM$ folder stays parallel to the i386 folder, not inside it. Anything in $1 will be copied to the root of the patition where Windows is installed to (C:\ for example). See the examples below on how it all works:

In preparation, the layout is:
C:\XPCD\$OEM$\$1\Install\

When burned to CD (X:\ being the CD-ROM Drive letter), the layout is:
X:\$OEM$\$1\Install\

When the \$OEM$\$1\Install is copied over to the hard drive during Setup, the layout is:
C:\Install\


I observed that the content of $OEM$ is copied to your Install partition at the very end of TXT-mode of XP Setup.
It means that your boot.ini will be copied AFTER the normal FileCopy and just before the reboot.
I don't know if it works for you, but it is certainly the best and last chance to manipulate XP Setup before the reboot for GUI mode.

Edited by wimb, 01 July 2011 - 11:09 PM.


#20
nilkanth

nilkanth

    Newbie

  • Member
  • 20 posts
  • Joined 01-May 05
I created bootable as shown by using source folder Unattended XPCD3 created by nLite integrating drivers, updated and using tweaks and user data. I copied all the content of folder XPCD3 to USB including i386\WINNT.sif.

While installing windows on target computer, after completion of copying setup files, I got the following error :

“Setup cannot find the temporary installation files.

The hard drive on which setup placed Temporary files is not currently available to Windows XP. You may need a manufacturer-supplied device driver or you may need to run setup again and select a device that is compatible with Windows XP for the temporary installation files. See your Windows XP documentation for more information.

On x86 based computers floppy disk generated by setup for use with non-CD installation are not suitable for installing from CD

Setup cannot continue, to quiet press F3”

Please guide me.

Thanks

#21
ilko_t

ilko_t

    MSFN Addict

  • Super Moderator
  • 1,722 posts
  • Joined 06-December 06
  • OS:none specified
  • Country: Country Flag
Did you follow instructions in this thread? Are you willing to experiment or need tested and working solutions?

What are contents of winnt.sif? Hide the sensitive information in it and post it.
Where did you place it?
What did you change in txtsetup.sif?
Where did you place it?
Do you get this message at start of GUI mode or after initialization of Text mode, before displaying available disks?
Did Text mode part complete without errors?

Install Windows from USB, boot Linux, multiboot and a lot more with WinSetupFromUSB


#22
nilkanth

nilkanth

    Newbie

  • Member
  • 20 posts
  • Joined 01-May 05
Attached File  WINNT.SIF   1.07KB   7 downloads

Did you follow instructions in this thread? Are you willing to experiment or need tested and working solutions?

What are contents of winnt.sif? Hide the sensitive information in it and post it.
Where did you place it?
What did you change in txtsetup.sif?
Where did you place it?
Do you get this message at start of GUI mode or after initialization of Text mode, before displaying available disks?
Did Text mode part complete without errors?


(1) I need solution because installing Windows by CD, I frequently experiencing problem due to improper writting of CD.

I attached here my WINNT.sif file.

I put the following two lines FIRST under SETUPDATA head in the TXTSETUP.sif file.

BootPath = "\i386\"
SetupSourceDevice = "\Device\Harddisk0\Partition1"

I placed both the files WINNT.sif and TXTSETUP.sif in the 'i386' folder of USB.

I got the Error after initialization of Text mode and copying of temporary installation files but before displaying available disks.

Text mode part completed without errors.

(2) Second thing if I put the MsDosInitiated = "0" in the DATA head in WINNT.sif I get the folowing error

"Setup cannot find a previous version of Windows installed on your Computer. To continue Setup needto verify that you qualify to use this upgrade product.

Please insert one of the following products CD into the CD-Rom Drive : Windows XP Home Edition (Full Version), Windows XP Professional (Full Version)...etc.

When the CD is in the drive Press ENTER
To quit setup press F3"

#23
ilko_t

ilko_t

    MSFN Addict

  • Super Moderator
  • 1,722 posts
  • Joined 06-December 06
  • OS:none specified
  • Country: Country Flag
You do need to set msdosinitiated to 0, or Setup will be looking for the default ~BT and ~LS folders.
As for the new error- if you do have the proper licensing and agree with EULA put in [data] section the following lines:
http://www.msfn.org/...post__p__954342

As a side note- there are number of tested and proven to work applications and methods for the purpose, pick one from the pinned topics. There is no need to reinvent the wheel unless you want to study the matter. This is just one of the many issues you might hit. Next question would be what do I do with boot.ini, next is why my unattended settings do not work and so on.
If you want to go further this path- please search in this subforum, you most likely will find answers of all the questions and issues you'd come across. All those have already been answered and taken care of in the referenced methods.

Install Windows from USB, boot Linux, multiboot and a lot more with WinSetupFromUSB


#24
Legorol

Legorol

    Newbie

  • Member
  • 23 posts
  • Joined 20-June 11
  • OS:none specified
  • Country: Country Flag
@nimb: That is very interesting, I will try your suggestion out with $OEM$.

@nilkanth: It sounds to me like you are mixing two entirely different sets of procedures up. If you have a winnt.sif file, that means that you have used winnt.exe or winnt32.exe to start preparing the installation, but you are trying to follow my procedure for installing from USB, which is a different procedure.

Some explanation:
When you use winnt.exe or winnt32.exe, a set of temporary folders are created, which setup will look for later on. However, you didn't copy those to your USB drive (you only copied the i386 folder), and so you are running into problems. The instructions I posted in the first post are NOT using winnt.exe or winnt32.exe to start the installation. There is no winnt.sif involved with my procedure, nor any temporary folders.

Also, you seem to have a misunderstanding about what "text mode setup" means. "Text mode setup" is all the steps that take place on the text screen with blue background and white letters. The text mode setup includes: computer boots, blue screen with white text is displayed, setup loads a set of drivers, setup examines your disks, you are prompted to accept the EULA, you are offered a choice of disk to install Windows on, and finally a yellow progress bar shows a large number of files getting copied over. The text mode setup ends when a 15-second countdown with a red progress bar appears saying that your computer will reboot.

EDIT: couple of other points:
Looks like you are trying to perform a fully unattended setup. My procedure was not developed for that.
Are you by any chance trying to use a product key and/or CD for an *upgrade* version of Windows XP, and not a full retail or OEM version?
My procedure requires that you place the modified copy of txtsetup.sif in the *root* directory of your USB drive (for example, D:\), not in the I386 folder. Otherwise it won't get read by setup.

Edited by Legorol, 06 July 2011 - 03:12 AM.


#25
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,428 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
@nilkanth
It seems to me like your post is completely void of any relevance to the actual topic.

As soon as you will acknowledge this post, I will split posts related to your issue to a new topic, where it will be easier to help you without "polluting" the present one, that is intended as an "experimental" one, nothing that you should (for the moment) try at home, as ilko_t pointed out there are several tested and working methods, it is pointless to use a harder way to get the job done, unless it is for "fun" or for the sake of experimenting.

jaclaz




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN