1937 replies to this topic

[JonF]

attt lasssst i can reproduce (after many combinations), fix will be easy but i am busy tonight, tomorrow

@JonF
temporary workaround: use clean temp button before hitting big blue.

OK. I downloaded a complete fresh copy of LiveXP. I'm still getting the _RAM_RAMs, BootSDI builds still crash in Virtual Box, but BootSDI builds work in QEMU in 384 MB now. Strange.

[pscEx]

Here the RAM_RAM_RAM story:

• In ProjectInfo root name of %IsoFile% + '_RAM' is written to projectinfo.ini

  [*]StrFormat,FILENAME,%IsoFile%,%tmp%
  
  ...
  
  IniWrite,%ProjectInfo%,Project,RamISORootName,%tmp%_RAM

• In BootSDI.Script this value is read and assigned to %RamISORootName%
  

  IniRead,"%ProjectInfo%","Project","RamISORootName","%RamISORootName%"

  That is still ok
• But now in BootSDI.Script:
  

  Set,%ISOfile%,%ISODir%\%RamISORootName%.iso,Permanent

  %ISOFile% has a _RAM at the end!
• Goto 1: _RAM_RAM
• etc. etc.

Peter

[pscEx]

Compare with nativeEx.

Last days I made a big consolidation about %IsoFile%, %RAMIsoFile%, %BurnISO% etc.

look into the scripts' history for 'consolidation'

Peter

Bump

There are only the variables

• %RamISORootName%
• %ISORootName%
• %burnISO%

EDIT: Here WinBuilder internal Variables

• %IsoFileName%
• %IsoFile%
• %ISODir%

set unique and solely used through the whole project.
No temporary %BootISO% or similar

Peter

[Lancelot]

@JonF

ram_ram issue fixed, on server, please check.

Sorry i missed this before because i didnt hit big blue twice, i hit small green of bootsdi twice


@psc
Here the RAM_RAM_RAM story:
I know the story you write psc, problem is for fix i cant to touch ProjectInfo bugy line

[*]StrFormat,FILENAME,%IsoFile%,%tmp%
...
IniWrite,%ProjectInfo%,Project,RamISORootName,%tmp%_RAM[/code]

bugy because Reference Static value is at [Main] ISO, not %ISOFile%

Reminding:
When you asked for %ISOFile% replacement 22 days ago

Replace %burnISO% by %IsoFile%.

%burnISO% is history and now no longer needed, because WinBuilder itself sets %IsoFile% from [Main]IsoFile in script.project

BTW: The newest VirtualBox emulate script does not contain %burnIso%. Therefore it can be used also inside the Vista / Win7 world

@Lancelot: Maybe some scripts in LiveXP should be revised.

I'll do so with nativeEx.

Peter

I start working on your request and i found out that there are 2 ways,
1) using single (%isofile%) variable.
2) creating new permanent variables for each create image script. (with livexp, 3 scripts, 3 variables)

And since you didnt mention new permanent variables on your request (you just did yesterday) I choose 1st way

.....
Set,%ISORootName%,%tmp%,PERMANENT
Set,%RamISORootName%,%tmp%_RAM,PERMANENT[/code]
....

Advantage of using 1st way is it makes things simple for "create image" and following scripts which i thought it was the thing you asked 22 days ago. Think that we have 10 create image scripts, 2nd method needs 10 permanent variables, 1st method uses 1 permanent variable



Well method is not much important for me, 1st way or 2nd way, All ways to Kusadasi

If nativeex development requests creating a new permanent variable for new create image scripts, Than i will follow this way when core scripts updated.

[pscEx]

I think that here are a couple of opinions passing the reality.
That is mainly my fault, because I did not explain clear enough.

Therefore here a trial to explain:
http://www.boot-land...?...ost&p=81223

Peter

[JonF]

ram_ram issue fixed, on server, please check.

Can't check; now BootSDI stalls on WimPack (10+ hours).
 log.7z   249.95KB   325 downloads

[Lancelot]

Can't check;

You can, just enable only bootsdi without wimpack.

The issue you get is different,
I am not sure but i guess it is related to the very recenty found wimpack issue, check here
http://www.boot-land...?showtopic=9281

I guess this is also the reason of your previous post (we didnt now this wimpack issue that time)

However, several shortcuts on the desktop and in the start menu have the generic icon and are inoperative:



(The HijackThis shortcut works ... I don't know why it doesn't show the correct icon.) I can't see any different between the shortcuts that work and the shortcuts that don't.

A workaround is selecting "Together" box on wimpack script.
I just changed the settings on server side to avoid reports from new users till "Individually" box is fixed , please download new wimpack.script



btw,
Is there "4NT.script" topic ?

[JonF]

Is there "4NT.script" topic ?

No, never bothered to upload it. I can if there is interest.

[JonF]

I am not sure but i guess it is related to the very recenty found wimpack issue, check here
http://www.boot-land...?showtopic=9281

I guess this is also the reason of your previous post (we didnt now this wimpack issue that time)

A workaround is selecting "Together" box on wimpack script.

I always do "Together". I've had problems with "Individually" in the past, I forget what they were.

[Lancelot]

No, never bothered to upload it. I can if there is interest.

