Doodoo

This is something I had tried a couple of days ago, but didn't seem to work. Now that the whole procedure works ok, I shall give it another try and see what happens. Hmm thanks for the details. I think I had modified the txtsetup.sif in the I386 folder so that might well be the cause of the problem ;-) By the way http://reboot.pro/8168/page__st__375#entry127841 seems to confirm something: This is more or less exactly what MSSTMake seems to complain about, when I try to use it to integrate WinVBlock. I think Shao, cdob and others have been looking at the problem, but there does not seem to be any real solution. Perfect If the whole thing works satisfactorily, and given the relatively limited changes that need to be made, would you consider making this as a new option in WinSetupFromUSB ? E.g. an IMG file instead of a USB drive could be selected from the drop-down menu (you'd still need to specify a (USB) boot drive though), all the rest would be identical. I believe this would bring many benefits (would make each setup entirely standalone and independant, e.g. XP, 2K3, W7, etc, etc... would all live in their own IMG so you can have as many flavours as you like, even on a single-partition USB stick)

Good news, GUI-mode setup completes without any problems, and everything works as exected (tested with a shared DriverPacks install, where the OEM folder still resides on the USB boot disk) Yep, and once again, all it takes to make it work is to edit the winmenu.lst entry for GUI-mode setup. Just before ls /shifthd.bat > nul || find --set-root --devices=hf /shifthd.bat I now add: map /WinSetup.img (hd) map --hook and just after shifthd.bat is called, add the following: find --set-root --devices=h /imgdrive.tag # get current root drive set /a RDSK=*0x82A0 & 0x7F In fact setup.cmd does not need to be changed, since the TAG file its looking for to establish the CD drive, is the folder WINSETUP/XPpSP3 which is located on the virtual drive, which is the correct place.

That is crystal clear ! Thanks for the consice yet very accurate answer ! It is immediately after the "Windows is loading/starting" message, just before the EULA or partition screen is displayed. No I haven't. For now I only stick to the latest development version that is ditributed as a virtual floppy in Wimb's latest XP_IMG package. The virtual floppy also includes a tweaked INF file to work around problems with the device manager. In fact my initial suspicion seems to be correct. This problem seems to be caused by the WinVBlock integration into the XP setup files. When I use a virtual floppy (standard WinSetupFromUsb option), then everything goes well. However, I would really like to have a flopyless solution, as I have problems on some machines when a virtual floppy is used (setup hangs at the very begining, on the message "setup is inspecting your hardware configuration") Like I said, I suspect that the BSOD 7E is caused by an incorrect integration in the XP setup files. Ideally I wish I could use MSSTMake, but there is something it does not like about WinVBlock (is it the INF file ?). So I used IntegrateDrv instead, but again, I might be doing something unconventional, as it has been designed to operate on the temporary Windows Installation directories ('$WIN_NT$.~BT' and '$WINT_NT$.~LS) but I point it to I386 instead. I haven't tried doing it manually, but I'm not sure if Shao's intructions include anything like this ? There are instructions to install WinVBlock indeed, but not (to my knowledge) any to integrate it in the Xp setup source files. Yep everything goes well till the first reboot. Even the migrate.inf works as expected, and when the partition list is displayed, the virtual drive where the setup source files are located is mounted as expected as U:\ Thanks for the info. This is the stage I'm looking at right now. I'll report soon on my findings ;-) Hopefully the whole thing will work. I can only see many advantages in having the source files in a virtual disk: copy and general mangement in much faster (only 1 file), updates are a lot easier (easy to mount the drive and change the contents, no need to rebuild an ISO), new drivers (including TXT-mode) can be integrated, possibly problems with Grub4Dos are avoided (not all ISOs are treated in the same way when mounted with Grub4Dos, but I am not aware of any such issues with IMGs)

OK so if I understand properly, the important thing is to actually make the target disk first, but not so much to make the USB (boot) disk last. All the other disks can pretty much be in any order, right ? E.g. if I wanted to install to a virtual disk, a mechanism would have to be introduced to make sure that target disk is first. Right ? This is really useful indeed ! Be design this will make sure that the virtual (source) drive is NOT first, so there is no need to shift it to a different position. Therefore when I install from a virtual disk, the procedure I described above should be adapted slightly: shifthd.bat and usbdrive.tag should also be moved from the virtual disk to the physical USB boot disk because the latter is still first in BIOS boot order, so it should be moved somewhere else. As a result, something needs to be sorted, because when shifthd.bat is executed, it sets RDSK to point to the physical USB boot disk instead of the virtual disk (where the setup source files are). So here is what I've done: just add a tag file in the virtual disk, .e.g imgdrive.tag. Then in winmenu.lst, just after shifthd.bat is called, add the following: find --set-root --devices=h /imgdrive.tag # get current root drive set /a RDSK=*0x82A0 & 0x7F Now the initial boot sequence works fine for me... Except I still get this BSOD 7E at the end of TXT=mode setup... Any ideas ?

