Jump to content











Photo
- - - - -

A (relatively) simple yet powerful way to installXP from USB


  • Please log in to reply
70 replies to this topic

#51 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 18 February 2011 - 09:28 AM

Thanks for your time and all the information you provide, Wimb !! :lol:

MassStorage TXT-mode drivers are needed in early mode of TXT-mode of XP Setup to allow you to detect your MassStorage device,
so that you can select where to install and let XP setup copy the files (otherwise harddisk would be invisible).
So this mechanism only loads more boot drivers that allow XP Setup to see your harddisk.

That is absolutely crystal clear, but I've always assumed (maybe wrongly) that as soon as the HDD can be seen by the TXT-mode part of XP setup, it will also be seen by the GUI-mode part.

For the timing of Install I can say that offering the Chipset and MassStorage drivers too late would mean
that XP Setup has in GUI-mode no access to your harddisk.

This also seem to imply that TXT-mode and GUI-mode parts of XP setup need different drivers. But imagine a plain vanilla XP setup (no driver packs included), to be installed on a SATA HDD. Isn't it enough to provide drivers with the F6 floppy ? I mean "enough" in the sense that both TXT-mode and GUI-mode parts of XP setup will use that very same driver.

Therefore it sounds to me as if integrating MassStorage TXT-mode drivers to XP setup is definately a must-have, but all the rest can be installed as late as desired (included post-install); however I understand that too early is not a good thing.

#52 wimb

wimb

    Platinum Member

  • Developer
  • 2574 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 18 February 2011 - 11:15 AM

After using DriverForge then the DevicePath settings of KTD are lost,
since DriverForge will Set DevicePath to what it needs.
It is a good idea to Reset DevicePath to the KTD values by using the DevicePath_Reset_KTD.reg tweak

I found also that in some cases intelppm service was loosing its preferred Start=3 value
e.g. Start=1 was installed at Intel machine, giving BSOD 7E when booting on AMD machine.

UsbBootWatcher can be used to keep the Start=3 value
Add rules for intelppm service in UsbBootWatcher.conf

Both changes will be added to next version of IMG_XP package.

#53 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 18 February 2011 - 12:53 PM

After using DriverForge then the DevicePath settings of KTD are lost,
since DriverForge will Set DevicePath to what it needs.
It is a good idea to Reset DevicePath to the KTD values by using the DevicePath_Reset_KTD.reg tweak

Isn't that something which should ideally be fixed in DriverForge itself ? It should update but not overwrite DevicePath, shouldn' it ?

I found also that in some cases intelppm service was loosing its preferred Start=3 value
e.g. Start=1 was installed at Intel machine, giving BSOD 7E when booting on AMD machine.

UsbBootWatcher can be used to keep the Start=3 value
Add rules for intelppm service in UsbBootWatcher.conf

This has also been reported here: http://reboot.pro/98...post__p__121965 [EDIT: no, I was completely wrong, this is a different issue]
Again, isn't that something that should ideally be fixed in UsbBootWatcher ? Unless I misunderstand the cause / problem / solution :lol:

Edited by Doodoo, 18 February 2011 - 01:52 PM.


#54 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14773 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 February 2011 - 01:13 PM

Again, isn't that something that should ideally be fixed in UsbBootWatcher ? Unless I misunderstand the cause / problem / solution :lol:

Usbbootwatcher is a tool in your hands.
It has a configuration file to tell it WHAT it should do.
Choose a configuration, but choose it wisely.
http://www.imdb.com/...uotes?qt0357926

Grail Knight: But choose wisely, for while the true Grail will bring you life, the false Grail will take it from you.

Here:
http://www.911cd.net...pic=22473&st=23

B)
Wonko

#55 wimb

wimb

    Platinum Member

  • Developer
  • 2574 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 18 February 2011 - 01:45 PM

Isn't that something which should ideally be fixed in DriverForge itself ? It should update but not overwrite DevicePath, shouldn' it ?

Yes, I agree, but DriverForge 4.5.4 overwrites DevicePath with what it needs and leaves it like that ....
So it is really advised to Reset DevicePath, so that XP default can make use of the DriverPacks store in WINDOWS
I don't know if it is the same in later version 5.0 :ph34r: Have to check that ....

This has also been reported here: http://reboot.pro/98...post__p__121965
Again, isn't that something that should ideally be fixed in UsbBootWatcher ? Unless I misunderstand the cause / problem / solution :dubbio:

Well I was a bit to early, because I think intelppm Start=3 in UsbBootWatcher.conf does NOT work reliable ...

