Jump to content

How to boot/install from USB key ?


Halfwalker

Recommended Posts

@jaclaz

About binifix4.cmd- used it from winnt.sif

[GuiRunOnce]

"%systemdrive%\windows\system32\undoren.cmd"

"%systemdrive%\windows\system32\binifix4.cmd C:"

I see the proper massages, answer YES to replace original boot.ini with boot.txt and get "the system cannot find the file specified. Could not find c:\windows\system32\boot.txt.", boot.txt is in root and looks ok, with all needed entries.

About boot sectors- still having issues after winnt32 is run and files put on stick.

Using Hitachi driver and format stick from XP no matter FAT16 or 32, copy ntldr, boot.ini and ntdetect.com - boots ok to boot.ini

Run winnt32 with parameters to put files directly on stick- cannot boot stick at all, no matter FAT16 or 32, nor if boot files copied before or after winnt32.

Interestingly, yesterday I managed somehow to make it working this way using FAT32, and the same routine, no flipping idea what it wants. Could try reverting bootsectors, but am tired of this.

Format stick with PEtoUSB- no matter seen as fixed or removable, use the very same procedure to prepare stick, both boot files copied before or after winnt32 and all work great.

MBR seems the same, geometry reported by PTEDIT32 is the same in all cases, bootsector changes the same way as when formated by XP and Hitachi driver used, but this time I get NO hangs at boot :wacko:

Anyway, will not keep trying format from XP, PEtoUSB does the job for me.

Another question- any idea what could be the variable path for the USB stick during GUI part?

I'd like not to copy boot_ren.cmd, undoren.cmd and binifix.cmd to system32 and edit txtsetup.sif, but rather put then on stick and call them directly from the relevant entries in winnt.sif.

Could be done easily if the same letter is assigned to USB stick, but to make it universal variable path would be nice.

@silacomalley- thanks for tip, I' ve been using Hitachi microdrive driver for a long time, never got permanent results about stick bootability, PEtoUSB and HP format tool always worked fine for me.

ilko

Edited by ilko_t
Link to comment
Share on other sites


I see the proper massages, answer YES to replace original boot.ini with boot.txt and get "the system cannot find the file specified. Could not find c:\windows\system32\boot.txt.", boot.txt is in root and looks ok, with all needed entries.

I'll look at it, maybe some "paths" are incorrect.

EDIT:

My bad, just temporarily change in the batch this:

:WriteBootIni 
CALL :attribs %source%
Copy boot.txt %source%
del boot.txt
ATTRIB !switches! %source%>nul
GOTO :EOF

to this:

:WriteBootIni 
CALL :attribs %source%
Copy %BOOTTXT% %source%
del %BOOTTXT%
ATTRIB !switches! %source%>nul
GOTO :EOF

I'll re-check the batch and add a kind of error check for this in next release. :blushing:

About boot sectors- still having issues after winnt32 is run and files put on stick.

Using Hitachi driver and format stick from XP no matter FAT16 or 32, copy ntldr, boot.ini and ntdetect.com - boots ok to boot.ini

Run winnt32 with parameters to put files directly on stick- cannot boot stick at all, no matter FAT16 or 32, nor if boot files copied before or after winnt32.

Interestingly, yesterday I managed somehow to make it working this way using FAT32, and the same routine, no flipping idea what it wants. Could try reverting bootsectors, but am tired of this.

It could be some kind of "glitch" in the FORMAT command.

I am sorry to say so, but to help in this I need you to do a lot of work :(, I need 2x2x2x3 series of bootsectors AND MBR's:

1) Bootsector FAT16 made by HP utility+MBR

2) Bootsector FAT16 made by PEto USB+MBR

3) Bootsector FAT 16 made by FORMAT with Hitachi filter+MBR (made with Disk Management?)

same as above FAT32

same as above FAT16 and FAT32 after the WINNT32 execution

