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. mycrof...@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
