13 replies to this topic

[PMilligan]

I hope this is the right forum - this seems a Winbuilder issue to me ?

I have a PE I've built - W7 and 'the kitchen sink' - all the GENA stuff, etc etc.
It builds fine, and tests great in VMWare. The desktop shows 2 columns of icons, and the BGInfo BMP I included in the build is correctly created and loaded.

However, when I load it from my Grub4DOS stick, either in VMWare (with PLOP) or in the 'real' machine via BIOS boot control, I only get some of the programs ( one column of desktop icons worth ), no BGINfo, etc. Most of the programs are missing from 'Program files'.

I also tried EASYBCD to built a stick, which also loads exactly like Grub4DOS as far as missing half the stuff in my build.

If I then boot the same exact ISO directly in VMWARE as a 'new machine', everything is there correctly.

Ideas ???? Tks.

[PMilligan]

Adding some info - this is what I get under various boot scenarios -

Direct load into VMWare as 'new machine' from the ISO output of Winbuilder :
X drive - small RAM disk
Y drive = virtual CD that exactly reflects the ISO
All programs show on desktop and 'Programs' from start menu, etc.
Y (CD) shows a folder 'Program Files' with all programs in it, just like Windows

BCD boot from USB ( via PLOP ) into VMWare ( this applies to G4D boot via PLOP also - same results )
X drive - small RAM drive
D drive - shows the PLOP loader files
No CD drive shown
Missing most add-in programs that are in the ISO

UEFI BIOS boot from USB (no PLOP or G4D, this is a BCD boot to the ISO output of WB)
X - 129 MB RAM drive
C drive - 100 mb 'reserved'
Unmounted CD available ( hardware CD, not virtual )
Missing most add-in programs that are in the ISO

Under the last two above, X drive has a 'Program FIles' folder, with only 'Common Files', 'Internet Explorer', and 'PEShell', none of my other programs in the build (BGInfo for example).

How do I tell WinBUilder to add all my other programs to this X disk ? WHat line in which script (or INI) tells WB where to put the tool being added? Can I change, for example, the BGInfo script to add BGInfo to that X drive ?

Can it be done with a 'meta' project-level command instead of me having to go edit scripts for 200 tools ?

Tks.

[pscEx]

I hope this is the right forum - this seems a Winbuilder issue to me ?

IMHO here is not the right forum.
WinBuilder is not responsible for the contents / quality / functionality of any project.

WinBuilder has a defined script syntax which should work in 99%. If a particular script line does not work, this line can be published under "bug report" or "support".

When you have troubles with a GENA project, you should ask in the GENA forum.

In reboot.pro GENA is "unknown".

Peter

[PMilligan]

Understood. However, this has nothing in the world to do with GENA. Please read my posts again, and in your mind totally remove GENA. I have done that in my builds to test, with no change in results. I mentioned them only as an example of 'other apps added to a build'.

My posts on this thread apply to ANY apps , GENA or otherwise, added to my build. This is not BGInfo specific, either, I use that only as an example, that is easy to spot on boot-up ( either it ran or it did not ). When I then examine the disks of the 'as booted' instance, I get the results as above, for ALL apps, regardless of source of script.

[pscEx]

How do I tell WinBUilder to add all my other programs to this X disk ? WHat line in which script (or INI) tells WB where to put the tool being added? Can I change, for example, the BGInfo script to add BGInfo to that X drive ?

Most app scripts have in the GUI a checkbox "Run from" where you can choose between RAM (WIM) and "CD" (X: ?).
Which project are you using?

Peter

[PMilligan]

I guess it started out was 'WIN7_PE', it was a while ago that I first built it (and some others).

I dont' see that checkbox in most apps - I do see it in the top-level 'main config'. I've been leaving it 'IN RAm (boot.wim). I tried this AM changing it to 'normal', and got a BSOD from the resulting ISO.

