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.

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:

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

FIXME: finish

2.2.3 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

This document was generated by Thomas Schwinge on November, 8 2007 using texi2html 1.76.