[oi-dev] [discuss] Re: basis for better collaboration on illumos and OpenIndiana: small circle, Big circle

[Jim Klimov]

On 2014-02-18 21:48, Peter Tribble wrote:
>     This requires support
>      >         for the Bourne Shell for all scripts that need to be run
>     before /usr
>      >         is mounted, which means to fix 6 shell scripts modified
>     by Sun in
>      >         spring 2010.
>
>
> And the illumos bug ids are?

I know those I've posted, a dozen or so starting by link-walk
from https://www.illumos.org/issues/829
I understand that it is now near-worthless to ask anyone
interested to sift through my bug reports/RFEs on this matter,
since they are in effect a working log of things I tried or
suggested. And since now I have an easily deployable solution
that works for me and is published and documented in the Wiki:
http://wiki.openindiana.org/oi/Advanced+-+Split-root+installation

However, in the end there are links to my other RFE/Bug IDs
on related matters, such as (in chronological order):

https://www.illumos.org/issues/3569
https://www.illumos.org/issues/4351
https://www.illumos.org/issues/4352
https://www.illumos.org/issues/4353
https://www.illumos.org/issues/4354
https://www.illumos.org/issues/4355
https://www.illumos.org/issues/4360
https://www.illumos.org/issues/4361

My research and work on the subject, and evolution of illumos
in the meanwhile, led me to these conclusions:
* ksh and its few dependency libraries can be packaged to
   reside in the minimized root fs (without /usr) and be not
   a symlink into /usr. I did this by hand, but this is better
   doable in packaging (where my skills seem lacking - did
   not succeed in pkg(5) on my early tries) of course.
   I have yet to notice any functional-equivalency downsides
   of old sh vs. ksh (or bash for that matter), although the
   memory footprint comparison was often cited as a difference.
* compression that can now be applied to rootfs takes care
   of most benefits that I cited for a split-off /usr, though
   gzip-9 does produce a noticeably smaller installation than
   lz4 or uncompressed. If only it were easily enabled during
   initial installation (I can, an average Joe can't).
* it is difficult to make a generic solution for the split-off
   /usr, because in some cases networking depends on it and in
   some - it depends on networking for remotely stored /usr.
   The one particular case that was of interest to me - with
   the /usr dataset (and optionally a few other paths) residing
   on a local ZFS rpool, is best fixed by an additional SMF
   service that is plugged to act early in the boot so that
   other services depend on it - including those that need the
   code from /usr, or the temporary areas in /var/tmp, etc.
* finally, ZFS clones inherit the ZFS attributes of parent
   datasets (in hierarchical parency) and thus are either
   uncompressed or lz4-compressed, whichever is in effect
   for rpool/ROOT. This makes one jump through a few hoops
   in order to retain original compression (i.e. gzip-9)
   on the split-off sub-datasets of the rootfs, when making
   BE clones and major package upgrades.

Now, the summary above uncovers things that should be done
in the installer, zfs clone (or BE clone) routines, changes
to ksh93 packaging and perhaps in delivery of my script for
the local ZFS split-root mounting at the proper step in the
SMF dependency graph - so that this feature desired by not
only myself is easily available and commonly maintainable.
I'd feel great if anyone would pick it up from here and
integrate the thing. I might too, some day, but have no
idea about when I would have enough time to do this.
Family, job and other time-eating stuff, you know ;)

But, really, this is no longer a matter of requiring some
different /sbin/sh code, or rewriting other method scripts.
Earlier I was convinced these steps are in order, but this
just happened to be not true. Although it wouldn't hurt
to fix the methods to call /sbin/sh instead of /bin/sh or
/usr/{,s}bin/{sh,ksh,ksh93} where appropriate so that the
existing /sbin/sh binary can be called instead of missing
objects in the yet-unmounted /usr dataset - see bug 4360,
such a fix would be rather pedantical than a requirement.

//Jim Klimov