MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically.

Share this post

Link to post

Share on other sites

I am using XP with BTS mass storage drivers pack slipstreamed, so it's via txtsetup.sif. I tried to change the order in txtsetup.sif, moving the Hardware VID&PID lines for USB mass storage and Sil3112 above then below anything else, hoping that SETUP reads the lines and scans for devices according to the order written in txtsetup.sif but that didn't change anything. Also tried to set mass storage drivers as described here, but to no avail too:

As far as I remember I tried to swap order in these lines, everything was shoots in the darkness:

[DiskDriverMap]

abiosdsk = "%1!u! MB Micro Channel Disk"

atdisk = "%1!u! MB IDE/ESDI Disk"

disk = "%1!u! MB Disk %2!u! at Id %3!u! on bus %4!u! on %5"

and

[sCSI.Load]

........

I believe similar setup could be achieved in VMware, set 2 disks- 1 SCSI and 1 IDE and try to change the order SETUP detects them. Normally IDE goes first, SCSI second. If one could find how to swap them, same method could be used to set USB stick last.

I will try first what happens to the stick when SETUP finds NT MBR on it, instead of GRUB.

edit: interesting line in txtsetup.sif, not sure is it used only when upgrading :

Share this post

Link to post

Share on other sites

When you have an IDE device attached, along with SATA disk, this breaks the order. IDE device could be CD/DVD or hard disk, and boot order on BIOS makes no difference. In this case the order SETUP enumerates devices is IDE-USB-SATA. If IDE device is disconnected or primary/secondary channel is disabled in BIOS order becomes SATA-USB.

On Gigabyte DS3P with Intel ICH8R (6 SATA ports) and JMicron 363 (2 SATA/1 IDE) if both controllers are in AHCI or RAID mode order is SATA1-SATA2-USB.

If Jmicron is in IDE mode this makes no difference, as its a separate controller, order is SATA1- SATA2- USB.

However, if Jmicron is in AHCI or RAID and ICH8 is in native IDE mode order changes to IDE (ICH8R) - USB - SATA (Jmicron). 1 hard drive attached to both controllers and a DVDRW to the JMicron IDE port, DVD was never disconnected or disabled.

So if IDE device is attached to external controller such as JMicron, this doens't change the order SETUP finds devices, and USB goes last, if a native IDE is connected it always goes first, then USB, and last is SATA.

If only IDE hard disk and USB stick are connected (CD/DVD disconnected or primary/secondary channel disabled in BIOS) order is IDE disc- USB. This was confirmed on Abit AN7 too. If CD (secondary channel) is disabled order was SATA-USB, when IDE disc was connected order becomes IDE-USB-SATA

That should clear any further issues with device order, once we ensure that USB is not first we can carry on with installation.

Here is what I did to overcome signature problem in BOOT.INI and make the installation as universal as possible.

Stick is formated by PEtoUSB, copy NTDETECT.COM, NTLDR and BOOT.INI, which is:

BOOT.INI

[boot Loader]

Timeout=15

Default=multi(0)disk(0)rdisk(1)partition(1)\WINDOWS

[Operating Systems]

c:\grldr="Start GRUB"

multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="GUI Setup" /FASTDETECT

If you are going to install on another partition/disk amend entries to reflect that.

Copy GRLDR to the root of stick and create

MENU.LST

color black/cyan yellow/cyan

timeout 15

default 0

title Phase 1 WinXP Text Mode Setup

chainloader (hd0,0)/ntldrstp

Create a folder BOOTFILES in root, and copy NTDETECT.COM, NTLDR and your custom BOOT.INI which will be copied on hard disk. Set them system, hidden and read-only in advance.

The rest is same as the first guide. This way GRUB mapping is not used, and once GUI setup is completed USB stick is no longer needed, we have brand new shining BOOT.INI along with all necessary boot files on the hard disk.

Note that at 01:31:28.859 SETUP reports free space on stick as its supposed to be if no files were deleted. Either that's incorrect or $WIN_NT$.~LS is deleted after 01:31:28.859 (about T-12- T-8). Or as I think folder is in use and cannot be renamed on time. May be one can spot something in the log.

Also, the idea to remove stick during T-1 to avoid long wait seems not so good, I can see SETUP is still doing something else at that stage, apart form deleting temp files.

Any ideas how to proceed further?

@Jaclaz - if you are still interested the attached files contains MBR and bootsector saved by HDhacker when formated by PEtoUSB and rewritten by TEXT mode SETUP.

@wimp - The IDs you have are for SIS IDE, and I can't see them in generic XP SP2 CD TXTSETUP.SIF HIDs, that means for me probably that yours are splipstreamed in your CD, SISIDE.SYS, which is later renamed and copied as NTBOOTDD.SYS. Can you search in your TXTSETUP.SIF on the CD for VEN_1039&DEV_5513 and give all results here?

Share this post

Link to post

Share on other sites

