Crunchgen (Was Re: actual boot device)

[Allan Fields]

On Tue, Aug 17, 2004 at 07:54:14PM +0300, Sergey Lyubka wrote:
> Probably kenv loaddev is the answer, my problem is that I cannot fit
> loader into the image - it is already packed enough.

Are you using/have you tried crunchgen(1)?
This is how the rescue binaries are done.

It might save on space in your image where memory is very tight and
this could free up space for a loader.


(I don't know if this has any relation to what your doing, but...)

On a side note:

I was experimenting around with a single process image that locked
a shell and basic binaries into memory for administrative purposes
(w/o using md), but haven't done much to eliminate problems with
file descriptors, etc.  (It also does strange things w/ some
libraries, which isn't unexpected given the simplistic approach I
took.)

Even though it isn't something you want to use everyday: crunchgen
made it quite space efficient.

The idea was that the main() in each binary would be called from the
shell with-in the same address space and it would then hook exit and
return to the shell command-loop: which warps the unix binary tools
based approach, but might be handy in some situations.  It makes tools
such as ps, kill and fsck shell built-ins.

Sort of taking a statically linked base to the extreme while keeping
the size down.  If there is interest it could be rewritten properly
to supplement rescue infrastructure.  I did make mlockall(2) and
rtprio(2) work (where it is supported) but haven't updated the
project files yet.  It's done in the style of a pseudo-port which
needs the freebsd sources to build and uses some rather nasty
patching techniques (patching on output of a tool, rather than
patching crunchgen).


Another approach would be to simply keep the crunched rescue binary &
hardlinked entries in a memory disk which is loaded from rc scripts
and then mounted at /rescue.  I'm not sure if in all cases that would
do it, but in case of a failed disk or other fs problems, it might be
helpful.

I'm also a fan of kill in the debugger, very handy in case a machine
on the edge is still able to be resuscitated.

-- 
 Allan Fields, AFRSL - http://afields.ca
 2D4F 6806 D307 0889 6125  C31D F745 0D72 39B4 5541