305 lines
8.5 KiB
Groff
305 lines
8.5 KiB
Groff
.TH INSTALLBOOT 8
|
|
.SH NAME
|
|
installboot \- make a device bootable
|
|
.SH SYNOPSIS
|
|
.B installboot \-i(mage)
|
|
.I image
|
|
.RI [ label :] kernel
|
|
.IR "mm fs" " ... " init
|
|
.br
|
|
.B installboot \-(e)x(tract)
|
|
.I image
|
|
.br
|
|
.B installboot \-d(evice)
|
|
.I device bootblock boot
|
|
.RI [[ label :] image
|
|
\&...]
|
|
.br
|
|
.B installboot \-b(oot)
|
|
.I device bootblock boot
|
|
.RI [ label :] image
|
|
\&...
|
|
.br
|
|
.B installboot \-m(aster)
|
|
.RI [ fix ]
|
|
.I device masterboot
|
|
.SH DESCRIPTION
|
|
.de SP
|
|
.if t .sp 0.4
|
|
.if n .sp
|
|
..
|
|
.B Installboot
|
|
may be used to make a device bootable by constructing a kernel image and
|
|
installing bootstrap code into the boot block of a Minix file system. To
|
|
understand how this can be done one first has to know what happens when a
|
|
PC is booted.
|
|
.PP
|
|
When the power is turned on the typical PC will try to read the first sector
|
|
from the first floppy disk or from the first hard disk into memory and execute
|
|
it. The code obtained from the hard disk (from the so-called master boot
|
|
sector) will immediately replace itself by the code found in the first sector
|
|
of the active partition. Thus the PC is now executing the bootstrap code found
|
|
in the first sector of /dev/fd0, /dev/hd1, /dev/hd2, /dev/hd3, or /dev/hd4.
|
|
The bootstrap will locate the operating system on the device it itself was
|
|
loaded from, load it, and execute it.
|
|
.PP
|
|
To make a Minix file system
|
|
.B /dev/fd0
|
|
mounted on
|
|
.B /mnt
|
|
bootable, enter the following:
|
|
.SP
|
|
.RS
|
|
.ft B
|
|
cp /usr/mdec/boot /mnt/boot
|
|
.SP
|
|
installboot \-i /mnt/minix kernel mm fs init
|
|
.SP
|
|
installboot \-d /dev/fd0 /usr/mdec/bootblock boot
|
|
.ft P
|
|
.RE
|
|
.PP
|
|
The "boot" program in the example is named the "boot monitor". It is loaded
|
|
by the bootblock code placed in the boot sector of /dev/fd0 and it will take
|
|
care of loading the kernel image "minix" from the root directory of the
|
|
file system. See
|
|
.BR monitor (8)
|
|
for a description of the boot monitor. Note that
|
|
.B boot
|
|
is a name in the file system on
|
|
.B /dev/fd0
|
|
in this example, the same file as
|
|
.BR /mnt/boot .
|
|
Making
|
|
.B /mnt/minix
|
|
is normally not necessary, there is usually a kernel image in the
|
|
.B tools
|
|
directory.
|
|
.SH OPTIONS
|
|
.B \-i(mage)
|
|
.I image
|
|
.RI [ label :] kernel
|
|
.IR "mm fs" " ... " init
|
|
.RS
|
|
The
|
|
.B \-image
|
|
option (or the
|
|
.B \-i
|
|
shorthand) combines the executable files needed to run Minix in one file.
|
|
Only the names and a few zero bytes are inserted into the image. The name
|
|
is for identification and the zeros are used to pad separate pieces to
|
|
sector boundaries for fast loading.
|
|
.SP
|
|
An executable may be prefixed by a label. The monitor may be instructed to
|
|
load processes by label. So more than one kernel process may be included in
|
|
the image, each with a different winchester driver for instance. So if you
|
|
have compiled two different kernels with an AT or XT driver then
|
|
.SP
|
|
.RS
|
|
.BI "installboot \-i" " image AT:at_kernel XT:xt_kernel mm fs init"
|
|
.RE
|
|
.SP
|
|
will make an image with two different labeled kernels and one
|
|
unlabeled set of the other binaries.
|
|
.RE
|
|
.PP
|
|
.B \-(e)x(tract)
|
|
.I image
|
|
.RS
|
|
Extract the binaries from
|
|
.I image
|
|
under the names stored in the image. (The name includes the optional label.)
|
|
.RE
|
|
.PP
|
|
.B \-d(evice)
|
|
.I device bootblock boot
|
|
.RI [[ label :] image
|
|
\&...]
|
|
.RS
|
|
Installs
|
|
.I bootblock
|
|
in the boot sector of
|
|
.I device
|
|
together with the disk addresses to
|
|
.IR boot .
|
|
These disk addresses are needed to load
|
|
.I boot
|
|
from the file system at boot time. The argument
|
|
.I boot
|
|
is first searched in the file system on
|
|
.IR device .
|
|
If it is not found then it is read as a normal file and added at the end of
|
|
the file system. The file system should be smaller than the device it is on
|
|
to allow this. Any extra images are also added to the end as described
|
|
under
|
|
.BR \-boot .
|
|
(Make sure you understand all this.)
|
|
.SP
|
|
The device need not be mounted when
|
|
.B installboot
|
|
is run, nor does it matter if it is.
|
|
.SP
|
|
.B Installboot
|
|
needs to be run again if
|
|
.I boot
|
|
is rewritten, because it will then occupy a new place on the disk.
|
|
.SP
|
|
Old boot parameters are kept if there are no images added.
|
|
.RE
|
|
.PP
|
|
.B \-b(oot)
|
|
.I device bootblock boot
|
|
.RI [ label :] image
|
|
\&...
|
|
.RS
|
|
This option fills a blank floppy in
|
|
.I device
|
|
with boot code and kernel images. This "boot disk" does not have a root
|
|
file system, only the boot monitor and Minix kernels. The boot parameters
|
|
sector is filled with code that enables menu options for selecting an
|
|
image. After loading an image, the monitor will ask you to insert a root
|
|
file system diskette before starting Minix.
|
|
.SP
|
|
The labels used on the images should match those on the executables used
|
|
inside the image. You can put a comma separated list of labels on an image
|
|
for each label used within the image. For the image created earlier one
|
|
would create a boot floppy like this:
|
|
.SP
|
|
.RS
|
|
.nf
|
|
.BI "installboot \-b /dev/fd0 bootblock boot" " AT,XT:image"
|
|
.fi
|
|
.RE
|
|
.SP
|
|
If a label-list is omitted on an image, then that image will be selected by
|
|
default. (Like in the normal one image, no labels case.)
|
|
.SP
|
|
Note that
|
|
.B \-device
|
|
and
|
|
.B \-boot
|
|
together allow you to make a boot floppy with or without a root file system.
|
|
With the boot code in the file system, attached to the end of it, or after
|
|
the boot block. And with one or more kernel images in the file system or
|
|
at the end of the device. Somewhat confusing.
|
|
.RE
|
|
.PP
|
|
.B \-m(aster)
|
|
.RI [ fix ]
|
|
.I device masterboot
|
|
.RS
|
|
This option installs the
|
|
.I masterboot
|
|
program into the boot sector of the given device. If another device is
|
|
given instead of
|
|
.I masterboot
|
|
then its bootstrap code is copied to
|
|
.IR device .
|
|
The master bootstrap on a hard disk boots the active partition on that disk
|
|
at boot time. The MS-DOS fdisk command normally puts a master bootstrap on
|
|
the hard disk. Minix has two bootstraps that can be used as a master
|
|
bootstrap. A fairly normal one named
|
|
.B masterboot
|
|
that works as follows:
|
|
.RS
|
|
.SP
|
|
If the ALT key is held down while booting then '/dev/hd?' appears and you
|
|
are expected to type a number key (0 \- 9) to select the device to boot.
|
|
.SP
|
|
If
|
|
.I fix
|
|
(a small number) is given then the bootstrap is locked into booting the
|
|
.BI /dev/hd fix
|
|
disk or primary partition. This is needed if 'boot *hd\fIN\fP' is used from
|
|
the monitor to boot an O.S. that needs the active flag set.
|
|
.SP
|
|
If installed on a Minix floppy then it will try to boot the next floppy or
|
|
the first hard disk. Ideal for floppies with just data on it, they will no
|
|
longer obstruct the boot process if left in the drive. Also a very useful
|
|
trick to boot from floppy drive 1.
|
|
.SP
|
|
If installed on a hard disk then the active partition is selected and booted
|
|
as usual, unless none of the partitions is marked active, then it will boot
|
|
the next disk. The latter is useful if you want to boot an operating
|
|
system from the second disk by default.
|
|
.RE
|
|
.SP
|
|
The second bootstrap is named
|
|
.BR extboot .
|
|
It has only one function, to boot the logical partition named by
|
|
.IR fix .
|
|
.I Fix
|
|
is not optional for
|
|
.B extboot
|
|
and must be a number-letter pair, like
|
|
.B 2c
|
|
for
|
|
.BR /dev/hd2c .
|
|
.SP
|
|
.B Extboot
|
|
or
|
|
.B masterboot
|
|
with a fix key need not be installed in the hard disk master bootstrap per
|
|
se if you don't want to mess with the DOS master bootstrap, or if you want
|
|
keep the active flag functioning. An extended partition or a non-root Minix
|
|
partition are better candidates. It seems logical to put
|
|
.B extboot
|
|
in the extended partition boot block.
|
|
.SP
|
|
A backup copy of the current master bootstrap (including the partition
|
|
table) can be made with:
|
|
.RS
|
|
.SP
|
|
dd if=\fIdevice\fP of=\fIbackup-file\fP count=1
|
|
.SP
|
|
.RE
|
|
A simple 'cat \fIbackup-file\fP > \fIdevice\fP' will put it back. You can
|
|
also use
|
|
.B fdisk /mbr
|
|
under MS-DOS 5.0 (or newer) to restore the master bootstrap.
|
|
.RE
|
|
.RE
|
|
.SH FILES
|
|
.TP 25
|
|
.B /usr/mdec/bootblock
|
|
Minix bootstrap for the Minix root device. To be placed in the boot sector.
|
|
.TP
|
|
.B /usr/mdec/boot
|
|
Minix Boot Monitor. Can usually be found in the root directory of a bootable
|
|
device.
|
|
.TP
|
|
.B /usr/mdec/masterboot
|
|
Master bootstrap. Can be placed in the first sector of a disk to select the
|
|
active partition. In a Minix primary partition it selects the active
|
|
subpartition.
|
|
.TP
|
|
.B /usr/mdec/extboot
|
|
Extended partition bootstrap.
|
|
.SH "SEE ALSO"
|
|
.BR part (8),
|
|
.BR monitor (8).
|
|
.SH DIAGNOSTICS
|
|
.I Boot
|
|
doesn't fit on
|
|
.I device
|
|
.RS
|
|
If there is no space on the device to add the boot code. This usually
|
|
means that there is no boot code in the file system you use
|
|
.B installboot \-device
|
|
on.
|
|
.RE
|
|
.PP
|
|
.I Image
|
|
doesn't fit on
|
|
.I device
|
|
.RS
|
|
If the device is too small for all the images you try to put on it.
|
|
.SH BUGS
|
|
It has four more options than the SunOS installboot program it is modeled
|
|
after.
|
|
.PP
|
|
The bootblock code has been crunched to such ugliness that you can use it
|
|
to scare little kids out of your garden.
|
|
.SH AUTHOR
|
|
Kees J. Bot (kjb@cs.vu.nl)
|