I have a problem with all this its one thing being directed to various threads but it obscures the problem. that being when boot.wim loads to ram it doesnt 'see' the cd from g4d where it loaded from surely thats the issue or is it me? It ,sees all the physical drives trying browse or repair options.
c'mon Wonko or Jac dare i say?

Had a similar problem with a sdi.img until this was added it didnt know where it was. using diskpart
Select volume=c
assign= noerr
exit

Ive also created a .vhd of the files on the .iso and at the shift F10 stage of the iso load
Diskpart
list volume
select vdisk file=(vol):\xxxx.vhd
attach vdisk
This also works
Is there any mileage in here somewhere ?

I really dont know perhaps this could be utilised to create a seamless install still toying with ideas myself.
ie memdisk initrd xxxx.vhd dont know.Thats why i threw the ball out here for talented people to play with.

edit: just tried that
it loaded ok but
it told me to select a proper boot device or insert boot whatever and press a key still worth a shot!

or perhaps the boot.wim loading and a script 'selecting' the 'install.wim' .vhd ? dunno
or maybe or maybe the iso with install.wim stripped out and a install.vhd . using boot. wim && xxx.vhd ????????
first part executes the vhd loads?

This thread is about booting off an UNtouched Windows 7 .iso mapped by grub4dos and solving the consequent normally happening problem with the "missing" and "required CD/DVD".

Do you think that experiments with .vhd's (mapped with grub4dos or memdisk or mounted through DISKPART) belong here?

Or maybe you could start a new thread DETAILING what you did (and the results you got) and the actual output?

More generally, it is very difficult (for me at least) to understand your posts in this thread, last three are:

a pointless quote of last post of steve6375

a partial, incomplete report of something that you tried and reportedly works but that is missing the preamble (WHAT exact steps you did BEFORE using diskpart, HOW you created the .vhd, etc., etc.)

a partial, incomplete report of something that you tried, missing as the above any detail to help understanding it, and an even more confuse description of the problem you got when attempting this.

I would personally appreciate much more your nice ideas and contributions if I could understand them, and I am pretty sure that another number of members would be interested to them but face the same problem.

It's not like telegrams, you don't pay a fee "per word" , if you could expand on both the reports and on the ideas it would be really great.

You also have to take into account how for a lot of members, English is not first language and a couple of words more sometime help a lot in understanding each other.

yes i appreciate this thread is about booting an untouched .iso so perhaps my ideas dont belong here.
i created the vhd in win7
disk management (computer management) using the files extracted from a win7 install .iso and managed to boot completely into the install enviroment no cd error etc fully functional without using imdisk.
by using firstly the iso with install.wim stripped out and then diskpart as described above selecting and attaching the vhd file which had boot.wim stripped out.
My initial post was about, could this idea be expanded any further,so there would be no need to use imdisk or the .iso but just the .vhd file containing the full contents of the installation .iso
thanks

I dont see an immediate solution because boot.wim has to be loaded into ram and find the install.wim but perhaps, big question, there is a way. By the way what I did is only the same as the imdisk solution.
The problem as I see it is that boot.wim has to be up and running and then find install.wim which is not truly 'mounted' by g4d i'm just trying to find another workaround as defined by tutorial 31 rmprep and why not. human endevour,
alcoholic
edit: i can see the problem but not the solution, said the alcoholic looking into his glass. the glass being both the problem and containing a solution.
Also all experiments belong here whats the point of the internet if we cant have an international community seeking the answer to a 'problem' Louis Pasteur would have regarded you as a heathen or einstein for saying that!
Do you look at a lift (elevator) and expand your mind into relativity ?
No you don't its an open forum even the insight into DNA was an aside (for non english cousins intuition. ask J darent mention his name.
its the definition of the problem that will provide the answer. The Truth isOut There.

You could always boot from the unmodified iso file, then use shift+f10 to get the command prompt, then run GImageX - all it needs is wimgapi.dll which is in all versions of Windows 7 and Vista (no need for WAIK) and so could be in the same folder on the USB boot drive (if not already in the X:\windows\system32 folder). Why use Setup to copy the wim image over to the hard disk when you can use GImageX instead? 7z also supports wim file extraction (though maybe does not fully support all aspects??).

