Halfwalker

How to boot/install from USB key ?

486 posts in this topic

...I get the boot.ini menu and after having choosen textsetup, Win complains that it cannot find hal.dll...
I am puzzled, bootsectors seems fine, however Jaclaz should confirm that.

The only reason I can see is that your USB stick is NOT getting C:\ or first HDD during boot. It could be seen as superfloppy or something, but not hard drive. This way NTLDR passes boot routine to wrong path, producing this "HAL.DLL is missing...." or "NTLDR is missing" with the old guide. .

Probably that's why the other method failed too.

You may try to update your BIOS from HP site, and test with USB Legacy Mode Support option in Advanced Menu.

We may try a few tests to confirm that.

Once the stick is prepared change BOOT.INI on it to :

[Boot Loader]
Timeout=10
Default=multi(0)disk(0)rdisk(1)partition(1)\WINDOWS
[Operating Systems]
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="GUI Mode Setup Windows XP" /FASTDETECT
A:\SETUPLDR.bs="TEXT Mode Setup Windows XP 1"
C:\SETUPLDR.bs="TEXT Mode Setup Windows XP 2"
D:\SETUPLDR.bs="TEXT Mode Setup Windows XP 3"
E:\SETUPLDR.bs="TEXT Mode Setup Windows XP 4"

and see which option (1-4) will start Text Mode Setup.

If it doesn't start we may try Grub4Dos will report a marker file is, wich will be placed on USB stick, but thats for later.

0

Share this post


Link to post
Share on other sites

Hi Ilko and thank you for checking the files.

Concerning Bios version, my computer is quite recent (1 week) so I'am afraid I cannot find a newer Bios.

I think I noticed an option in advanced bios menu relative to USB Legacy mode but I have not investigated, I dont know well what it is. do you think it's worth toggling it?

For the test, I shall do it at night as soon as I am home.

Regards

Edit : I modified boot.ini as Ilko suggested. At first, I choose to boot from D: and Windows told it lacked some file. I then choose C: and Windows installation began. I dont know exactly what solved the point but it works. I have to come back to the previous situation in order to confirm the diagnostic.

Edited by happyusers
0

Share this post


Link to post
Share on other sites
Edit : I modified boot.ini as Ilko suggested. At first, I choose to boot from D: and Windows told it lacked some file. I then choose C: and Windows installation began. I dont know exactly what solved the point but it works. I have to come back to the previous situation in order to confirm the diagnostic.
You must have changed something else, originally BOOT.INI was pointing to C:\SETUPLDR.bs too. Good that it worked though :)
0

Share this post


Link to post
Share on other sites

I think the status of an USB device depends on its state at boot time : I had another experiment booting XP on the same computer from an USB hdd. The drive is recognized by the Bios only if the drive is switched off and on before switching the computer on. In any other case, the bus seems to be reset, the light of the drive turns off one second and the drive does not appear among bootable devices in the bios boot menu.

Perhaps its more or less analogous for USB stick and it happened to work once out of many times just because it was in the appropriate state to be recognized as bootable device.

Regards

0

Share this post


Link to post
Share on other sites

Hi,

I believe all your troubles are with BIOS, once you get it solved you will have no problems with the guide or the batch file.

Your system is new, many systems are shipped with old BIOSes, give it a try on HP web site for a new BIOS, it may help.

Have you tried with other USB stick?

My old motherboard Abit AN7 was playing funny with USB boot- if on shutdown USB stick is not present it loses boot order, on next boot with USB stick plugged it boots from hard drive, have to reboot and change boot order back to USB stick first. Had to keep stick plugged all the time in order to keep boot order.

regards,

ilko

0

Share this post


Link to post
Share on other sites

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

Edited by wimb
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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?

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.

0

Share this post


Link to post
Share on other sites

Hi,

Thanks for the feedback :)

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.

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.

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.

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 :thumbup

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

Edited by ilko_t
0

Share this post


Link to post
Share on other sites
@ilko_t

Cannot remember if we talked about this :unsure::

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? :blink:

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

0

Share this post


Link to post
Share on other sites

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? :-)

0

Share this post


Link to post
Share on other sites

These 3 files are modified by usb_prep.cmd. Not sure where this one came from:

migrate.inf

before installation:

uniqueid="C:\WINDOWS\CON"

after installation:

uniqueid="C:\WINDOWS\MOI"

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 :)

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? :-)

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

0

Share this post


Link to post
Share on other sites

@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. :unsure:

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

0

Share this post


Link to post
Share on other sites

@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!

0

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.