Now, ALL the above but using BEFORE 1) 2) and 3) a hex editor or a direct disk access utility like dsfo/dsfi to write hex value F6 to first 100 sectors of the stick.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Would samples only from XP format (right click on drive and format) and PEtoUSB be enough? I already have most of the files needed, just need to do it with F6 written prior to format.

PEtoUSB formats only AFAIK in FAT16 or FAT16x, would that be enough too? When stick is formatted by it boots every time, no matter when boot files are copied, or whether Hitachi driver is used or not (PEtoUSB senses the difference).

Meanwhile- any ideas about

Another question- any idea what could be the variable path for the USB stick during GUI part?

I'd like not to copy boot_ren.cmd, undoren.cmd and binifix.cmd to system32 and edit txtsetup.sif, but rather put then on stick and call them directly from the relevant entries in winnt.sif.

Could be done easily if the same letter is assigned to USB stick, but to make it universal variable path would be nice.

Link to comment
Share on other sites

Would samples only from XP format (right click on drive and format) and PEtoUSB be enough? I already have most of the files needed, just need to do it with F6 written prior to format.

PEtoUSB formats only AFAIK in FAT16 or FAT16x, would that be enough too? When stick is formatted by it boots every time, no matter when boot files are copied, or whether Hitachi driver is used or not (PEtoUSB senses the difference).

Well, maybe yes, the problem might derive from the fact that, as has been reported by Dietmar on the famous Full XP on USB thread on 911CD, some utilities (NOT the HP one ;) ) could try to interpret data already on MBR and/or bootsector.

This is has been reported for XP's FORMAT command (in other words a partition formatted with XP's tools from scratch on a blank 00's or F6's drive may be different from one created over a previously existing one, as XP's FORMAT comand may "inherit" some of the previous data).

This has been proved beyond any doubt for floppies:

http://www.denispetrov.com/format144/

but about hard disks/USB devices I have no definite proof.

So the problem might arise by a combination of the previous format with the new tool used.

Another question- any idea what could be the variable path for the USB stick during GUI part?

I'd like not to copy boot_ren.cmd, undoren.cmd and binifix.cmd to system32 and edit txtsetup.sif, but rather put then on stick and call them directly from the relevant entries in winnt.sif.

Could be done easily if the same letter is assigned to USB stick, but to make it universal variable path would be nice.

We can search for a file and set the variable to the drive where the file is found, using "binifix.cmd" or another "tagfile" just like the common "WIN51.IP" is used in Windows Setup, but still we need a minimal batchfile in %systemdrive% or in another path for which an environment variable is already established.

Try the following add this one liner (save it as CHECKVAR.CMD):

SET >CHECKVAR.TXT

put it in \System32 and add this in winnt.sif:

[GuiRunOnce]

"%systemdrive%\windows\system32\checkvar.cmd"

"%systemdrive%\windows\system32\undoren.cmd"

"%systemdrive%\windows\system32\binifix4.cmd C:"

You should get a CHECKVAR.TXT file with all Environment Variables already SET when [GuiRunOnce] is run.

We can even make a self-deleting batch, though it's a bit tricky, it can be done.

I'll think some more about this issue and see if I can come out with and idea. :unsure:

jaclaz

Link to comment
Share on other sites

@jaclaz

About boot sectors- please find attached what I gathered, Before and After stands for before winnt32 is run, right after format, after is after winnt32. In some folders I put a file telling how the stick boots with this bootsector. F6 folders are for stick when first 100 sectors filled with F6.

About binifix4.cmd- works fine, you may now remove YES confirmation. How would it behave if script is run for a second time? I mean for repair install, script would be already run once, and for a second time when repairing.

As for the variables- I am trying to avoid modifying TXTSETUP.SIF at all, and call boot_ren.cmd, binifix.cmd and undoren.cmd from winnt.sif directly on stick, without copying them on hard disc.

I was expecting to have a preset variable like %installdrive% or something similar, but cannot find any.

