I recently became convinced that all of the shared root schemes have
to happen before the standard startup happens (ie: before 'init').
Since all of the distributors utilize initial RAM disk to their own
advantage, inserting custom logic there can be difficult. But one can
pass an "init=" boot parameter, which is rarely done in stock
distributions, and thereby work the needed magic. This this sounds
like what MacK does.
I have re-vamped my latest such "init interceptor" to accomodate ...
+ private /etc on RO root
+ RW root with RO system via bind
+ RW root with RO system via sym-links
Take charge of your boot parms. The "root=" points to your RO root or
to your system base vol. Drive this guy with "init=/sbin/init+vol".
It will then look for "etc=/dev/whatever" or "runroot=/dev/writeable",
in that order, and act accordingly. For the latter, each RO system
dir can either be a sym-link or a mount point (and it handles either
case #2 or case #3, even mixing them). I have no idea how broadly it
will work, but I designed it for NORD Linux and tested it heavily on
Ubuntu. (Fedora is likely next, but my SuSE systems are committed and
already using one of the other ROR schemes.) Someone should try it
with FreeBSD. I bet it would work.
The private /etc, which I like, is still a little awkward. The
interceptor must perform 'fsck' and doesn't check for errors at this
time. I don't like the whole idea of reinventing the 'fsck' error
handling wheel. Otherwise it's fine and promises to minimize root
pollution (because guest owners can't add arbitrary stuff).
The writable root seems to let normal distributor practices flow
nicely after stock INIT logic gets control. Most people seem to
prefer this. But the interceptor doesn't account for the (unlikely)
case where the system expected root to be RW at boot time.
In all cases, you make it work by taking your /etc content and copying
that either to the disk or partition which will be mounted at /etc or
to a sub-dir of the disk or partition which will be your writable root
(along with all requisite mount point directories, especially a
"system" mount point). The "system" mount point is eg Linux-i386 or
Linux-s390 or Linux-s390x ... you get the idea. The script will need
a few more changes (sysconfig customization for starters), but is
presently in use on some of my systems and available is at ...
http://www.casita.net/pub/nord/sbin/init+vol
MacK further said:
> Did that include moving the RPM database from /var/lib/rpm/ to somewhere
> under /etc/? I'm guessing the answer is "no way", but it just seems out
> of place in /var/lib/rpm/.
In my day job, we considered putting the RO RPM database at
/usr/lib/rpm. But it later made more sense to simply reconcile the RW
RPM database with the known list-o-packages. That way, a "guest" with
its own set of RPM packages (installed with relocation to RW places,
of course) could still have a true RPM DB. I forget the RPM options
just now, but it works. But I'm honestly not sure we ever followed
through with maintaining the writable RPM DB.
John mentions NFS shared root:
> A little while ago, I wanted to make a system with / on nfs, with the
> ability to run multiple copies of it. Sorta like what you're talking about.
There are some shops which are totally sold on the idea of RO root,
usually with NFS backing. In virtualization, of course, other media
are perhaps more interesting.
Russ said:
> ... All the issues of the RO compoennt
> are long since known and solved, and really the issue is that
> a distribution packaging strategy designed to meet the needs
> of 'onsies and twosies' installs, is not well suited for
> hundreds or thousands of replications.
So you're saying that RPM will see a file in the target location,
confirm that the content matches what is/was intended to go there, and
no longer complains because it cannot re-write a RO file?
I agree with you that sites with hundreds of penguins need to look
seriously at in-house packaging expertise.
-- R; <><
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
