Jump to content











Photo
- - - - -

"ISO build size is 34.00 Kb"


  • Please log in to reply
22 replies to this topic

#1 exenia

exenia
  • Members
  • 5 posts
  •  
    United States

Posted 19 June 2008 - 04:34 AM

Add another one to the 34kb club. I've tried several builds, but since I have yet to spit out my first working VistaPE image I'm not too knowledgable of the program to track down the cause. With v075b2 I'm now down to 0 errors and 0 warnings, I just can't pass the final step.

Some suggestions in this post say to leave all settings at default, but I can't take all defaults.

Possible problems:
1> I'm running Vista64 (but using Vista32 sources). UAC is disabled and I'm runing as the true Administrator. I know it's supposed to be ok, but since the VistaPE scripts require 32-bit sources, I mention it.
2> I don't know what boot/install index number to pick. Right now I've been using the boot.wim index pointing to "Microsoft Windows Longhorn WinPE" (instead of the "setup" image), and this seems to work ok.
3> I'm using the install.wim index pointing to "Windows Vista HOMEPREMIUM", but really don't know which version VistaPE is expecting to build from.
and more troubling...
4> I have repeated problems getting changes to stick in Winbuilder. There's no Save button in most individual scripts, so if I try to change the WAIK path or something, I have to fight through some combination of restarting, hitting Refresh, or hitting Save under the Main Configuration script. Eventually it gets the right setting saved. Or at least the gui says it does.

If I mount the .wim file left in the /target folder it has some contents for the build addons, but not very many. Since I haven't made a working image yet I don't know what to expect there, but it seemed like there must be *some* parts of my build completed. I used oscdimg to create an .iso out of it using WAIK. That didn't boot correctly, Virtualbox began the windows startup progress bar and then got hung up. That's just the boot.wim at work, I got the same result if I renamed vistape.wim to install.wim or if I left it out completely. Is there some other way to manually create the .iso after hitting the 34kb wall? Or is the build hopelessly trashed?

I've erased everything and redownloaded scripts several times, tried selecting only VistaPE for the project or getting tools collections from others, but I keep hitting the same dead end. Is there some other dependency? Or any good clues about where this is breaking?

#2 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 19 June 2008 - 07:59 AM

Welcome to the "club". :)

We had Peter (psc) introduce the term "voodoo" exactly for this problem.

And we have a nice emoticon, too:
:)

The 34kb problem appears to be a semi-random one. :)

Common things that were tried:
1) use a simple path short and with NO spaces in it, i.e. C:\Winbuilder instead of C:\Documents and setiings\this is where I would like to place the prog\winbuilder\test 1\run 5\
2) use only lower case names:
http://www.boot-land...?showtopic=3009
3) use only a NTFS drive
4) copy the Vista source on HD instead of accessing it from DVD

But the actual reason seem not to be have exactly pinned:
http://www.boot-land...?showtopic=3687


Post anyway your .log, maybe there is something in it that, even if it does not produce an error can be spotted by someone.


jaclaz

#3 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10557 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 19 June 2008 - 08:51 AM

Also a good thing to use version 075 beta 3 and download a fresh copy of VistaPE.

http://winbuilder.ne...oad.php?list.12

You seem to be on the right track, let's see if this can be solved so that we can later try to debug the reasons that were causing your build to fail.

:)

#4 exenia

exenia
  • Members
  • 5 posts
  •  
    United States

Posted 20 June 2008 - 12:14 AM

1) Done, I was initially trying to use e:\winbuilder, e:\Vista, and e:\WAIK anyway.
2) I'm don't understand where something might be case-sensitive? Would that be mostly in things internal to Winbuilder, like the project name, ISO filename, etc? My target folder does end up with several capitalized filenames, but it looks like they are copied from source .wim files that way.
3) It's all NTFS, yes.
4) Locally saved DVD dump, yes.

I'll start testing with 075b3 in case that helps in some way. I'm also starting to test on an XP system as well as the Vista64 box. So far it's no good, and all I can suspect is the source. I'm using a Vista32 disk image, the boot.wim and install.wim look ok to me but I don't know what image name VistaPE is expecting to be given.

Here's a logfile using XP to build, this is working with c:\winbuilder, c:\vista, and c:\program files\windows aik, and for the project I downloaded the 'minumum' contents. The changes made from defaults are paths and the image index numbers (boot=1 and install=2 this time), set default shell=Explorer (but BSExplorer results in 34kb build too), and I put the .iso volume name into lowercase.

Attached Files

  • Attached File  log.html   1.05MB   647 downloads


#5 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 20 June 2008 - 07:24 AM

