[OpenIndiana-discuss] Split-root installations

Cedric Blancher cedric.blancher at gmail.com
Wed Nov 27 17:14:11 UTC 2013


On 27 November 2013 15:59, Jim Klimov <jimklimov at cos.ru> wrote:
> On 2013-11-27 15:15, Peter Tribble wrote:
>>
>> NIC drivers can't live in /usr at all. That part
>> isn't an interesting problem to solve.
>
>
> Good to know. Then we don't declare that networking should restart
> after the devfsadm re-run for the possibly newly mounted /usr might
> find new drivers.
>
> We do it only due to the programs which appear with this /usr... :)
>
>
>> That (testing for /usr/bin) is not a valid test. That, or any number
>> of random things from /usr,  might exist on the root filesystem,
>> minimally populated with just enough for the system to boot,
>> waiting for the genuine /usr to be mounted over the top of
>> it when ready. The check would have to be an explicit check of
>> whether /usr is a separate mountpoint. (Parse vfstab, maybe.)
>
>
> Not really. If the rootfs is monolithic and includes root and /usr
> as it does today by default, there won't be a separate mountpoint,
> but all the needed programs would be delivered - as they are today.
> They would just be stored with no/low compression, that's all...
>
>
>> But that really tells you what the proper way to solve this problem
>> is - ensure that what you need from /usr is actually present before
>> /usr gets mounted. Either by having the minimal subset of the files
>> copied into a skeletal /usr that you mount over the top of, or move
>> the files out of /usr into somewhere that will always be available
>> early in boot (that's what we have /sbin and /lib for).
>
>
> Thanks, I did consider some of these ideas as well :)
>
> On one hand, if we're talking about getting just the physical/nwam
> script to work, this is indeed a small subset of programs that should
> be available as builtins in the shell or as binaries (in /sbin), the
> latter including pkill (or ps for parsing its output - or revert to
> looking into /proc?), sort (may be replaced with the snippet from
> Lionel Cons); maybe ls; cut, cat, grep and some others are acceptably
> implemented as ksh93 builtins.

AFAIK ls(1) is introduced in ksh93v- libcmd only (with O_XATTR
support, but not ACL support yet) but maybe Roland Mainz did backport
that work to Opensolaris, like he did with grep(1) too. I don't know.

Ced
-- 
Cedric Blancher <cedric.blancher at gmail.com>
Institute Pasteur



More information about the OpenIndiana-discuss mailing list