In fact I've managed to work around the problem, with a solution which I find suitable (but others might see problems that I haven't seen), and which doesn't require deleting these lines. Initially I carry out the procedure described above, i.e. create a virtual disk, and run WinSetupFromUSB , using the advanced options and the "display drives on all interfaces, not only USB" checkbox. The next step is fairly simple: everything that does does not need to be in the virtual disk is deleted from there and moved to the physical USB stick (as it would be in the normal WinSetupFromUSB procedure). This includes the DPMS and the WinSetup/OEM folders (if present), and everything at the root of the virtual drive except shifthd.bat and usbdrive.tag Therefore, all the initial boot procedure is entirely happening on the physical disk, and the unmap & unhook do not interfere. Now, to complete the changes, all is needed is to modify the winmenu.lst, to map the virtual disk, at the right time. Just before: ls /shifthd.bat > nul || find --set-root --devices=hf /shifthd.bat I now add the following: map /WinSetup.img (hd2) map --hook (twice, in the two main winmenu.lst entries). I'm hardcoding (hd2) but that may have to be changed depending on your hardware config, Yep, i'm using WinVBlock. Yesterday I carried out a simple experiment, just using the WinSetupFromUSB feature where you can specify a F6 floppy (use the WinVBLock.ima included in Wim'b latest XP_IMG package). That worked ok, and install was successful (TXT-mode at least, didn't go further). However last night I tried something slightly more refined, where no floppy is needed, but where the WinVBlock is integrated into the XP source directly (with other mass-storage drivers). I think this is a great option, as it kills two birds with one stone, and allows installing XP from a virtual disk, but also to a virtual disk. Initially I tried to use MSSTMake but there seem to be an incompatibility with WinVBlock and it just doesn't like it. I could be just an INF file problem, but this is way beyond anything I can resolve myself... but if anyone is up for the challenge .... So I moved to a different tool: IntegrateDrv which I discovered here: http://reboot.pro/8168/page__st__400#entry148258 This one can integrate WinVBlock properly, but it has been designed to operate on the temporary Windows Installation directories ('$WIN_NT$.~BT' and '$WINT_NT$.~LS). I tried using it directly on the plain XP source (I386 directory) and it did complete without moaning.... But now when I try to install XP, at the very end of TXT-mode setup when "Windows Starts", I get a BSOD 7E. In QEMU because setup is pretty slow, I can clearly see the WinVBlock driver being loaded, but somehow something seems to be not working.... Anyone cares to try and reproduce ? Yep, I appreciate that things might be a little more tricky than I thought. However if the disk is mounted properly, migrate.inf should do the job, I can't see any reason why the virtual disk signature wouldn't be recognised ok. By the way, when shifting drives to make the USB disk last.... is it really the virtual disk that should be made last, or the physical one ? Can you quickly explain why ?

By the way this is a DriverPacks problem and should have been fixed long ago.... perhaps in the near future ?

Hi ilko, I'm trying to use WinSetupFromUSB in an unconventional way.... and I thought you might be able to answer some of my questions. Basically I have two different goals, but both relate to the very same problem. 1/ I would like to install XP/Vista/W7 to a virtual disk. When the OS doesn't natively support booting from virtual disk, this can be achieved with third-party drivers, e.g. WinVBlock or FiraDisk The only problem is that when booting from USB, this target IMG has to be mapped as a HDD in Grub4Dos, before the usual WinSetupFromUSB procedure starts. This conflicts with most of the winsetup.lst entries which start with something like "map --unmap=0:0xff && map --unhook && map --rehook" I'm not entirely sure what the purpose of this command is, but I have no doubt it's there for a good reason. I have tried deleting them all, and it just works.... but is that a satisfying solution ? What would be a nice and clean solution ? 2/ My second goal is kind of the counter-part of the first one, i.e. I would like to install XP/Vista/W7 from a virtual disk. As explained in your first post, WinSetupFromUSB supports Vista/Windows 7/Server 2008 setup to different primary partitions, which is therefore not possible on removable media (USB sticks). In order to work around the problem, I have tried the following: create a virtual HDD image, mount it with MS virtual storage driver (ImDisk not suitable), then (multi) partition-it, format it, and install whatever I want with WinSetupFromUSB , using the advanced options and the "display drives on all interfaces, not only USB" checkbox. This IMG can now be physically located on a USB stick, so it would in principle be possible to have Vista/Windows 7/Server 2008 setup (indirectly) on removable media. In the end the problem is still the same: this source IMG has to be mapped as a HDD in Grub4Dos before the usual WinSetupFromUSB procedure starts, which conflicts with most of the winsetup.lst entries, etc. etc... So same question again (which may or may not have the same answer as in #1) : What would be a nice and clean solution ? Using virtual source disk has (I think) many beneficial side effects: - When running WinSetupFromUSB, the virtual disk can be physically located on the internal HDD, which is a lot faster than on any USB stick. Transfering the IMG to the USB stick then doesn't take long (one big files, as opposed to thousands of small files) - The IMG can be transferred from USB stick to USB stick very easily. Presumably, WinSetupFromUSB has appropriate means (migrate.inf perhaps ?) to assign a given letter to the setup disk. I guess it wouldn't work to copy all the flat files on a different stick, (at least if it has a different signature). But it should work to copy the IMG (which contains it own signature !) Does it all make sense ?

Any idea what it would it take to work around the problem (if possible at all) ? Would a tweaked INF file solve the issue ? Or is it just wishful thinking ? Yes indeed it's not perfect... but the source code is available ! As usual it's a question of time more than a question of skill... but I suppose it could easily be integrated in WinNTSetup and improved at the same time :-) Yes I've experienced it myself... It just doesn't like that.... Perhaps the simplest solution is to keep MSSTMake as the default tool, and only use IntegrateDrv for problematic drivers such as WinVBlock ? (anyone tried FiraDisk ?)

In fact it can even be automated: http://reboot.pro/8168/page__st__400#entry148258 Is that something that could be integrated into WinNTSetup ? Seems like something useful and not only cosmetic.

Yes of course that's always possible and it's been reported to work. I didn't try it because I thought the driver integration would do the job.... Yes I've also come to that conclusion. I'm not an expert, and perhaps I'm not looking where I should, but when I look in $WIN_NT$.~BT on the boot drive, there is no sign of winvblk32.sys although I would expect to find it there.... Is there a fundamental problem to make the driver integration work with WinVBlock ? or is this some sort of bug / incompatibility ? At least can WinVBlock be integrated manually (if yes, how) ? Would the driver integration work with e.g. SATA drivers for physical hardware ?

There is certainly one INF file around, that is used by most people in a Virtual floppy, to install this driver during TXT-mode setup (F6). Are we talking about the same thing ? Fair enough, I appreciate it might be a big job for little benefit :-) However for now, I'm having problems with "the manual way". Please could you advise what might be going on ? So here is what I do. Within XP, I create a virtual HDD image, say XP.IMG (could be VHD as it's nearly the same thing). Mount it as a virtual drive with ImDisk. Then I configure WinNTSetup to use the virtual drive as a target disk, and to inject the WinVBlock driver ("Add Driver" checkbox). So far so good. Next, first reboot. Said XP.IMG is now mounted as virtual HDD by Grub4Dos. Chainload NTLDR on the physical HDD to start setup. TXT-mode setup goes well....till the phase "Windows is Starting". At this point it greets me with something like "the setup temporary files cannot be found and cannot continue". Any clue what the problem might be ?