1) Done, I was initially trying to use e:\winbuilder, e:\Vista, and e:\WAIK anyway.
2) I'm don't understand where something might be case-sensitive? Would that be mostly in things internal to Winbuilder, like the project name, ISO filename, etc? My target folder does end up with several capitalized filenames, but it looks like they are copied from source .wim files that way.
3) It's all NTFS, yes.
4) Locally saved DVD dump, yes.

I'll start testing with 075b3 in case that helps in some way. I'm also starting to test on an XP system as well as the Vista64 box. So far it's no good, and all I can suspect is the source. I'm using a Vista32 disk image, the boot.wim and install.wim look ok to me but I don't know what image name VistaPE is expecting to be given.

Here's a logfile using XP to build, this is working with c:\winbuilder, c:\vista, and c:\program files\windows aik, and for the project I downloaded the 'minumum' contents. The changes made from defaults are paths and the image index numbers (boot=1 and install=2 this time), set default shell=Explorer (but BSExplorer results in 34kb build too), and I put the .iso volume name into lowercase.

The log shows that this might be an issue of mkisofs.

The target directory is 'full' as all the successful copies and extracts show.
But the complete CreateISO script is done within half a second.

If it happens reproducabe, try to remove -duplicates-once from the mkisofs start parameters.

Peter

#6 exenia

exenia
  • Members
  • 5 posts
  •  
    United States

Posted 20 June 2008 - 08:33 PM

The log shows that this might be an issue of mkisofs.

The target directory is 'full' as all the successful copies and extracts show.
But the complete CreateISO script is done within half a second.

If it happens reproducabe, try to remove -duplicates-once from the mkisofs start parameters.

Peter


Yes, there definitely is a lot of material under target\, and when I'm running the build I can see that it takes some time to go through the "packing .wim" stage. I removed all 4 instances of -duplicates-once, but the same problem still exists on every build.

I have now found a workaround so mkisofs is probably ok as it is. Unfortunately, I don't like the fix because it's to use WAIK as the build source instead of a Vista disk. (MMC/imagex/explorer support are the functions I most want to use)

I'm starting to doubt this is the exactly the same problem as the "voodoo" occurrence because mine is always broken. The fault may be similar for both, but I'm now trying to find an alternate source disk to use. I can't track the origins of the one I'm using back to a physical disk, so I don't know if there's something strange about it. With AIK working, that piece is just way too suspicious.

#7 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 20 June 2008 - 11:13 PM

Yes, there definitely is a lot of material under target\, and when I'm running the build I can see that it takes some time to go through the "packing .wim" stage. I removed all 4 instances of -duplicates-once, but the same problem still exists on every build.

I have now found a workaround so mkisofs is probably ok as it is. Unfortunately, I don't like the fix because it's to use WAIK as the build source instead of a Vista disk. (MMC/imagex/explorer support are the functions I most want to use)

I'm starting to doubt this is the exactly the same problem as the "voodoo" occurrence because mine is always broken. The fault may be similar for both, but I'm now trying to find an alternate source disk to use. I can't track the origins of the one I'm using back to a physical disk, so I don't know if there's something strange about it. With AIK working, that piece is just way too suspicious.

Now I'm rather sure that it is mkisofs having problems with certain constellations of %target%

Changing the source also changes the resulting target ...
BTW: I have had (only with a certain project configuration) one of seven builds having the 34 kb.

If it is 100% reproducable with a certain %target%: Can you zip the complete target and PM me?

Peter

#8 exenia

exenia
  • Members
  • 5 posts
  •  
    United States

Posted 21 June 2008 - 07:11 AM

Sent a link for a copy of my files. I think it'll take me a while to dig up a different vista32 disk so in the meantime I may try LiveXP, it should have enough in common to do what I want. The more I read about Vista's type of NTFS I worry that even a natively 64-bit VistaPE would still be difficult to manage disk imaging and editing.

#9 cdob

cdob

    Gold Member

  • Expert
  • 1450 posts

Posted 22 June 2008 - 02:09 PM

Crystal ball:

mkisfos -b "boot/etfsboot.com"
Be aware: -b file name is case sensitive.
Mkisofs finds a file boot/etfsboot.com, but not a file BOOT/ETFSBOOT.COM.

WAIK and some Vista disks contain a file \boot\etfsboot.com.
Some OEM Vista disks contain a file \BOOT\ETFSBOOT.COM.

Does Winbuilder copy a file \boot\etfsboot.com or \BOOT\ETFSBOOT.COM?
Create a file \boot\etfsboot.com always.

