*BSD News Article 21480


Return to BSD News archive

Xref: sserve comp.os.386bsd.announce:121 comp.answers:2077 news.answers:12528
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!news.dell.com!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail
From: burgess@hrd769.brooks.af.mil (Dave Burgess)
Newsgroups: comp.os.386bsd.announce,comp.answers,news.answers
Subject: [comp.os.386bsd] Berkeley Net Release/2 derived BSD for PCs FAQ (Part 3 of 10)
Followup-To: comp.os.386bsd.announce
Date: 27 Sep 1993 13:14:27 -0000
Organization: Armstrong Laboratory, Brooks AFB, TX
Lines: 1423
Approved: news-answers-request@MIT.Edu
Distribution: world
Expires: 10/15/93
Message-ID: <386bsd-faq-3-749135665@hrd769.brooks.af.mil>
References: <386bsd-faq-1-749135665@hrd769.brooks.af.mil>
Reply-To: 386bsd-faq@hrd769.brooks.af.mil (386bsd FAQ Maintainer)
NNTP-Posting-Host: hrd769.brooks.af.mil

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part3

Section 2.	(Common installation questions)


2.0	Install process
	
	The 386 BSD system is distributed in many ways.  One of the most 
	common is via DOS diskettes, (either 3 1/2 or 5 1/4, both high 
	density) with the actual distribution being a 'CPIO archive' broken 
	into 240K pieces.  This allows the distribution to fit onto a 
	minimum number of floppies. 
	
	Once the files are on floppies, thoughts usually turn to questions 
	about how to install the boot image on a floppy.  The rawrite 
	program (for DOS) is used to write the bootable images (dist.fs and 
	fixit.fs) onto floppies.  The same image can used for 3 1/2 and 
	5 1/4 high density diskettes.  Low density diskettes are not 
	supported in this version of 386bsd.
	
	Once the bootable images are written onto the floppies, insert 
	the dist.fs disk into the A: drive and reboot.  If the system does 
	not boot, see section 2.5 below for more information.
	
	If the disk boots, type install and proceed to use the 
	INSTALL.NOTES to get more information.
	
	Problems with the install are either related to hardware (i.e. Do 
	you want to install on your T.V.?) or software.  Of the hardware 
	issues, the most common FAQs are usually straight out of the 
	installation notes.  Of the software issues, there are only two 
	that really concern us.  The first is bad files.
	
	On some systems, files that are loaded from floppy appear to 
	'go bad' when they arrive on the hard disk.  Try some of these 
	solutions:

	- You forgot binary.  Don't get insulted.  Those of us that FTP 
	for a living forget sometimes.  If so, the distribution will come 
	out with all different sizes and install will complain about every 
	disk.
	
	- One or two of the files are no good.  Try getting them again.  
	As a  precaution, rename the bad files on your hard drive to names 
	like foo.1 and bob.23.  Copy the files again from floppy.  If they 
	are still bad, rename the file, and the one immediately before the 
	first bad file (bin01.23 if bin02.24 is bad) and copy them again.  
	If they are still bad, download those files again from the 
	distribution site (including the one before and after the bad one) 
	and try again.  
	    The reason for renaming the files is that sometimes, especially 
	with drive that do not auto-magically record bad sectors, you could 
	copy a distribution file onto a bad spot on the disk.  If this 
	happens, you want to isolate the bad spot.  The easiest way to do 
	that is just leave the bad file on it.
	
	- Keep trying, these same files have been used by literally 
	thousands of people to install 386bsd.
	

2.0.1	Tiny boot disk  (versions and media formats)
	
	There is currently one official boot disk, referred to as the 
	"Tiny" boot disk.  In addition, there is at least one patched 
	unofficial boot disk available from agate and its mirror sites.

	There are a few FAQs from the boot/install disk.


2.0.1.1	Where does extract go when I reboot?
	
	It was in /tmp, which is cleaned the first time you reboot the 
	system from the hard drive.  If you have just booted from the 
	hard drive for the second time, chances are you just wiped out 
	extract.  It is not really needed, since the instructions for 
	building your own install are included in section 2.5.2 of 
	the FAQ, under custom installation.

	When installing NetBSD, the set_tmp_dir and extract programs are 
	part of the .profile that is booted when you are installing.  
	This .profile is overwritten as part of the install process, and
	extract then disappears.  If you need extract again, you can mount 
	the install disk and source .profile.  This will recreate these 
	two routines.

	There is also an install procedure that NetBSD uses that does
	the same job.  It is defined as part of the .profile on one of the
	installation floppies.  You can either copy it from there, or use
	the procedure for 'real disk partitioning'.

	
2.0.1.2	I put the floppy in and try to boot, and nothing happens.  What now?

	This is usually referred to as the Compaq boot problem.  The easiest 
	solution is to get a patched boot disk.  The normal source for this 
	disk is agate (also known by its real name agate.berkeley.edu) in 
	the directory /pub/386BSD/386bsd-0.1/unofficial/patchkit.

	Another source of possible hope for you is to grab the NetBSD bootable
	disks.  They are compatible with 386BSD and allow you to install on
	some of the more recalcitrant hardware.


2.0.1.3a	The floppy booted, but now the hard disk won't boot?
2.0.1.3b	I am trying to reinstall.  I run install and it loops asking
	          me if I want to use the whole disk?
	
	The most likely culprit is your hard disk controller.  It is 
	probably doing some type of disk translation for you.  If this is 
	the case (assume it is) then you will need to find out the real 
	disk controller geometry, and rewrite your disk label.  See section 
	2.6.2, but before doing that get the program pfdisk.exe from agate 
	(It is out there, somewhere in the ~unofficial/ref-tfs stuff).  
	This program will tell you what the controller geometry is (right 
	before it reboots your computer).  Make the disklabel agree with 
	this program and your system should boot.  You may have to 
	reinstall, but at least your disklabel will be right.

	NOTE:  If the hard disk controller does NOT have an option for
	turning off the geometry, you may well be completely out of
	luck.  There are very few controllers that fall into this
	category.  The ones that do full time translation will often
	boot up in translated mode.  pfdisk will help you determine the
	correct geometry for your drive by telling you what the geometry
	looks like when 386bsd boots up.  

	But on the other hand, maybe not...

	See section 2.5.5 below for a detailed set of instructions about
	getting NetBSD (and by implication 386BSD) to work with a system
	that uses full time translation.


2.0.1.4	There are a bunch of flashing colored things on the screen.  Now what?
	
	See section 2.7 below.  It gives a rather detailed description of 
	the cause and solution.

	
2.0.2	Fix-it boot disk 
	
	The fix-it disk contains a series of programs that are 
	particularly handy for 'fixing' your disk in case you can't get 
	logged in.  It includes the disklabel program and other utilities 
	for system maintenance.


2.1	Binary distribution

	The binary distribution consists of virtually all of the programs 
	that a typical Unix system would be expected to have.  The list 
	includes mail, UUCP, GCC version 1.39, and others.
	
	Known problems with the binary distribution include the following:
	
	1.  Mtools as shipped in the bindist does not always work.  The 
	ones on the install disk seem to work fine.
	
	2.  The install script built into the binary distribution does 
	not correctly install all of the files and symbolic links that it 
	should.  For example,  some of the symbolic links to the 
	/usr/include directory are botched up.
	
	3.  'tip', the modem control program, does not always work right 
	out of the box.
	
	4.  Any program that relies on a valid symbol table in the kernel 
	(e.g. ps) will not work because the kernel is stripped so that it 
	will fit onto the bootable disk.

	These problems are all cured either by patches available in the
	patchkit, or through re-compilation.