Well i am and with wondering which specific task you use with 4nt (better to explain on script's topic if you like),

If JonF uses sth, there is a reason

I always do "Together".

maybe sth about uumerge.exe !
your log says it fails at
If,EXISTDIR,%ProjectTemp%\Include,ShellExecute,Hide,"%Tools%\Wim\uumerge\uumerge.exe","-merge -nice #$q%ProjectTemp%\Include\*.txt#$q #$q%ProjectTemp%\IncludeFolderList.txt#$q"
but i dont know the reason !

Adding:
at least i can say, this error does not happen here with complete build, here is a log with together option.
http://lancelot.winb...1009_190409.rar

[JonF]

Well i am and with wondering which specific task you use with 4nt (better to explain on script's topic if you like),

If JonF uses sth, there is a reason

In this case it's mostly historical. I used 4DOS a lot in the 80's, and for a time was a beta tester. XP's cmd.exe does most of what I used to use 4NT for. I use aliases, and 4NT keeps its history stack between invocations, but I don't see a huge advantage in it now.

[Lancelot]

In this case it's mostly historical.

I fully understand your feelings

Also, i hope you can find more clue of your issue (wimpack). Galapo would have more ideas since i dont know these wimpack script lines well.

[pscEx]

If,EXISTDIR,%ProjectTemp%\Include,ShellExecute,Hide,"%Tools%\Wim\uumerge\uumerge.exe","-merge -nice #$q%ProjectTemp%\Include\*.txt#$q #$q%ProjectTemp%\IncludeFolderList.txt#$q"
but i dont know the reason !

What is when the directory exists, but there is no *.txt.

Peter

[Lancelot]

@psc



@JonF
The issue happens because your build order is 1st BootSDI than CreateISO which is not designed that way .
Normally when wb finishes the whole build, script.project of [LiveXP-ONBUILDEXIT] deletes Include folder
You manually changed the settings of scripts which cause not deleting Include folder, than CreateISO caused error with uumerge.

Well, i updated bootsdi.script to overcome your configuration.

Besides:
According to your log, create iso wont make a usable iso, for a long while create iso supports wimpack but requires other settings.
Play with create iso with wimpack by enableing !WBVerify (Verify Project).
Rest is up to you

[maanu]

im having a little issue with define bootsector script .

if i choose " create iso " it does make grub4dos my default boot loader , but when i choose bootsdi , it does not do so (although grldr and menu.lst got created at the root of iso ) .

have a look at the following log ( im not using bootsdi latest version ,create iso is latest one )

in same log , when i choose create iso ,the grldr sets as boot loader ,but when i select bootsdi , then default NT5 code sets as boot loader.

Attached Files

•  log.7z   34.89KB   305 downloads

[Galapo]

have a look at the following log ( im not using bootsdi latest version ,create iso is latest one )

That's your reason there -- only version 105 and above support the setting of bootsector by the bootsector script. Either update BootSDI to current or modify the older script yourself.

Regards,
Galapo.

[JonF]

OK, now that I'm runing in test mode I can build with Imdisk and BootSDI. But it doesn't work.

While BootSDI is running I get two modal dialogs:



As before, the result doesn't run in Virtual Box. In QEMU I get:



and then when it reboots:



BootSDI.img is 360 MB and QEMU is running with 512 MB RAM.

 log.7z   4.58KB   298 downloads

[JonF]

Whoops. looks as if those QEMU errorsw were left over from a previous build.

With a new build, the error is:

[Lancelot]

Hi JonF

can you test with using "Fixed" option on bootsdi script with an appropriate number.
according to your previous post picture, maybe ~400MB nice for a test.

[JonF]

Hi JonF

can you test with using "Fixed" option on bootsdi script with an appropriate number.
according to your previous post picture, maybe ~400MB nice for a test.

400MB fixed gets me only one zcopy error (suggested RAMdisk size 401 MB) and a different error message on booting:

[Lancelot]

JonF

try 450

Seems to me it is the known issue (informed by you before) about space calculation with vista ntfs6, you know we dont have a precaution on bootsdi yet for ntfs6 which results size calculations mismatch on vista's ntfs6.

For now, for vista users, using bootsdi with ntfs option seems to me trials with fixed or free size.

If you are not using wimpack (seems to me you are not ), you can quickly select use fat32 option too.

Shortly 2 tests:
1) fixed 450 with ntfs
2) freespace 60 with fat32

?

[JonF]

450 works.

Also increasing the QEMU VM RAM to 640 MB works, with only one non-critical error message on boot. Bot I'm wondering why it appears that the RAM requirements have increased so much. I used to be able to boot a BootSDI image in 384 MB.

[Lancelot]

maybe vista occupy a lot of extra space for ntfs6 feature ! which results increasing RAM requirements....
even maybe it becomes less useful to use ntfs compress with ntfs6 than ntfs5.

An IDEA for Vista with bootsdi (Tested ):
on ProgramFilesPE -->Define %Programfiles% location, "Settings Drive"
http://img193.images...gramfilespe.png
on bootsdi select fat32,
(my settings during test: http://img44.imagesh...38/2wimpack.png )
on wimpack disable "dont load vmdk container into BootSDI ram image"
(my settings during test: http://img199.images...70/3bootsdi.png )
==>
using fat32 result with no compress of core files (~60 MB or maybe ~100MB due to additions) but other files would be compressed much more than a ntfs-compress can do, and all in bootsdi.img (which i guess your main goal). This will I hope result less space than 450MB...... I hope you understand me.
http://img199.images.../169/4final.png
http://img194.images...905/4finalb.png
http://img194.images...390/4finalc.png

[JonF]

This will I hope result less space than 450MB...... I hope you understand me.

That appears to require more RAM ... the 640MB QEMU box complains that my system is low on virtual memory and fails to load all the desktop.

[Lancelot]

JonF

with fixed 450, ram requirements may increase because of mounting .vmdk and .wim files (imagex) ,
besides the required total size of bootsdi.img should decrease noticably,
I am not sure which side of the ballance have more effect, I felt with a big build (~450MB) like yours, decrease of .img would be more than increase of ram requirement when bootsdi free space ~24 used.

I tried, at least we now practice a workaround for vista ntfs , I put pictures on previous post of my settings on my test build.