diff options
Diffstat (limited to 'distrib/notes/mvme68k/install')
| -rw-r--r-- | distrib/notes/mvme68k/install | 361 |
1 files changed, 361 insertions, 0 deletions
diff --git a/distrib/notes/mvme68k/install b/distrib/notes/mvme68k/install new file mode 100644 index 00000000000..193b95f75e0 --- /dev/null +++ b/distrib/notes/mvme68k/install @@ -0,0 +1,361 @@ +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. 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. + +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. + +First, you must setup a diskless client configuration on a server. If +you are using a OpenBSD system as the boot-server, have a look at the +diskless(8) manual page for guidelines on how to proceed with this. +If the server runs another operating system, you'll have to consult +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 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 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 +distribution. Unfortunately, it is necessary to install this file +differently for sun4 and sun4c clients: the sun4 version needs to have its +`a.out' header stripped off (otherwise the machine will crash), while the +sun4c version must retain it (otherwise the PROM will complain). + +Here's an example to illustrate this whole mess: + + server# cd /<client-root-dir>/usr/mdec + if client is a sun4: + server# set SKIP=1 + server# set KARCH=SUN4 + else + server# set SKIP=0 + server# set KARCH=SUN4C + server# dd if=boot of=/tftpboot/boot.sparc.OpenBSD.$KARCH skip=$SKIP bs=32 + server# cd /tftpboot + server# ln -s boot.sparc.OpenBSD.$KARCH 8273900B.$KARCH + +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 +filesets. However, the easiest way is to put the *.tar.gz files you want +to install into the root directory for your client on the server. + +Next, unpack `base.tar.gz' and `etc.tar.gz' on the server in the root +directory for your machine. If you elect to use a separately NFS-mounted +filesystem for `/usr' with your diskless setup, make sure the "./usr" base +files in base.tar.gz end up in the correct location. One way to do this is +to temporarily use a loopback mount on the server, re-routing <root>/usr to +your server's exported OpenBSD "/usr" directory. Also put the kernel and the +install/upgrade scripts into the root directory. + +A few configuration files need to be edited: + + <root>/etc/hosts + Add the IP addresses of both server and client. + + <root>/etc/myname + This files contains the client's hostname; use the same + name as in <root>/etc/hosts. + + <root>/etc/fstab + Enter the entries for the remotely mounted filesystems. + For example: + server:/export/root/client / 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' +and run the MAKEDEV script: `sh MAKEDEV all'. + +On SunOS 5.x systems, MAKEDEV can also be used, but there'll be error +messages about unknown user and groups. These errors are inconsequential +for the purpose of installing OpenBSD. However, you may want to correct them +if you plan to the diskless setup regularly. In that case, you may re-run +MAKEDEV on your OpenBSD machine once it has booted. + +Boot your workstation from the server by entering the appropriate `boot' +command at the monitor prompt. Depending on the PROM version in your machine, +this command takes one of the following forms: + + > b le()bsd -s # for sun4 monitors + ok boot le()bsd -s # for version 1 OpenBOOT ROMs + ok boot net bsd -s # for version 2 OpenBOOT ROMs + +This will boot the OpenBSD kernel in single-user mode. + +[[ +NOTE: the latter two examples assume you operate the OpenBOOT ROM in +"new command mode". If your machine comes up and gives you a `>' prompt +instead of `ok', type: + + >n # enter native OpenBOOT mode + ok setenv sunmon-compat? false # make it permanent + ok +]] + +If you use a diskless setup with a separately NFS-mounted /usr filesystem, +mount /usr by hand now: + +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. 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. 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 +the actual partition size information at the bottom (the lines starting +with `a:', `b:', ...). + +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 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 +treated as a comment and need not be filled in when altering partitions. + +Special note: the line containing `8 partitions:' is best left alone, +even if you define less then eight partitions. If this line displays +a different number and the program complains about it (after you leave +the editor), then try setting it to `8 partitions:'. + + +<BEGIN SAMPLE DISKLABEL SCREEN> +OpenBSD# disklabel sd2 + # /dev/rsd2c: +type: SCSI +disk: SCSI disk +label: Hold Your Breath +flags: +bytes/sector: 512 +sectors/track: 64 +tracks/cylinder: 7 +sectors/cylinder: 448 +cylinders: 1429 +rpm: 3600 +interleave: 1 +trackskew: 0 +cylinderskew: 0 +headswitch: 0 # milliseconds +track-to-track seek: 0 # milliseconds +drivedata: 0 + +8 partitions: +# size offset fstype [fsize bsize cpg] + a: 50176 0 4.2BSD 0 0 0 # (Cyl. 0 - 111) + b: 64512 50176 swap # (Cyl. 112 - 255) + c: 640192 0 unknown # (Cyl. 0 - 1428) + d: 525504 114688 4.2BSD 0 0 0 # (Cyl. 256 - 1428) +<END SAMPLE DISKLABEL SCREEN> + + +If you are upgrading a OpenBSD installation, start the upgrade script: + +OpenBSD# sh upgrade.sh + +else, start the installation script: + +OpenBSD# sh install.sh + + +These scripts will do most of the work of transferring the system from the +tar files onto your disk. You will frequently be asked for confirmation +before the script proceeds with each phase of the installation process. +Occasionally, you'll have to provide a piece of information such as the +name of the disk you want to install on or IP addresses and domain names +you want to assign. If your system has more than one disk, you may want +to look at the output of the dmesg(8) command to see how your disks +have been identified by the kernel. + +The installation script goes through the following phases: + + - determination of the disk to install OpenBSD on + - checking of the partition information on the disk + - creating and mounting the OpenBSD filesystems + - setup of IP configuration + - extraction of the distribution tar files + - installation of boot programs + + +Now try a reboot. (If needed, swap your scsi id's first). Initially +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 / + +The Sun monitor normally tries to load a file called "vmunix". On +OpenBOOT ROM systems you can change it to load OpenBSD instead using +the following commands: + +On version 1 OpenBOOT ROMs: + >n + ok setenv boot-from sd(0,0,0)bsd + ok + +On version 2 OpenBOOT ROMs: + ok setenv boot-file bsd + ok setenv boot-device /sbus/esp/sd@0,0 + + +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 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 +system administration, it's recommended that you buy a book that +discusses it. + + + +Installing from SunOS. + +You need a SunOS machine to install OpenBSD. You also need at +least the following pieces: + + the *.tar.gz files you want to install (as a minimum, base.tar.gz) + gzip (GNU gzip) SunOS binary + gtar (GNU tar) SunOS binary + the "install.sh" script + a "/boot" file from a SunOS machine that matches your machine type + (e.g. sun or sun4c) + a kernel, most likely "/bsd" + +All these pieces, except "/boot", are supplied in the OpenBSD/sparc +distribution. + +You need to format and partition the disk using SunOS (since +OpenBSD/sparc uses SunOS disk labels.) Give yourself adequate +partition sizes. Here is an example layout: + + partition size offset will be.. + sd2a 28140 0 / + sd2b 16170 28140 swap + sd2c 204540 0 `whole disk' + sd2g 160230 44310 /usr + +BTW, These are not recommended sizes. They simply match the first +(tiny) disk that OpenBSD/sparc ran on. + +Use SunOS to newfs the partitions which will have filesystems on them. +(OpenBSD's filesystem format is identical to SunOS). + + sunos# newfs /dev/rsd2a + [... lots of output] + sunos# newfs /dev/rsd2g + [... lots of output] + +NOTE: If you are able to, there is a performance benefit from +newfs'ing using OpenBSD. If you newfs using the OpenBSD newfs command, +be sure to use the -O flag for your / partition, so that newfs will +use the 4.3BSD filesystem format, rather than the new 4.4BSD filesystem +format. If you forget, you will not be able to boot -- the SunOS boot +blocks do not understand the extended 4.4BSD filesystem format. + +Mount those partitions in a tree formation, under /mnt; ie: + + sunos# df + Filesystem kbytes used avail capacity Mounted on + [...] + /dev/sd2a 11501 0 11501 0% /mnt + /dev/sd2g 179529 0 179529 0% /mnt/usr + +Place a standard SunOS "/boot" program in /mnt (your new root +partition), and use the SunOS command "installboot" to make it work. +The installboot man page says to do something like this: + + sunos# cp /boot /mnt/boot + sunos# /usr/mdec/installboot -vlt /mnt/boot /usr/mdec/bootsd /dev/rsd2a + +You can now extract the provided "*.tar.gz files onto your disk. The +provided script, "install_from_sunos.sh" will help you: + + sunos# ls -FC + base.tar.gz etc.tar.gz man.tar.gz secr.tar.gz + comp.tar.gz games.tar.gz misc.tar.gz text.tar.gz + install.sh bsd.id3_scsi + sunos# ./install_from_sunos.sh + [...] + +This script NEEDS gzip and gtar (GNU gzip and GNU tar) on your +execution path! The tar files are in a "new format" that includes +directory information, and SunOS tar will not read them. Statically +linked versions of these programs for SunOS are supplied in the +distribution. + +After the files have been extracted, repair /mnt/etc/fstab to match +your actual disk layout. (Minus the "/mnt" component of each path, of +course :-) + +Now proceed to reboot the machine as described above in "Installing +using a diskless setup". |