2.2	Source distribution

	The source distribution contains all of the source code for every 
	program in the bindist.  Known problems (which are fixed in the 
	patchkit) include the following:
	
	1.  There is an error message during install about install.src01 
	not being found.  It is not an error, there isn't an install.src01.  
	Think of it as Bill and Lynne's idea of a practical joke.
	
	2.  There are several symbolic links that are not made correctly.  
	In addition, there are several files that should have been deleted 
	(to ensure clean 'make's) before the files were packed.  This is 
	fixed by the patchkit, as of 0.2.3.
	  
	3.  The /usr/src tree does not compile cleanly.  This is fixed by 
	the patchkit, as of 0.2.3.
	

2.3	Additional software distribution

	The etc distribution contains source trees for many programs that 
	are of interest to 386bsd users.  The complete ISO software 
	development environment, as well as many additional software 
	packages (and all of the games) are included in this distribution.

	The most common problem with the etc distribution is the error 
	"too many files open".  Followed closely by "install.etc01 not 
	found".  The latter is a annoyance (see above) but the former can 
	be easily overcome in a couple of ways.
	
	The "too many files open" is a result of the "cat" command leaving 
	files open after it has read a file.   Dwight E. Cass (his Email 
	address is dec@lazarus.nrtc.northrop.com) has provided us with this 
	anecdotal work around for his own experiences:
	
	--------------------------------------------------------------------
	So - back to installation.  This time, when I get to the etc01 
	partition, I am a bit more awake, so I run it from Csh (with the 
	open file limit at 256).  Works pretty well - but complains at the 
	end that it could not do the final configuration because it could 
	not find the configuration file - I checked the MANIFEST and the 
	file is not there, so I finally decided to ignore the message (but 
	it was bothersome!)  Once etc01 was done - source was easy ... and 
	I am now up and running, and quite impressed!!!
	--------------------------------------------------------------------
	
	Another method is to use a loop construct in the Bourne shell.  For 
	example:
	
	for i in (etc01.*)
	do
	  cat $i
	done | compress -d | cpio -idalmu

	-or-
	
	for i in (etc01.*)
	do
	  zcat $i
	done | cpio -idalmu
	
	will also solve the problem handily.  This solution solves the problem
	by running cat multiple times, with one file each.  Since cat now only
	has one file, there are no limits on the number of files that can be
	used for the distribution set.
	
2.4	Patch-kit
	
	Rod Grimes is the patchkit coordinator.  It is his job to ensure 
	that patches suggested by the 386bsd user community integrate into 
	the current patchkit and do not cause new problems.  His cadre of 
	dedicated and professional patch writers and testers work at a 
	fever pitch preparing and disseminating patches.

	There are two mailing lists dedicated to the patchkit.  They are as 
	follows:

	386bsd-patchkit@cs.montana.edu, which is primarily for discussion of
	up-coming patches and patchkit philosophy.
	
	patches@cs.montana.edu, which is dedicated to submitting new,
	untested patches.
	
	The current version of the patchkit is 0.2.4, which has absolutely 
	no relationship with the new version of 386bsd.  This patchkit is
	available but is still in testing.  Watch comp.os.386bsd.* for an
	announcement of the imminent release of the 'official' patchkit.


2.5	Configuration

	By far, the most common configuration questions are partitioning, 
	followed closely by all of the other software in the system.  
	Sendmail and named are also problems occasionally, but the 
	documentation that comes with them usually gets you through.  If 
	you run into a problem, post a question to comp.os.386bsd.questions.  

	A less frequently asked question is "Where can I get info on how 
	to configure a kernel?"  The answer to this question has been 
	provided by Richard Murphey (Email address rich@Rice.edu).  
	
	--------------------------------------------------------------------
	Ready-to-print PostScript files for each section of the net2 system 
	maintainer's manual are on nova.cc.purdue.edu in 
	pub/386bsd/submissions/bsd.manuals.
	
	smm.02.config.ps.Z describes kernel configuration for the VAX, 
	however some of it is relevant to 386BSD.  There is no freely 
	available rewrite for 386BSD that I know of.  
	--------------------------------------------------------------------



2.5.1	Partitions

	This section describes many of the questions that people ask about 
	hard disk partitioning.
	
	The first is a brief explanation of the BSD system disk partitions.