First I install XP on AMD machine and then use USB_XP_Fix.exe to fix XP Image file copied to USB.
When I next boot from USB on Intel machine then on Install of CPU the intelppm Service is set to Start=1
I need to change that to Start=3 since otherwise next boot from USB on AMD machine will give BSOD 7E

I can use registry tweak online or use USB_XP_Fix.exe again offline to set intelppm Start=3

Anyway that is also something that needs more attention ....

;)

#56 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 18 February 2011 - 06:42 PM

...I've always assumed (maybe wrongly) that as soon as the HDD can be seen by the TXT-mode part of XP setup, it will also be seen by the GUI-mode part...

I believe that in the text-mode portion of Windows XP/2003 installation, you are booted from the installation medium. I believe that in the GUI-mode portion of Windows XP/2003 isntallation, you are booted from the installed-to medium. I believe that "F6" drivers (drivers loaded during the text-mode portion) will be injected into the Windows installation, though I am not sure of the criteria (all F6 drivers or just some). This is, in fact, the nature of a current outstanding bug with WinVBlock: When the text-mode portion prepares the Windows installation for the GUI-mode portion, it injects the WinVBlock driver with a "wvblk32" service name, instead of the preferred "WinVBlock" service name. Disclaimer: I could be wrong.

#57 wimb

wimb

    Platinum Member

  • Developer
  • 2574 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 19 February 2011 - 07:37 AM

I did some analysis of the situation just after TXT-mode has finished and before GUI mode has to begin.

The WinVBlock driver is injected in WINDOWS\OemDir which has oemscs01.inf
and is specified in [OemInfFiles] section of WINDOWS\system32\$winnt$.inf
$winnt$.inf contains in fact the setup info as specified in winnt.sif file plus this [OemInfFiles] section specified in OemDrivers = "OemInfFiles"
WVBlk32.Sys is already present in WINDOWS\system32 and registry contains wvblk32 Service

TXT-mode boots with all MassStorage drivers to support all kind of hardware and
then Hardware detect (NTDETECT.COM) determines which drivers can be used and presents what partition can be used.
Only the needed MassStorage drivers are copied in second part of TXT-mode to WINDOWS\system32\drivers
GUI-mode is then capable to boot since it has the required MassStorage and WVBlk32.sys driver available.

So it means that the C:\WINDOWS\DriverPacks store as made by the KTD option,
is the way to support all kind of hardware, since in that case all MassStorage and Chipset drivers are available for XP to adapt to new hardware.

#58 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 21 February 2011 - 10:10 AM

I believe that in the text-mode portion of Windows XP/2003 installation, you are booted from the installation medium. I believe that in the GUI-mode portion of Windows XP/2003 isntallation, you are booted from the installed-to medium. I believe that "F6" drivers (drivers loaded during the text-mode portion) will be injected into the Windows installation, though I am not sure of the criteria (all F6 drivers or just some).

Many thanks Shao for the clarification :lol: This is more or less the concept I had in mind, but it's easy to live all one's life with misconceptions ;-)
Bravo Wimb :confused1: I've seen you keep up the great work and have come up with yet another release of IMG_XP !!!

On a completely different note, I just wanted to mention that the menu.lst in my very first post should perhaps be slightly modified, when installing XP to an image file. On some machines, the wanted partition in the mounted image does not get assigned driver letter C.
In this case Karyonix has suggested a simple workaround here

The following can optionally be added (in the already optional part of menu.lst), after map /XP-1.img (hd0)

# Hide other disks, so partition in virtual disk will get C letter. 

map --harddrives=1

It would have been nice to edit the first post but for some reason it won't let me.... :smiling9:

#59 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 21 February 2011 - 11:56 AM

On some machines, the wanted partition in the mounted image does not get assigned driver letter C.
In this case Karyonix has suggested a simple workaround here

The following can optionally be added (in the already optional part of menu.lst), after map /XP-1.img (hd0)


# Hide other disks, so partition in virtual disk will get C letter. 

map --harddrives=1

I've seen Wimb uses this bit of code instead in this menu.lst:

checkrange 0x80 read 0x8280 && map (hd0) (hd1)

checkrange 0x80 read 0x8280 && map (hd1) (hd0)

I know all the information is available if I look a bit carrefully, but without asking to be spoon-fed, can anyone advise as to what this bit of code really does ? Does it replace Karyonix's suggestion ? Or should come on top ?

#60 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14773 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 February 2011 - 12:02 PM

I know all the information is available if I look a bit carrefully, but without asking to be spoon-fed, can anyone advise as to what this bit of code really does ? Does it replace Karyonix's suggestion ? Or should come on top ?

The code does exactly what is written in it.