Is it possible to do both ? E.g. to integrate the WinVBlock driver with the "Add Driver" checkbox, and also to integrate Driverpacks ? I know it might be a big ask, but would it be possible for WinNTSetup to automatically integrate WinVBlock / FiraDisk without any user intervention (other than tick a checkbox !), so that install to IMG / VHD is easily achieved for all OSes, including those that don't natively support booting from a virtual disk (XP, etc...)? On the same line, would it be possible to support VHD creation (Ctrl + Shift + V) when running on XP ? It may be not be as straightforward as on W7, but in the worst case it's always possible to create an IMG first (e.g. with Hddimage) and then to convert to VHD (e.g. with VHD Tool). I'm sure there is a billion ways to achieve the same result. Basically what I'm asking is whether it would be possible to offer the very same possibilities for XP as for W7, thanks to a few tweaks and workarounds ?

Except maybe if you want to use an answer file ? Or do you include it in the ISO itself (but I find that a little less flexible... Just a matter of personal taste really)

Have you tried cdob's trick ? Presumably this applies to a vanilla XP ISO: and this to a modified ISO with DriverPacks integrated: It would be very useful to know if this trick solves the problem in your case.

If you look carrefully, I think the device is working absolutely fine, there is no exclamation mark on the device icon. It is just an unknown device, and it comes with a question mark; XP does not know in which correct category it should put it (SCSI and RAID controllers). But it is really working fine and does not need repairing.