Next: Foundations, Previous: Introduction, Up: Top [Contents][Index]
Bootstrapping2 is the procedure by which your machine loads the microkernel and transfers control to the Hurd servers.
• Bootloader: | Starting the microkernel, or other OSes. | |
• Server Bootstrap: | Waking up the Hurd. | |
• Shutdown: | Letting the Hurd get some rest. |
Next: Server Bootstrap, Up: Bootstrap [Contents][Index]
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: Shutdown, Previous: Bootloader, Up: Bootstrap [Contents][Index]
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).
• Recursive Bootstrap: | Running a Hurd under another Hurd. | |
• Boot Scripts: | Describing server bootstrap relationships. | |
• Invoking boot: | How to use the boot program. |
Next: Boot Scripts, Up: Server Bootstrap [Contents][Index]
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:
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 $
$ 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
boot
.
$ boot -D ./my-boot ./my-boot/boot/servers.boot ./my-partition [...]
$ settrans /mnt /hurd/ex2fs --readonly /dev/hd2s1 $ boot -d -D /mnt -I /mnt/boot/servers.boot /dev/hd2s1
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: Invoking boot, Previous: Recursive Bootstrap, Up: Server Bootstrap [Contents][Index]
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: Boot Scripts, Up: Server Bootstrap [Contents][Index]
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: Server Bootstrap, Up: Bootstrap [Contents][Index]
You can shut down your GNU/Hurd machine by typing
$ su # halt
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.
The GRand Unified Bootloader, available from http://www.gnu.org/software/grub/.
Previous: Server Bootstrap, Up: Bootstrap [Contents][Index]