ilko_t

Install 2000/XP/2003 from RAM loaded small ISO

40 posts in this topic

There are a few entries in txtsetup.sif, allowing Setup to continue loading driver files for the first stage, until the partitioning screen, from alternative location, this is our USB stick/disk.

Location of the rest of the files, needed to continue Text mode (EULA and file copy part) are given as per this topic:

http://www.msfn.org/board/2-t119742.html

1. Create a small ISO containing only \I386\SETUPLDR.BIN, \I386\NTDETECT.COM and \I386\TXTSETUP.SIF for 32-bit setups. In case of 64-bit only TXTSETUP.SIF is in I386 AMD64, the other 2 files are in \AMD64\ I386.

2. Add these lines to your TXTSETUP.SIF in the ISO:

[SetupData]
....
SetupSourcePath ="\WIN_SETUP\2000\"
SetupSourceDevice=\ArcName\multi(0)disk(0)rdisk(1)partition(1)
BootPath="\WIN_SETUP\2000\I386\"
BootDevice="multi(0)disk(0)rdisk(1)partition(1)"
....

After loading the 3 files from the ISO setup continues loading the other from BootDevice\BootPath.

3. Grub4Dos menu.lst:

title First part of 2000 setup
find --set-root /WIN_SETUP/2000.ISO
map --mem /WIN_SETUP/2000.ISO (0xff)
savedefault 1
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
root (0xff)
chainloader /I386/SETUPLDR.BIN

title Second part of 2000 setup/Start from the first internal disk
savedefault
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
rootnoverify (hd0)
chainloader (hd0)+1

4. Put that ISO say in \WIN_SETUP\ on the USB disk.

5. Copy the all 2000 setup files in \WIN_SETUP\2000\

6. At start of GUI mode the value of sourcepath in $winnt$.inf is "translated" to dos path, with a drive letter and is used for the rest of the GUI mode.

Default behavior is to translate this NT path to Dos path, which is used for the GUI mode. If the value is ARC path it gets translated to \device\harddiskX\partitionY\WIN_SETUP\2000\. If the value is \device\harddiskX\PartitionY\WIN_SETUP\2000\ it gets translated to U:\WIN_SETUP\2000\. This is saved as the value of dospath entry in $winnt$.inf.

Instead, use presetup.cmd and Pyron's fake setup to change 'setupsource' value to something more useful- "\??\U:\WIN_SETUP\"

U: is taken by searching in all local drives for a tag file.

Winnt.sif if present in the source folder (\WIN_SETUP\2000\I386\) is applied, migrate.inf too. The ISO file needs just the 3 files mentioned.

If txtsetup.oem is present in the ISO, alongside txtsetup.sif, it's also honored.

No files are deleted from the source folder. Msdosinitiated in sould be 0, NO, or absent in winnt.sif, as in a regular source.

Boot.ini is generated correctly and placed always on the internal disk.

Practically unlimited number of sources can be easily placed on the USB disk.

Tested successfully with USB stick on all possible Windows versions 2000-XP-2003, on virtual machines and real hardware.

The only problems I got were with USB hard disk and 64-bit versions, this could be because of the IDEtoUSB adapter I am using. At start of GUI mode partitions on USB disk do not get drive letters. Diskpart shows the disk, but no volumes are mounted from it, just the internal disk :unsure:

To do list:

Find out what's going on with USB hard disks and x64 versions.

Test USB stick/disk mapped to say hd21.

Find workaround for USB sticks, seen as floppy by BIOS. Lacking hardware for this part.

Here is a very unfinished, test version of WinSetupFromUSB, which has a lot to be changed and fixed, but does the most of the required changes, if anyone want's to jump in and help testing:

http://www.datafilehost.com/download-48372825.html

Same approach might be used for loading multiple BartPEs in the USB stick/disk, no need of the ISO file, just settings in txtsetup.sif pointing where the files are to be found, not tested.

edit: (18-11-2009) Fixed locations of files in case of 64 bit versions

edit: (20-11-2009) WinSetupFromUSB download link modified

edit: (21-11-2009) WinSetupFromUSB download link modified

edit: (10-12-2009) WinSetupFromUSB download link modified

edit: (19-12-2009) WinSetupFromUSB download link modified