2.5.1.1	What is a 'disklabel' and why do I need one?

	The BSD partition table supplements the DOS partition table.  The 
	entries in this table are meaningful to BSD.  There are eight 
	partitions in the BSD partition table, and they are normally 
	lettered from a: to h:.  This supplemental partition table is
	often refereed to as the 'disklabel'.
	

	This tutorial is provided by by "<haley@husc.harvard.edu>" and 
	provides an  excellent overview of the hard disk partitioning 
	procedure from start to finish.

		"Disk Partitioning for the Compleat Idiot"

	There are times, in our trials with our computers, that it becomes
	necessary to mess about with the disklabel. For those not
	knowledgeable of BSD or Unix Systems administration, this somewhat
	simple task can be somewhat daunting. This document is the result of
	my own short experience.

	This does not cover physical installation of the disk. For those who
	are having trouble with that, I direct you to any of the fine manuals
	dealing with hard drives and your hardware.

	It also does not deal with the vagaries of the DOS partition manager.
	It assumes you have done that as well, if need be...

	After the drive is physically installed and is recognized in the BSD
	startup, and it mentions both your drives, in the order you expect
	them... Or perhaps just the one, if you had special problems with
	installation. Now all you have to do is "disklabel" the drive... Well,
	what is *THAT*??? 

	The disklabel is used by the kernel and other utilities to tell how
	you want or have the drive set up *logically*. 

	In a beautiful world, we might have a very free hand at this set-up
	and expect it to work. Unfortunately, the authors of the software
	dealing with the hard drives either decided or were forced by
	circumstance to make certain things about the disklabel inviolate. 
	
	When you let the installation disk set the disklabel for you first
	drive it comes out like this:

	    The a: partition is the primary partition.
	    The b: partition is the swap partition.
	    The c: partition is the amount of the disk used by 386bsd 
	    	(swap and data)
	    The d: partition is the entire disk.

	Of these, the only one that could be different is a:... 

	(Note for those of us who have spent far too much time using DOS: the
	labels a: b: c: d: e: f: g: h: DO NOT refer to DOS drives, but to
	partitions in your 386bsd partition... confusing, eh?  For the sake 
	of consistency I will never make a reference to DOS drives except by
	saying something like "DOS drive C:". )

	It's possible to divide up the disk a bit differently, but three
	things MUST be:

	c: must refer to every cylinder you wish 386bsd to use, either
	for your data or the swap space. 

	d: Must refer to the whole disk, from cylinder 0 to the last
	one...
	
	b: Should always refer to a swap partition. Note that on any
	other than the first disk it does not have to, but if you
	enable swapping on that drive, and you are using b: for
	something else, that something else will be killed.

	The reason for this is simple: It's hard coded in.

	"WHY?" you ask? (I did...) Probably time constraints, maybe tradition.
	But if you look at the code in "isofs" and "ufs" in your sys.386bsd
	directory, you will see numerous comments asking some of the same
	questions, which leads me to believe this may change in the future,
	making our lives both more complicated and easier at the same time...

	Getting past the esoteric explanations, here is a method for figuring
	out and "labeling" your disk.

	We'll start with the disklabel from my second disk, in the form most
	understandable by humans... #'s signify the start of a comment.

	# /dev/rwd1d:
	type: ESDI
	disk: maxtor7245
	label: 
	flags:
	bytes/sector: 512
	sectors/track: 31
	tracks/cylinder: 16
	sectors/cylinder: 496
	cylinders: 967
	rpm: 3600
	interleave: 1
	trackskew: 0
	cylinderskew: 0
	headswitch: 0		# milliseconds
	track-to-track seek: 0	# milliseconds
	drivedata: 0 
	
	5 partitions:
	#      size  offset  fstype [fsize bsize   cpg]
  	a:   198400       0  4.2BSD    512  4096    16 	# (Cyl.    0 - 399)
  	b:    31744  447392    swap                  	# (Cyl.  902 - 965)
  	c:   479136       0  unused      0     0       	# (Cyl.    0 - 965)
  	d:   479136       0  unused      0     0       	# (Cyl.    0 - 965)
  	e:   248992  198400  4.2BSD    512  4096    16	# (Cyl.  400 - 901)
	
	Some math:
	Looking at the comments at the end and the size and offset columns,
	size is a function of (last - first + 1) * sectors per cylinder:
	a: 399 - 0 + 1 = 400 * 496 = 198400
	b: 965 - 902 + 1 = 64 * 496 = 31744
	c: & d: (Since I have no DOS partition, whatsoever)
   	   965 - 0 = 1 = 966 * 496 = 479136
	e: 901 - 400 = 502 * 496 = 248992
	
	248992 + 198400 + 31744 = 479136 (all the parts should equal the whole)
	
	Some things I discovered  (for all you in novice land like me...)
	
	1. As you can see this disk has 967 cylinders, but I only refer to 966
	of them, 0 - 965... This is because it's good practice to leave the
	"Landing Zone" cylinder out of it... This is usually the last
	cylinder, and it's where the read/write heads hang out when your disk
	is off...

	Note from TSgt Dave:

	Most modern drive heads come to rest on a polished surface inside the 
	highest cylinder.  I could be mistaken, of course, and the Hard Drive 
	Bible (or other appropriate reference manual) will tell the tale for 
	each drive.

	2. a: can be a regular partition, b: should be swap, c: everything
	386bsd will get to use, including swap. d: is the entire disk from 
	0 - (cylinder_per_disk - 2)   [leaving out the Landing Zone]

	On the boot drive (The drive that actually contains the kernel), a: 
	is the boot partition.  On all other drives, it is a regular partition.

	You can then use e - h for your other partitions. I am not sure
	whether you could specify b: as other than a swap partition and not
	run into trouble, but you could surely make it a zero sized one
	starting and stopping on the Landing Zone...

	Note from TSgt Dave:

	This is a good idea.  Another way to accomplish this is to
	simply not specify it in the map.

	3. Stupid human trick: When doing the math don't forget that 400 - 900
	refers to 50*1* cylinders. I did, for a while. No great problem I
	suspect, but why waste a cylinder...

	4. newfs'ing really is that simple if you have the label right:
	"newfs /dev/rwd?x config_template" where the question mark is the 
	physical disk, the x is a partition letter, and the config_template 
	is the configuration from /etc/disktab for your disk drive. 

	* NOTE:  This is a thumbnail sketch; read the man page to verify all 
	of the options and be sure about how to proceed...
	
	5. then fsck the partition: 
	fsck /dev/rwd?x 
	
	Don't forget that fsck should be run on the RAW device.

	6. As long as it checks out, you can then mount it and do disk things
	with it...

	7. Add it to the fstab... (follow the man page).  Don't forget 
	that your new swap partition won't work if your kernel isn't 
	configured for it, but it won't cause you any problem to have 
	it there. 

	One last note from TSgt Dave:

	And I have yet to figure out a way to determine if it is or
	isn't using the swap partition anyway.  There is a program called
	'swapinfo' and it is part of the NetBSD source tree.  On my system, 
	it tells me that I never use the swap area. :)

	Comnonly used definitions:

	bsize:
	Block Size:  This is the smallest allocatable area on a disk file 
	system, sort of.  A file uses the maximum amount of blocks until it
	can not completely fill up a block. 

	fsize:
	Fragment Size:  This is the size of the 'leftover' data that didn't
	fit into a full block.  For example, assuming a using an 8K Block
	Size/1K Fragment Size, a 34.5K file, would use up 4-8K Blocks (4 *
	8K = 32K) and 3 1K fragments (3 * 1K = 3K).  There is 512 bytes of
	wasted space, since 32K + 3K = 35K, which is 512 bytes larger than
	34.5K.  If you want to reduce the amount of wasted space, you can
	reduce your fragment size, but you also reduce the amount of data
	you read at one time, so your disk performance decreases also.
	A good setup is 8K/1K for performance, but if you are really
	concerned about wasted space you can consider using a 4K/512byte
	filesystem.

	For further information, find an article that explains the Berkeley
	FFS in more detail.

	cpg:
	Cylinders Per Group, it determines the cylinder group size, which 
	in turn determines the number and location of the alternate 
	superblocks.


	Cgd posted a description of how to manually install 386bsd and 
	create 'real' BSD partitions.  It is excerpted below:
	
	--------------------------------------------------------------------
	HOW TO GET 386bsd 0.1 INSTALLED WITH "REAL" PARTITIONING:
	
	(remember, if things don't work, they might be in places that aren't 
	normally looked in... things should work as below, but you might 
	have to use explicit paths occasionally... the 'better' stuff -- 
	mount, umount, cp, etc... is in /usr/distbin on the fixit floppy...  
	even mknod is there, if the devices you need aren't on the fixit 
	floppy...) 

	(1) boot the fixit floppy
	(2) disklabel the disk as appropriate
	(3) newfs the partitions
	(4) mount the new root partition under /mnt
	(5) mkdir /mnt/usr
	(6) mount the new /usr partition under /mnt/usr

	(7) cpio the entire contents of the fixit floppy to the hard drive
		cd /
		ls .profile * [0-ln-z]*/* */*/* | cpio -pdalmu /mnt
		(NOTE: [0-ln-z]*/* is to avoid matching mnt/mnt)
	(8) copy /usr/distbin/mount and /usr/distbin/umount to /mnt (so that
		they'll be in the new root partition, so you can mount the
		new /usr partition...)
	(9) shutdown
		and the eject the floppy.
	(10) reboot off the hard drive, then fsck -p <root raw device>
		If there are any errors, after the fsck is done, hit
		ctl-alt-delete, and repeat this step.
	(11) fsck -p <usr raw device>
	(12) mount -u <root device> /
	(13) mount <usr device> /usr
	(14) insert 0.1 boot/install floppy (dist.fs) into floppy drive
		and "mount /dev/fd0a /mnt"
	(15) cd /mnt
		and then
		usr/bin/zcat etc/baselist.Z | usr/bin/cpio -pdalmu /
	(16) cd /
		and then
	/mnt/usr/bin/zcat /mnt/etc/baseutils.cpio.Z | /mnt/usr/bin/cpio -idalmu
	(17) umount /mnt	then eject the floppy
	(18) umount /usr
	(19) shutdown
	(20) reboot off the hard drive, and get all of the various files (the
		bindist files, srcdist files, etc...).
		I put them into /usr/tmp, because there wasn't enough space
		in /tmp (because it was on a small root partition...).
	(21) cd / ; cat <all the binary files> | uncompress | cpio -idalmu
	(22) rm <all the binary files>
	(23) put your hostname into "/etc/myname" and put your ip addr/hostname
		into /etc/hosts.
	(24) make an fstab for yourself.  specifically, you want something like:
		<root device name>	/	ufs rw 1 1
		<usr device name>	/usr	ufs rw 1 2
	
	congratulations!  you now have a working system!
	
	you can repeat step 21 for the srcdist and etcdist files, as well, 
	if you wish...


