HEADS UP: /bin and /sbin are now dynamically linked

Bill Vermillion bv at wjv.com
Thu Nov 20 16:41:48 PST 2003


On Thu, Nov 20, 2003 at 16:31 , while impersonating an expert on 
the internet, Tim Kientzle sent this to stdout:

> Garance A Drosihn wrote:
> >At 6:26 PM +0100 11/17/03, Julian Stacey wrote:
> >>Seconded !  Better commit an improved switch with
> >>default = Off.

> >The time for voting was months ago.  

> Actually, the discussion started almost a year ago now.
> That's when the new PAM/NSS libraries were first being
> announced, which was a big driving factor for all-dynamic
> linking.  I recall quite a bit of that discussion
> happening right here on current at .

> Many of us here have been hamstrung by systems that didn't
> provide a static fallback.  I've personally been bitten by
> unrecoverable Linux and Solaris systems due to hosed shared
> libraries.  That's why I volunteered to build /rescue in the
> first place, so that I'd never be faced with an unrecoverable
> FreeBSD machine.

Happened to me in the past too.

> I'm pretty comfortable with the failsafes that we
> have in place:
>  * /sbin/init is static
>  * If /bin/sh fails, /rescue/sh can be run
>  * /rescue provides a complete set of statically-linked
>    sysadmin utilities that should be sufficient
>    for recovering a damaged system.

> There are a few things I'd like to see:
>  * It would be nice if the kernel noticed that /sbin/init
>    failed too quickly and prompted the user for an alternate
>    init.  That would open the door to a dynamic or just more
>    ambitious /sbin/init, since you could always fall back
>    to /rescue/init for recovery.
>  * /rescue/vi is currently unusable if /usr is missing because
>    the termcap database is in /usr.  One possibility
>    would be to build a couple of default termcap entries
>    into ncurses or into vi.

Considering that rescue mode will most often be run from a console
login or a serial console, I would thing the default console name
termcap [cons25] and something ubuiquitous such as vt102 would 
do quite well - as you could cover almost all with just those
two.

That surely beats older systems where all I had in recovery
attempts was  echo  to see what was there, and  ed  for editing.

I like your idea.

Bill

-- 
Bill Vermillion - bv @ wjv . com


More information about the freebsd-current mailing list