ON that config screen, bootmanager is set to 'Auto' ( I usually boot from G4D, but I'm not asking WB to create the stick for me, I already have a multi-boot stick with G4D, and the ISO comes up OK except for the issues above.

[patsch]

again: what project di you use?

I guess it started out was 'WIN7_PE', it was a while ago that I first built it (and some others).

is that project up2date?

and then try to setup your usb stick with a program like RMPrepUSB (http://www.rmprepusb.com/) and do not use the project method. Then copy the content of your target dir (the compiled project) to your stick and try again

[PMilligan]

Another example
New fresh DL and build of Win7PESE - same problem as above
has Super Finder XT, some others ( NIR, etc )

Booting via 'New machine'in VMWare from the ISO -
Has CD drive Y "Win7PESE" volume ID
Has SuperFinder folder under Programs, Nir, etc.
IOW - all is well

Booting in VMWare via Plop -> G4D -> Win7PESE - no such drive or folders
Booting 'Real' machine via EUFI BIOS boot to USB -> G4D - same as PLOP in VM

################ THIS FIXED THE PROBLEM in all builds

option Build / CdDrive x: - y: - set to 'run all from RAM' -

X drive now has 'Program files' will all the add-ins in it !!!

So, it was a Winbuilder issue. I would suggest that maybe this should be the default setting in the script distros (in the knowledge that I don't know enough about it to know i that is a good idea or not)

Thanks to all who helped here.

[pscEx]

So, it was a Winbuilder issue.

To be precise:

It is not a WinBuilder issue, but an issue of the project you are using.

Peter

[sbaeder]

Peter is right...And one of the first rules of Winbuilder is to mention the project - AND post a debug log file of the build (somewhere we can access it to see what is really going on).

Looks like you are having issues related to the mapping (remapping?) of the "CD" drive, and if you are using a CD or a USB (I am guessing a USB), then that could explain things. As others mentioned above, many scripts have options to either include them in the WIM file or to leave them on the media (the ISO or CD, or even USB - depending on how you boot.

So also showing yout boot config files for grub would help...

Also, how are you booting from Plop into vmware?

Remember the more details you give, the better.

[PMilligan]

(issue is solved as above. This post is just to add to the KB for others)

I have a PLOP VM set up to test booting from USB,which has G4D.

The issue I had was that booting the ISO directly into VM as 'new machine' (either via the WB script or manually), all was well. Under any other scenario (PLOP -> G4D in VM, PLOP -> EasyBCD in VM, direct 'meatspace' USB boot -> G4D or EasyBCD to my ISO via the UEFI BIOS on the box), I got the failure mode as above.

Tks.

[sbaeder]

################ THIS FIXED THE PROBLEM in all builds

option Build / CdDrive x: - y: - set to 'run all from RAM' -

YEs, this is just the way it is...If you always want ALL the files available no matter what, they have to go to the RAM disk that is created for the PE to boot into. There are lots of issues with things like Real vs. Protected mode drivers...If you search around here, you will find ways to use tools like FiraDisk to make a ram disk of the ISO, and boot off of it...

So, it was a Winbuilder issue. I would suggest that maybe this should be the default setting in the script distros (in the knowledge that I don't know enough about it to know i that is a good idea or not)

Again, to be CORRECT, it is a PROJECT issue, and not a "WinBuilder" issue. WHile they are linked, WinBuilder is the ENGINE that a project uses. It is like blaming the CAR for crashing into a wall when that was where the driver has told it to go. Don't blame the car - blame the driver.

As for it being a default, it has a lot to do with the history of things from XP (and before) where there wasn't a compressed image loaded into RAM. Also, many projects want to leave as much as possible on the physical media to conserve ram space, since many of the PE projects will run in limited RAM.

The "failure" mode you experianced is really just a by-product of how you split the content, and how you provided access to that content when the PE is booted. If it is on a medai that is really accessible to the PE when running, and you have the right Path variable or initialization, then there is no issue with keeping some in RAM and some on physical meda...

But glad you are happy... even if all you did was remove the symptom, and didn't really cure the underlying root cause...

(but a glass half full is better than a poke in the eye)


Scott

[PMilligan]

Big Dog -

Yes, I understand it's a script issue, not a WB issue per se. Not even really a script 'issue' (the script is fine), but a 'settings' issue. We can all stop beating that horse now :-)

I appreciate the added info. In my case, for my purposes, the 'symptom' is not merely 'cured', the 'problem' is 'fixed'. I carry a few dozen diferent boots on the stick, all under G4D, and this is one of them. I do carry bunches of stuff that I can access 'direct' on the stick also, but for the WinPE build I'm focusing on things to run 'live', so to speak.

I would reach out and virtually pet your cute little avatar nose, but then again maybe not (don't know if you bite) :-).

[paraglider]

Actually you have not solved anything. All you have done is hidden the issue you were experiencing - the drive that contains boot.wim was not found and hence could not be mapped to drive Y:.