2.5.2	Common Disk Label Problems.
2.5.2.1	Swap space.

	Nate Williams provides a short tutorial on swap space in 386bsd, 
	excerpted below:
	
	To be able to use additional swap partitions, you need to specify 
	them in the config (/sys/i386/conf/WHATEVER) file.
	
	Ex:
	
	config          "386bsd"        root on sd0 swap on sd0 and sd1
	
	Allows swap on sd0 and sd1
	
	config          "386bsd"        root on wd0 swap on wd0 and sd0
	
	This would allow swap on both wd0 and sd0 OR whichever (both/either) 
	of the two had a valid disklabel.  Note, you can really screw 
	yourself up with this, if you should happen to not want to swap to 
	this partition, and it happens to be the first one found...
	
	The problem of not being able to swap was from the config file not 
	having wd1 in it.
	
	controller      wd0     at isa? port "IO_WD1" bio irq 14 vector wdintr
	disk            wd0     at wd0 drive 0
	disk            wd0     at wd0 drive 1
	                ^^^                  
	This should have been wd1, and that's why it didn't get added by 
	default.  I may be wrong, but I have swapped to two different 
	partitions w/out any problems since patchkit 0.1, and there aren't 
	any patches to swap386bsd.c
	   
	Once the install is complete, swapping will not be enabled on the 
	second drive.  The following steps can be used to make sure that it 
	is enabled correctly.
	
	If there is a 'b' partition in your root disk 386bsd partition, it 
	will be used automatically (MAKE SURE B is not the start of the 
	disk, and MAKE SURE b doesn't contain any data you wish to keep).  
	If b starts at disk offset 0, it will promptly wipe out your boot 
	sectors and other important disk stuff.  (This appears to be fixed
	in the current NetBSD sources)
	
	If you want an additional partition, put an entry similar to this 
	in /etc/fstab:
	
	/dev/sd1b	none			swap		sw
	
	I'm swapping on sd0b and sd1b, and 'swapon' is run on this partition 
	on boot up.
	
	Swapping to a file is still not implemented.  Rumor has it 0.2 will 
	have such things.  If someone wanted to add it, the vnops_* files 
	would have to be radically modified to get it to work correctly.


2.5.2.2	Increasing the 386bsd partition size.

	Once the install is finished, the system has it's 386bsd partition.
	This includes a 5Meg swap partition, which is altogether too small.  
	There is no easy way to increase this swap partition without 
	relabeling the drive.   Unfortunately, relabeling usually involves 
	reinstalling.  That involves re-doing just about everything you have 
	just finished doing.  The good news is that if all you have done is 
	the base installation, you don't have a lot of time and energy 
	invested in the system.  Take the time, and make sure that your swap 
	space is at least as big as your memory; many people recommend even
	larger.  There is no real limit to the size that this space can
	take.  If you have two disk drives, you can have space space on both.
	Simply follow the instructions above, and you will be all set.
	If your swap space is smaller than your real memory, system core 
	dumps will be disabled.


2.5.3	How do I set up the system so that I can boot from more than one
	operating system/file-loader without using floppies?
	
	There are many people that wish to be able to boot DOS or 386bsd 
	at will.  There are several programs that allow this.  The 
	program "os-bs" is one such program, "BOOTEASY" is another, and 
	there are three or four others.  There are problems in some 
	configurations using the os/2 boot manager for this, so beware.  
	
	In addition to being able to boot from either of two partitions, 
	some people want to operate more than one disk drive (and perhaps 
	boot from either as well).  Christoph Robitschko provided one 
	description of this.  Since there are virtually limitless 
	possibilities for configurations for BSD systems, it will be 
	impossible to answer all of the possible questions about these 
	features.  Many people operate with multiple disk drives on one 
	or more controllers.  

	Yu-Han Ting provides this tutorial on partitioning and booting
	multiple systems with a single hard disk.

	After spending one day fighting with the nasty partition table, 
	finally I had NetBSD, DOS 5 (Sorry, I don't use DOS 6), and 
	OS/2 2.1 March beta co-existing on my hard drive.  Here is the 
	answer:

	Since that my original hard disk setup was corrupted by NetBSD's
	installation program, I decided to rebuild it.  I would like my 
	partition table looks like this:

	Partition 0: OS/2 2.1 beta (Primary, HPFS, C:)
	Partition 1: MS-DOS 5.0 (Primary, C:)
	Partition 2: MS-DOS 5.0 (Extended, D: & E:)
	Partition 3: NetBSD

	You will need the following tools before you can setup a similar 
	environment:

	1) Mr. Wolfram's OS-BS.  (It's an excellent boot selector, much
	   better than OS/2's boot manager, IMHO)
	2) PFDISK.EXE.  (It's available from wuarchive.wustl.edu:mirrors/
	   linux/dos_utils/pfdisktc.zip.)
	3) A binary editor.  I use Norton Utilities' DiskEdit.
	4) 386BSD's 'tinyBSD' distribution disk.

	After you have the necessary tools handy: 

	1) Use OS/2 'fdisk' to create partition 0.  Make it install-able 
	   and install the system as usual.
	2) Use OS/2 'fdisk' to create partition 1.  Assign drive C: to 
	   the partition.  Then reboot from DOS.
	3) Use DOS 'fdisk' to create the extended partition.  Assign logical
	   drive D and E to the partition.
	4) Reboot from DOS again.  Format drive C: (for DOS), D:, and E:.
	5) Use 'tinyBSD', NOT 'NetBSD', to boot the machine.  Create a genuine
	   386BSD partition.  Once the 386BSD partition has been made,
	   boot DOS from floppy and execute PFDISK.EXE.  For example, issue
	   the following commands once you get into DOS:

		C>pfdisk 0 <enter>
		pfdisk> L <enter>  ("pfdisk>" is the command prompt and "L"
				    is the actual command.)

	   The second line, i.e., command 'L', will tell you the starting
	   address and the length of each partition you have.  Record the
	   information for step 6.
	6) Reboot NetBSD from floppy.  Install NetBSD over the original
	   386BSD partition.  Fill out the information you get from step
	   5 to the installation program.  'halt' the system after you
	   have installed 'install2.fs'.
	   (Ed.Note:  This step is the same for 386bsd or NetBSD)
	7) Boot OS/2 from floppy.  Use fdisk to assign drive C: to the OS/2
	   partition.  In my case, partition 0.  Note that fdisk will
	   change the ID of partition 1 from '0x06' to '0x16'.  '0x06'
	   stands for 16-bit DOS FAT; while '0x16' stands for non-DOS
	   partition.  In the next step, we have to change '0x16' back to
	   '0x06' manually.  You can get the ID information by issuing "I"
	   under PFDISK.  It will tell you what the IDs represent.
	8) Boot DOS from floppy.  Use the binary editor to change the
	   partition type as stated in step 7.
	9) Install OS-BS under DOS.  Remember to enable "Modify startup ID
	   before booting".
	10) Now you can boot any partition w/o floppy diskettes during
	    startup. :)

	The above procedures may not be optimized.  But it works for me.  
	I won't spend anytime to deal with tedious work again :)

	You might feel strange why we need 'tinyBSD'.  Simply trust me.  
	By using 'tinyBSD' to create a partition for NetBSD, it will 
	make your life a lot easier.  Hope this helps.  

	Ed. Note:  The reason is because several versions of NetBSD and 
	FreeBSD will not label a disk that doesn't have a disklabel.  
	Catch-22.


	PS:  %%%%% REMEMBER TO BACKUP YOUR SYSTEM BEFORE YOU CONDUCT THE 
			EXPERIMENT !!! %%%%%

	Here is Christoph's explanation of how to set up a dual hard drive
	system so that the 386BSD/NetBSD system is stored entirely on the
	second hard drive.

	I have done this with two IDE drives. IDE+SCSI should be a bit 
	simpler.  There's a boot selector called BOOTEASY that can load 
	from the second drive (you can get it from 
	ftp.tu-graz.ac.at:pub/386BSD/0.1/unofficial/booteasy).

	What I have done to boot 386bsd from the second (IDE) drive:

	- installed booteasy on the first drive
	- (you can install booteasy on the second drive, too, if you
	  have multiple partitions there)
	- modified Julian's boot blocks to use the second drive per default
	  (Ed. Note:  See below for the illumination of this step)
	- rebuilt the kernel to have root and swap on wd1 (probably not
	  necessary for you, since your second disk is sd0, which is
	  already in the config file).

	It worked perfectly for me.

	This should also work with equal facility for 386bsd users.

	Julian Elischer (julian@jules.dialix.oz.au) adds:

	To make the bootcode default to drive 1 look in 
	/sys/{arch/}i386/boot/boot.c for the following (or similar.. It has 
	changed a little) code:

