"Add a second initrd" - wait, what?

[cg]

Okay.  So, I'm reading through this discussion, because it's relevant to my interests.  In post #5, Curaga says "Should be easiest just to extract your mydata.tgz to the second initrd."  Rather than necro an old thread, I figured I'd just ask here (since I seem to be monopolizing the board today anyway ) :  How, exactly, would one go about doing that?  I can add "APPEND initrd=/wherever/I/put/the/thing" to extlinux.conf, but I have no clue what would happen after that point.  Does the system just view the newly appended .gz as a disk?  If so, will it run the "on startup, do this" scripts on the second initrd?

Basically, what I'm trying to do is create a live CD with custom scripts that I can use to make appliance-boxes with.  I would just leave the files on the HDD, but (as I think I mentioned in another post) after a sudden and unexpected power outage, there's about a 1-in-3 chance that the disk won't boot.  (I think it loses the MBR, since the file structure and data are preserved, but that's beside the point).  Is there a better way to accomplish this goal that I'm just too fixated to see?

[gerald_clark]

Change the initrd from "core.gz" to "core.gz,additions.gz"
or use the cat method described here:

http://wiki.tinycorelinux.net/wiki:remastering

[cg]

I've scrolled through that page several times, but it always reads to me as being only applicable to extensions.  Right now, all I have are scripts.  Will that method work without creating custom extensions, or am I gonna have to go that route no matter what?

[gerald_clark]

The .gz files are not extensions.  They are gzipped cpio archives.

[hiro]

It loses the MBR? what?
I used to turn off my old desktop PC at the power plug - without ever shutting it down. I've done that over thousands of times and the HDD is still working.
If you don't get power outage while you're actually writing to you HDD you shouldn't actually get any problems. perhaps use a simpler filesystem or set stuff like noatime?

[cg]

It loses the MBR? what?
I used to turn off my old desktop PC at the power plug - without ever shutting it down. I've done that over thousands of times and the HDD is still working.
If you don't get power outage while you're actually writing to you HDD you shouldn't actually get any problems. perhaps use a simpler filesystem or set stuff like noatime?

1) I *think* that's what's happening, since - like I think I mentioned - the file structure and data are all intact - i.e., the disk isn't corrupting.  I have no proof that this is actually the case, but it seems like a plausible working theory.

2) The HDD basically is always being written to - the machine is going to be used as a sniffer box, so wireshark (well, Tshark - same difference) is always recording traffic.  I have no clue how that could translate into the MBR going "boom" (unless it has something to do with the fact that the capture files are being written to sda2, maybe?), but...yeah.

[Rich]

Hi cg
The MBR is not accessed during normal disk operations, so I doubt that is the problem. When you say it does
not boot, is there a black screen, or do some of the normal boot messages show up. I would be more inclined
to believe it has something to do with one of your custom scripts and the functional implementation of the
sniffer itself. A hypothetical example of this could be, your box is saving information about its current state
in a RAM based directory, such as /var or a non-persistent /home. An abrupt loss of power prevents the state
from being saved in your backup. When power returns, the old state information is found, but it conflicts
with the actual state of the system, and causes a script to hang. Or, it could be as simple as, your box loses
power while writing to a file, and when power returns, you attempt to read that file but receive unexpected
results. Just some thoughts.

[cg]

Hi Rich - nice to see you again!

What happens is, the machine boots, passes the POST, starts looking for boot media, and fails to find anything (assuming there's no CD in the tray, etc).  A standard "non-system disk error - replace disk and hit enter" message comes up, but I'm like 99% sure that that's coming from the computer's internal components, and not from TCL.

[Rich]

Hi cg
I think a "non-system disk" message comes from the BIOS, so maybe the MBR is getting clobbered after all.
This is easy to confirm. Take a working system and execute:

Code: [Select]

dd if=/dev/sda1 of=mbrgood bs=512 count=1Copy the file mbrgood to a safe place. Now crash the machine and boot it with a Tinycore CD. Execute:

Code: [Select]

dd if=/dev/sda1 of=mbrbad bs=512 count=1Run diff on the two files and see if they match.