[OpenIndiana-discuss] Split-root installations

Jim Klimov jimklimov at cos.ru
Tue Nov 26 23:07:34 UTC 2013


Thanks for the reply, some answers/couter-arguments are below :)

On 2013-11-26 23:51, Peter Tribble wrote:
> Here, you're solving the wrong problem. Just put the drivers in the right
> place from the start. I've never understood why drivers were scattered.

This might be out of admin's control somewhat - i.e. for drivers
delivered as a third-party package (say, virtualbox does this).

> The miniroot for any live or network boot already has a chunk
> of /usr. There's a real problem here in that there simply isn't
> a clean separation of root vs usr any more.  (...)
 > My worry here is that you're adding complexity to an already
 > complex system; instead, we need significant simplification.

Well, this is a setup which I do use for years with ZFS roots -
on Solaris 10 x86/SPARC, on OpenSolaris SXCE, on OpenIndiana now.
Very convenient, especially on space-constrained root devices,
and after some R&D and hands-on experience - finally rock solid.
Until my recent interest into NWAM (that is, previous setups were
all with "physical:default" setups), I did not notice any problems,
beside the fragility of mounts (fixed in my published scripts) and
the /sbin/sh fiasco in OpenIndiana (easily fixed however).

And the systems are used in production in a great number of ways,
so I wouldn't say that just some one deployment scenario has been
touched and tested and cloned all over the place.

Basically, there are just a few system components which (think they)
need to be started before filesystem/root, and after this service
completes - the split-off /usr dataset is available for any other
services and applications.

And I guess my changes don't (shouldn't) influence any other sorts
of filesystem splits, such as network-mounted parts of the rootfs.
If they work - then they do; if they don't work - I don't believe
I broke them (at least not intentionally) ;)

> (As an aside, I would really like to go back to the days where /lib
> was a symlink to /usr/lib, and things were much cleaner. But that
> ship sailed, and I fear it's not coming back.)

Well, for compact miniroots, I might agree - if the binaries in /sbin
(the stuff needed to mount /usr and/or run fsck where available) were
statically compiled so that /lib would not be a critical component
for the minimized root's ability to work. I believe /sbin/sh was an
example of that for many releases.

>> Ultimately, these can be (and are) different "root" service instances
>> which can have very different dependency graphs...
>>
>
> The live boot has a bunch of logic to run different services
> depending on how it booted, not entirely dissimilar in approach
> to what you've outlined above (but for different reasons). It's a
> nightmare.

I wouldn't disagree here ;)

So maybe this is another reason to hack an "svcadm restart/clear"
of the "network/physical" service into "fs-root", and keep the
currently defined dependencies as they are?.. :)

//Jim





More information about the OpenIndiana-discuss mailing list