9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Iruata Souza <iru.muzgo@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Announcing: rootless post kernel load startup
Date: Sun,  3 Jan 2010 00:25:08 -0200	[thread overview]
Message-ID: <d1c554291001021825w18ab7053ub3b9cb0dcaa01b76@mail.gmail.com> (raw)
In-Reply-To: <b2d3848d1001020756h70f27db7wd28f511ca42f1584@mail.gmail.com>

On Sat, Jan 2, 2010 at 1:56 PM, mycroftiv 9gridchan
<mycroftiv@sphericalharmony.com> wrote:
> More recent work - available on sources in
> contrib/mycroftiv/rootlessboot as both patches and a compiled ready to
> use kernel and optional rootfs.tgz additional tools to be placed in
> 9fat partition.
>
> "Rootless" bootup is a rewrite of the post-kernel load bootup process
> as handled by boot and init. The motivation is severalfold: the basic
> nature of the Plan 9 kernel as a 9p multiplexer means that there is no
> inherent reason to make any given filesystem special and necessary to
> keep the system usable. The particular case of a tcp-booted cpu server
> losing its network root fs is a traditional example. It is sometimes
> the case that a system with local fossil and remote venti can't be
> successfully booted if the IP address of the venti has changed from
> that given in plan9.ini. The overall goal is to improve reliability by
> enabling a running system to always repair and recover itself even if
> it experiences failure of normally criticial resources like a local
> venti+fossil.
>
> The rootless boot method combines boot and init into a much smaller
> program that does much less, and adds the rc shell and a few other
> tools to the kernel's compiled-in /boot. An rc script called plan9rc
> handles the tasks of starting up factotum, ipconfig, venti, fossil,
> and setting up a desired initial filesystem mount and running
> additonal options scripts and/or conventional cpurc or termrc from an
> external fs. Depending on the settings in plan9.ini, this can all be
> done interactively with the ability to drop to an rc shell. The
> plan9rc script can act to imitate the standard bootup process, or
> setup the environment in a different way - for instance by creating a
> ramfs with additional tools loaded from 9fat to create a working
> environment independent of the environment created by the standard
> bootup.
>
> As an example of the flexibility of this approach, I have tested this
> scenario: a rootless system starts up with interactive=yes set in the
> plan9.ini. It starts factotum, ipconfig, and then a venti server, and
> then pauses its bootup process. A second machine is then started as
> the fossil file server, and it is instructed to dial the venti and
> begin serving fossil and its normal startup. Once the fossil is
> serving, we return to the machine serving venti, and continue through
> the bootup process, and choose to imitate tcp-booting - and select the
> external fossil for the external service to mount. The fossil is
> dialed and bootup continues as if it was a standard tcp root cpu
> server.  The end result is that even the system hosting the venti is
> still "rooted" via an external fossil which is in turn using the venti
> as a backing store. This sequence would not be possible using the
> standard bootup method. Rootless booting also enables tcp booted cpu
> servers to be recovered without rebooting. The initial console process
> is usually kept in a protected namespace, with no connections to
> non-kernel resources. Consequently, if the non-kernel 'root' is lost,
> the dead processes can be killed off, another root acquired, and work
> resumed. If no local resources are available, a srv and mount of
> sources allows access to the tools of the full distribution.
>
> contrib/mycroftiv/rootlessboot holds the source for the modifications,
> as well as a compiled kernel. Also available is a rootfs.tgz for use
> in creating an optional ramfs based independent environment. If you
> wish to use this, put it in your 9fat. There is a lot of flexibility
> in exactly what is compiled into /boot and whether or not a ramfs with
> additonal tools loaded. Some users may prefer a light kernel that
> acquires a relatively large rootfs.tgz, whereas others might prefer to
> make a heaver compiled in /boot. The sample kernel on sources and
> rootfs.tgz there are both fairly heavy to try to support most common
> possibilities - venti, fossil, kfs, cfs are all compiled in, for
> instance.
>
> The rootlessboot directory has a fair amount of small modifications
> that are necessary or helpful, such as changing rc to look for
> /boot/rcmain rather than /lib/rcmain, and giving cfs the ability to
> post a srv. contrib/mycroftiv/rootlessboot/bootdir.extras/plan9rc
> controls the boot process and provides many options for controlling
> its behavior via plan9.ini variables. The default behavior is intended
> to closely mimic the standard existing logic for handling plan9.ini.
> The prebuilt kernel is a cpu kernel but setting service=terminal in
> plan9.ini will produce terminal style behavior. As always, I would
> recommend using a plan9.ini menu or setup so that choice of kernel
> used is selectable at boot.
>
> I have read the paper on the 9null kernel load boot process from this
> year's IWP9 and I am hoping that this work is consistent with its
> approach. As I have been working only on the post kernel load actions,
> I believe it to be mostly non-overlapping. This is still very much a
> work-in-progress, although I am using this boot process on my machines
> and VMs and am happy with the additional flexibility and control.
> These patches are most relevant and useful to those working with
> multiple system/VM Plan 9 installations. Although this modified kernel
> can be used to create the same type of base environment as usual, the
> usage model of booting a minimal environment that can be used as a cpu
> server that then creates several externally rooted subenvironments is
> very compelling. A set of provided scripts is intended to make working
> in this manner easier. 'rerootwin' for instance allows you to keep
> your current drawterm connection intact within a window even when
> completely restructuring your namespace to use a different root
> fileserver.
>
> mycroftiv@sphericalharmony.com
> Ben Kidwell
> 9gridchan.org provides a variety of public plan 9 services
> project channel: #plan9chan on irc.freenode.net for 9gridchan
> also in #plan9 for general Plan 9 discussion
>
>

hello,

i guess the work i'm doing overlaps at some extent to yours. we should
definitely talk (off list, perhaps).
i rewrote /boot/boot as a set of rc scripts with a minimal rootfs.tgz.
no big changes were needed.
if you want to take a look http://src.oitobits.net/9null contains the stuff.

thanks,
iru



  reply	other threads:[~2010-01-03  2:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-02 15:56 mycroftiv 9gridchan
2010-01-03  2:25 ` Iruata Souza [this message]
     [not found] <<b2d3848d1001020756h70f27db7wd28f511ca42f1584@mail.gmail.com>
2010-01-02 17:27 ` erik quanstrom
2010-01-02 19:18 mycroftiv 9gridchan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d1c554291001021825w18ab7053ub3b9cb0dcaa01b76@mail.gmail.com \
    --to=iru.muzgo@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).