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 _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