0

Share this post


Link to post
Share on other sites

That sounds very cool! :D

Could you give me an example of your presetup.cmd file?

Now it's got me thinking.

Would something like this be possible...

Could we create our mini ISO's with the needed files and edits you have above. Plus add only the needed files which are different between different versions of XP. Like XP Pro OEM / VLK / Retail.

So that when setup is performed those files are placed into the setup?

This way we could simply have the entire disk from XP Pro OEM on the USB Stick. Plus mini iso's of the others. XPPROVLK.ISO, XPPRORTL.ISO.

During setup all of the XP Pro OEM files would be placed onto the drive through txtmode setup. But the files for VLK or Retail would overwrite the OEM files just before Guimode.

I'm really curious if it would work. As you know. Thats exactly what I have been looking to do for a long time now. ;)

I'll test out your new method sometime later tommorrow if I get a chance.

Thanks! :thumbup

0

Share this post


Link to post
Share on other sites

presetup.cmd:

@echo off
SET TAGFILE=\WIN_SETUP
FOR %%h IN (U D M N O P Q R S T V W X Y) DO IF EXIST "%%h:%TAGFILE%" SET USBDRIVE=%%h:
if "%USBDRIVE%" == "" (
FOR %%h IN (C E F G H I J K L) DO IF EXIST "%%h:%TAGFILE%" SET USBDRIVE=%%h:
)

set srcpath=\??\%USBDRIVE%\WIN_SETUP\2003\
%systemroot%\system32\fixsrcpath.exe %srcpath%
EXIT

fixsrcpath.exe is a simple AutoIt code- attached with the compiled fixsrcpath.exe, along with the fake setup.ex_. Works for both 32 and 64 bits versions of setup.

Added entries to TXTSETUP.SIF in the ISO:

...
[SourceDisksFiles]
...
fixsrcpath.exe=1,,,,,,,2,0,0
presetup.cmd=1,,,,,,,2,0,0
setupORG.exe=1,,,,,,,2,0,0
...
[SetupData]
SetupSourcePath ="\WIN_SETUP\2003\"
SetupSourceDevice=\ArcName\multi(0)disk(0)rdisk(1)partition(1)
BootPath="\WIN_SETUP\2003\I386\"
BootDevice="multi(0)disk(0)rdisk(1)partition(1)"
...

Make sure you use similar entries for grub4dos menu.lst as posted above.

Extract the existing original setup.ex_ and rename to setupORG.exe in \I386\. Put setup.ex_ from the archive in \I386\.

As for your idea- should be easily doable- just slightly different txtsetup.sif's in the ISO, pointing to the same source, which has needed files for all versions mentioned. I'd need to get back to your notes for details.

fixsrcpath.7z

0

Share this post


Link to post
Share on other sites

Breaking News, this sounds very interesting :thumbup

0

Share this post


Link to post
Share on other sites

Premilary note:

Test version WinSetupFromUSB 0.2.4

XP SP2 64 bit

fixsrcpath.exe=1,,,,,,,2,0,0

setupORG.exe= 1,,,,,,,2,0,0

presetup.cmd= 1,,,,,,,2,0,0

[setupData]

SetupSourcePath ="\WIN_SETUP\XP_x64\"

SetupSourceDevice=\ArcName\multi(0)disk(0)rdisk(1)partition(1)

BootPath="\WIN_SETUP\XP_x64\AMD64\"

BootDevice="multi(0)disk(0)rdisk(1)partition(1)"

I'm using -graft-points to create the ISO file. Files are read from USB drive.

\WIN_SETUP\mkiso.cmd

set win_root=%~dp0
set win_files=XP_x64

mkisofs.exe -graft-points -o %win_root%/%win_files%.ISO ^
/I386/SETUPLDR.BIN=%win_root%\%win_files%\I386\SETUPLDR.BIN ^
/I386/NTDETECT.COM=%win_root%\%win_files%\I386\NTDETECT.COM ^
/AMD64/TXTSETUP.SIF=%win_root%\%win_files%\AMD64\TXTSETUP.SIF

32 bit fake setup complains:

C:\WINDOWS\system32\presetup.cmd : file not found

C:\WINDOWS\system32\setupORG.exe : file not found

Both file does exit at hard disk.

