Date: Wed, 19 Nov 2003 14:43:19 -0500 From: Ken Smith <kensmith@cse.Buffalo.EDU> To: Bruce Evans <bde@zeta.org.au> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: Unfortunate dynamic linking for everything Message-ID: <20031119194319.GB5566@electra.cse.Buffalo.EDU> In-Reply-To: <20031120061110.P8759@gamplex.bde.org> References: <200311182307.hAIN7Wpm000717@dyson.jdyson.com> <20031118164905.R35009@pooker.samsco.home> <20031119141059.GA14308@madman.celabo.org> <20031119141950.GA95734@ussenterprise.ufp.org> <20031119142535.GA27610@electra.cse.Buffalo.EDU> <20031119172533.GB9066@dhcp01.pn.xcllnt.net> <20031120061110.P8759@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 20, 2003 at 06:27:31AM +1100, Bruce Evans wrote:
> > set init_path=/rescue/init
>
> If dynamic root were ready to be turned on, then /rescue/init would be
> in the default init_path.
I had that explained to me too. :-)
There is a loop in sys/kern/init_main.c that "probes" for an init
to run. But it only does what you want for cases of the files
not existing or otherwise just totally not executable. It won't
handle the "started but then dumped core" case the way it would
need to if /sbin/init were to fail because of shared library
problems. So if just relying on this mechanism it would either
not work right (/sbin/init in the path before /rescue/init) or
it would always start /rescue/init (/rescue/init before /sbin/init
in the path).
--
Ken Smith
- From there to here, from here to | kensmith@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031119194319.GB5566>