Going Dynamic (Was: HEADS UP: new NSS)

[Craig Reyenga]

From: "Tim Kientzle" <kientzle at acm.org>
Subject: Re: Going Dynamic (Was: HEADS UP: new NSS)
> David Taylor wrote:
>  > Hmm, but if /sbin/mount_ufs (say) is dynamically linked, and the
libraries
>  > are still in /usr, how do you mount /usr?
>
> That's why certain critical shared libs
> (e.g., libc.so) need to be moved to /lib.
>
>  >>As I said, I've already done a chunk of work
>  >>for this.  If someone would like to help finish...
>  >
>  > If there's a list of tasks that need to be done, I'd be willing to see
>  > what I can do (although I'm going back to uni next week)...
>
>
> Here are the remaining tasks that I know of:
>
> 1) Create /lib, move shared libraries.
>
>      This involves working on bsd.lib.mk and a few related
>      pieces so that certain libraries get installed
>      differently:
>        * shared lib into /lib
>        * compatibility symlinks from /usr/lib -> /lib
>        * static lib into /usr/lib
>
>      Here's a list of libraries that I believe need to
>      be moved:
>
>      libc libcrypt libedit libkvm libl libm libtermcap
>      libutil libalias libatm libcam libcurses libdevstat
>      libipsec libipx libmd libncp libreadline libsbuf libsmb
>      libufs libz
>
> 2) Update ld-elf.so.1
>
>      I've not yet looked carefully at this.  This may need
>      to be moved?  It will definitely need to have the
>      default search path altered to look in /lib first.
>
> If the above is done correctly, it should be possible to dynamically
> link one of the standard utils (by adding NOSHARED=yes to the
> Makefile for 'ed' or 'pax', for example), boot to single user and
> have that utility work, even without /usr being mounted.
>
> 3) Set up a system-wide switch.  This may just mean
>     setting a default for NOSHARED.  It may be necessary
>     to visit specific Makefiles to override NOSHARED=no
>     to force those utilities to be compiled static.
>     (/sbin/init may require this.  A few other utils may
>     also benefit.)
>
> 4) Boot-time safety issues.  Various tweaks to ensure that
>     _something_ is possible even if the system gets screwed up.
>     Not sure which of the following is best:
>      a) Kernel automatically runs /rescue/init if /sbin/init fails
>         too quickly.
>      b) Prompt user for an alternate init if /sbin/init fails.
>      c) Have /sbin/init remain static, alter it to prompt
>         for /rescue/sh in single-user mode (always? sometimes?).
>     I'm leaning towards some variant of (c), but I'm not sure
>     what all the issues are here.
>
> Tim Kientzle
>

5) Tell sysinstall to make a bigger root filesystem.

-Craig

(Sorry for being mouthy.)