Simple way to set such for the USB drive is to use PRESETUP.CMD, which if seen by GUI Setup will be launched before anything else.

Here we have 2 options

1. Set the variable if possible- I am not in this field at all, tried to substitute SET with SETX for permanent results in simple script like this:

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

Where folder MISC will be on stick, containing the files in question. Using SET works for this command prompt session only, using SETX should do it permanent, but seems the syntax is different and SETX with -m parameter works on

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

which I am not sure if it's ready at that point, before GUI setup continues.

2. My dumb and simplier way :D- use presetup.cmd to copy needed files in \system32 and call them easily from winnt.sif

ilko

MBRs_bootsects1.zip

Link to comment
Share on other sites

I'll check the bootsectors and let you know.

About re-running the batch, at first sight the only missing thing is a check for NOT duplicating the "Old Default" entry, it can be fixed allright, I'll do that and the other more general polishing as soon as I have time.

The PRESETUP.CMD appears to me an excellent idea, one could also try a POSTSETUP.CMD, as you already posted, it's not easily found info on WHEN postsetup.cmd is processed, but it seems like it is executed at the same point of GuiRunOnce:

http://blogs.msdn.com/pointofservice/

http://blogs.msdn.com/pointofservice/archi...stallation.aspx

though it seems that it is called by setuplauncher.exe:

http://msdn2.microsoft.com/en-us/library/ms912403.aspx

Check this oldie too:

http://www.msfn.org/board/index.php?showtopic=12566

(could we use devicesetpath.exe?)

Or maybe we could use Fedit.exe:

http://www.msfn.org/board/index.php?showtopic=48200&hl=

to edit WINNT.SIF on the fly?

jaclaz

Link to comment
Share on other sites

Why winnt32 changes bootsector? And what exactly it changes

That's syspart design: prepare install for another machine.

http://support.microsoft.com/kb/241803/en-us

In Windows 2000, the /syspart parameter for Winnt32.exe causes Windows 2000 Setup to copy all the necessary boot files and temporary Setup files to a drive and mark the partition as active. You can then install the drive in another computer, turn the computer on, and continue with Setup.
This goes for XP too.

Obviously winnt32.exe wasn't created for USB devices.

BIOS hard disk sort order maybe involved too.

Syspart work fine at internal drives.

C:\$WIN_NT$.~BT\BOOTSECT.DAT contain a boot sectors, string ntldr is edited.

Link to comment
Share on other sites

I have tried postsetup.cmd a while ago- could't get it launched, it may be launched only in Windows Embedded setup, or I didn't make it right. Will try again. It's supposed to run when GUI setup is completed, may be after T-1 "deleting temp. files"

Fedit.exe seems good idea, I'll study it further.

@cdob- I get what you are saying, it's just a few things which doent's make any sense to me, please reread the posts above about bootsect.dat and how winnt32 with /syspart changes bootsector, rendering the stick non bootable. If stick is formated by PEtoUSB this doesn't happen.

It could be BIOS involved, that's an idea, or as you are saying winnt32 gets confused about the USB device.

It doesn't create abootsect.dat nywhere, but makes boot.ini on stick pointing to it, despite the fact TXT part will be launched by the renamed setupldr.bin anyway. Could be the part when winnt32 is not designed for USB drives and gets confused.

If it was creating bootsect.dat with a patched bootsector on the USB stick it would've been nice, one external tool (jaclaz's makeBS.cmd) less. Not a big deal though, I am just studying it's behavior and reporting results here.

Another thing- please excuse me as I sometimes use the topic as a draft, usually when I get too many results in my head and need to clear and sort it up, and at that point I write some unnecessary and not proved results and conclusions. Just noone else to talk with about this matter :D

Will try not to :blushing:

Link to comment
Share on other sites

I tried to make an easy way to prepare everything, please find attached an archive, containing all needed files, please excuse my skills in batch scripts, there is probably a lot to be improved in this simple script:

Quick how to:

1. Extract files to a folder of your choice

