The Shœstring Foundation Weblog

The Shœstring Foundation Weblog, Miscellaneous Byproducts

Matthias Bauer
bauerm (at) shoestringfoundation · org
reop pubkey

Subscribe to a syndicated feed of my weblog, brought to you by the wonders of RSS.

Blosxom Logo

Sat, 09 Mar 2013

Remote Boot and Root for Plan9

Started to play with Plan9 again. First major experiment: Run a bare-metal cpu server without local disks. All configuration can be done from an OpenBSD server supplying the loader, kernel, bootup-config, and filesystem. The Plan9 server runs on an old 1U Pentium 4 server.

Results so far: PXE finds Plan9 loader, that again loads a plan9.ini by TFTP which specifies a kernel, which then mounts its rootfs from a u9fs on OpenBSD. Said rootfs contains cpurc which determines the server's behaviour.


dhcpd.conf on DHCP/TFTP server:

host cpu {
        hardware ethernet 00:11:22:33:44:55;
		filename "9pxeload";
Once the PXE Plan9 bootloader1 9pxeload is running it pulls the file /cfg/pxe/001122334455 from the DHCP/TFTP server. This file is used as the plan9.ini.

Example plan9.ini:

console=0 b19200 pn
9pxeload will load 9pccpu from the TFTP server it found on ether0 and supply that kernel with the infomation that its rootfs will be remotely supplied from Console is on first serial interface with 19200bps and no parity.

On the following entry in inetd.conf starts 9legacy's modified u9fs2 process on demand:

9fs stream tcp nowait root /mnt/9atom/unix/u9fs u9fs -a none /mnt/9atom
(This implies that the service 9fs is already defined as 567 in /etc/services.)
The u9fs exports the filetree under /mnt/9atom without authorization. This is excusable only in a private network and necessary only because my rootless cpu server does not know the password for the remote fs. A way around that would be to put the password into the kernel itself (which again is totally insecure in an open network where everybody can fake the MAC and pull the kernel...)

The Plan9 server can now be controlled completely from the OpenBSD machine which is nice for testing configurations.

Footnote 1

There are several loaders around, at least the following:

  • 9load loads from disks
  • 9pxeload loads from PXE
  • iplpxe seems to be a smaller re-implementation of 9pxeload

Footnote 2

The original u9fs found in /sys/src/cmd/unix/u9fs.c exported the whole fs of the server. This led to the custom of chrooting the process, with all the pitfalls included. The 9legacy patch allows to export arbitrary subtrees.

[/plan9] permanent link

Tue, 08 Jul 2008

The ubiquitous fs in Plan9

The terms file server, file system and the abbreviation fs appear a lot in Plan9 documentation. For example, there are the manpages fs(3), fs(4), fs(8), and kfs(4).

First fs(4) aka Ken's FS. This was a file server inside the kernel which required a specially built kernel and was used together with a dedicated CPU server and many terminals. It is not part of the kernel sources any more, but its manpage lives on. To add confusion, there is also a manpage fs(8) for the console of Ken's fs.

Then there is kfs(4), a file system for terminals. It is implemented in user-space. No relation to Ken's FS besides the name. Strangely there seems to be no option to repair a broken kfs:

If the file system is inconsistent, the user is asked for permission to ream (q.v.) the disk.
(reaming means deleting). kfs cannot be managed by a console like Ken's fs and fossil, but by options to an executable kfscmd. UPDATE kfscmd has commands to repair a broken kfs.

As another example for the non-injectivity of abbreviations, there's fs(3) which is not a file system at all, but a kind of soft-raid that allows concatenation, striping and (simple) mirroring of files, e.g. disks.

On the fourth hand, there is fossil. This is the current default for CPU and File servers. It can be configured to move its blocks to an archival storage server venti. It is managed with its own console fossilcons which attaches itself not as /srv/fossilcons but /srv/fscons.

[/plan9] permanent link

Wed, 27 Jun 2007


Plan9 is an operating system by the authors of the original Unix, with integrated support for distributed applications.

Plan9 has its own windowing system, rio, quite different from X11.

It is possible to connect to Plan9 machines by drawterm from Unix machines running X11. drawterm starts the windowing system on the remote Plan9 and everything works as if sitting in front of it.

While typing from one machine I remembered I had already solved a problem in a one-liner, but on a different drawterm which ran on a Unix box miles away.

cpu% echo $wsys
cpu% lc /srv/rio.*
rio.myname.1234		rio.myname.5678

So the other drawterm runs the rio mounted on /srv/rio.myname.5678. To get at the scrollback of a window displayed on a screen on a totally different machine:

cpu% mount /srv/rio.myname.5678 /n/wsys 1
cpu% cat /n/wsys/text 
[...lines of output...]
[...including the one-liner...]

[/plan9] permanent link