@wimp - The IDs you have are for SIS IDE, and I can't see them in generic XP SP2 CD TXTSETUP.SIF HIDs, that means for me probably that yours are splipstreamed in your CD, SISIDE.SYS, which is later renamed and copied as NTBOOTDD.SYS. Can you search in your TXTSETUP.SIF on the CD for VEN_1039&DEV_5513 and give all results here?

My setup files are slipstreamed with RVM Integrator.

A search for VEN_1039&DEV_5513 in the TXTSETUP.SIF for my slipstreamed and my generic XP SP2 CD

Share this post

Link to post

Share on other sites

Why are NTDETECT.COM and NTLDR copied by BOOT_REN.CMD from BOOTFILES to SYSTEMDRIVE ?

In a few cases I noticed that they are not written there, but may be SETUP tried to put them on stick or skipped because saw them on stick. That way we are sure everything needed to boot is in place.

I came through the Windows Setup procedure, but obtained a boot.ini with two entries as given below:...

rdisk(1) is because no mapping is made via GRUB, that was the reason we used map (hd0) (hd1) in the previous guide. It also won't add signature, because no mapping is made and SETUP sees the disks as they are.

The working line rdisk(0) I beleive is a copy of the one on the USB stick, I have no idea when SETUP adds it, but I noticed the same behavior. If mapping was used on my last test it was ending with signature and disk couldn't be booted with that signature, no idea why it worked before. That's why I decided to be brutal and replace the whole BOOT.INI as this would resolve all issues with it.

Your BOOT.INI was not copied, I believe CMDLINES was not set up properly, or switches in WINNT.SIF were missing. I am going to repeat all this step by step to make sure I haven't missed anything when was writing the post.

Thanks for your time

edit: Are you sure that CMDLINES.TXT and BOOT_REN.CMD were placed in the right subfolder \$WIN_NT$.~LS\$OEM$ ?

Share this post

Link to post

Share on other sites

I beleive this topic, as well as Grub4Dos README.TXT will give you the ideas how to launch Ghost.

About the slow boot- it's because your motherboard supports USB1.1 boot only, once control is passed to a USB2 driver it operates at it's full speed. Bart PE loads much more before USB2 driver is loaded (may be driver could made to load earlier?) than XP Setup.

My laptop Dell Inspiron 6000 supports USB2 boot and believe me XP setup loads in a flash, no more than 10-12 secs. I can't read the names of the drivers being loaded, whereas on the Gygabyte DS3P and Abit AN7 motherboards it's much much slower. Bart PE loads at horrible speed too on them.

Once USB driver takes control it's fast again.

I have written recently to Gigabyte support about that, in the first few responses they had no idea what I was talking about, once we made it clear no more responses ... for now. I also phoned tech. support in UK and the guy got the idea, but only adviced me to unplug all other USB devices and not to use front ports, no difference at all. Next to call is support in Taiwan

Update of BIOSes didn't do any change, for now.

I have just started a new topic in 911cd.net about that, you may keep an eye what is going on :

Share this post

Link to post

Share on other sites

About the slow boot- it's because your motherboard supports USB1.1 boot only, once control is passed to a USB2 driver it operates at it's full speed. Bart PE loads much more before USB2 driver is loaded (may be driver could made to load earlier?) than XP Setup.

Maybe Bart Lagerweij can make the USB2 driver being earlier effective in booting BartPE.

I have just registered in the CD forum, and will ask him there if this is possible.

I will also present there the relevant data of my motherboard and BIOS.

The motherboard of my Medion MD6100 laptop is equipped with:

BIOS Version PTLTD - 6040000

PhoenixBIOS 4.0 Release 6.0

Ver 1.00PARTTBL

BIOS Date 01/26/03

It supports apparently from the slow (30 minutes) booting of BartPE only USB 1.1 boot.

I have used a Apacer HT203 - 1 GB USB-stick which is very fast and

allows to install Windows XP from bootable USB-stick in only 30 minutes.

So I think in the GUI mode of the setup that USB2.0 is already effective.

In Windows XP the laptop supports USB 2.0

My MultiBoot USB-stick is ready and supports now also DOS with Ghost, and booting with BartPE.

According to our experience the USB port under DOS mode is run USB 1.1, thatâ€™s why the time takes so long.

Regards,

GBT TECH

Well, DOS and Bart PE... at least they are trying, hopefully some progress could be achieved.

When the new type of boot.ini with the 6 entries is present on the harddisk,

then after booting from the USB-stick, an option to Repair an existing Windows installation ( the 1 1 )

becomes available ( it is the second time when an option R is presented ).

I never use such a repair option, but when you select this option R to repair an existing installation,

the Windows repair takes place as expected, but with an unwanted effect on the USB-stick !

The result is that $WIN_NT$.~BT and $WIN_NT$.~LS folders are deleted and txtsetup.sif in the root directory

of the USB-stick is deleted as well !

...

That's interesting result, but I believe normal, actually we have never tried so far to use the repair option when SETUP uses different approach. The way now USB write-protect is implemented by MIGRATE.INF and oemHIVES.inf applies only for new installations only. Further investigation will be needed how to fix it, thanks for bringing this up Edited May 18, 2007 by ilko_t