loadstart:
 
	/***************************************************************\
        * As a default set it to the first partition of the first	*
        * floppy or hard drive						*
  	\***************************************************************/
        part = unit = 0;
        maj = (drive&0x80 ? 0 : 2);             /* a good first bet */
        name = names[currname++];


and change it to:


loadstart:

	/***************************************************************\
	* As a default set it to the first partition of the SECOND	*
	* floppy or hard drive						*
	\***************************************************************/
!	part = 0;
!	unit = 1;
	maj = (drive&0x80 ? 0 : 2);             /* a good first bet */
	name = names[currname++];


2.5.4	How do I disklabel my second hard drive?

	The obvious answer is to use 'disklabel -w -r /dev/rwd1d'.  
	Unfortunately, this does not always put a real disklabel on the
	drive.  The symptom is that the drive labels and can be used
	until the system is reset, at which point the system tries to
	read the label from the disk.  It was never actually written to 
	the disk, so the operation fails.

	There are also reports that the /usr/mdec files are corrupted in 
	some of the distributions.  If you have tried everything else, you
	can either load the files from one of the many archive sites that
	keep the /usr/mdec files around, or you can recompile them 
	yourself.

	Mark Weaver (mhw@cs.brown.edu) provides us with an illuminating
	answer to this perplexing problem.

	I had the same problem and there is a simple solution.  I'm not 
	sure why this works, but it does.

	Instead of specifying the entire device path name (i.e. /dev/rsd0c), 
	only specify the two letters of the device type and the unit number 
	(i.e. "sd0").  Disklabel figures out the rest, and it works.

	For instance, the following line works for me:

	  disklabel -w -r sd0 <drive-type>

	assuming of course that the boot block files are in /usr/mdec/ and
	the <drive-type> is in the /etc/disktab.

	This is also a symptom of some of the versions of FreeBSD and 
	NetBSD where the disklabel code was 'fixed' to only write a 
	disklabel on a drive with a disklabel.  Oops.


2.5.5	386bsd/NetBSD cannot handle disk geometry translations, but it 
	turns out that my disk geometry is translated.  It has five zones, 
	each with a different sec/track!  What kind of things can I do 
	about the disk translation my hard disk controller uses?

	There are several ways to get around these problems with disk 
	geometry translation.  If you are using a SCSI controller, you can
	specify the geometry such that each 'cylinder' is 1 Meg (64 sectors
	by 32 tracks for example).  Most SCSI controllers will blithely
	ignore what YOU tell it the geometry is and press on using this
	type of 1 Meg cylinder had to get the job done.  NOTE:  If you are
	going to try this, try to ensure that each 'pseudo cylinder' is a
	reasonable size (like 1Meg or 512K).

	An interesting method for dealing with disk geometry comes from 
	Alan Barrett (barrett@lucy.ee.und.ac.za):

	This sort of problem happens when you try to install NetBSD in a
	partition of a disk whose controller does geometry translation.  I
	have not had time to find the bug that causes the problem.  One 
	option is to disable the geometry translation:  Use ide_conf to 
	find the true geometry, use the CMOS setup program to tell your 
	BIOS about the true geometry, and reformat everything.  I 
	successfully did that on one of my systems.
	
	If you are not able to, or do not wish to, disable the geometry
	translation then the following work-around might work for you.  
	This requires that the disk have unused space on {cylinder 0, 
	head 0}, from sector 2 to sector 16.  Almost all DOS disks that 
	I have ever seen satisfy this condition, because they usually 
	start the DOS partition in {cylinder 0, head 0, sector 1}, 
	leaving most of {cylinder 0, head 0} unused apart from the 
	partition sector in {cylinder 0, head 0, sector 1}.  However, 
	many partitioning programs like to hide this fact from you, 
	and pretend that the DOS partition starts at the front of the 
	disk; don't believe them until you have checked with a raw 
	disk editor.

	    0.  Make sure you have adequate backups.

	    1.  Use a partition sector editor (fdisk, pfdisk, os-bs, 
	    	booteasy, Norton utilities, whatever) to mark the partition 
	    	that you want for NetBSD as bootable with type 0xA5 
	    	(decimal 165).

	    2.  Halt the system.  Boot the NetBSD kernel copy floppy.  
		When it asks you to insert the floppy for the root file 
		system, switch to the Install-1 floppy and press enter.

	    3.  Answer all the installation prompts, using numbers based 
		on the translated geometry.  When it asks if you really 
		want to label the disk, be brave and say yes.

	    4.  Halt the system.  Boot to DOS.  Run a disk editor program, 
		such as Norton utilities.

	    5.1.  Verify that the partition sector in {cyl 0, head 0, 
		sec 1} is undamaged.  Verify that the disklabel program 
		run as part of the NetBSD install has written the NetBSD 
		primary boot block to {cylinder xx, head 0, sector 1}, 
		written the disk label to {cyl xx, head 0, sec 2}, and 
		written the secondary boot program to {cyl xx, head 0, 
		sectors 3 to 16}.  ("xx" represents the translated 
		cylinder number you chose for the start of the NetBSD 
		partition.  You did choose to start on a cylinder boundary, 
		I hope.)

	    5.2.  Verify that the space in {cyl 0, head 0, sectors 2 to 
		16} is still available.  Copy the fifteen sectors containing 
		the NetBSD disk label and secondary boot block from {cyl 
		xx, head 0, sectors 2 to 16} to {cyl 0, head 0, sectors 2 
		to 16}.

	    5.3.  Edit the partition table in {cyl 0, head 0, sec 1}.  
		Change the system ID of the NetBSD partition from 0xA5 
		(decimal 165) to something else (I use 0xA4, decimal 164), 
		but keep it flagged as bootable.  This will let you boot 
		to the NetBSD primary boot block.

	    5.4.  Edit one of the previously unused partition table entries 
		(I hope you have one), to contain the following information: 
		{sys id = 0xA5, boot flag = 0, start cylinder/head/sector = 
		0/0/1, end cylinder/head/sector = anything, initial 
		offset = 0, total size = anything}.  This will tell the 
		NetBSD primary boot block, or a NetBSD system booted from 
		a floppy, that it should look for the NetBSD disk label 
		in {cyl 0, head 0, sec 2}.

	    6.  Halt the system.  Boot the NetBSD kernel copy floppy.  When it
	    	asks you to insert the floppy for the root file system, just 
	    	press enter without changing disks.

	    7.  Copy the kernel, and proceed with the rest of the installation 
	    	as per the instructions provided with NetBSD.  It should now 
	    	work because of the trickery with the partition table etc.


