summaryrefslogtreecommitdiff
path: root/distrib/notes/sparc/install
diff options
context:
space:
mode:
Diffstat (limited to 'distrib/notes/sparc/install')
-rw-r--r--distrib/notes/sparc/install115
1 files changed, 87 insertions, 28 deletions
diff --git a/distrib/notes/sparc/install b/distrib/notes/sparc/install
index ca3f2496b1d..e7abe4a4482 100644
--- a/distrib/notes/sparc/install
+++ b/distrib/notes/sparc/install
@@ -1,12 +1,58 @@
Installing OpenBSD is a relatively complex process, but if you have
this document in hand it shouldn't be too much trouble.
-There are several ways to install OpenBSD onto a disk. If your Sparcstation
-is hooked up in a network you can find find a server and arrange for a
-diskless setup which is a convenient way to install on a machine with
-a single disk attached. Alternatively, you could use SunOS (booted from
-a local disk) and install OpenBSD onto a second disk. For the latter method,
-skip to the section "Installing from SunOS" below.
+There are several ways to install OpenBSD onto a disk. The easiest way
+nin terms of preliminary setup is to use the OpenBSD miniroot that can
+be booted off your local disk's swap partition. Alternatively, if your
+Sparcstation is hooked up in a network you can find a server and arrange
+for a diskless setup which is a convenient way to install on a machine
+whose disk does not currently hold a usable operating system (see the
+section `Installing using a diskless setup' below).
+
+
+Installing using the OpenBSD miniroot.
+
+The miniroot is a self-contained OpenBSD filesystem holding all utilities
+necessary to install OpenBSD on a local disk. It is distributed as a plain
+file designed to be transferred to a raw disk partition from which it can
+be booted using the appropriate PROM command. Usually, the miniroot will
+be loaded into the swap partition of a disk. If needed, you can use any
+other unused partition, but remember that the partition will then not
+available during the installation process.
+
+Loading the miniroot onto your raw partition is simple. On OpenBSD as well
+as SunOS you use a command like:
+
+ # dd if=miniroot20.fs of=/dev/rsd0b bs=20b conv=sync
+
+(here `/dev/rsd0b' is assumed to be your swap partition). There's a
+potential problem here if /dev/rsd0b is actually in use as a swap
+partition by your currently running system. If you don't have another
+disk or partition to spare, you can usually get away with running this
+command anyway after first booting into single-user mode to ensure a
+quiet system.
+
+After transferring the miniroot to disk, bring the system down by:
+
+ # halt
+
+Then boot the miniroot by typing the appropriate command at the PROM:
+
+ > b sd(,,1)bsd -s # for sun4 monitors
+ ok boot sd(,,1)bsd -s # for version 1 OpenBOOT ROMs
+ ok boot disk:b bsd -s # for version 2 OpenBOOT ROMs
+
+If you've loaded the miniroot onto some other disk than `sd0' adapt
+the boot specifier accordingly, e.g.:
+
+ ok boot disk1:b bsd -s
+
+to boot from SCSI disk target 1 from a version 2 OpenBOOT ROM.
+
+This will cause the kernel contained in the miniroot to be booted.
+After the initial probe messages you'll asked to start the install
+or upgrade procedure. Proceed to the section `Running the installation
+scripts' below.
Installing using a diskless setup.
@@ -19,12 +65,12 @@ documentation that came with it (on SunOS systems, add_client(8) is a
good start).
Your Sparcstation expects to be able to download a second stage bootstrap
-program via TFTP after havinf acquired its IP address through RevARP when
+program via TFTP after having acquired its IP address through RevARP when
instructed to boot "over the net". It will look for a filename composed of
the machine's IP address followed by the machine's architecture, separated
by a period. For example, a sun4c machine which has been assigned IP
address 130.115.144.11, will make an TFTP request for `8273900B.SUN4C'.
-Normally, this file is symbolic link to an appropriate second-stage
+Normally, this file is a symbolic link to an appropriate second-stage
boot program, which should be located in a place where the TFTP daemon
can find it (remember, many TFTP daemons run in a chroot'ed environment).
You can find the boot program in `/usr/mdec/boot' in the OpenBSD/sparc
@@ -42,14 +88,29 @@ Here's an example to illustrate this whole mess:
else
server# set SKIP=0
server# set KARCH=SUN4C
- server# dd if=boot of=/tftpboot/boot.sparc.bsd.$KARCH skip=$SKIP bs=32
+ server# dd if=boot of=/tftpboot/boot.sparc.OpenBSD.$KARCH skip=$SKIP bs=32
server# cd /tftpboot
- server# ln -s boot.sparc.bsd.$KARCH 8273900B.$KARCH
+ server# ln -s boot.sparc.OpenBSD.$KARCH 8273900B.$KARCH
-Note: some versions of Openboot ROMs (sun4c) seem to require that the
+Note: some versions of Openboot ROMs (sun4c/sun4m) seem to require that the
boot program size is nicely rounded. Therefore it may be necessary to
strip(8) off the symbol table.
+After the boot program has been loaded into memory and given control by
+the PROM, it starts locating the machine's remote root directory through
+the BOOTPARAM protocol. First a BOOTPARAM WHOAMI request is broadcast
+on the local net. The answer to this request (if it comes in) contains
+the client's name. This name is used in next step, a BOOTPARAM GETFILE
+request -- sent to the server that responded to the WHOAMI request --
+requesting the name and address of the machine that will serve the client's
+root directory, as well as the path of the client's root on that server.
+
+Finally, this information (if it comes in) is used to issue a REMOTE MOUNT
+request to the client's root filesystem server, asking for an NFS file
+handle corresponding to the root filesystem. If successful, the boot
+rogram starts reading from the remote root filesystem in search of the
+kernel which is then read into memory.
+
As noted above in the section `Preparing your System for OpenBSD Installation',
you have several options when choosing a location to store the installation
@@ -77,7 +138,7 @@ A few configuration files need to be edited:
Enter the entries for the remotely mounted filesystems.
For example:
server:/export/root/client / nfs rw 0 0
- server:/export/exec/sun4.bsd /usr nfs rw 0 0
+ server:/export/exec/sun4.OpenBSD /usr nfs rw 0 0
Now you must populate the the `/dev' directory for your client. If you server
runs SunOS 4.x, you can simply change your working directory to `<root>/dev'
@@ -112,27 +173,25 @@ instead of `ok', type:
If you use a diskless setup with a separately NFS-mounted /usr filesystem,
mount /usr by hand now:
-openbsd# mount /usr
+OpenBSD# mount /usr
At this point, it's worth checking the disk label and partition sizes on
the disk you want to install OpenBSD onto. OpenBSD understands SunOS-style
disklabels, so if your disk was previously used by SunOS there will be
a usable label on it. Use `disklabel -e <disk>' (where <disk> is the
device name assigned by the OpenBSD kernel, e.g. `sd0') to view and
-modify the partition sizes. A comfortable size for the root filesystem
-partition is about 20MB; a good initial size for the swap partition is
-twice the amount of physical memory in your machine (though, unlike
-SunOS 4.x, there are no restrictions on the size of the swap partition
-that would render part of your memory unusable). A full binary installation
-takes about 60MB in `/usr'. Make all your partitions start and end on
-cylinder boundaries.
+modify the partition sizes. See the section `Preparing your System for
+OpenBSD Installation' above for suggestions about disk partition sizes.
+Make sure all your partitions start and end on cylinder boundaries.
NOTE: if you are installing on a SCSI disk that does *not* have a SunOS
or OpenBSD label on it, you may still be able to use disklabel(8) but you'll
have to create all partitions from scratch. If your disk is listed in
`/etc/disktab', you may use the entry (which in most cases only defines
a `c' partition to describe the whole disk) to put an initial label on
-the disk.
+the disk. DO NOT USE `disklabel -r ...' TO INITIALIZE YOUR DISK LABEL;
+THIS WILL LEAD TO UNPREDICTABLE RESULTS. This deficiency will be fixed
+in a next release.
Here follows an example of what you'll see while in the dislabel editor.
Do not touch any of the parameters except for the `label: ' entry and
@@ -143,7 +202,7 @@ The size and offset fields are given in sector units. Be sure to make
these numbers multiples of the of the number of sectors per cylinder:
the kernel might be picky about these things, but aside from this you'll
have the least chance of wasting disk space.
-Partitions on which you intend to have a a mountable filesystem, should
+Partitions on which you intend to have a mountable filesystem, should
be given fstype `4.2BSD'. Remember, the `c' partition should describe
the whole disk.
The `(Cyl. x - y)' info that appears after the hash (`#') character is
@@ -156,7 +215,7 @@ the editor), then try setting it to `8 partitions:'.
<BEGIN SAMPLE DISKLABEL SCREEN>
-openbsd# disklabel sd2
+OpenBSD# disklabel sd2
# /dev/rsd2c:
type: SCSI
disk: SCSI disk
@@ -186,11 +245,11 @@ drivedata: 0
If you are upgrading a OpenBSD installation, start the upgrade script:
-openbsd# sh upgrade.sh
+OpenBSD# sh upgrade.sh
else, start the installation script:
-openbsd# sh install.sh
+OpenBSD# sh install.sh
These scripts will do most of the work of transferring the system from the
@@ -217,7 +276,7 @@ I'd suggest you "boot sd()bsd -bs", then try multiuser after that.
if you boot single-user the OpenBSD incantation to make the root
filesystem writable is
- openbsd# mount -u /dev/sd0a /
+ OpenBSD# mount -u /dev/sd0a /
The Sun monitor normally tries to load a file called "vmunix". On
OpenBOOT ROM systems you can change it to load OpenBSD instead using
@@ -233,13 +292,13 @@ On version 2 OpenBOOT ROMs:
ok setenv boot-device /sbus/esp/sd@0,0
-Congratulations, you have successfully installed OpenBSD RELEASE. When you
+Congratulations, you have successfully installed OpenBSD 2.0. When you
reboot into OpenBSD, you should log in as "root" at the login prompt.
There is no initial password, but if you're using the machine in a
networked environment, you should create yourself an account and
protect it and the "root" account with good passwords.
-Some of the files in the OpenBSD RELEASE distribution might need to be
+Some of the files in the OpenBSD 2.0 distribution might need to be
tailored for your site. In particular, the /etc/sendmail.cf file will
almost definitely need to be adjusted, and other files in /etc will
probably need to be modified. If you are unfamiliar with UN*X-like