WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Odd remastering problem  (Read 3698 times)

Offline CentralWare

  • Administrator
  • Hero Member
  • *****
  • Posts: 1652
Odd remastering problem
« on: October 20, 2014, 09:00:47 AM »
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)

« Last Edit: October 20, 2014, 10:32:11 AM by centralware »
Over 90% of all computer problems can be traced back to the interface between the keyboard and the chair

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: Odd remastering problem
« Reply #1 on: October 20, 2014, 11:05:29 AM »
That error is either broken hw or kernel bug. Your initrd is likely all ok.
The only barriers that can stop you are the ones you create yourself.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11178
Re: Odd remastering problem
« Reply #2 on: October 20, 2014, 12:27:51 PM »
Hi centralware
Can you try it using real hardware and take VMWare  out of the equation?

Offline CentralWare

  • Administrator
  • Hero Member
  • *****
  • Posts: 1652
Re: Odd remastering problem
« Reply #3 on: October 20, 2014, 08:41:52 PM »
@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.

Over 90% of all computer problems can be traced back to the interface between the keyboard and the chair