2.6	Common installation problems.

	There are many common installation problems.  This section covers
	the most basic and common of these problems.  In addition to this
	section, you should also read through the other sections of the
	FAQ, since many of the less common questions are answered in other
	places in the doc.

2.6.1	Swap space not identified correctly.
	
	There are several levels of problems associated with swap space.  
	The first is that the swap space on a second disk will not get 
	used if it is not in your /etc/fstab file.  Your /etc/fstab should 
	have the swap space identified.  The following is a representative 
	fstab:
	
	/dev/wd0a		/		ufs  rw 1 1
	/dev/wd1b		swap		swap sw 0 0
	 
	Another common question is that the install program installs the
	swap partition in the 'b' partition, but does not mark it correctly
	as a swap partition.  The swapping software will use the swap 
	partition regardless of what it is called, but it should still be
	identified in the disklabel as the swap partition.  Use 'disklabel'
	to change the partition type from 'unused' to 'swap'.

	NOTE:  I mean it when I say that 386bsd will use the b: partition
	for swap without regard to what you called it.  If it was your 
	root partition, it will be toast the first time you try to swap
	a process out to disk.  I'm not kidding!

2.6.2	Endless reboot cycles.
	
	Endless reboot cycles are the single most vexing aspect of 386bsd.  
	Part of the problem is that the 0.1 distribution boot routines 
	were never checked against many types of computers and have bugs.  
	Most of the bugs are fixed in the patchkit, but that doesn't do 
	the average novice user any good.
	
	In general, this will show up as a "bad disk label" error, and 
	can result in in not booting from the hard drive "most of the time".  
	You may be able to partially (or even completely) work around this 
	problem by making your machine run at a lower clock rate.

	This problem is the result of the kernel reading the wrong register 
	waiting for the drive controller to come ready.  On some 
	controllers, this isn't a problem; on others, it's fatal.
	This problem is solved for almost all controllers in the patchkit.

	The correct solution is to use a patched "dist.fs" or "fixit.fs" 
	boot disk.  These have been provided by the patchkit maintainers 
	and are located on the machine agate.berkeley.edu in the directory 
	pub/386BSD/386bsd-0.1/unofficial/patchkit.  In addition, new
	patches kernels or a NetBSD kernel may be able to solve your 
	immediate problems.

	Another incarnation of this symptom is that the disk geometry on 
	your disk label (as installed by install) is different than the 
	geometry that your hard drive controller thinks it is using.  This 
	will most often manifest itself on controllers that insist on 
	operating in some type of translation mode.  Normally the fix is to 
	find out what the controller geometry is and make the disk label 
	agree.  There are programs available to help with this problem.  

	Julian's new boot blocks may also solve this problem.  They are 
	available where fine precompiled kernels may be found.  Also, they
	are included in the patchkit as of version 0.2.2.


2.7	The computer just sits there, or 'that isn't right'.
	
	This class of problems is sometimes caused by an incorrect FTP of 
	the boot disk.  Make sure that the files were grabbed in 'binary' 
	mode and that the size reported back is 1244000 bytes.  Use the 
	Unix program 'dd' or the DOS program RAWRITE to put these files 
	onto the diskette.  In addition, this is the 'miscellaneous' 
	section of the FAQ.  These problems are included here because they
	are usually preceded by 'I just finished installing...'


2.7.1	The boot disk works all right on one computer but not another. 

	This could be a problem with many different pieces, some of which are: 

	- Misconfigured hardware.  The iomem, IRQ, and other board settings 
	must match the ones listed in the INSTALL.NOTES.  Unfortunately, the 
	INSTALL.NOTES are on the disk that will not boot.  You can grab them 
	via FTP from /pub/386BSD/386bsd-0.1/filesystem.

	- Unsupported hardware.  There are several SCSI controllers on the 
	market that are not fully supported by 386bsd.  The Ultrastore 24F 
	(when not running in ISA emulation mode) is a good example of this.  
	There are also some network cards that are not directly supported 
	in 386bsd.  If you get into a real bind, you can post a question 
	to comp.os.386bsd.questions, and one of the many experienced 386bsd 
	gurus that reads that group will probably try to help you.

	
2.7.2	The screen has "flashing multicolored characters and ptdi81061 
	prompt" error?
	
	The problem is that the code checking the return from the read of 
	the CMOS RAM value falls through in the case of an invalid value.  
	What really is needed is the non-existence "else" case for a bad 
	CMOS setup, which goes and probes memory to see it's size.  What 
	currently happens is that the code falls through, the Maxmem is 
	set to zero, and the maxmem and physmem are set to -1 (this is a 
	bad thing).
	
	To solve this, Terry Lambert wrote a program in (forgive him!) 
	Turbo C to read and write CMOS values, so that he could force the 
	memory count to the correct value.  For a machine with a base 
	memory of 640K, the expected value in CMOS is 0280 (in bytes 
	0x16 and 0x15, respectively).  What the AT&T boxes and the HP 
	Vectra have is 027f, so it falls through to the default case and 
	blows up.
	
	The quick and dirty work-around:  If you download the new patchkit 
	bootables from agate.berkeley.edu they have fixed these problems.  
	If not, you can use uzap (available for anon ftp from 
	wuarchive.wustl.edu, located at mirrors2/unix-c/editors/uzap.tar-z) 
	to binary edit the dist.fs at byte offset 946834; it should be 
	changed from 81FE8002 to 81FE7F02.  This is the compare for 640K 
	in the bogus code.  You can look for the pattern 81FE8002 in the 
	other *.fs files, including fixit.fs, and change it there, if you 
	MUST use one of them instead.
	
	It should be noted that, if you download uzap, you should "touch" 
	uzap.c, as otherwise, make will try to use lex to create it, and
	will probably fail.  This is due to the tar extraction order from
	the uzap tar archive.


