2. Bootstrap

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

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.

Currently, 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

The serverboot program has been deprecated. Newer kernels support processing the bootscript parameters and boot the Hurd directly.

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 using serverboot, the microkernel must start serverboot as its first task, and pass it appropriate arguments. serverboot has a counterpart, called boot, which can be invoked while the Hurd is already running, and allows users to start their own complete sub-Hurds (see section 2.2.3 Recursive Bootstrap).

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

2.2.2 Boot Scripts

Boot Scripts are used to boot further Hurd systems in parallel to the first, and are parsed by serverboot to boot the Hurd. See `/boot/servers.boot' for an example of a Hurd boot script.

FIXME: finish

2.2.3 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:

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

   $ dd if=/dev/zero of=my-partition bs=1024k count=400 400+0 records in 400+0 records out $ mke2fs ./my-partition mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 my-partition is not a block special device. Proceed anyway? (y,n) y Filesystem label= OS type: GNU/Hurd Block size=1024 (log=0) Fragment size=1024 (log=0) 102400 inodes, 409600 blocks 20480 blocks (5.00%) reserved for the super user First data block=1 50 block groups 8192 blocks per group, 8192 fragments per group 2048 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 Writing inode tables: done Writing superblocks and filesystem accounting information: done $

2. Copy the core servers, C library, your modified programs, and anything else you need onto the pseudo-root.

   $ settrans -c ./my-root /hurd/ext2fs -r `pwd`/my-partition $ fsysopts ./my-root --writable $ cd my-root $ tar -zxpf /pub/debian/FIXME/gnu-20000929.tar.gz $ cd .. $ fsysopts ./my-root --readonly $

3. Create a new boot script (FIXME xref).

4. Run boot.

   $ boot -D ./my-boot ./my-boot/boot/servers.boot ./my-partition [...]

5. Here is an example using a hard drive that already has a GNU/Hurd system installed on an ext2 filesystem on `/dev/hd2s1'.

   $ settrans /mnt /hurd/ex2fs --readonly /dev/hd2s1 $ boot -d -D /mnt -I /mnt/boot/servers.boot /dev/hd2s1

6. See see section 2.2.4 Invoking boot for help with boot.

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.4 Invoking boot

Usage: boot [option...] boot-script device...

--kernel-command-line=command line

-c

Simulated multiboot command line to supply.

--pause

-d

Pause for user confirmation at various times during booting.

--boot-root=dir

-D

Root of a directory tree in which to find the files specified in boot-script.

--interleave=blocks

Interleave in runs of length blocks.

--isig

-I

Do not disable terminal signals, so you can suspend and interrupt the boot program itself, rather than the programs running in the booted system.

--layer

-L

Layer multiple devices for redundancy.

--single-user

-s

Boot into single user mode.

--store-type=type

-T

Each device names a store of type type.

Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options.

If neither `--interleave' or `--layer' is specified, multiple devices are concatenated.

2.3 Shutdown

FIXME: finish