Anyway to debug:
Add true command line log file. Name working directory and expand Variables like %BaseDir%.
And add a mkisofs output to the log file. Error output goes to Standard error (stderr).
http://en.wikipedia....or_.28stderr.29

#10 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 22 June 2008 - 02:16 PM

Error output goes to Standard error (stderr).
http://en.wikipedia....or_.28stderr.29


This may prove more useful for DOS/Windows users:
http://www.robvander...edirection.html

:)

jaclaz

#11 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10557 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 22 June 2008 - 04:00 PM

This is an interesting detail cdob.

I will keep this in memory for future reference, thank you for mentioning it.


One detail: winbuilder and related scripts support very well long paths with spaces by default but it has been noticed that some scripts lack the proper #$q chars (") wrapped inside variables when launching these variables as parameters for external programs using the shellexecute command (for example).

From experience, when coding a script my %basedir% and %sourcedir% are often placed on long paths with spaces in between just to ensure that I don't forget myself of adding the necessary "" wherever needed.

This might be the case on the CreateISO script and if so it will require to add the missing #$q around the parameters that are passed onto mkisofs.


:)

Edited by Nuno Brito, 22 June 2008 - 04:16 PM.
Added info about spaces and long path names wrapped with #$q


#12 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 22 June 2008 - 04:04 PM

Crystal ball:

mkisfos -b "boot/etfsboot.com"
Be aware: -b file name is case sensitive.
Mkisofs finds a file boot/etfsboot.com, but not a file BOOT/ETFSBOOT.COM.

No crystal ball, engineering report:

In a special constallation I have had 3 from around 20 builds with the 'super compressed' 34 kb.
Any lc / uc values have never been changed inside the builds.

The crystal ball may help do find and remove the :)

Peter

#13 exenia

exenia
  • Members
  • 5 posts
  •  
    United States

Posted 22 June 2008 - 07:58 PM

Crystal ball:

mkisfos -b "boot/etfsboot.com"
Be aware: -b file name is case sensitive.
Mkisofs finds a file boot/etfsboot.com, but not a file BOOT/ETFSBOOT.COM.

WAIK and some Vista disks contain a file \boot\etfsboot.com.
Some OEM Vista disks contain a file \BOOT\ETFSBOOT.COM.

Does Winbuilder copy a file \boot\etfsboot.com or \BOOT\ETFSBOOT.COM?
Create a file \boot\etfsboot.com always.

Anyway to debug:
Add true command line log file. Name working directory and expand Variables like %BaseDir%.
And add a mkisofs output to the log file. Error output goes to Standard error (stderr).
http://en.wikipedia....or_.28stderr.29

Ah, that is very interesting. Yes, I DID see that path in all caps, when checking if everything was in lowercase. Doing a quick test I changed it to lowercase, ran the entire project, and the file changed back to ETFSBOOT.COM (but the directory stayed lowercase) and a 34kb build. Whatever is mounting the boot files does not check for existing files.

Because that sounded like a reasonable cause, I ran the full project, and just slipped in to rename etfsboot.com while the scripts were processing. When it reached the end, it gave me a 300mb .iso. Silly way to fix it, but that worked! :)

I think psc is right, though. This is not "voodoo" because it happened every time, and will continue to happen until I edit the mkisofs command line to use \boot\ETFSBOOT.COM (or find a different Vista source). Before I start tweaking the build a lot I'll add stdout/stderr redirects to mkisofs, and check those if I ever get a blank .iso again.

I don't know a lot about winbuilder scripting yet, would it also be possible to make the finalize script check if \boot\etfsboot.com exists? Are ExistDir and ExistFile case sensitive?

#14 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 22 June 2008 - 08:29 PM

Ah, that is very interesting. Yes, I DID see that path in all caps, when checking if everything was in lowercase. Doing a quick test I changed it to lowercase, ran the entire project, and the file changed back to ETFSBOOT.COM (but the directory stayed lowercase) and a 34kb build. Whatever is mounting the boot files does not check for existing files.

Because that sounded like a reasonable cause, I ran the full project, and just slipped in to rename etfsboot.com while the scripts were processing. When it reached the end, it gave me a 300mb .iso. Silly way to fix it, but that worked! :)

I think psc is right, though. This is not "voodoo" because it happened every time, and will continue to happen until I edit the mkisofs command line to use \boot\ETFSBOOT.COM (or find a different Vista source). Before I start tweaking the build a lot I'll add stdout/stderr redirects to mkisofs, and check those if I ever get a blank .iso again.

I don't know a lot about winbuilder scripting yet, would it also be possible to make the finalize script check if \boot\etfsboot.com exists? Are ExistDir and ExistFile case sensitive?

Great that it helped you.
And also great that we now know the cause.