Fake setup.exe is 28 kb size, that's the BTS one, not Pyron's.

PE booted: setuporg.exe renamed to setup.exe.

The same experience: USB drive is missing.

Next idea add Dietmar's usbboot.inf.

USB drive should be available at first reboot.

To be continued.

As for your idea- should be easily doable- just slightly different txtsetup.sif's in the ISO, pointing to the same source, which has needed files for all versions mentioned. I'd need to get back to your notes for details.

Grub4dos support hex editing in RAM nowadays.

Add one setupldr.bin and different renamed txtsetup.sif.

Patch setupldr.bin on the fly.

0

Share this post


Link to post
Share on other sites
As for your idea- should be easily doable- just slightly different txtsetup.sif's in the ISO, pointing to the same source, which has needed files for all versions mentioned. I'd need to get back to your notes for details.
Grub4dos support hex editing in RAM nowadays.

Add one setupldr.bin and different renamed txtsetup.sif.

Patch setupldr.bin on the fly.

Now that is a great idea too. :thumbup

0

Share this post


Link to post
Share on other sites

@ilko_t

Wow64FsRedirection did confuse me.

Brute force approach did work using fake setup.exe from WinSetupFromUSB 0.2.4.

fixsrcpath.exe=1,,,,,,,2,0,0

setupORG.exe= 1,,,,,,,2,0,0

presetup.cmd= 1,,,,,,,2,0,0

fixsrcpath.exe=1,,,,,,,82,0,0

setupORG.exe= 1,,,,,,,82,0,0

presetup.cmd= 1,,,,,,,82,0,0

Can you name a good x64 txtsetup.sif example?

Dietmar's usbboot.inf. and txtsetup.sif [bootBusExtenders.Load] set.

After reboot there is d: USB drive available.

Presetup.cmd and fixsrcpath.exe does adjust $winnt.sif$. Setup does continue.

Next drive d: disappear. Setup holds, missing files.

Try editing usb*.inf or do you have another suggestion?

@Siginet

Different txtsetup.sif is a inter media step.

Use ONE ISO image finally.

Load this to RAM. Use grub4dos to change txtsetup.sif in RAM.

There are dd, write and 'cat --locate --replace' to edit txtsetup.sif.

0

Share this post


Link to post
Share on other sites
Can you name a good x64 txtsetup.sif example?
Exactly as you figured it out.

fixsrcpath.exe=1,,,,,,,82,0,0
presetup.cmd=1,,,,,,,82,0,0
setupORG.exe=1,,,,,,,82,0,0

Section is still SourceDisksFiles. Those files are in AMD64 folder in source.

And yes, sorry for confusion, fake setup.exe is taken from BTS DP, auto renames original setup.exe and launches it.

SysWOW redirection was real pain in the rear to figure out, I was trying with batch files, but it was behaving very weird and inconsistent, even using start64.exe to launch 64 bit cmd.exe and execute the batch file.

Next was to compile 64 bit version of the fake setup.exe, but rather than that, I just created AutoIt script, which works on both platforms, disabling SysWow redirection, it was much quicker and safer to do it this way.

I hope I am not forgetting something, I was coding all changes directly in the AutoIt script, but the basics are covered above.

As for the USB start type changes- I was thinking in this direction too, what stopped me was why 2003 SP1 32 bit works just fine, but 64 bit version not, in the very same setup :blink: , the USB stick works fine. Did MS introduced more changes compared to 32 bit similar versions?

The other thing is that looking at setuplog.txt reveals that the USB disk is enumerated, I suspected other reason for this behavior.

As for the drive letters- when using grub4dos MBR there is no need of active partition, so partitions on the USB disk will get lower priority in drive letter assignment. Another idea- hide the partitions for the Text mode, unhide them for GUI, not tested, should work, risky though for regular user.

The idea with editing TXTSETUP in RAM is great, didn't know it's already implemented in grub4dos, thanks.

0

Share this post


Link to post
Share on other sites
In case of 64-bit only TXTSETUP.SIF stays in I386, the other 2 files go in \AMD64\.
I'm using -graft-points to create the ISO file. Files are read from USB drive.

\WIN_SETUP\mkiso.cmd

set win_root=%~dp0
set win_files=XP_x64