2.7.3a	I get the error "isr 15 and error: isr 17" on an NE2000 card.
2.7.3b	I have some card on IRQ2 and it doesn't work; why?
2.7.3c	I am getting lousy performance out of my network card.  What are 
	    some of the other possibilities?
	
	The description of this problem is that one of the cards in your 
	system; most likely the VGA card, is either generating interrupts 
	or is causing the IRQ 2 to be actively disabled.  The VGA card uses
	IRQ 2 during vertical retrace to prevent sparklies.

	One solution would be to plan on not using your Ethernet card until 
	you have rebuilt the kernel so that it expects it at an interrupt 
	other than IRQ 2 or 9, re-jumper or reconfigure the card to match the 
	IRQ you have selected, and enable it.  
	
	From time to time, this problem will manifest itself as a general
	tendency of the network card to transfer either very sporadically
	or very slowly. It is precisely the same problem.

	James Van Artsdalen (email at james@bigtex.cactus.org) has given us 
	a solution:
	
	--------------------------------------------------------------------
	Some VGA cards use IRQ 2 for a vertical retrace interrupt.  Even 
	when the interrupt is not enabled in the VGA, some cards drive 
	IRQ 2 inactive instead of leaving the signal tristate.

	If this is the problem, you can use Scotch tape to cover the IRQ 2 
	signal on the VGA's ISA connector.
	--------------------------------------------------------------------
	
	There has been some discussion as to whether scotch tape is really 
	appropriate inside a card slot.  My answer would be "yes".  This is 
	because the alternate solution of cutting the trace on the video 
	board seems, to my mind, to reduce the value of the board.  It is 
	possible that, in the future, with a bi-bipartite driver, you would 
	want to catch the retrace interrupt to get rid of "sparklies" or to 
	implement a driver for a very high resolution monitor for X.  In 
	this happens, given a choice between alcohol and solder, I vote for 
	alcohol.
	

2.7.4	What is the difference between IRQ2 and IRQ9?  Are they really
	the same, or are they really different?  

	Holger Veit (veit@mururoa.gmd.de) says:
	IRQ 2 is unused on XT systems (except for retrace on some VGA 
	cards), so the board might offer this as a valid interrupt.  
	On an AT system (including the 386/486-ISA boards) there are two 
	interrupt controllers.  The second one is chained to the first via 
	interrupt line 2, so this one is actually used to forward 
	interrupts from the second controller.  So IRQ 2 is not a good 
	choice.  IRQ 8, which is the first interrupt line on the second 
	controller, serves as the "no interrupt" signal for the second 
	controller.  So the first available interrupt on the second 
	controller is IRQ 9.  

	It is reported that on AT bus systems, the IRQ9 trace is in the 
	same place as the IRQ2 trace on XT bus systems.  



2.7.5	Some of my SCSI devices (like a tape drive) don't work; why?
	
	That is because the original SCSI drivers didn't recognize any 
	devices past the first two (ID 0 and ID 1).  Also, there was a bug 
	in the distribution floppy regarding the devices at ID 6.  The 
	'dev' files for that id need to be remade.  Use MAKEDEV to do that.

	The disks and tapes will be recognized and configured when they 
	are first accessed. 
	
	A new and improved SCSI driver has been written by Julian Elischer 
	and is available from many sources.  It includes support for many 
	new types of SCSI controllers and many devices that are thereby 
	attached.  This driver is included in the patchkit.


2.7.6	I try to run 'ps' or 'w' and get ': cannot get namelist'
	from the TinyBSD kernel.  What did I do wrong?

	Nothing.  There is a class of programs that interact directly with 
	the current kernel.  These programs include 'ps', 'w', 'uptime', and 
	others.  The shell on the TinyBSD disk is not capable of supporting 
	these programs because the symbol table that these programs use has 
	been stripped out of the kernel to save space.  The easiest way to 
	fix this is to get a  different kernel (build it yourself, or from 
	agate.berkeley.edu or one of the other FTP sites).  Of course, you 
	can have a fully functional system with these programs, but they are 
	nice to have.  

