Next: , Previous: , Up: Top   [Contents][Index]

2 Bootstrap

Bootstrapping2 is the procedure by which your machine loads the microkernel and transfers control to the Hurd servers.


Next: , Up: Bootstrap   [Contents][Index]

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


Next: , Previous: , Up: Bootstrap   [Contents][Index]

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/startup as PID 2. /hurd/startup starts the /hurd/proc and /hurd/auth servers. After the servers are launched /hurd/startup starts the /etc/hurd/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 Recursive Bootstrap).


Next: , Up: Server Bootstrap   [Contents][Index]

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 Invoking boot for help with boot.

If you do not know what you are doing, sharing microkernel devices between two running hurds could cause serious harm. For example, two hurds with two filesystems writing to the same partition will wreak havoc. In the same way, two hurds reading from the same terminal device will not share nicely.

However, sharing is possible for network devices. The different pfinet instances will just pick the packets applying to them, based on IP. There is also a proper user-space multiplexer for network devices now, called eth-multiplexer. This is only needed though if you also want to allow network traffic between the Hurd instances uning the device in question, rather than just each of them communicating with other machines.

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


Next: , Previous: , Up: Server Bootstrap   [Contents][Index]

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


Previous: , Up: Server Bootstrap   [Contents][Index]

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.


Previous: , Up: Bootstrap   [Contents][Index]

2.3 Shutdown

You can shut down your GNU/Hurd machine by typing

$ su # halt


Footnotes

(2)

The term bootstrapping refers to a Dutch legend about a boy who was able to fly by pulling himself up by his bootstraps. In computers, this term refers to any process where a simple system activates a more complicated system.

(3)

The GRand Unified Bootloader, available from http://www.gnu.org/software/grub/.


Previous: , Up: Bootstrap   [Contents][Index]