diff options
| -rw-r--r-- | distrib/notes/mvme68k/contents | 78 | ||||
| -rw-r--r-- | distrib/notes/mvme68k/hardware | 55 | ||||
| -rw-r--r-- | distrib/notes/mvme68k/install | 361 | ||||
| -rw-r--r-- | distrib/notes/mvme68k/prep | 4 | ||||
| -rw-r--r-- | distrib/notes/mvme68k/upgrade | 6 | ||||
| -rw-r--r-- | distrib/notes/mvme68k/whatis | 5 | ||||
| -rw-r--r-- | distrib/notes/mvme68k/xfer | 78 | ||||
| -rw-r--r-- | distrib/notes/sparc/whatis | 6 |
8 files changed, 590 insertions, 3 deletions
diff --git a/distrib/notes/mvme68k/contents b/distrib/notes/mvme68k/contents new file mode 100644 index 00000000000..3a730e4b714 --- /dev/null +++ b/distrib/notes/mvme68k/contents @@ -0,0 +1,78 @@ +The mvme68k-specific portion of the OpenBSD 2.0 release is found in the +"mvme68k" subdirectory of the distribution. That subdirectory is laid +out as follows: + +.../2.0/mvme68k/ + INSTALL.mvme68k this document + tars/ mvme68k binary distribution sets; + see below. + tools/ Base GENERIC kernel, tools, + and an installation script. + +The OpenBSD/mvme68k binary distribution sets contain the binaries which +comprise the OpenBSD 2.0 release for the mvme68k. There are seven binary +distribution sets, and the "security" distribution set. The binary +distribution sets can be found in subdirectories of the "mvme68k/tars" +subdirectory of the OpenBSD 2.0 distribution tree, and are as follows: + + base20 The OpenBSD/mvme68k 2.0 base binary distribution. You + MUST install this distribution set. It contains the + base OpenBSD utilities that are necessary for the + system to run and be minimally functional. It + includes shared library support, and excludes + everything described below. + [ 8.0M gzipped, 24.4M uncompressed ] + + comp20 The OpenBSD/mvme68k Compiler tools. All of the tools + relating to C, C++, and FORTRAN. + This set includes the system include files + (/usr/include), the linker, the compiler tool chain, + and the various system libraries (except the shared + libraries, which are included as part of the base + set). This set also includes the manual pages for all + of the utilities it contains, as well as the system + call and library manual pages. + [ 5.4M gzipped, 17.6M uncompressed ] + + etc20 This distribution set contains the system + configuration files that reside in /etc and in several + other places. This set MUST be installed if you are + installing the system from scratch, but should NOT be + used if you are upgrading. (If you are upgrading, + it's recommended that you get a copy of this set and + CAREFULLY upgrade your configuration files by hand.) + [ 62K gzipped, 338K uncompressed ] + + games20 This set includes the games and their manual pages. + [ 2.9M gzipped, 7.4M uncompressed ] + + man20 This set includes all of the manual pages for the + binaries and other software contained in the base set. + Note that it does not include any of the manual pages + that are included in the other sets. + [ 0.8M gzipped, 3.3M uncompressed ] + + misc20 This set includes the system dictionaries (which are + rather large), the typesettable document set, and + man pages for other architectures which happen to be + installed from the source tree by default. + [ 1.9M gzipped, 6.6M uncompressed ] + + text20 This set includes OpenBSD's text processing tools, + including groff, all related programs, and their + manual pages. + [ 0.8M gzipped, 3.1M uncompressed ] + +The mvme68k binary distribution sets are distributed in the same form as +the source distribution sets; catted together, the members of a set +form a gzipped tar file. Each mvme68k binary distribution set also has +its own "CKSUMS" file, just as the source distribution sets do. The +binary sets are "rooted" at /, that is, if you want to extract the +binaries "into" your system, i.e. replace the system binaries with +them, you have to run the "tar xfp" from /. Also note that if you +upgrade or install this way, those programs that you are using at the +time will NOT be replaced. If you follow the normal installation or +upgrade procedures, this will be taken care of for you. + +The "mvme68k/install" directory contains an install script, and a +GENERIC kernel. diff --git a/distrib/notes/mvme68k/hardware b/distrib/notes/mvme68k/hardware new file mode 100644 index 00000000000..fead464a3b7 --- /dev/null +++ b/distrib/notes/mvme68k/hardware @@ -0,0 +1,55 @@ +OpenBSD/sparc 2.0 runs on the following classes of machines: + - sun4c (e.g. the SS1, SS1+, SS2, IPC, ELC, IPX, and SLC) + - sun4 (e.g. the 4/100, 4/200, and 4/300. note that support + for the 4/400 processor is incomplete) + - sun4m (e.g. sparc classic, 4, 5, 10, and 20) + +OpenBSD/sparc 2.0 does *not* run on these machines (yet): + - sun-4/400 (lacking support for the I/O cache, and has + ethernet problems) + - sun4d (e.g. sparc center 2000) + - sun4u (e.g. Ultrasparcs) + +The minimal configuration requires 4M of RAM and ~60M of disk space. +To install the entire system requires much more disk space, and to run +X or compile the system, more RAM is recommended. (OpenBSD with 4M of +RAM feels like Solaris with 4M of RAM.) Note that until you have +around 16M of RAM, getting more RAM is more important than getting a +faster CPU.) + +Supported devices include: + sun4c sbus video: + cgsix, cgthree, and bwtwo frame buffers + sun4 video (not thoroughly tested?): + P4 on-board bwtwo, and VME cgtwo card + serial ports: + ttya and ttyb (can be used as console if needed) + ethernet: + on-board AMD Lance ethernet ("le0"), + Sbus AMD Lance ethernet cards, + on-board Intel 82586 ethernet (ie0 on 4/100's and 4/200's), + VME Intel 82586 ethernet cards + SCSI: + on-board "esp" SCSI controller (sun4c's, and the 4/300), + sbus "esp" SCSI controller, + Sun "SUN-3"/"si" VME SCSI controller (polled mode only, slow), + Sun "SCSI Weird"/"sw" on-board controller (4/110 only, polled) + VME disks: + Xylogics 7053 VME/SMD disk controller ("xd"), + Xylogics 450/451 VME disk controller ("xy") + [note: VME/IPI disks are not supported] + sun floppy disk drive on sun4c's + sun keyboard and mouse + sun4c audio + + +Hardware the we do NOT currently support, but get many questions +about: + multiprocessor machines + audio drivers for sun4m machines + floppy driver for sun4m machines + interrupt driven SCSI driver for sun-4/100's and sun-4/200's + +The next release will hopefully run on many more machines. In +particular, some Sun4m support will be there. + 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". diff --git a/distrib/notes/mvme68k/prep b/distrib/notes/mvme68k/prep new file mode 100644 index 00000000000..bdd53ff5829 --- /dev/null +++ b/distrib/notes/mvme68k/prep @@ -0,0 +1,4 @@ +; +; This section should talk about setting up the NVRAM environment +; on the various models. +; diff --git a/distrib/notes/mvme68k/upgrade b/distrib/notes/mvme68k/upgrade new file mode 100644 index 00000000000..cc43a36d291 --- /dev/null +++ b/distrib/notes/mvme68k/upgrade @@ -0,0 +1,6 @@ +To upgrade to OpenBSD 2.0 from a previous version follow the instructions +in the section "Installing OpenBSD", but run the script `upgrade.sh' +in stead of `install.sh'. + +The upgrade script will use the existing disk partitions to install the +new system in, and also preserves the files in `/etc'. diff --git a/distrib/notes/mvme68k/whatis b/distrib/notes/mvme68k/whatis new file mode 100644 index 00000000000..eb399d82882 --- /dev/null +++ b/distrib/notes/mvme68k/whatis @@ -0,0 +1,5 @@ +OpenBSD/mvme68k 2.0 was written under contract for Willowglen Singapore +for an embedded application. Theo de Raadt, Dale Rahn, and Chuck Cranor +were involved in working on this port which runs on the MVME147, MVME162, +MVME167 and perhaps other models also. + diff --git a/distrib/notes/mvme68k/xfer b/distrib/notes/mvme68k/xfer new file mode 100644 index 00000000000..221c6cb9f4a --- /dev/null +++ b/distrib/notes/mvme68k/xfer @@ -0,0 +1,78 @@ +Installation is supported from several media types, including: + NFS partitions + FTP + Tape + +The steps necessary to prepare the distribution sets +for installation depend on which method of installation +you choose. The various methods are explained below. + +To prepare for installing via an NFS partition: + + Place the OpenBSD software you wish to install into + a directory on an NFS server, and make that directory + mountable by the machine which you will be installing + OpenBSD on. This will probably require modifying the + /etc/exports file of the NFS server and resetting + mountd, acts which will require superuser privileges. + Note the numeric IP address of the NFS server and of + the router closest to the the new OpenBSD machine, + if the NFS server is not on a network which is + directly attached to the OpenBSD machine. + + If you are using a diskless setup to install OpenBSD on + your machine, you can take advantage of the fact that + the above has already been done on your machine's server. + So, you can conveniently put the OpenBSD filesets in your + machine's root filesystem on the server where the install + program can find them. + + Once you have done this, you can proceed to the next + step in the installation process, preparing your + system for OpenBSD installation. + +To prepare for installing via FTP: + + NOTE: this method of installation is recommended + only for those already familiar with using + the BSD network-manipulation commands and + interfaces. If you aren't, this documentation + should help, but is not intended to be + all-encompassing. + + The preparations for this method of installation + are easy: all you have to do is make sure that + there's some FTP site from which you can retrieve + the OpenBSD installation when it's time to do + the install. You should know the numeric IP + address of that site, the numeric IP address of + your nearest router if one is necessary + + Once you have done this, you can proceed to the next + step in the installation process, preparing your + system for OpenBSD installation. + +To prepare for installing via a tape: + + To install OpenBSD from a tape, you need to somehow + get the OpenBSD filesets you wish to install on + your system on to the appropriate kind of tape, + in tar format. + + If you're making the tape on a UN*X system, the easiest + way to do so is: + + tar cvf <tape_device> <files> + + where "<tape_device>" is the name of the tape device + that describes the tape drive you're using (possibly + something like /dev/nrst0, but we make no guarantees 8-). + Under SunOS 5.x, this would be something like /dev/rmt/0mbn. + Again, your mileage may vary. If you can't figure it out, + ask your system administrator. "<files>" are the names + of the "set_name.nnn" files which you want to be placed + on the tape. + + Once you have done this, you can proceed to the next + step in the installation process, preparing your + system for OpenBSD installation. diff --git a/distrib/notes/sparc/whatis b/distrib/notes/sparc/whatis index 7435a57969f..9afa18af6cc 100644 --- a/distrib/notes/sparc/whatis +++ b/distrib/notes/sparc/whatis @@ -1,5 +1,5 @@ -OpenBSD 2.0 is brought to you by the same people who did the first free -BSD port (based on Chris Torek's 4.4BSD work). Many more sparc models -and devices are now supported. +OpenBSD/sparc 2.0 is brought to you by the same people who did the first +free BSD port (based on Chris Torek's 4.4BSD work). Many more sparc +models and devices are now supported. In addition to the SunOS 4.1 compatibility, OpenBSD 2.0 will also run some number of SunOS 5 (SVR4) executables in binary emulation mode. |