2.7.7	I get a 'Floating point constant out of range' when I try to compile
	package 'n'.  What is broke?

	This problem was encountered during many package compilations, 
	including compiling gcc-2.3.3 under NetBSD-0.8.  

	NetBSD-0.9, and presumably FreeBSD, contain a repaired printf()
	function, which corrects this problem.  The easiest solution for
	this (and MANY other) problems is to upgrade. 

	There is also a circular dependency for protoize.o/unprotoize.o 
	in the Makefile. Add the lines
 
	      touch protoize.o
	      touch unprotoize.o
 
	after the line:

	      touch stamp-proto
 
	After this "make bootstrap" will run to completion.

	gas apparently has bugs too.  It should produce +Infinity.  I 
	think it is OK internally but it may be trusting the library 
	too much.  gcc can easily be changed to avoid printf for output, 
	but input is harder.
 
 	One of the problems is that various pieces of code rely on the
 	value of DBL_MAX.  A kludge to fix it is to change the line
 	below:

	#define DBL_MAX         1.7976931348623157E+308

	One value that works is
 
 	#define DBL_MAX         1.7976931348623147E+308
	                                        ^ was 5

	This is a kludge, but it does mostly work.


	The problem is entirely in printf() (really in cvt()), NOT in
	atof().  I have inspected the output of atof() bit by bit, and 
	it is well within IEEE specification.

	The digits `157' are the `best' approximation.

	The code for printf() generates a representation which is not even 
	in the range of doubles.  Below are the details:

	atof("1.7976931348623157e+308") returns 
	
	 	0x7fefffffffffffff

	which is the maximum double value and is correct.  However, 
	printf() of the previous yields `1.7976931348623168e+308', which 
	isn't even within the floating point range.  It is clearly printf() 
	that is broken, and a quick inspection of the code is enough to 
	determine that it uses a pessimal algorithm.

	atof() has been tested with many other values, and it has never 
	been off by more than is allowed by IEEE 754 (though it is not 
	optimal).


2.7.8	I want to use the Adaptec 1542C SCSI controller.  What are the 
	problems/tricks you need to know to get it working?

	The first thing to check when trying to use the 1542C is the setting 
	of 'Enable Disconnection' under the 'SCSI Device Configuration' 
	menu.  It should be set to YES for all devices, as the manual warns 
	you. 

	Matthias Urlichs (urlichs@smurf.ira.uka.de) has provided this 
	description of the types of things that can cause problems for the
	controller and devices attached to it.
	
	The problem is that the Adaptec 1542C has (a) rather powerful line 
	drivers, and (b) is sensitive to transient signals which can be 
	induced by them via either a bad cable or a bad external terminator.

	A bad cable is almost any cable which doesn't meet SCSI-2 specs.

	A bad external terminator is one which doesn't adequately buffer 
	its resistor network.

	So...

	- Remove the internal terminator from the last drive in your chain. 
	  Replace with an active SCSI-2 external terminator.  Side 
	  improvement: active terminators consume a bit less power.

	- Check cables.  Specifically, some cables carry less than the 
	  nominal 50 signal wires. Manufacturers sometimes think they can 
	  get away with this because almost all odd-numbered pins are GROUND 
	  anyway. So, if pins 1 and 3 or 3 and 5 are connected, you're 
	  likely to have a marginal cable.

	- Make sure that the terminator power is supplied by all devices 
	  and that the power pin is actually connected on your cable. The 
	  problem here is that some idiot device manufacturers save on 
	  2-cent diodes, which means that the thing will pull terminator 
	  power to ground if it's not plugged in.  (Two of these on one 
	  bus are even worse.)

	- Consider creating your own cabling. Take a 50-wire flat ribbon 
	  and press the appropriate connectors onto it in precisely the 
	  right places. (Move your devices as to minimize cable length.) 
	  Be aware that if a device has two external connectors, you must 
	  take the SCSI bus in at one connector and out at the other 
	  -- don't leave the other connector dangling; this isn't within 
	  the SCSI specs because the cable usually is too long.

	- Better but more expensive: use 2-twisted cable. (I.e., wires 1&2 
	  are twisted around each other, wire 3&4, ...) This will improve 
	  reliability because the wires are twisted at different rates. 
	  These cables have short non-twisted segments every 50 cm (1.5') 
	  so that you can press on your connectors instead of heating up 
	  that soldering iron.

	- While you're rebuilding your system anyway...: If you have more 
	  than one drive per power supply, check if these drives have 
	  adequate condensors to buffer their power.  I have two 80-MB 
	  Seagates which refused to work more than a few hours without 
	  glitches -- then I soldered two 10-uF Tantals onto their power 
	  connector and they've been flawless ever since.

	The terminator power is pin 26. Be aware that SCSI counts pins as 
	they appear on a ribbon cable, not as they're sometimes numbered 
	on the connectors.  Pin 25 is supposed to be disconnected.

2.7.9	Did anyone ever find out on how to use the 3c509 etherlink III 
	card yet for bsd?

	Herb Peyerl (hpeyerl@fsa.ca) responds:

	I have a mostly working 3c509 driver that I've been working on 
	for far too long.  There are a couple of problems with it that 
	I've addressed (in my mind mostly).  I have several things I have 
	to do before I can go back to working on it (mostly Windsurfing, 
	waterskiing, suntanning, climbing, and drinking)...

	I have yet to look at the recently announced Linux 3c509 driver 
	but plan to do that to see if it can address any of the problems 
	that I'm having.

	I always offer to give out my existing code on the off chance i
	that someone has more energy and time than I do to get it working.
	But invariably I end up getting requests to photocopy and mail my 
	documentation which is something I'm tiring of doing.

	So, to everyone who's waiting for a 3c509 driver, I say "keep 
	waiting, it'll happen someday"...


2.8	Other common problems that are attributed to the installation
	process but are caused other places.
	
2.8.1	Why don't the man pages for "magic" and "file" work?

	The manual page for magic and file all have two dots before the 
	commands,  e.g.. "..SH" it should be ".SH" just delete one of the 
	double dots in the whole file and then it will work.  These man 
	pages are fixed by both the patch-kit, NetBSD, and FreeBSD.  The
	only time this problem every occurs is when you are using the
	distribution from one of the old CD-ROM distributions are get the
	original 386bsd 0.1 release.


2.8.2	Why is apropos broke?

	The Makefile in /usr/othersrc/share/man/Makefile creates the 
	whatis.db.  The problem is that it doesn't strip the backspaces in 
	the title and apropos can't handle that.  So add a "col -b" to strip 
	those.

	excerpt from the Makefile.

	makedb:
	   for file in `find /usr/share/man -type f -name '*.0' -print`; do \
		sed -n -f /usr/share/man/makewhatis.sed $$file; \
	   done | col -b | sort -u > whatis.db
	   install -o ${BINOWN} -g ${BINGRP} -m 444 whatis.db \
	              ${DESTDIR}/usr/share/man

	This problem is also solved in the patchkit, and other *BSD releases.

	Also, if the Makefile is moved to the /usr/share/man directory, the 
	whatis.db will reside where it needs to eventually reside, and the 
	install will wipe it out.  An easy fix for that problem is to change 
	the two references of whatis.db in the excerpt above to 
	/tmp/whatis.db.  This will ensure the file is correctly built and 
	installed.


2.8.3	I want to use more than 16 Megabytes of memory.  Will any of the 
	Net/2 derived BSD systems support it?

	Early on, 386bsd 0.1 would choke radically on any system that had
	more than 8M of memory.  With the advent of the patchkit, this 
	problem was, for the most part, solved; memory could then expand to
	the 16M limit inherent in the ISA bus.

	As people started using VESA and EISA busses, however, attempts 
	were made to push the envelope even further.  Memory limits have 
	expanded seemingly without limit.  Since the EISA bus (for example) 
	has more than the 24 address lines (the 16Meg limit), it is capable 
	of supporting more memory.

	When using NetBSD and FreeBSD, there is no SOFTWARE limitation on 
	more than 16Meg of memory.  There are still hardware limitations.
	The limit is caused by DMA controllers which copy memory images
	around the system.  Many cards which people use in VESA and EISA
	machines either emulate ISA cards (in order to work with *BSD) or
	are really ISA cards.  

	Jordan K Hubbard (jkh@thrush.lotus.com) has provided this 
	explanation of the distinction:


	Just so long as you're using a DMA-using disk controller in EISA 
	mode, rather than ISA mode, you can use more than 16 Meg of memory.

	For those who may find such a distinction confusing, let me explain:

	You can use an ISA controller (such as an Adaptec 1542) in an EISA
	machine, but as it will still think it's in an ISA box and refuse to
	use the extra address lines, this is no different than having an
	ISA machine as far as >16MB is concerned.

	You can use an EISA controller in "ISA mode", meaning it uses the
	older protocols for compatability reasons (examples being Adaptec 
	1742 in "standard" mode, DTC 3290 in "Adaptec" mode, etc) and 
	again, does not use the extra address lines.

	The only way to get full EISA, 32MB-of-memory-and-everything, mode 
	is to use an EISA controller in full EISA mode (for Adaptec 1742, 
	this is "enhanced" mode, for DTC 3290 it's "DTC" mode).

	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

	In addition, several other types of EISA controllers which do NOT
	use DMA will not cause problems.  IDE, ESDI, and RLL controllers
	are examples of this type of card.  The discussion above also applies
	to VESA and VLB cards. 

	So, the bottom line is that you are limited to the amount of memory
	that your DMA equipped devices can access.  Once again, the weakest
	link is the strength of your machine.


-- 
------
TSgt Dave Burgess
NCOIC AL/Management Information Systems Office
Brooks AFB, TX