On Wed, 26 Dec 2001, Luke Mewburn wrote:

> On Thu, Dec 20, 2001 at 05:58:33PM -0800, cgd@broadcom.com wrote:
> As to /sbin/init; there's a couple of solutions:
>
> 	- Statically link /sbin/init, for simple sane recovery.
> 	  My test box currently has this.

I vote for this. See below for reasons. :-)

> 	- Dynamically link /sbin/init so that dynamic features
> 	  can be used (e.g, ldap for secure console access, different
> 	  dynamically linked locales, etc ;-).
> 	  Provide /sbin/init.static and/or /recovery/sbin/static
> 	  (see below for more info about recovery options), and add
> 	  those paths to the list of paths (listpaths[]) that
> 	  sys/kern/init_main.c::start_init() tries to exec.
>
> The former is simpler, and less intrusive whilst experimenting with
> the system.  The latter still providss for recovery.

[snip]

> In the case of a broken ld.so (or whatever), recovery is not much
> different than today:
>
> 	- If you are already logged in to your system you'd just
> 	  use the tools in /recovery instead of /bin and /sbin.
>
> 	- If you reboot to single user mode, you can specify
> 	  /recovery/sh as the shell.  If /sbin/init was dynamically
> 	  linked (see above), the kernel could just try
> 	  /recovery/init as an alternative (see above).

The kernel trying /recovery/init isn't 100% as I understand things. That
list of inits the kernel looks for are ones the kernel tries to start. But
once one of them starts, it is init.

And if it exits, the kernel panics.

If we have a dynamically-linked init, problems with libc or any other lib
can cause init to crash, potentially panicing the kernel. And as above, if
the problems occur after the exec starts, down goes the kernel.

We could have the kernel try /recovery/init at that point, but how does
the kernel know if we're in a, "libc is messed up, try recovery" mode, or
a, "we're doomed, panic until someone comes to help" mode?

My vote is everything except init dynamically linked. :-)

Take care,

Bill