If the contents of 0x8280 is 0x80, then map (hd0) (hd1).
If the contents of 0x8280 is 0x80, then map (hd1) (hd0).

It exchanges drives on a condition (location 0x8280 being equal to 0x80), see here:
http://reboot.pro/9733/
Something else (more) here:
http://reboot.pro/12449/

This is not categorized as "spoon-feeding" but rather in "your google-fu is low, my young padawan" :dubbio:.

:cheers:
Wonko

#61 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 21 February 2011 - 12:17 PM

The code does exactly what is written in it.

If the contents of 0x8280 is 0x80, then map (hd0) (hd1).
If the contents of 0x8280 is 0x80, then map (hd1) (hd0).


I did work out this bit by myself... But the thing is, I had no idea what the contents of 0x8280 was supposed to mean or represent. Hence my question.
I suppose this is what I really needed to know, thanks Wonko.

Therefore, if my understanding is correct, it looks like this bit of code can just replace Karyonix's as suggested above, unless it only partially solves it when several HDDs are connected.

Edited by Doodoo, 21 February 2011 - 12:21 PM.


#62 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14773 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 February 2011 - 12:39 PM

Therefore, if my understanding is correct, it looks like this bit of code can just replace Karyonix's as suggested above, unless it only partially solves it when several HDDs are connected.

I don't see a "therefore" connection. :dubbio:
That code is used, mainly in the case of USB booting, to re-establish "normal drive order" for the first internal drive.

When you boot "normally", the first internal hard disk is (hd0) or disk 0x80 or disk 128.
If you boot from USB it is likely that the USB device becomes (hd0) and internal HD is "shifted" to (hd1).
(subsequent internal hard disks -if any - are also "shifted" by one).
The mentioned code will re-set the internal first hard disk to (hd0) and set the USB device to (hd1), leaving all other internal hard disks - if any - as they were.

This:
map --harddrives=1
should tell the BIOS that ONLY disk (hd0) exists.

:cheers:
Wonko

#63 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 21 February 2011 - 12:57 PM

I don't see a "therefore" connection. :dubbio:

Hmmm yes and no.
As you explained, the code will re-set the internal first hard disk to (hd0) and set the USB device to (hd1), leaving all other internal hard disks - if any - as they were. So the mounted disk image (where XP is to be installed) will appear as C: if it was set to (hd1) originally. When that is the case, the problem is solved... Doesn't this establish a connection ?
But to be fair, I guess it's unlikely the mounted disk image would appear as (hd1) since any physical HDDs would have already been set to that. But again I really don't know much about these things and i'm just guessing here.

This:

map --harddrives=1
should tell the BIOS that ONLY disk (hd0) exists.

To cut a long story short it seems to be the safest thing to do, to make sure the disk image appears as C:

#64 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14773 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 February 2011 - 01:42 PM

To cut a long story short it seems to be the safest thing to do, to make sure the disk image appears as C:

Actually, if I get right what is the intended result :cheers:, a migrate.inf file might give even safer results. :dubbio:
http://www.911cd.net...showtopic=19663
(or a direct offline registry injection in the \dosdevices\)

:cheers:
Wonko

#65 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 21 February 2011 - 02:01 PM

Actually, if I get right what is the intended result :cheers:

The whole point is that when installing XP to a disk image (not a physical disk), you want to make sure it will be assigned letter C (well ok, i know we should talk about paritions within the disk image, but you get the idea).

a migrate.inf file might give even safer results. :dubbio:

I can't argue with that. I don't really understand how this thing works for now. Most importantly, I don't see how it could be used with the install method suggested in this thread, i.e. direct from ISO located on USB, because at first sight I understand migrate.inf must be in the ISO.

Edited by Doodoo, 21 February 2011 - 02:40 PM.


#66 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14773 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 February 2011 - 02:43 PM

I can't argue with that. I don't really understand how this thing works for now. Most importantly, I don't see how it could be used with the install method suggested in this thread, i.e. direct from ISO located on USB.

Yes, I am not sure what the "goal" is. :cheers:

If I get it right the thread is to install from .iso (on USB device) to internal hard disk.
Then you are doing a "spin-off" to install from .iso (on USB device - WHY?) to hard disk image.

Since the target is anyway a hard disk partition (real or within the .img), and the "source .iso" is NOT "vanilla" you can add a migrate.inf to the source and then "force" a disk signature on the target device, or use grub4dos to "patch on the fly" the added migrate.inf with the actual target disk signature.

The good thing about a migrate.inf for a single partition is that it's length is fixed, so it can be easily manipulated by grub4dos commands as long as such a file does exist inside \$WIN-NT.~BT\ :dubbio:

