Odd remastering problem

[CentralWare]

I wrote a script which does the following:
1) CPIO Extract core.gz (4.7.7)
2) Embed Xvesa, Xprogs, flwm_topside and wbar (it handles dependencies)
3) COPY "mc" into a /tcz folder which later is used with tce-load
4) Rebuild core.gz (find | cpio -o -H newc | gzip -2 followed by advdef -z4)

When running the script, it does the job perfectly (from what can be seen)
The core.gz (called BASE.gz on my end) is then moved into my tftp directory and life is grand.

When booting a client (VM for the moment) it's entirely random.
The SAME compilation (no changes in the script) fails with "Fixing recursive fault but reboot is required"
I run the script a second time (again, no changes) and the problem may or may not vanish.  After 2-3 runs, it works on the client.

My first guess was that maybe the output file hadn't completely sync'ed up (written to HD) completely, so I went back and added "sync" before and after each write.  This had no affect on the outcome.

My second guess was that TFTP (dnsmasq) might be caching some portion of the core.gz file as it was just read not but a few minutes ago.  I edited the script to stop/restart the service...  no such luck.

Added: Third guess was Advanced Compression, so I removed advdef...  it's not the culprit.

THUS...  I'm throwing out a call for help in case anyone out there has had similar issues and/or ideas for the "next guess!?"

Server: TCL 4.7.7 Frugal on x686/12GB/4CORE
Client: VMWare Player running PXE->TCL 4.7.7 (2GB/2CORE)

[curaga]

That error is either broken hw or kernel bug. Your initrd is likely all ok.

[Rich]

Hi centralware
Can you try it using real hardware and take VMWare  out of the equation?

[CentralWare]

@Rich: Good call.  When a created image fails within the VM, it fails on hardware as well with an error as described.  Oddly enough, on a VIA 800A with 512MB, it throws "initrd too large to handle."  The largest image is 24.7MB.

@Curaga: Under normal circumstances I'd agree with your assessment...  except...  this is intermittent.  I run the script build.sh which I've created and the generated remastering of core.gz works perfectly.  If I run it again (the old core.gz being deleted and rebuilt from scratch) the remastered core.gz has a good chance of failing with the aforementioned error.

Based on how things act, I'm starting to think it's a combination of a couple different ingredients.

Code: [Select]

########################
# Repackage CORE IMAGE #
################################################################################
    pack="/tftp/images/tc/BASE.gz"
    if [ -f $pack ]; then rm $pack; fi
    echo -n "${RED}Rebuilding CORE${NORMAL} "
    cd $curdir/$src; sync; sync;
    find | cpio -o -H newc | gzip -2 > $pack; sync; sync;
    echo "${GREEN}Done.${NORMAL}"
    cd ..

    echo "${RED}Compressing CORE${NORMAL} "
    advdef -z4 $pack
    sync; sync;
################################################################################
I added sync before and after writes just as a precaution as the host machine is also running TCL with 3GB RAM and zero swap.
find) This should be pretty solid
cpio+gzip) If the output file from two compression algo's were ODD in file size (possibly due to seeding...) would this not throw a wrench in the mix?  It's just a theory at the moment; we'll see what turns up.