amiga and sun3 turned out to not be y2k+3 compliant here. Remove them, as

well as the few userland tools which were only used on these platforms.

7 files changed, 0 insertions, 540 deletions

diff --git a/distrib/notes/sun3/contents b/distrib/notes/sun3/contents
deleted file mode 100644
index 7976ed41fc0..00000000000
--- a/distrib/notes/sun3/contents
+++ /dev/null
@@ -1,39 +0,0 @@
-TopPart
-
-OpenBSDdistsets
-
-OpenBSDbsd
-
-OpenBSDrd
-
-		installboot	The OpenBSD/MACHINE boot loader installation
-				program.
-		bootxx		The OpenBSD/MACHINE boot block.
-		netboot		The OpenBSD/MACHINE network boot loader.
-		tapeboot	The OpenBSD/MACHINE tape boot loader.
-		ufsboot		The OpenBSD/MACHINE disk boot loader.
-
-These files can be used to make a boot tape suitable for installing
-OpenBSD/MACHINE.  These files can also be used to configure an NFS server
-to support installation "over the network".  See the section "Getting
-the OpenBSD System onto Useful Media" for instructions on either method.
-
-DistributionDescription(nine)
-
-OpenBSDbase(2293,69.5,shared)
-
-OpenBSDcomp(16.0,47.9,shared)
-
-OpenBSDetc(1.5,5.5)
-
-OpenBSDgame(2.8,6.6)
-
-OpenBSDman(5.6,20.0)
-
-OpenBSDmisc(1.7,5.6)
-
-OpenBSDxbase(7.0,20.3)
-
-OpenBSDxfont(32.3,35.9)
-
-OpenBSDxshare(1.6,7.7)
diff --git a/distrib/notes/sun3/hardware b/distrib/notes/sun3/hardware
deleted file mode 100644
index f4eca39e5cb..00000000000
--- a/distrib/notes/sun3/hardware
+++ /dev/null
@@ -1,43 +0,0 @@
-OpenBSD/MACHINE OSREV runs on most MACHINE machines, including:
-		3/50
-		3/60, 3/60LE
-		3/75, 3/110, 3/1[4568]0
-		3/2[68]0
-
-OpenBSD/MACHINE OSREV does not run on the Sun 3/80 and Sun 3/4x0 (sun3x
-class) because the sun3x MMU and other devices are very different.
-
-The minimal configuration requires 4M of RAM and ~80MB of disk space.
-To install the entire system requires much more disk space (at least
-200MB is recommended, without counting the additional space necessary
-for sources or packages). To run X or compile the system, more memory
-is recommended. Acceptable performance requires 8MB of RAM, or 16 MB
-when running the X Window System.
-
-The following MACHINE hardware is supported:
-
-	Serial ports (RS232):
-		built-in ttya, ttyb
-
-	Video adapters:
-		bwtwo, cgtwo, cgfour
-
-	Network interfaces:
-		On-board Lance Ethernet (le)
-		On-board or VME Intel Ethernet (ie)
-
-	SCSI:  (Most SCSI disks, tapes, CD-ROMs, etc.)
-		On-board "si" (SCSI-3)
-		VME "si" (SCSI-3) board
-
-	SMD Disks Controlers:
-		Xylogics 450/451
-		Xylogics 750/7053
-
-	Input devices:
-		Sun keyboard and mouse
-
-	Miscellaneous:
-		Battery-backed real-time clock.
-
-Hardware not listed here is likely to be unsupported by this release.
diff --git a/distrib/notes/sun3/install b/distrib/notes/sun3/install
deleted file mode 100644
index 35a090c396a..00000000000
--- a/distrib/notes/sun3/install
+++ /dev/null
@@ -1,326 +0,0 @@
-dnl	$OpenBSD: install,v 1.20 2002/06/09 05:53:55 todd Exp $
-OpenBSDInstallPrelude
-
-There are several ways to install OpenBSD onto a disk. The easiest way
-in terms of preliminary setup is to use the OpenBSD miniroot that can
-be booted off a tape.
-
-If your MACHINE is hooked up in a network and you can find a server to
-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.
-This is difficult to get set up correctly the first time, but easy to
-use afterwards.  (see ``Installing using a diskless setup'' below).
-
-It is also possible to install OpenBSD "manually" from a running SunOS
-system, using the system tools, as well as gnu tar and gunzip (see
-``Installing from SunOS'' below).
-
-
-Booting from the Installation Media:
-
-Prior to attempting an installation, you should make sure that everything
-of value on the target system has been backed up.  While installing OpenBSD
-does not necessarily wipe out all the partitions on the hard disk, errors
-during the install process can have unforeseen consequences and you will
-probably render the system unbootable if you start, but do not complete
-the installation.  Have the installation media for the prior installation,
-be it a SunOS or OpenBSD tape is good insurance if you want to be able to
-"go back" for some reason.
-
-After taking care of all that, bring your system down gracefully using
-the shutdown(8) and/or halt(8) commands.  This will get you to the monitor
-prompt.
-
-
-Booting from SCSI tape:
-
-Boot the miniroot by typing the appropriate command at the PROM:
-
-	> b st()
-	
-The above instructions assume your tape drive is the default tape drive
-using SCSI id 4. If your drive uses id 5, modify the boot command
-accordingly:
-
-	> b st(,28,)
-	
-This will cause the kernel contained in the miniroot to be booted.
-
-
-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) and
-the Sun System/Networks administrators guide constitute a good start;
-on Solaris systems, share(1M) is a good starting point as well).
-
-Boot your workstation from the server by entering the appropriate `boot'
-command at the monitor prompt. Depending on the ethernet chip in your
-machine, this command takes one of the following forms:
-
-	> b le()bsd.rd		# for sun pizza boxes (3/50, 3/60)
-	> b ie()bsd.rd		# for other MACHINE
-
-In order to have a MACHINE machine boot diskless by default, you need to
-do some nvram wizardry:
-
-	> q 18
-	12
-then, if your machine is a model 3/50 or 3/60, continue with:
-	6c
-	65
-	00
-	00
-	00
-or, for other MACHINE machines:
-	69
-	65
-	00
-	00
-	00
-and return to the prom prompt with:
-	q
-	>
-
-The above set of commands has changed the boot path strategy to the
-network interface, thus a diskless boot.
-To change the strategy in diagnostic mode (when the "Diag/Norm" switch
-is set to "Diag"), enter the same set of data after a "q 22" command
-instead of "q 18".
-Remember that the prom having a limited number of write cycles, you
-shouldn't abuse this feature.
-
-Installing using the Tape or netboot procedure:
-
-OpenBSDInstallPart2
-
-	Boot your machine from the installation media as described above.
-
-	It will take a while to load the kernel especially from a
-	slow network connection, most likely more than a minute.  If
-	some action doesn't eventually happen, or the spinning cursor has
-	stopped and nothing further has happened, either your boot medias
-	is probably bad, your diskless setup isn't correct or you may have
-	a hardware or configuration problem.
-
-OpenBSDBootMsgs
-
-	You will next be asked for your terminal type.  If you are
-	installing from a keyboard/monitor console, the default of
-	"sun" if correct.  If you are installing from a serial console
-	you should choose the terminal type from amongst those listed.
-	(If your terminal type is xterm, just use vt100).
-
-OpenBSDInstallPart3
-
-OpenBSDInstallPart4
-
-OpenBSDInstallPart5(sd0)
-
-OpenBSDInstallNet({:-CD-ROM, NFS, -:})
-
-OpenBSDFTPInstall
-
-OpenBSDHTTPInstall
-
-OpenBSDCDROMInstall
-
-OpenBSDTAPEInstall(3)
-
-OpenBSDNFSInstall
-
-OpenBSDDISKInstall({:-"xdN" or -:},{:-only -:})
-
-OpenBSDCommonFS
-		
-OpenBSDCommonURL
-
-OpenBSDCongratulations
-
-If you will be running your OpenBSD system from a serial console, you may
-need to edit /etc/ttys and change the terminal type, and getty method from
-"sun" and "console" to "vt100" and "std.9600" or something similar.
-
-In order to use 'tip' on OpenBSD/MACHINE, you'll need to edit /etc/ttys
-and add "local" to the end of the tty configuration line, and run
-'ttyflags -a' to put your changes into effect.
-
-
-
-Installing from SunOS:
-
-You need a SunOS machine to install OpenBSD.  You also need at
-least the following pieces:
-
-  - the *.tgz files you want to install (as a minimum, base{:--:}OSrev.tgz and
-    etc{:--:}OSrev.tgz)
-  - gunzip (GNU gzip) SunOS binary
-  - gtar (GNU tar) SunOS binary
-  - a "/boot" file from a SunOS MACHINE machine (not sun3x!)
-  - an OpenBSD kernel
-
-All these pieces, except "/boot" and the GNU utilities are supplied in
-the OpenBSD/MACHINE distribution.
-
-You need to format and partition the disk using SunOS (since
-OpenBSD/MACHINE uses SunOS disk labels.)  Give yourself adequate
-partition sizes.  Here is an example layout:
-
-    partition    size   offset	  will be..
-    sd0a        80000        0	  /
-    sd0b       256000    80000	  swap
-    sd0c      4165271        0	  `whole disk'
-    sd0d       100000   436000    /var
-    sd0f       100000   336000    /tmp
-    sd0g      3229271   936000    /usr
-    sd0h       400000   536000    /var/tmp
-
-Use SunOS to newfs the partitions which will have filesystems on them.
-(OpenBSD's filesystem format is identical to SunOS).
-
-    sunos# newfs /dev/rsd0a
-    [... lots of output]
-
-Repeat for any other partition (in this example, /dev/rsd0d, /dev/rsd0f,
-/dev/rsd0g, /dev/rsd0h).
-
-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/sd0a              38427       0   38427     0%    /mnt
-    /dev/sd0d              48249       0   48249     0%    /mnt/var
-    /dev/sd0f              48249       0   48249     0%    /mnt/tmp
-    /dev/sd0g            1564024       0 1564024     0%    /mnt/usr
-    /dev/sd0h             193536       0  193536     0%    /mnt/var/tmp
-
-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 /usr/mdec/ufsboot /mnt/boot
-    sunos# sync; sync
-    sunos# /usr/mdec/installboot -vlt /mnt/boot /usr/mdec/bootxx /dev/rsd0a
-
-You can now extract the provided "*.tgz files onto your disk.
-
-    sunos# ls -FC
-    base{:--:}OSrev.tgz   comp{:--:}OSrev.tgz   game{:--:}OSrev.tgz   misc{:--:}OSrev.tgz
-    bsd          etc{:--:}OSrev.tgz    man{:--:}OSrev.tgz
-    sunos{:-#-:} gunzip < base{:--:}OSrev.tgz | (cd /mnt; gtar xvpf -)
-    [...] for each set
-
-And finally copy the OpenBSD kernel onto your disk.
-
-    sunos# cp bsd /mnt/bsd
-
-The GNU gunzip and gtar programs are not distributed as part of SunOS,
-but may be present in your /usr/local/bin.  If not, you will need to
-obtain them from a GNU archive and install before proceeding.  The
-OpenBSD tar files are in the "new format" that includes directory
-information, and the standard SunOS tar will not extract from them
-successfully.
-
-After the files have been extracted, setup /mnt/etc/fstab to match
-your actual disk layout.  (Minus the "/mnt" component of each path, of
-course :-)
-
-Now proceed to reboot the machine and the customize your installation.
-
-
-
-Net Boot or Diskless Setup Information:
-
-The setup is similar to SunOS diskless setup, but not identical, because
-the Sun setup assumes that the bootblocks load a kernel image, which then
-uses NFS to access the exported root partition, while the OpenBSD bootblocks
-use internal NFS routines to load the kernel image directly from the
-exported root partition.
-
-Please understand that no one gets this right the first try, since
-there is a lot of setup and all the host daemons must be running and
-configured correctly.  If you have problems, extract the diskless(8)
-manpage, find someone who's been through it before and use the host
-syslog and tcpdump(8) to get visibility of what's happening (or not).
-
-Your MACHINE 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
-corresponding to the machine's IP address. For example, a MACHINE machine
-which has been assigned IP address 130.115.144.11, will make an TFTP
-request for `8273900B'.
-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/netboot' in the OpenBSD/MACHINE
-distribution.
-
-Here's an example to illustrate this whole mess:
-
-    server# cd /<client-root-dir>/usr/mdec
-    server# cp boot /tftpboot/boot.MACHINE.OpenBSD
-    server# cd /tftpboot
-    server# ln -s boot.MACHINE.OpenBSD 8273900B
-
-
-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
-program starts reading from the remote root filesystem in search of the
-kernel which is then read into memory.
-
-You will want export the miniroot{:--:}OSrev.fs filesystem to the client.  You
-can dd this filesystem image to some spare partition, mount and export
-that partition or use tar to copy the contents to a more convenient spot.
-
-Alternatively you can build a bootable partition from the distribution sets
-as follows:
-
-Unpack `base{:--:}OSrev.tgz' and `etc{:--:}OSrev.tgz' on the server in the root directory
-for your target 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{:--:}OSrev.tgz 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/MACHINE.OpenBSD /usr  nfs  rw 0 0
-
-Now you must populate the the `/dev' directory for your client. For
-this, you can simply change your working directory to `<root>/dev'
-and run the MAKEDEV script: `sh MAKEDEV all' (this might require the edition
-of MAKEDEV to change the PATH for it to work properly).
diff --git a/distrib/notes/sun3/prep b/distrib/notes/sun3/prep
deleted file mode 100644
index b5be2832fbc..00000000000
--- a/distrib/notes/sun3/prep
+++ /dev/null
@@ -1,60 +0,0 @@
-Most MACHINE machines usually need little or no preparation before
-installing OpenBSD, other than the usual, well advised precaution
-of BACKING UP ALL DATA on any attached storage devices.
-
-You will need to know the SCSI target ID of the drive on which you
-will install OpenBSD.
-
-It might be a good time to run the diagnostics on your MACHINE.  First,
-attach a terminal to the "ttya" serial port, then set the "Diag/Norm"
-switch to the Diagnostic position, and power-on the machine.  The
-Diag. switch setting forces console interaction to occur on ttya.
-
-The console location (ttya, ttyb, or keyboard/display) is controlled
-by address 0x1f in the EEPROM, which you can examine and change in
-the PROM monitor by entering "q 1f", then a numeric value (or just a
-'.' if you don't want to change it, and "q" again to return to the prom).
-Console values are:
-	00: monochrome framebuffer (on-board or VME)
-	10: tty a (9600-N-8-1)
-	11: tty b (1200-N-8-1)
-	12: color framebuffer
-	20: color option board on P4 (model 3/60 only)
-
-OpenBSD will use the EEPROM setting to determine which device to
-use as the console, so you should make sure it is correct.
-
-Please note that while OpenBSD and SunOS have a reasonable degree of
-compatibility between disk labels and filesystems there are some problems
-to watch out for during initial installation or when trying to maintain
-both OpenBSD and SunOS environments on the same system.
-
-    If the OpenBSD fsck(8) utility is used on a SunOS filesystem, it will
-    set OpenBSD "clean flags" and BSD4.4 summary fields in the superblock.
-    SunOS does *not* like this and you will have to do a "fsck -b 32" under
-    SunOS to access an alternate superblock to repair the filesystem.  You
-    should always specify SunOS filesystem with a "pass number" of 0 in
-    their /etc/fstab entry to prevent this, and preferably mount them "RO".
-
-    If SunOS fsck is used on an OpenBSD filesystem in the default OpenBSD
-    (4.4BSD) format, it will first complain about the superblock and then
-    about missing . and .. entries.  Do *not* try to "correct" these
-    problems, as attempting to do so will completely trash the filesystem.
-
-    You should avoid using softupdates (option softdep in /etc/fstab)
-    on your shared filesystems.
-    Although untested, it is likely that SunOS would be confused by a
-    filesystem with soft update flags enabled.
-
-The OpenBSD "Sun Compatible" disklabel have been extended to support 16
-partitions, however the old SunOS format(8) utility only sees the first
-8 partitions and may "lose" information about the extended partitions.
-
-Use SunOS format(8) only with *extreme* caution on drives that contain
-OpenBSD partitions.
-
-OpenBSD and Sun BSD bootblocks are similar in concept, though implemented
-differently.  The OpenBSD bootblocks are architecture independent and also
-understand the extended disklabels with 16 partitions.  You can use SunOS
-bootblocks, but remember that OpenBSD bootblocks must be installed with
-OpenBSD installboot and SunOS bootblocks with SunOS installboot.
diff --git a/distrib/notes/sun3/upgrade b/distrib/notes/sun3/upgrade
deleted file mode 100644
index 944f3bfb16a..00000000000
--- a/distrib/notes/sun3/upgrade
+++ /dev/null
@@ -1 +0,0 @@
-OpenBSDUpgrade({:-the miniroot, or an installation tape-:})
diff --git a/distrib/notes/sun3/whatis b/distrib/notes/sun3/whatis
deleted file mode 100644
index 3918543440b..00000000000
--- a/distrib/notes/sun3/whatis
+++ /dev/null
@@ -1,2 +0,0 @@
-OpenBSD/MACHINE OSREV is a port to the ``MACHINE'' series of workstations
-manufactured by Sun in the late 1980s.
diff --git a/distrib/notes/sun3/xfer b/distrib/notes/sun3/xfer
deleted file mode 100644
index cdf778df381..00000000000
--- a/distrib/notes/sun3/xfer
+++ /dev/null
@@ -1,69 +0,0 @@
-Installation is supported from several media types, including:
-
-	CD-ROM (with PROM versions >= 3.0)
-	FFS partitions
-	Tape
-	Remote NFS partition
-	FTP
-	HTTP
-
-However, you can only boot the installation procedure from disk, tape or
-network. This requires some setup work to prepare a bootable image,
-either a tape, or a compatible net boot server.
-
-Although you can access the distribution sets directly from one of the
-FTP mirrors over the internet, you may wish to transfer the sets to a
-local FTP or NFS server, or copy them to a partition on the target
-system's disk or onto a SCSI tape.
-
-
-Creating a bootable hard disk using SunOS or other Un*x-like system:
-
-	You can copy the miniroot image "miniroot{:--:}OSrev.fs" onto
-	the hard disk you intend to boot on.  Traditionally, the
-	way to do this is to use dd(1) to place the bootable filesystem
-	image in the "swap" partition of the disk (while running in
-	single user mode), and then booting from that partition.
-
-	Using the "b" partition allows you to boot without overwriting
-	any useful parts of the disk. You can also use another partition,
-	but don't use the "a" or "c" partition without understanding
-	the disklabel issues described below under "incompatible systems".
-
-	This requires that you are running SunOS, Solaris, OpenBSD or NetBSD
-	which have a compatible view of SunOS disk labels and partitions.
-
-	Use the dd(1) utility to copy the file to the hard drive.
-	Under SunOS, the command would be:
-
-		dd if=miniroot{:--:}OSrev.fs of=/dev/rsd0b bs=36b
-
-	The blocksize is arbitrary as long as it's a multiple of 512-bytes
-	and within the maximum supported by the driver, i.e. bs=126b may
-	not work for all cases.  Again, device/partition names may vary,
-	depending on the OS involved.
-
-
-Creating a network bootable setup using SunOS or other Un*x-like system:
-
-	The details of setting up a network bootable environment vary
-	considerably, depending on the networks host.  Extract the
-	OpenBSD diskless(8) man page from the man{:--:}OSrev.tgz distribution
-	set or see the copy on the OpenBSD web page.  You will also
-	need to reference the relevant man pages or administrators guide
-	for the host system.
-	
-	Basically, you will need to set up reverse-arp (rarpd) and boot
-	parameter (bootpd) information and make the OpenBSD bootblock,
-	kernel/miniroot partition, and a swap file available as required
-	by the netboot setup.
-
-
-OpenBSDXferPrelude
-
-
-OpenBSDXferBootTape(,tapeboot obs=8k conv=sync,bsd.rd obs=8k conv=sync)
-
-OpenBSDXferNFS
-
-OpenBSDXferFFS