Remastering Core does not work, prints stacktrace

[nim108]

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.

[Rich]

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.

[nim108]

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.

[Rich]

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.

[nim108]

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.

[Rich]

Hi nim108

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.

[curaga]

Do try to do it from within TC; that is where the official images are done from, using busybox tools.

[tinypoodle]

Besides from already mentioned recommendations, I would suggest you experiment with dynamic remasters - while leaving core.gz untouched.

[nim108]

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.

[coreplayer2]

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..

[curaga]

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

[nim108]

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.

[nim108]

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.