2. Run PEtoUSB and format stick

3. Run PREPARE.CMD, and follow prompts, pauses are added for troubleshooting

4. When notepad opens WINNT.SIF, delete the whole [unattended] section and add/amend whatever you

That's it, please test it, any feedback is appreciated.

---------------------

Could someone have a look at PREPARE.CMD and add a section to delete the whole [unattended] section in WINNT.SIF, I had no idea how to do it. Feel free to add any improvements i.e. error checking or whatever is needed to polish it, that was beyond my capabilities :)

Some of the batches could be merged at later stage.

For testing prepare.cmd ImDisk comes so helpful :thumbup

Regards,

ilko

prepare_USB.zip

Link to comment
Share on other sites

@ilko_t

I like adding lines to TXTSETUP.SIF at a batch files.

This goes to a end user solution.

Free time: unfortunately I havn't tried hole solution yet.

I dislike possible changed boot sector still.

it's just a few things which doent's make any sense to me, please reread the posts above about bootsect.dat and how winnt32 with /syspart changes bootsector, rendering the stick non bootable. If stick is formated by PEtoUSB this doesn't happen.

Winnt32.exe goes back to NT4 times, there was no USB at all. Except some third party drivers.

Used at a not supported environment may get unexpected results.

Don't rely on a unsupported feature. You never know results.

By design Winnt32.exe /syspart makes a internal hard disk bootable.

MBR and boot sector are updated, if it is necessary.

Necessary according to Winnt32.exe rules. This rules may fail at USB.

A boot sector maybe valid by change according to Winnt32.exe rules.

The question:

Use a solution requiring a Winnt32.exe friendly boot sector?

Does all BIOS boot from a PEtoUSB boot sector?

Isn't PEtoUSB limited to FAT16?

My opinion:

A end user friendly solution dosn't require a winnt32.exe friendly boot sector.

You mentioned ImDisk already.

There are other Virtual Disk Drivers too.

What about?

create a virtual disk

winnt32.exe writes to this virtual disk

copy files to USB next

Granted, this may take longer.

But final USB stick may work at more machines.

Link to comment
Share on other sites

Totally agree with you.

What I tried in the previous post is to make the steps as few as possible. The way could be always extended to meet specific needs- use HP format tool or whatever makes the stick bootable, usage of virtual disks to avoid winnt32 change of bootsector and messing with the local BOOT.INI etc.

Just need more tests to get the most simple, reliable and universal way, your remarks are always on spot. I believe Jaclaz's analysis of the attached boot sectors will give more light on what is happening and what could be done.

Here is my short "to do" list:

1. Find a virtual disk program, simple to use and not residing in RAM, but rather in a file. Manage this program by prepare.cmd to automate the process.

2. A script, deleting the whole [unattended] section in WINNT.SIF

3. Tests with USB hard disks, I don't have any bootable enclosures to play with. Issues I foresee:

-Text Setup will see it as fixed, list as first, before SATA/IDE disks, rewrite bootsector, possibly render it nonbootable(worst case)

-boot files will be placed on USB disk, instead of the local hard disk, need additional checks in binifix.cmd, for proper entries in the local boot.ini and ntdetect.com/ntldr.

-drive letters may get messed

4. Merge some of the scripts for simplicity

Some of the steps takes me a lot of studying, batch scripting is something very new to me, bootsectors/MBR structure too, and I really feel uncomfortable to ask Jaclaz every second post please this, please that, because I can't do it on my own :blushing:

BTW over 50 000 hits to this thread and only 4-5 active posters :blink:

That was the other reason for the post above and prepare.cmd.

edit: 1) and 2) completed

edit2: 3) completed

Edited by ilko_t
Link to comment
Share on other sites

@ilko_t

I had a preliminary view at the posted bootsectors and MBR, and I am really puzzled, as I can see no difference that can justify the booting/not booting.

Maybe after all there is nothing connected to MBR/bootsector that causes this behaviour. :unsure:

