2.1 Bootloader

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.

GNU GRUB(3) is the GNU bootloader.
GNU 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 the Hurd servers.
You will need to refer to your bootloader and microkernel documentation
for more information about the details of this process.

2.2 Server Bootstrap

As it can be seen from the GNU GRUB configuration, the Hurd is
bootstrapped by starting the GNU Mach microkernel and two programs:
the root filesystem and the exec server.

The `--multiboot-command-line' option tells the file system server that
it is a root filesystem, which triggers it to run /hurd/init as PID
1. /hurd/init starts the /hurd/proc and
/hurd/auth servers. After the servers are launched
/hurd/init starts the /libexec/runsystem.sh script to
finish booting.

After the Hurd has been booted, other sets of core Hurd servers can be
started in parallel. They're called sub-Hurds or neighbor Hurds
(see section Recursive Bootstrap).

2.2.1 Recursive Bootstrap

The boot program can be used 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 to control the new Hurd (or allow
it to access certain devices), 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:

Create a pseudo-root device. Usually, you would do this by creating a
new partition under your old Hurd, and initializing it with your
favorite filesystem format. boot understands the regular
libstore options (FIXME xref), so you may use a file or other
store instead of a partition.

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).

2.2.2 Boot Scripts

Boot Scripts are used to boot further Hurd systems in parallel to the first,
and are parsed by boot to boot a sub-Hurd.

In that script, the variables 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 it is assumed that the Hurd is already running, and the current
ports will be fetched from the procserver.

root-name is the name of the microkernel device that should be used as
the Hurd bootstrap filesystem.