Bootstrapping(3) is the procedure by which your machine loads the microkernel and transfers control to the Hurd servers.
The bootloader is the first software that runs on your machine. Many hardware architectures have a very simple startup routine which reads a very simple bootloader from the beginning of the internal hard disk, then transfers control to it. Other architectures have startup routines which are able to understand more of the contents of the hard disk, and directly start a more advanced bootloader.
Currently, GRUB(4) is the preferred GNU bootloader. GRUB provides advanced functionality, and is capable of loading several different kernels (such as Linux, DOS, and the *BSD family).
From the standpoint of the Hurd, the bootloader is just a mechanism to
get the microkernel running and transfer control to serverboot.
You will need to refer to your bootloader and microkernel documentation
for more information about the details of this process.
The serverboot program is responsible for loading and executing
the rest of the Hurd servers. Rather than containing specific
instructions for starting the Hurd, it follows general steps given in a
user-supplied boot script.
To boot the Hurd, the microkernel must start serverboot as its
first task, and pass it appropriate arguments. serverboot may
also be invoked while the Hurd is already running, which allows users to
start their own complete sub-Hurds (see section Recursive Bootstrap).
serverboot
The serverboot program has the following synopsis:
serverboot -switch... [[host-port device-port] root-name]
Each switch is a single character, out of the following set:
All the switches are put into the ${boot-args} script
variable.
host-port and device-port are integers which represent the
microkernel host and device ports, respectively (and are used to
initialize the ${host-port} and ${device-port} boot
script variables). If these ports are not specified, then
serverboot assumes that the Hurd is already running, and fetches
the current ports from the procserver (FIXME xref).
root-name is the name of the microkernel device that should be
used as the Hurd bootstrap filesystem. serverboot uses this name
to locate the boot script (described above), and to initialize the
${root-device} script variable.
FIXME: finish
The most appealing use of the serverboot program is to start a
set of core Hurd servers while another Hurd is already running. You
will rarely need to do this, and it requires superuser privileges, but
it is interesting to note that it can be done.
Usually, you would make changes to only one server, and simply tell your programs to use it in order to test out your changes. This process can be applied even to the core servers. However, some changes have far-reaching effects, and so it is nice to be able to test those effects without having to reboot the machine.
Here are the steps you can follow to test out a new set of servers:
Note that it is impossible to share microkernel devices between the two
running Hurds, so don't get any funny ideas. When you're finished
testing your new Hurd, then you can run the halt or reboot
programs to return control to the parent Hurd.
If you're satisfied with your new Hurd, you can arrange for your bootloader to start it, and reboot your machine. Then, you'll be in a safe place to overwrite your old Hurd with the new one, and reboot back to your old configuration (with the new Hurd servers).
FIXME: finish
Go to the first, previous, next, last section, table of contents.