mkisofs.exe -graft-points -o %win_root%/%win_files%.ISO ^
/I386/SETUPLDR.BIN=%win_root%\%win_files%\I386\SETUPLDR.BIN ^
/I386/NTDETECT.COM=%win_root%\%win_files%\I386\NTDETECT.COM ^
/AMD64/TXTSETUP.SIF=%win_root%\%win_files%\AMD64\TXTSETUP.SIF

me confused so who is right about the file locations?

I think ilko is wrong saying TXTSETUP staying in I386 because the default location of this files in an official iso are where wrote cdob

0

Share this post


Link to post
Share on other sites
...me confused so who is right about the file locations?

I think ilko is wrong saying TXTSETUP staying in I386 because the default location of this files in an official iso are where wrote cdob

You are correct, it's the opposite of what I posted, editing the post above.

I'd recommend you to stick with the test version of WinSetupFromUSB, most of the changes were coded directly and I am posting the procedure here by actually reading the AutoIt code and looking at already made USB disk.

0

Share this post


Link to post
Share on other sites
SysWOW redirection was real pain in the rear to figure out, I was trying with batch files, but it was behaving very weird and inconsistent, even using start64.exe to launch 64 bit cmd.exe and execute the batch file.

Next was to compile 64 bit version of the fake setup.exe

I've compiled a 64 bit version of Pyron's fake setup.exe. Don't you remember from ISO RAM load?

As long as you use 64 bit only applications, setup behave consistent.

I just created AutoIt script, which works on both platforms, disabling SysWow redirection, it was much quicker and safer to do it this way.
As you like.
As for the USB start type changes- I was thinking in this direction too, what stopped me was why 2003 SP1 32 bit works just fine, but 64 bit version not, in the very same setup :blink: , the USB stick works fine. Did MS introduced more changes compared to 32 bit similar versions?
No explanation. Contrary missing USB is reported at 32 bit ISO RAM load too: some strange BIOS.

Missing USB seems to be more common.

The other thing is that looking at setuplog.txt reveals that the USB disk is enumerated, I suspected other reason for this behavior.
PNP works up to USB Root Hub device, installation does fails. Driver not found anymore.

Add a work around to presetup.cmd, open drive U:

[BootBusExtenders.Load]
usbehci = usbehci.sys
usbohci = usbohci.sys
usbuhci = usbuhci.sys
usbhub = usbhub.sys
usbstor = usbstor.sys

[InputDevicesSupport.Load]
;usbohci = usbohci.sys
;usbuhci = usbuhci.sys
;usbehci = usbehci.sys
;usbhub = usbhub.sys
;usbstor = usbstor.sys

[BootBusExtenders]
usbehci = "Enhanced Host Controller",files.usbehci,usbehci
usbohci = "Open Host Controller",files.usbohci,usbohci
usbuhci = "Universal Host Controller",files.usbuhci,usbuhci
usbhub = "Generic USB Hub Driver",files.usbhub,usbhub
usbstor = "USB Storage Class Driver",files.usbstor,usbstor

USB drives are available at first reboot.

Next USB hardware did break, hardware not detected anymore.

New hardware prepared: dosn't boot anymore: biosinfo.inf not found.

Reason: FAT16 formated, directory WIN_SETUP not found.

WIN_SETUP renamed to WINSETUP (8.3 name) and config adjusted.

XP installation does work again.

Dosdev.exe from resource kit list device names.

Did you tried USB SourcePath "Device\Harddisk1\DP(1)0-0+2\WIN_SETUP\XP_x64\AMD64\" at $winnt$.sif?

USB stick keeps available, but PNP freeze.

Be aware, testings are done at one machine only. Different BIOS may get different results.

PyronSetup.7z

0

Share this post


Link to post
Share on other sites
I've compiled a 64 bit version of Pyron's fake setup.exe. Don't you remember from ISO RAM load?
You mentioned that it's compiling in 64 bit env., I must have missed a compiled exe if you posted such. The other reason is that prefer BTS version, one thing less to worry about, renaming setup.exe and launching it.
Contrary missing USB is reported at 32 bit ISO RAM load too: some strange BIOS.
Wasn't that happening with fixed type media and when mapping was not performed?

