3. Bootstrap

Bootstrapping is the procedure by which your machine loads the microkernel and transfers control to the Hurd servers.(3)

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

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.

3.2 Server Bootstrap

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 bootstrap the Hurd, the microkernel must start this program as its first task, and to 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 Invoking boot).

3.2.1 Invoking 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:

` a'

Prompt the user for the root-name, even if it was already supplied on the command line.

` d'

Prompt the user to strike a key after the boot script has been read.

` q'

Prompt the user for the name of the boot script. By default, use `root-name:/boot/servers.boot'.

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.

3.2.2 Boot Scripts

FIXME: finish

3.2.3 Invoking boot

The boot program is used to start a set of core Hurd servers while another Hurd is already running. You will rarely need to do this, and it currently requires superuser privileges (to access the host privileged port), 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.

The boot program has the following synopsis:

boot [option]… boot-script root-store

boot-script is the name of the boot script (see section Boot Scripts). root-store is the store that is used as the root partition (see section Store Library).

Here are the steps you can follow to test out a new set of servers:

1. Create a new root partition and initialize it with your favorite filesystem format. The boot program uses libstore, so you can use any valid store as your root, with any options that libstore recognizes:

   $ dd if=/dev/zero of=my-partition bs=1024 count=80 $ mke2fs ./my-partition

   It is better to use a raw partition, if possible. With a raw partition, the sub-Hurd doesn't depend on its parent for anything except the default pager.

2. Copy the core servers, C library, and any of your modified programs onto the new partition:

   $ settrans -c ./my-root /hurd/ext2fs `pwd`/my-partition $ (cd my-root && tar -zxf ../my-files.tar.gz)

3. Use some clever shadowfs hacks (FIXME xref) to mirror the rest of your programs under the modified partition. Copying them will work, too, if you don't like shadowfs.

4. Create a boot script on the new partition, in `/boot/servers.boot'.

5. Make your root filesystem read-only for the parent Hurd, to prevent any conflicts:

   $ settrans -g ./my-root $ settrans -c ./my-root /hurd/ext2fs -r `pwd`/my-partition

6. Run boot on your new partition:

   $ boot -D ./my-root ./my-root/boot/servers.boot ./my-partition

Note that sharing microkernel devices between the two running Hurds may cause conflicts, 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).

3.3 Shutdown

FIXME: finish

This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.