[BusyBox] ramdisk to ramfs confusion

Gavin Dolling gavind at lsil.com
Thu Oct 18 03:59:50 UTC 2001


I'm trying to turn my ramdisk FS into a ram/shm FS so I can take advantage
of the memory efficiencies.

After looking at the archives and askign a few questions it seems many
people have tried this - some have got it to work. I can't - I suspect
mainly as I can't see how it should work and messing around with scripts in
the hope that one day it will all fall into place is getting me nowhere.

So I am hoping someone could clarify exactly how this procedure is supposed
to work.

After the pivot root. The FS has the old root somewhere below the new root.
The next step is to umount the old root and blow it away.

However it seems clear that the init process is still running. Indeed if I
look at the /proc after the pivot_root I see:

bash-2.03# cd /proc/1
bash-2.03# ls -l exe
lrwxrwxrwx    1 root     root            0 Jan  1 00:54 exe ->
/initrd/bin/busybox
bash-2.03#

It has been moved from /bin/busybox (/sbin/init is a symbolic link to
busybox).

Clearly I cannot umount the ramdisk when the init process is still running
from it. In addition It appears to me that to kill off the init process
results in the death of the system (does it automatically get restarted?).
How can you stop the init process and restart it from the new position
(/sbin/init). Surely you have to kill the original (/initrd/sbin/init) and
then exec the version in the new root (/sbin/init). Once the init process is
running and paged in I don't see how you can shift its position in the FS.
Moreover I don't see how you can kill process 1 and restart it.

How is this conflict resolved? An answer in terms of OS thoughts i.e what is
actually suppsoed to be happening (as opposed to look at my script that
works) is what I am looking for. In return I'll put together a document that
details how it works afterwards that can be put somewhere and this whole
issue laid to rest.

My apologies if this is slightly off topic I appreciate this is busybox
system related rather than strictly busybox stuff -it does at least seem to
be most relevant to the busybox community.

Thanks,

Gavin.








More information about the busybox mailing list