I think this has something to do with Windows detecting the boot device and something strange around it, so it doesn't give it drive letter, or something along those lines. Remember, USB sticks work just fine with 64 bit versions.

Add a work around to presetup.cmd, open drive U:

start /min "USB keep mounted - work around" pushd %CDDRIVE%

USB drive keeps available. Setup does work.

Hmm, in my tests with hard disk and 64 bit vers. %CDDRIVE% did not get value, tag file was not found in presetup.cmd. USB disk partition did not have any drive letter assigned when fake setup.exe was launched. Did you test with 64 bit and USB hard disk?
As for txtsetup.sif:

No need for a usbboot.inf, but change drive load priority.

BootBusExtenders.Load are set to boot drivers at registry: start=0

I'd try that, want to get away for a bit from this matter, had too much testing last weeks and need to clear up my head a bit :)
Did you tried USB SourcePath "Device\Harddisk1\DP(1)0-0+2\WIN_SETUP\XP_x64\AMD64\" at $winnt$.sif?
Nope. Does harddisk1 represent ARC path to disk(1), or it's internal numeration, as drivers return it?

Next week if time allows will go and get the cheapest CPU, supporting virtualization, so I can test 64 bit versions in VMWare. Good excuse for a little upgrade :rolleyes:

On real hardware this takes way too much time.

0

Share this post


Link to post
Share on other sites
Hmm, in my tests with hard disk and 64 bit vers. %CDDRIVE% did not get value, tag file was not found in presetup.cmd. USB disk partition did not have any drive letter assigned when fake setup.exe was launched.
USB drivers was set at txtsetup.sif [bootBusExtenders.Load] section.

USB drive got a letter.

Did you test with 64 bit and USB hard disk?
That's a very good question. It turned out:

I used previously a micro SC card and a USB micro SD card reader.

PNP did disable USB drive. This can be avoided with "pushd %CDDRIVE%".

Next i used the same micro SC card, but another USB SD card reader.

presetup.cmd edited: "pushd %CDDRIVE%" was NOT launched.

PNP does keep the USB drive.

Installation does complete without a error.

To crosscheck I used the old broken USB micro SD card reader.

Once again the same micro SD card, no editing at all now.

PNP does disable the USB drive.

The USB SD card reader makes the difference.

Strange, I'm surprised and confused. No explanation.

Does harddisk1 represent ARC path to disk(1), or it's internal numeration, as drivers return it?
No idea. Ignore this part so far.

Idea was to use dosdev.exe and use this to set sourcepath.

That's note necessary, your solution works fine.

Next week if time allows will go and get the cheapest CPU, supporting virtualization, so I can test 64 bit versions in VMWare.
My testing hardware use a 32 bit CPU. No 64 bit testing possible.

The good 64 bit hardware is used for importand work, not to be used for testings. Used for testings currently.

0

Share this post


Link to post
Share on other sites

ilko, there is something wrong with WinSetupFromUSB_0-2-4 which seems the source of my problem with the past version < 0.2.4 which I had explained here in the actual latest post

bug:

2009/11/20 13:02:07- Creating boot ISO
2009/11/20 13:02:07- Launching MkMigrateInf4.cmd
2009/11/20 13:02:07- ERROR!!!--- Could not create migrate.inf
2009/11/20 13:02:08- Ensuring presetup is launched

in your TEMP folder stands the files ready to be packed as .iso + migrate.inf

Result in: no iso created and the job is not 100% done.

I attach the 0.2.4 log file to this post, I can also add Im trying with a XP64 SP2 sleapstreamed, nothing ripped, on an Active FAT32 partition from USB HDD eSATA only connected in USB mode, and in WinSetupFromUSB im forced to use "Force Target Disk Type" => removable because there is no rdummy.sys for x64.

USE 7-zip to unpack the attached log file

WinSetupFromUSB.7z

Edited by class101
0

Share this post


Link to post
Share on other sites

@class101

Can you try renaming WinSetupFromUSB directory to something simple, like WinSetup for example.

Ignore the message about migrate.inf missing, fixed/removable type does not matter as well, rdummy is not used at all and the radio buttons do nothing now, they are to be removed in the final release.

If you want to use migrate.inf manually copy it from the ISO to the AMD64 folder on the USB disk.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.