yep steve i have it working from .vhd but only after the initial load of boot.wim via the iso actually its been converted to a .ima thats because its the same as the imdisk solution Diskpart makes the files tenable.
ive been trying to make it seamless no user intervention, i.e trying i stress to get boot.wim to load and then find install.wim i have done the same as you but using Diskpart>
Try it create a .vhd of the files on the .iso and keep the iso boot with g4d normal i.e, as an image file in my case, or the iso if you want, boot no disk swaps and in shift f10 cmd prompt do as mentioned above and it works perfectly ha ha> to define the vhd file as the imdisk file is available to boot.wim loaded in ram. I feel there may be a way to load boot.wim and make install.wim available ive tried memdisk and various,

probably a bit mixed up by now with various results the vhd image as you know has to be contiguous but also on a ntfs f/s im trying to get boot.wim to load from g4d no problem really but tricky second part make install.wim available>

yes i know the menu.lst (LST) is all over the place so dont bother commenting part of the thought process.

When WinPE 2/3 boots (i.e. Win7 or Vista setup DVD) it loads WinPE. I **think** WinPE looks for an \Autounattend.xml file and if it has a 'PE' section it will use any settings in that section. If this is so, then if we place a 'RunSynchronous' section in the AutoUnattend.xml, it could be used to run a cmd file which 'mounts' the ISO file on the USB boot drive - say using ImDisk. That way the whole ISO would be sitting as a drive letter just waiting to be found by Setup when the user got to the point where it tries to find \sources\install.wim. This would mean that the ISO would not have to be changed in any way and it would all work without any extra user SHIFT+F10 stuff.

Only problem I can see is how do we path the RunSynchronous command so it runs a cmd file from the USB boot drive as the USB boot drive could be any letter?? One idea for this would be to have multiple entries in the RunSycnhronous section - C:\LoadISO.cmd in one, D:\LoadISO.cmd in next entry, E:\LoadISO.cmd in next entry - etc. (though there is a danger of Setup erroring out for a missing file???)

LOADISO could have a menu asking the user which ISO to load - then we we can have multiple ISOs on the same USB drive. The user adds an ISO by editing menu.lst and LoadISO.cmd.

So no modified ISOs, no WAIK, no bootmgr. Just copy ISO + bunch of files (mostly ImDisk + few cmd files + Autounattend.xml) to a USB Flash drive.

Then add a menu.lst for the ISO of your choice (must be Vista or later) and add a choice to a CMD file on the USB drive. The same CMD file will do both 64-bit and 32-bit ISOs.

From the users point of view it is:1. Choose which ISO to run from grub4dos menu list2. WinPE loads from the ISO - Setup starts to run - choose Language/Time/Currency/Keyboard type - click Install Now3. Choose again the same ISO again from WinPE text menu4. Carry on in normal way

Now if only there was some way to pass the name of the ISO via grub4dos ( (rd) perhaps?? ) to the command console session.. If I set the name of the ISO in (rd) using grub4dos menu entry and then loaded ImDisk - could it see that (rd) drive and read the iso filename, then mount it in ImDisk - job done and only one menu.lst entry to edit for each iso. Anyone know how to do this?

AFAIK firadisk/winvblock do have *something* that passes the .iso file name to the driver.

Now if only there was some way to pass the name of the ISO via grub4dos ( (rd) perhaps?? ) to the command console session.. If I set the name of the ISO in (rd) using grub4dos menu entry and then loaded ImDisk - could it see that (rd) drive and read the iso filename, then mount it in ImDisk - job done and only one menu.lst entry to edit for each iso.

BUT I am not sure I get it. Can you try to better explain the requisite?I.e. cannot a "tag" file of some kind on the actual USB device be used (containing the name of the .iso)?(or simply parsing in CMD the menu.lst)?

The ISO boots to Setup - runs a cmd file which displays a menu ('which ISO do you want') - user chooses the same ISO again so we can specify that ISO filename for ImDisk to map to a virtual drive letter - then quits command console session and goes back to user Setup GUI as usual.

So I need a way to pass the name of the ISO selected in the grub4dos menu to ImDisk when the command console session runs automatically during GUI Setup.

One way is to use write command in GRUB4DOS to write ISO file name (or the whole line that call imdisk) to existing cmd file in UFD.

Another way is to load a small disk image with cmd2 file in it to RAM and write ISO file name to it. Use FiraDisk or WinVBlock loaded by cmd1 to access RAM drive. And your cmd1 in UFD can call cmd2 in in RAM drive that call imdisk with ISO file name.

Another way is to use FiraDisk or WinVBlock loaded by cmd to access iso with parameter passed from GRUB4DOS in a small RAM drive.