I'll try building a couple of Virtual disks with those bootsectors and check them....

As cdob hinted, IMDISK, while being an exceptionally GOOD tool, is not suited to work with "full" HD images.

You'd better shift, at least for this kind of testing to Ken Kato's VDK:

http://chitchat.at.infoseek.co.jp/vmware/vdk.html

(optionally using my pseudo-GUI for it)

http://home.graffiti.net/jaclaz:graffiti.n...ts/VDM/vdm.html

You will need to use .pln file descriptors for geometry of drive, see my posts here:

http://forum.winimage.com/viewtopic.php?p=938

Some of the steps takes me a lot of studying, batch scripting is something very new to me, bootsectors/MBR structure too, and I really feel uncomfortable to ask Jaclaz every second post please this, please that, because I can't do it on my own

Fell free to ask at any time :), whether I can help you or not in a timely fashion it depends on the amount of free time I can set aside for this :rolleyes: , however, the more you study and learn and the more you will see how there is nothing "magic" about anything computer related, everything can be, before or later, tracked to a cause, and (hopefully) a workaround or fix, even for the queerest of "behaviours" can be found, if only the same thing could be applied to "real" world.

jaclaz

Link to comment
Share on other sites

@ilko_t

I had a preliminary view at the posted bootsectors and MBR, and I am really puzzled, as I can see no difference that can justify the booting/not booting.

Could I help with anything else? Give me any ideas what I could do on my side.
Maybe after all there is nothing connected to MBR/bootsector that causes this behaviour. :unsure:
What else could matter for bootability? Could it be something beyond MBR/bootsector?
You'd better shift, at least for this kind of testing to Ken Kato's VDK...
Thanks for it, prepare.cmd is redone, now it creates a virtual disk, formats it, makes WINNT32 to place all files there, amends the needed files and copies all on USB stick. Tested it with 2 XP sources- worked fine. A lot is to be polished, step by step. An archive containing all needed files is attached.
Fell free to ask at any time :), whether I can help you or not in a timely fashion it depends on the amount of free time I can set aside for this :rolleyes: , however, the more you study and learn and the more you will see how there is nothing "magic" about anything computer related, everything can be, before or later, tracked to a cause, and (hopefully) a workaround or fix, even for the queerest of "behaviours" can be found, if only the same thing could be applied to "real" world.

jaclaz

Thanks, the information coming from you is usually like a waterfall, one can hardly drink that much at a time :w00t:

edit1: _prepare.cmd updated, now deletes the whole [unattended] section in winnt.sif

prepare2.zip

Edited by ilko_t
Link to comment
Share on other sites

It's my turn to take a few days off-line.

@ilko_t

Could I help with anything else? Give me any ideas what I could do on my side.

Unfortunately I have no definite ideas at the moment. :(

I have re-checked the MBR/bootsectors you posted, and though I had no time to completely test them in VM's, I have reinforced my "feeling" that something else might be involved in the non-booting problem.

The only "strange" thing I have found is the number of reserved sectors on FAT16 formatted bootsector, 08, which is "normal" for FAT32, but that is normallly 01 for FAT16, at least on DOS and NT/2K formatted partitions, I need to try what happens under XP to make sure.

I hope to have time to do so on my portable while on vacation.

So, since the only other two things needed for booting (to an error message) are NTLDR/SETUPLDR.BIN and NTDETECT.COM, maybe there are some changes to them? :unsure:

Any other missing/wrong file should generate a definite error message.

Please post the error message you got (if any) when NOT booting, it could help on pinning down where the problem might lie.

The ideas by cdob, as always ;), make sense, it is possible that some part of WINNT32.EXE does not "recognize" the usage of the Filter, accessing the drive directly or whatever.

Another thing you could try could be using instead of the Hitachi Filter, the dummydisk.sys driver from CodeProject:

http://www.911cd.net/forums//index.php?sho...181&st=1954

jaclaz

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...