:cheers:
Wonko

#67 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 21 February 2011 - 03:06 PM

The least I can say Wonko, is that you get me to think really hard :dubbio:

If I get it right the thread is to install from .iso (on USB device) to internal hard disk.
Then you are doing a "spin-off" to install from .iso (on USB device - WHY?) to hard disk image.

At first sight it might seem really odd to install from USB to hard-disk image.... But the thing is I don't want to mess with plenty of partitions on my HDD, so using disk images is definitely great. Why install from USB ? Because I happen to carry out my experiments on a notebook without an optical drive. I have also tried to install from ISO (on HDD) to disk image (on HDD), and funnily enough it's not really faster than from ISO (on USB stick). But the portable aspect of the USB version is very convenient I think.

Since the target is anyway a hard disk partition (real or within the .img), and the "source .iso" is NOT "vanilla" you can add a migrate.inf to the source and then "force" a disk signature on the target device, or use grub4dos to "patch on the fly" the added migrate.inf with the actual target disk signature.

The source is not "vanilla" , but one (implicit) idea is that you don't want to regenerate the ISO every day.... For instance, having the DriverPacks outside the ISO is very convenient from that point of view (OK, you have to make a new ISO when you want to update the txt-mode mass-storage drivers).
Conceptually, your suggestions to force the disk signature or to patch the migrate.inf with gru4dos make complete sense to me. But in practise we're getting to the limits of my free time to experiment :cheers: (I know you'd do it in 15 seconds, but I'm not as familiar as you are with all this... It would take me quite a bit more time). For now I think a good effort / result ratio consists in hiding all disks but the target one (physical or image).

#68 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14773 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 February 2011 - 03:19 PM

The least I can say Wonko, is that you get me to think really hard :dubbio:

Sure :), that's EXACTLY the idea. :smiling9:

The source is not "vanilla" , but one (implicit) idea is that you don't want to regenerate the ISO every day....

Sure :), but nothing prevents you from adding to it a migrate.inf file filled with (say) 512 spaces.
You should know how to create such a file without emac :cheers:
:rofl:

You just mark it mentally "reserved for future use"....

Conceptually, your suggestions to force the disk signature or to patch the migrate.inf with gru4dos make complete sense to me. But in practise we're getting to the limits of my free time to experiment :cheers: (I know you'd do it in 15 seconds, but I'm not as familiar as you are with all this... It would take me quite a bit more time). For now I think a good effort / result ratio consists in hiding all disks but the target one (physical or image).

I don't think you were given a timetable and certainly NOT a deadline. :w00t:
Take your time, have fun, experiment whatever you like when you have time to do so. :)

:cheers:
Wonko

#69 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 21 February 2011 - 03:29 PM

Sure :cheers:, but nothing prevents you from adding to it a migrate.inf file filled with (say) 512 spaces.
You should know how to create such a file without emac :cheers:
You just mark it mentally "reserved for future use"....

If XP setup can live with a blank migrate.inf, then it's certainly worth adding it to the ISO. Then you're free to overwrite it or not.
Just for the record, I can't help showing off some emacs skills.... Open emacs, CTRL-u 512 [SPC], finished.... Other ways are fun but not as short :dubbio:

I don't think you were given a timetable and certainly NOT a deadline. :)
Take your time, have fun, experiment whatever you like when you have time to do so. :smiling9:

Most likely my future free time (between nappies, bottles, and work) will be spent playing with Win 7. I have seen quite a few threads related to setting up Win7 from ISO (at least this one,and that one, and also that one), but at this point I don't understand the conclusion...
Can anyone tell me if install from ISO (on USB or HDD) to disk image works ? Not knowing anything about Win7 doesn't help, given the number of new tools to be aware of, and ideally master...

Edited by Doodoo, 21 February 2011 - 03:34 PM.


#70 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 24 February 2011 - 09:50 AM

Just for the record, it looks like the install method in this thread may not work 100% of the time, on tricky machines....
But it has been reported here that remaining problems can be fixed by adding in presetup.cmd the following code:


start /b "Open handle to virtual CD-ROM drive." pushd "%CDDRIVE%"

immediately after the (already patched) line, see post #1:


if not defined CDDRIVE (goto EOF)

I haven't had any problems myself, but I'd be happy to hear from anyone who was able to solve all problems that way !

Edited by Doodoo, 24 February 2011 - 10:01 AM.


#71 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 24 February 2011 - 03:08 PM

I did some analysis of the situation just after TXT-mode has finished and before GUI mode has to begin...

Very nice analysis! Thanks!




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users