Another way is to modify ImDisk from source code to include the code that detect GRUB4DOS and read data.

I've been digging in the same direction past few weeks and can confirm that way works.

I am booting small ISO containing only bootmgr, BOOT folder and SOURCES with only boot.wim inside to start the Setup, with Autounattend.xml in root of the USB disk invoking AutoIt program which loads imdisk stuff. Setup finds and uses the imdisk mounted large ISO.

Why small ISO- could be easily defragmented or if fragmented, faster to load the whole in memory. Another reason are the systems where BOOTMGR complains about missing WINLOAD.EXE if those files are on the USB drive.

Past few days I am trying to resolve the following issues:

1) What do we do if the ISO contains custom unattend.xml?- Merge it with set of autounattend.xml files in advance?- Merge the XML files using XSLT, does Setup read that?- Launch new Setup.exe /unattend:custom_unattend.xml? Using RunSynchronousCommand in windowsPE pass to open CMD and start x:\Setup.exe leads to commands in Autounattend.xml run once again (Win7 32 bits), when launched with /unattend switch I don't see settings in the file specified applied, still very preliminary tests...

2) The combo Dell Latitude E6400 + Server 2008 (6001.18000.080118-1840_x86fre_Server_en-us-KRMSFRE_EN_DVD.iso) gives me serious headaches, USB stick (2GB Buffalo, removable) is not visible once PE pass is loaded, diskpart does not see the disk. Replug the stick, diskpart-->rescan and we got it, with drive letter, but autounattend.xml was not found when Setup searched for it and hence not used.IDE/AHCI/IRRT mode in BIOS doesn't change behavior.Hot reboot and BIOS won't even find the USB stick anymore, nor the preinstalled Win 7 on the internal disk does. On cold reboot everything goes back to normal, or replugging the stick. Bugger... Just got 2008 R2 SP1 and will test what happens with it. Same scenario works just fine using vanilla Windows 7 32 bits.

3) Would Autounattend.xml be found and used if in root of a USB fixed disk? Has anyone tried? MS article mentions removable media. Another interesting part in this article:

If an answer file is found in one of the valid locations, it must include a valid configuration pass. If an answer file is found and it includes no settings for the given configuration pass that is running, that answer file will be ignored.

Does that also mean that if that answer file is ignored, next one would be used if contains valid settings for the particular pass?

Another important part:

Windows Setup automatically searches for an answer file every time a configuration pass starts.

Grub4dos emulated floppy doesn't seem to help, from what I've observed search for Autounattend.xml is performed once PE is fully loaded.

4) As for passing ISO name to imdisk- could we write by grub4dos to an address in memory which won't be wiped out by PE, then read it if using AutoIt script or similar, then pass it as imdisk iso name? What that address could be?

So it depends on where the image has it's unattend. Also, Setup will look for the applicable section only - e.g. when booting to WinPE it looks for a valid WindowsPE section - if it does not find one it will keep looking in other locations until it finds one.So the only section that will be overriden is the WinPE section even it it does find the Autounattend on the USB drive first.

When I tried Vista, it did not load the Autounattend.xml until after the language selection screen.

To be honest, I am not really interested in modified ISOs. If you have gone to the trouble of modifying them, why not just store the images in a WIM file and Apply them to the target hard disk using ImageX, GImageX etc. after preparing it with a scripted Diskpart?

I will post another (!) tutorial on what files I used, etc. but here is the Autounattend.xml I used:

Steve, I got that, posted similar link and read it many many times. Imagine the scenario- user has own unattend.xml. It has windowsPE pass, custom drivers or whatever. If using Autounattend.xml to launch imdisk stuff how would that custom unattend.xml be used for windowsPE pass? I am not worried for the other passes.

As for the modified ISOs- I am also not in that, at all, not in WAIK either. Reasons why I opt for that option were explained above- easy defragmentation if needed, quick load with map --mem if fragmented and no chance to hit RAM limit with 140-170 MB ISO.

Download 5 large ISO files. Transfer them to USB. How many of them will be fragmented?Defragmenting them once USB flash is pain, there is also disk space restriction.

If you end up with large fragmented file for one or another reason, map --mem is not the best option, it may not fit in RAM, or may take ages to load.

Creating small ISO is quick and programmable, extract a few files with 7-zip and put them in ISO with mkisofs, no need of WAIK or dism either. Personal choice, not that important for the issues discussed, though.