|
Boot is the first program run after a kernel has been loaded.
It sets up usb input devices if needed and creates a minimal namespace.
It then exec(2)'s the plan9rc(8) script. It is started by the
kernel, never run directly by the user. See booting(8) for information
about the process of loading the kernel (and boot) into
memory.
Once loaded, the kernel initializes its data structures and devices.
It sets the two environment variables /env/cputype and /env/terminal
to describe the processor. It then binds a place–holder file server,
root(3), onto / and crafts an initial process whose sole function
is to exec(2) /boot/boot, a binary
which is compiled into root(3). Boot completes by exec(2)'ing
/boot/plan9rc.
The following information applies mostly to plan9rc(8) but has
been left in this section of the manual for convenience to existing
users. In general read "plan9rc" for "boot" in the section that follows
and consult the plan9rc documentation for definitive reference.
CPU Servers
The user owning devices and console processes on CPU servers and
that user's domain and encryption key are read from NVRAM on all
machines except PC's. PC's keep the information in the disk partition
/dev/sdXX/nvram. If a –k option is given or if no stored information
is found boot will prompt for all three
items and store them.
| |
password:
authid: bootes
authdom: research.bell–labs.com
|
The key is used for mutual authentication of the server and its
clients. The domain and id identify the owner of the key.
Booting Methods
The methods available to any system depend on what was compiled
into the kernel. The complete list of booting methods are listed
below.
tcp connect via Ethernet using the TCP protocol. The args are passed
to ipconfig(8) when configuring the IP stack. The plan9.ini(8)
variables fs and auth override the file server and authentication
server IP addresses obtained (if any) from DHCP during ipconfig(8).
localconnect to the local file system. The first argument is a
disk holding a file system. Boot inspects the disk. If the disk
is a fossil(4) file system, it invokes /boot/fossil to serve it.
If the venti environment variable (really, plan9.ini(8) variable)
is set, boot first arranges for fossil to be able to contact the
| |
| |
named venti(8) server. The variable's value can take the following
forms:
/dev/sdC0/arenas
the file should be a venti partition with a configuration stored
on it using venti/conf (see venti–fmt(8)). Boot will start a loopback
IP interface on 127.0.0.1 and start venti announcing on tcp!127.1!17034
for venti service and tcp!127.1!8000 for web service, using the
configuration stored in that
partition.
/dev/sdC0/arenas tcp!*!17034
same as the last but specify an alternate venti service address.
In this example, using * will announce on all available IP interfaces
(even ones configured later) rather than just the loopback device.
The loopback interface is still configured.
/dev/sdC0/arenas tcp!*!17034 tcp!*!80
same as the last but specify alternate venti service and web addresses.
The loopback interface is still configured.
tcp!135.104.9.2!17034 [ args ]
the network address of a venti server running on a separate machine.
Boot will configure the IP stack by passing args, if any, to ipconfig(8).
If the disk is not a fossil(4) partition, boot invokes /boot/kfs.
A variety of programs, like 9660srv and dossrv(4) masquerade as
kfs to allow booting from alternate media formats, so as long
as the disk is not a fossil disk, no check is made that the disk
is in fact a kfs disk. The args are passed to kfs(4).
For the tcp method, the address must be a numeric IP address.
If no address is specified, a file server address will be found
from another system on the network using the BOOTP protocol and
the Plan 9 vendor–specific fields.
|
|
|