But for me there is still one question:
As told some posts ago, I got it in 3 of about 20 builds. And I am sure that I did not change anything in uc / lc of these critical files.

The question now is: What's the mechanism inside Bill the Door's OS (In my case I used XP) to use / change existing file names.

@cdob and @exenia: Many thanks. Your results opened a new gate to make WinBuilder better (I hope that I can find something behind this gate)

Peter

#15 cdob

cdob

    Gold Member

  • Expert
  • 1450 posts

Posted 22 June 2008 - 09:39 PM

Actually there maybe different reasons.

NT based windows can handle long command lines, at least 2047 characters:
http://support.micro....com/kb/830473/

Winbuilder, shellexecute, mingw32, cygwin, windows or a script may truncate command line.

Or a false command line is launched.

Or command line does not match files at hard disk.

Non ASCII chars may get funny results. Windows use different character sets at GUI mode and at command line.

Again:
For debug purposes it would be nice to have full used mkisofs command line.
And mkisofs output to stdout and stderr.

#16 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 23 June 2008 - 07:48 AM

It is posible to rename the Eltorito Boot file befor using it in mkisofs.
This command looks crasy but it works!
FileRename,%TargetDir%\%BootSect%,%TargetDir%\%BootSect%
This renames to exactly how it is defined in %BootSect%
I tried 'eTfsboot.com' and it renames accordingly!

This additional line fixed the 'Eltorito based' 34kb bug for ever.

I already changed CreateISO.script on the nativeEx server accordingly.

Peter

#17 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 23 June 2008 - 11:56 AM

I already changed CreateISO.script on the nativeEx server accordingly.


Hi Peter,

The version on the LiveXP server has the following line which I suggest adding to the one on the nativeEx server so that they're standardised.
Disable="%scriptdir%\BootSDI.Script","%scriptdir%\SaveBase.Script","%scriptdir%\SaveBase.Link","%ProjectDir%\Finish\1 Optimizations\WimPack.script"

Thanks,
Galapo.

#18 ksanderash

ksanderash

    Frequent Member

  • Advanced user
  • 162 posts
  • Interests:electronics, PCs, cinema, reading books, psychology, philosophy
  •  
    Moldova

Posted 26 June 2008 - 04:31 PM

As I see the problem "34kb" is solved now, right? :) I have this phenomenon too (tried to practice witchcraft with upper/lower case but no results), but being a completly newbie I just wanted to ask you folks if somebody could, pls, upload the corrected ISO-generating script in here, to replace the original questionable one.

p.s. Oh yes, I struggle with this thing: http://vistape.net/f...ape12b2-base.7z

#19 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 26 June 2008 - 05:28 PM

As I see the problem "34kb" is solved now, right?

Remember what I said:

This additional line fixed the 'Eltorito based' 34kb bug for ever.

I have had this bug with a certain constellation in 7 of 20 builds. And I'm rather sure that beween these builds the uc / lc writing of the boot file name did not change!

... I just wanted to ask you folks if somebody could, pls, upload the corrected ISO-generating script in here, to replace the original questionable one.
p.s. Oh yes, I struggle with this thing: http://vistape.net/f...ape12b2-base.7z

Here we have the issue that there is nobody besides NightMan, who can fix files on the vistape server. And he is currently very invisible.
But maybe somebody here can post a fix snippet you can insert by yourself?
(I do not have any VistaPE, therefore I cannot)

Peter

#20 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 28 June 2008 - 02:36 PM

Here we have the issue that there is nobody besides NightMan, who can fix files on the vistape server. And he is currently very invisible.
But maybe somebody here can post a fix snippet you can insert by yourself?
(I do not have any VistaPE, therefore I cannot)

Now I have!
And here how you can fix it by yourself: http://www.boot-land...?...ost&p=38678


Peter

#21 ksanderash

ksanderash

    Frequent Member

  • Advanced user
  • 162 posts
  • Interests:electronics, PCs, cinema, reading books, psychology, philosophy
  •  
    Moldova

Posted 28 June 2008 - 11:12 PM

Oh, thank you very much for the hint! It works!! :)

#22 M. Safdar

M. Safdar

    Newbie

  • Members
  • 23 posts
  •  
    Pakistan

Posted 13 April 2010 - 08:14 PM

I have an alternate solution to make ISO file. please read this post. http://www.boot-land...amp;#entry97888

#23 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 14 April 2010 - 04:16 PM

I have an alternate solution to make ISO file. please read this post. http://www.boot-land...amp;#entry97888

The easiest way is to take care uf upper / lower case when you pass the boot sector name to mkisofs.

Peter




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users