WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Remastering Core does not work, prints stacktrace  (Read 6162 times)

Offline nim108

  • Full Member
  • ***
  • Posts: 107
Remastering Core does not work, prints stacktrace
« on: November 09, 2012, 11:20:57 AM »
Ok, so very simply, I am manually remastering Core on Xubuntu 12.04 (LTS) by adding some persistent binaries that I need using these commands:

Extracting core.gz: zcat core.gz | sudo cpio -i -H newc -d

Then I add some binaries in /usr and package it back up using this:

Packaging core.gz: sudo find | sudo cpio -o -H newc | gzip > ../core.gz

This does NOT work. When I boot up the remastered core.gz now, the system prints out a stacktrace followed by the message "Fixing recursive fault but reboot is needed!" If the kernel is printing this out, it should not, because I did not touch vmlinuz. If I download core.gz from the website, it works just fine, so extracting it or packaging it up must be causing an issue somewhere. I used to use the same procedure in 3.x and it always worked fine, but it doesn't seem to be working in Core 4.7. Is it possible that a new version of cpio or gzip/gunzip is causing errors (I used to be on Xubuntu 11.04 which probably used older packages)? Did something else change in the core structure? Thanks. I don't want to use any of the remaster extensions because we will need a build script to automate this procedure eventually, and this is the easiest way. I guess the next logical thing to try is to use an older environment to remaster this in, like the 11.04 I was using before.

Thought I'd point this out too: I get the same exact error message printed when I try to upgrade the kernel to 3.0.50. I compile the kernel just fine and it works fine. But when I get to modifying the core.gz structure to point to 3.0.50 folders now instead of the 3.0.21 ones and packaging it back up, I get the same error on startup.
« Last Edit: November 09, 2012, 11:33:46 AM by nim108 »

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11516
Re: Remastering Core does not work, prints stacktrace
« Reply #1 on: November 09, 2012, 11:32:33 AM »
Hi nim108
The first thing I would try is extract and repackage without adding any binaries to isolate the problem.
If that boots OK, then try to figure out which binaries are causing the problem.

Offline nim108

  • Full Member
  • ***
  • Posts: 107
Re: Remastering Core does not work, prints stacktrace
« Reply #2 on: November 09, 2012, 11:35:24 AM »
Hi nim108
The first thing I would try is extract and repackage without adding any binaries to isolate the problem.
If that boots OK, then try to figure out which binaries are causing the problem.
I tried this, this does not work either. I'm thinking my VM is breaking something for some reason, though it should not be because I am not getting any errors when using cpio / gzip. I will quickly try this again.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11516
Re: Remastering Core does not work, prints stacktrace
« Reply #3 on: November 09, 2012, 11:55:50 AM »
Hi nim108
You should mention up front that you are running a VM. Quite frankly, I don't know where this subject belongs now
so I'm moving it to  Off Topic. If anyone disagrees, fell free to move it elsewhere.
I would recommend losing the VM, boot to a Tinycore environment, and run your commands and scripts there.

Offline nim108

  • Full Member
  • ***
  • Posts: 107
Re: Remastering Core does not work, prints stacktrace
« Reply #4 on: November 09, 2012, 11:59:00 AM »
Hi nim108
You should mention up front that you are running a VM. Quite frankly, I don't know where this subject belongs now
so I'm moving it to  Off Topic. If anyone disagrees, fell free to move it elsewhere.
I would recommend losing the VM, boot to a Tinycore environment, and run your commands and scripts there.
Will do, should make no difference if it's a VM or not though. The versions of the tools even on a physical system would be the same. I will try remastering core with another Linux distro.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11516
Re: Remastering Core does not work, prints stacktrace
« Reply #5 on: November 09, 2012, 12:01:36 PM »
Hi nim108
Quote
should make no difference if it's a VM or not though
I wouldn't know, I work in a real world, not a virtual one.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11027
Re: Remastering Core does not work, prints stacktrace
« Reply #6 on: November 09, 2012, 12:13:25 PM »
Do try to do it from within TC; that is where the official images are done from, using busybox tools.
The only barriers that can stop you are the ones you create yourself.

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
Re: Remastering Core does not work, prints stacktrace
« Reply #7 on: November 09, 2012, 12:33:45 PM »
Besides from already mentioned recommendations, I would suggest you experiment with dynamic remasters - while leaving core.gz untouched.
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline nim108

  • Full Member
  • ***
  • Posts: 107
Re: Remastering Core does not work, prints stacktrace
« Reply #8 on: November 09, 2012, 04:50:23 PM »
Besides from already mentioned recommendations, I would suggest you experiment with dynamic remasters - while leaving core.gz untouched.
Actually, this is what we originally had (an untouched core.gz and customize.gz which includes remaster content, which load just fine from SysLinux), but we later discovered we also have to kexec another variation of TC and I am fairly certain kexec does not allow multiple initrds.

I will have to go with curaga's recommended solution of setting up a TinyCore build environment and doing all these remasters in there with the proper versions of the BusyBox tools.

Offline coreplayer2

  • Hero Member
  • *****
  • Posts: 3020
Re: Remastering Core does not work, prints stacktrace
« Reply #9 on: November 10, 2012, 02:09:34 AM »
All my x86 remaster's are build on VirtualBox VM's  whilst x64 builds are built in the  always booted to tc

With flawless remastered copies at the rate of on average of one each week, I have to say all the issues i experienced in the early days were of my own doing.   ::)

I use ezremaster exclusively for all x86 builds, and custom frugal based builds for x64 remasters.  Which are usually deployed ass images for USB thumb drives.

YOu'll find the ezremaster script a vital source of information if you're rolling your own..
« Last Edit: November 10, 2012, 02:20:10 AM by coreplayer2 »

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11027
Re: Remastering Core does not work, prints stacktrace
« Reply #10 on: November 10, 2012, 05:17:46 AM »
Re multiple initrds - the kernel allows you to cat them together, which should work with kexec too. The downside is that you can't get back from that easily, so keep the originals around.

cat core.gz customize.gz > new.gz
The only barriers that can stop you are the ones you create yourself.

Offline nim108

  • Full Member
  • ***
  • Posts: 107
Re: Remastering Core does not work, prints stacktrace
« Reply #11 on: November 10, 2012, 09:56:02 AM »
Re multiple initrds - the kernel allows you to cat them together, which should work with kexec too. The downside is that you can't get back from that easily, so keep the originals around.

cat core.gz customize.gz > new.gz
Hmmm, this I have yet not tried, this could be a very viable solution, I will try this when I get back to work on Monday, thanks curaga.

Offline nim108

  • Full Member
  • ***
  • Posts: 107
Re: Remastering Core does not work, prints stacktrace
« Reply #12 on: November 13, 2012, 11:59:02 AM »
Re multiple initrds - the kernel allows you to cat them together, which should work with kexec too. The downside is that you can't get back from that easily, so keep the originals around.

cat core.gz customize.gz > new.gz
Hmmm, this I have yet not tried, this could be a very viable solution, I will try this when I get back to work on Monday, thanks curaga.
This method works w/ kexec! Thank you curaga. I have upgraded Xubuntu to 12.10 (which uses gzip 1.5) to see if this is an issue with gzip 1.4. Even though I now have a workaround, I am trying to nail the culprit down. I will test this shortly.