From lcs@MIT.EDU Thu Nov  6 16:46:28 1997
Flags: 000000000001
Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA24573; Thu, 6 Nov 97 16:47:47 EST
Received: from MIT.MIT.EDU by MIT.EDU with SMTP
	id AA11989; Thu, 6 Nov 97 16:46:46 EST
Received: from DEFIANT.MIT.EDU by MIT.MIT.EDU (5.61/4.7) id AA14410; Thu, 6 Nov 97 16:46:28 EST
Sender: lcs@MIT.EDU
Message-Id: <34623AB4.41C6@MIT.EDU>
Date: Thu, 06 Nov 1997 16:46:28 -0500
From: Larry Stone <lcs@MIT.EDU>
Organization: Massachusetts Institute of Technology
X-Mailer: Mozilla 3.01 (X11; U; IRIX 5.3 IP22)
Mime-Version: 1.0
To: lcs@MIT.EDU
Subject: netscrape wants a subject here
Content-Type: multipart/mixed; boundary="------------167E2781446B"

This is a multi-part message in MIME format.

--------------167E2781446B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Here's some intresting info..

--------------167E2781446B
Content-Type: text/html; charset=us-ascii; name="complete.faq.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="complete.faq.html"
Content-Base: "http://cynjut.neonramp.com/complete.fa
	q.html"

<BASE HREF="http://cynjut.neonramp.com/complete.faq.html#7.2">

<html>
<head><title>Section 0.  (Basic FAQ information)</title></head>
<body>
<p>
<p>
<h2><pre>
</h2>
			Frequently Asked Questions
<br>
		   386BSD, NetBSD, FreeBSD, OpenBSD and
<br>
		       other BSD derived Operating 
<br>
				 Systems.
<br>
<p>
<p>
		   	   EXTREMELY UNOFFICIAL
<br>
<p>
<p>
  Original FAQ by:
	Terry Lambert
<p>
  New New FAQ by:
	Dave Burgess
<p>
	<a href="mailto:burgess@cynjut.neonramp.com">burgess@cynjut.neonramp.com</a>
<p>
<p>
			   Last Update:  26 Jun 1997 
<br>
<h2></pre>
</h2>
<p>
<h2>Section -1. (Where else to look)
</h2>
<p>
	In the distribution of each of the *BSD systems, there is a LOT
	of documentation.  If you are completely unfamiliar with Unix,
	there is a reading list recommended in <a href="#section_1">Section 1</a> of the FAQ.

	There are also various documents in the /usr/share/doc directory
	on the installed system.  Many of these give detailed information 
	about the design, history, and use of many of the pieces of the
	*BSD system you are interested.  Once you are familiar with
	Unix-like systems, you can probably graduate to the 'man'
	program.  The 'man' program is a series of manual pages which
	describe various parts of the system (kernel stuff, file
	formats, commands, 'C' standard functions, etc.) in enough
	detail to generally get you where you want to be.  The command
	'man man' will give you a lot of details.  The other command
	which might help is called 'apropos' (pronounced ap'-rO-pO).
	This command searches the title lines of every manual page
	looking for a match in the word you include as an argument.  If
	you have the system running, try the command 'apropos ttys' to
	get a feel for all the stuff that's out there.
<p>
<p>
<a name="section_0"><h2>Section 0.  (Basic FAQ information)
</h2>
<p>
<a name="0.0"><h3>0.0 : Master Index.</h3>

<p>
<b>0.0 <a href="#0.0">Master Index.</a></b><p>
<b>0.1 <a href="#0.1">A brief history of the *BSD family.</a></b><p>
<b>0.1.1 <a href="#0.1.1">How close is NetBSD (or FreeBSD) to BSD 4.4?</a></b><p>
<b>0.1.3 <a href="#0.1.3">Where can I get more information about the *BSD family of Operating Systems?</a></b><p>
<b>0.2 <a href="#0.2">About this FAQ.</a></b><p>
<b>0.2.1 <a href="#0.2.1">I want to start up a thread about why *BSD is or isn't as good as some other operating system. Can anyone suggest a good reason why I shouldn't?</a></b><p>
<b>0.3 <a href="#0.3">Are there any resources on the Net (like URLs) associated with the BSD family of operating systems?</a></b><p>
<b>0.4 <a href="#0.4">How to add your pet answer to the FAQ.</a></b><p>
<b>0.5 <a href="#0.5">Administrivia.</a></b><p>
<b>0.6 <a href="#0.6">Does anyone reading this have any sense of humor at all?</a></b><p>
<p>
<b>1.0 <a href="#1.0">I just downloaded all of 386bsd version 0.1 and I can't get [some feature] to work? Do you have any suggestions?</a></b><p>
<p>
<b>1.1 <a href="#1.1">Minimum hardware configuration recommended</a></b><p>
<b>1.4 <a href="#1.4">Where to get the source and binaries</a></b><p>
<b>1.4.1 <a href="#1.4.1">Where can I get the distribution on CD ROM?</a></b><p>
<b>1.5.3 <a href="#1.5.3">*BSD system mailing lists.</a></b><p>
<b>1.5.4 <a href="#1.5.4">System Updates.</a></b><p>
<b>1.6 <a href="#1.6">Documentation available</a></b><p>
<b>1.6.1 <a href="#1.6.1">BSD manuals</a></b><p>
<b>1.6.2 <a href="#1.6.2">BSD books</a></b><p>
<b>1.6.6 <a href="#1.6.6">The O'Reilly and Associates BSD 4.4 Set.</a></b><p>
<b>1.6.7 <a href="#1.6.7">Other FAQ's on the net that are relevant</a></b><p>
<b>1.7.1 <a href="#1.7.1">Official distribution sites</a></b><p>
<b>2.0 <a href="#2.0">Install process</a></b><p>
<b>2.0.1 <a href="#2.0.1">Boot disks (versions and media formats)</a></b><p>
<b>2.0.1.1 <a href="#2.0.1.1">I have the base system installed, and now I want to install the rest of the system. Where did the 'extract' program go?</a></b><p>
<b>2.0.1.2a <a href="#2.0.1.2a">The floppy booted, but now the hard disk won't boot?</a></b><p>
<b>2.0.1.2b <a href="#2.0.1.2b">I am trying to reinstall. I run install and it loops asking me if I want to use the whole disk?</a></b><p>
<b>2.0.1.4 <a href="#2.0.1.4">What are the options on the boot prompt?</a></b><p>
<b>2.0.1.5 <a href="#2.0.1.5">I just used the '-s' option on the boot, but I can't write anything onto the disk. What is wrong? If I use a plain 'mount' command it tells me that my root file system is read-only.</a></b><p>
<b>2.1 <a href="#2.1">Binary distribution</a></b><p>
<b>2.1.1 <a href="#2.1.1">I want to install by NFS but I am having all kinds of problems connecting to the Sun server where the files are.</a></b><p>
<b>2.2 <a href="#2.2">Configuration</a></b><p>
<b>2.2.1 <a href="#2.2.1">Partitions</a></b><p>
<b>2.2.1.1 <a href="#2.2.1.1">What is a 'disklabel' and why do I need one?</a></b><p>
<b>2.2.1.2 <a href="#2.2.1.2">What other kinds of information do I need if I really want to tune my hard drive's performance in conjunction with a newfs?</a></b><p>
<b>2.2.2 <a href="#2.2.2">Common Disk Label Problems.</a></b><p>
<b>2.2.2.1 <a href="#2.2.2.1">Increasing the *BSD partition size.</a></b><p>
<b>2.2.2.2 <a href="#2.2.2.2">I can access the DOS partition on my second disk from Unix but not DOS? Any suggestions?</a></b><p>
<b>2.2.2.3 <a href="#2.2.2.3">I want to use my entire 2 Gig drive as the root partition. Why doesn't it work?</a></b><p>
<b>2.5.3 <a href="#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?</a></b><p>
<b>2.2.3 <a href="#2.2.3">How do I get the system to boot from the second hard drive?</a></b><p>
<b>2.2.4 <a href="#2.2.4">How do I disklabel my second hard drive?</a></b><p>
<b>2.2.5 <a href="#2.2.5">NetBSD and FreeBSD 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?</a></b><p>
<b>2.2.6 <a href="#2.2.6">I am having trouble installing on the EIDE hard drive. What are some of the things that I need to look into?</a></b><p>
<b>2.2.7 <a href="#2.2.7">My disk label is complaining about '256 heads' in the disklabel. This is obviously bogus, but it doesn't seem to be hurting anything. Is it Okay or should I fix it?</a></b><p>
<b>2.2.8 <a href="#2.2.8">What are the options for the boot up prompt?</a></b><p>
<b>2.2.9 <a href="#2.2.9">I am having trouble installing WRT 'syslogd: bind: Can't assign requested address' errors. What are some of the things I should look at? I also am having trouble with the network: 'starting network ... ifconfig: localhost: badvalue'.</a></b><p>
<b>2.2.10 <a href="#2.2.10">When I start up my system, it hangs for three or four minutes during the 'netstart' program. Our network nameserver is working OK, and I use it all the time; my resolv.conf file says to use the network nameserver. Why would netstart have such problems using it?</a></b><p>
<b>2.2.11 <a href="#2.2.11">I am having trouble getting net aliases to work. What could some of the problems be?</a></b><p>
<b>2.2.12 <a href="#2.2.12">I'm having trouble with the networking code (specifically the PPP stuff to my ISP). How can I debug NetBSD's networking?</a></b><p>
<b>2.2.13 <a href="#2.2.13">I want to hard wire my SCSI devices to a particular device number. Is that possible?</a></b><p>
<b>2.3 <a href="#2.3">Common installation problems.</a></b><p>
<b>2.3.2 <a href="#2.3.2">Endless reboot cycles.</a></b><p>
<b>2.4 <a href="#2.4">The computer just sits there, or 'that isn't right'.</a></b><p>
<b>2.4.1 <a href="#2.4.1">The boot disk works all right on one computer but not another.</a></b><p>
<b>2.4.2 <a href="#2.4.2">Really strange errors in the various *BSD flavors.</a></b><p>
<b>2.4.2.2 <a href="#2.4.2.2">Using the new code in NetBSD, I get a "panic: pdti 206067" in pmap_enter(). What should I do?</a></b><p>
<b>2.4.3a <a href="#2.4.3a">I get the error "isr 15 and error: isr 17" on an NE2000 card.</a></b><p>
<b>2.4.3b <a href="#2.4.3b">I have some card on IRQ2 and it doesn't work; why?</a></b><p>
<b>2.4.3c <a href="#2.4.3c">I am getting lousy performance out of my network card. What are some of the other possibilities?</a></b><p>
<b>2.4.4 <a href="#2.4.4">What is the difference between IRQ2 and IRQ9? Are they really the same, or are they really different?</a></b><p>
<b>2.4.5 <a href="#2.4.5">Some of my SCSI devices (like a tape drive) don't work; why?</a></b><p>
<b>2.4.6 <a href="#2.4.6">I want to use the Adaptec 1542C SCSI controller. What are the problems/tricks you need to know to get it working?</a></b><p>
<b>2.4.7 <a href="#2.4.7">Is there a SCSI utility which works to fix up the random problems I sometimes have with my drives?</a></b><p>
<b>2.4.8 <a href="#2.4.8">My system boots OK off the floppy, but once I try to boot from the hard drive, the message "changing root device to sd0a" appears and the system hangs. What is the most likely thing that I have done wrong?</a></b><p>
<b>2.5 <a href="#2.5">Other common problems that are attributed to the installation process but are caused other places.</a></b><p>
<b>2.5.1 <a href="#2.5.1">I want to use more than 16 Megabytes of memory. Will any of the BSD based systems support it?</a></b><p>
<b>2.5.2 <a href="#2.5.2">I tried to use a device in my computer that should be there. When I did, I got a "Device not configured error." What do I do now?</a></b><p>
<b>2.6 <a href="#2.6">Customizing the system to meet my needs.</a></b><p>
<b>2.6.1 <a href="#2.6.1">How do I get the system to not display the machine name, but display our company name?</a></b><p>
<b>2.6.2 <a href="#2.6.2">I have a program that, under normal circumstances, starts once a second. This regularly causes inetd to terminate the program with a 'server failing (looping), service terminated' error. How do I fix this?</a></b><p>
<b>3.0 <a href="#3.0">System Internals</a></b><p>
<b>3.1 <a href="#3.1">Kernel</a></b><p>
<b>3.1.1 <a href="#3.1.1">How do I build a kernel?</a></b><p>
<b>3.1.1.1 <a href="#3.1.1.1">Why does the kernel code for NetBSD still use the old K&R style declarations when the ANSI declarations are SO much better?</a></b><p>
<b>3.1.1.2 <a href="#3.1.1.2">How do I port NetBSD to another platform?</a></b><p>
<b>3.1.2 <a href="#3.1.2">I want to do one of the following things: * add a device not in the distributed kernel (third com port, additional disk or tape, line printer driver, etc). * use a patch from the net or the patchkit to fix a kernel bug. * add another swap device. * recompile the kernel to remove extraneous devices so that it takes up less space. * configure more pseudo-terminals to allow for more xterms or network logins.</a></b><p>
<b>3.1.3 <a href="#3.1.3">I want to build and profile a kernel. What do I need to do?</a></b><p>
<b>3.1.4 <a href="#3.1.4">Now that I have a kernel, how do I install it?</a></b><p>
<b>3.1.5 <a href="#3.1.5">My system is complaining about stray interrupt 7. Is my machine going to explode or anything?</a></b><p>
<b>3.1.6 <a href="#3.1.6">I keep getting "wd0c: extra interrupt". What does it mean?</a></b><p>
<b>3.1.7 <a href="#3.1.7">I keep getting silo overflow messages, but the system doesn't seem to mind. Is there a problem?</a></b><p>
<b>3.1.8 <a href="#3.1.8">I found a bug in the kernel. How do I report it?</a></b><p>
<b>3.2 <a href="#3.2">What exactly is this config file, anyway? What are all of these cryptic notations?</a></b><p>
<b>3.2.1 <a href="#3.2.1">Okay, fine. Why shouldn't I just add every device I can find to the kernel, so I'll never have to recompile this again?</a></b><p>
<b>3.2.2 <a href="#3.2.2">What should I remove from the kernel?</a></b><p>
<b>3.2.3 <a href="#3.2.3">I can't get enough remote login sessions or xterm sessions. I also can only get four sessions working at a time. What can I do?</a></b><p>
<b>3.2.4 <a href="#3.2.4">How do I get ddb, the kernel debugger, compiled into the kernel and running?</a></b><p>
<b>3.2.5 <a href="#3.2.5">I'm getting all kinds of errors when I try to build a new version of GCC. How can I upgrade GCC to the most current version?</a></b><p>
<b>3.2.6 <a href="#3.2.6">Can I patch the current running OS image?</a></b><p>
<b>3.2.7 <a href="#3.2.7">Can I have more than one config file? Should I rename it to something else? Any other hints?</a></b><p>
<b>3.2.8 <a href="#3.2.8">I have been getting a lot of "virtual memory exhausted" errors when I am compiling a program with a really big static array. I have 128Meg of memory and 8Gig of swap. How can this be happening?</a></b><p>
<b>3.2.8.1 <a href="#3.2.8.1">I am running NetBSD and really DO have 128 Meg of memory; but the generic kernel only sees the first 64Meg. How can I fix this?</a></b><p>
<b>3.2.8.2 <a href="#3.2.8.2">How do I dedicate 16Meg of memory to nothing but disk buffers?</a></b><p>
<b>3.2.9 <a href="#3.2.9">Where can I learn more about all this?</a></b><p>
<b>3.3 <a href="#3.3">Other kernel related kind of questions.</a></b><p>
<b>3.3.1 <a href="#3.3.1">Has the method for system call changed in NetBSD?</a></b><p>
<b>3.3.2 <a href="#3.3.2">Does anyone have a system building script that takes things like building a new config and multiple config files into account?</a></b><p>
<b>3.3.3 <a href="#3.3.3">How do I upgrade from my release version of NetBSD (and probably FreeBSD) to the '-current' development sources?</a></b><p>
<p>
<b>3.3.4 <a href="#3.3.4">Is there a Makefile that does all that happy world-building stuff?</a></b><p>
<b>3.3.5 <a href="#3.3.5">Can NetBSD do cross compilation?</a></b><p>
<b>3.3.6 <a href="#3.3.6">My network memory seems to be leaking. The numbers just keep increasing slowly over time. Is there a problem I need to worry about?</a></b><p>
<b>3.4 <a href="#3.4">X11/XFree86/XS3</a></b><p>
<b>3.4.1 <a href="#3.4.1">What options should I define to get the X extensions included?</a></b><p>
<b>3.4.2 <a href="#3.4.2">Where can I get the FAQ for 'X'?</a></b><p>
<b>3.4.3 <a href="#3.4.3">Why does X drop characters when using xdm? When I run xdm from the console, it keeps losing keystrokes and the shift keys don't always work. Why?</a></b><p>
<b>3.4.4 <a href="#3.4.4">What can I do to figure out why 'X' doesn't work with NetBSD?</a></b><p>
<b>3.4.5 <a href="#3.4.5">Under NetBSD and FreeBSD, xlock (or any other program that uses passwords) fails to validate user passwords. Anyone know why?</a></b><p>
<b>3.5 <a href="#3.5">I want to run 'XYZA' which is dynamically linked and from 'some other operating system'. What special things do I have to do to get it working?</a></b><p>
<b>3.6 <a href="#3.6">You promised to talk about timezones below. Are you going to?</a></b><p>
<b>3.6.1 <a href="#3.6.1">How do you change the timezone on NetBSD (FreeBSD also?)?</a></b><p>
<b>3.6.2 <a href="#3.6.2">The translation between seconds-since-the-epoch and date differs by about 18 seconds between BSD and other Unixes when running ntp; why?</a></b><p>
<b>3.7 <a href="#3.7">How can I implement CVS to track MY changes to the kernel source tree, yet still follow the -current development tree?</a></b><p>
<b>3.8 <a href="#3.8">Optional Op-codes for NetBSD, FreeBSD, and other systems.</a></b><p>
<b>4.0 <a href="#4.0">Introduction</a></b><p>
<b>4.1 <a href="#4.1">Common (sort of) Kernel-related problems</a></b><p>
<b>4.1.1 <a href="#4.1.1">Sometimes I have trouble with my system resetting the terminal to seven bit mode. Isn't BSD eight bit clean?</a></b><p>
<b>4.1.2 <a href="#4.1.2">How do you implement quotas on Net/2 derived BSD systems?</a></b><p>
<b>4.1.3 <a href="#4.1.3">What are the correct permissions for the /tmp, /usr/tmp, and /var/tmp directories?</a></b><p>
<b>4.2 <a href="#4.2">Available kernel add-ons</a></b><p>
<b>4.2.1 <a href="#4.2.1">Loadable Kernel Modules</a></b><p>
<b>4.3 <a href="#4.3">Other program building type problems.</a></b><p>
<b>4.3.1 <a href="#4.3.1">I am building a program that requires access to the crypt library. Either I have it and it isn't getting copied into the executable, or I don't have it; why?</a></b><p>
<b>4.3.2 <a href="#4.3.2">I am having trouble with long file names in my libraries. It seems like there is a 16 character limit in the library somewhere.</a></b><p>
<b>4.3.3 <a href="#4.3.3">I'm getting annoyed with having this "conflicting types for `sys_errlist'" problem show up nearly every time I build a program. What do I need to do?</a></b><p>
<b>4.4 <a href="#4.4">System Administration Questions</a></b><p>
<b>4.4.1 <a href="#4.4.1">Where can I get good books about NetBSD or FreeBSD?</a></b><p>
<b>4.4.2 <a href="#4.4.2">I am concerned about system security. What should I do to protect my system from net attacks?</a></b><p>
<b>4.4.3 <a href="#4.4.3">How can I log failed login attempts?</a></b><p>
<b>4.4.4 <a href="#4.4.4">Can I use a Concatenated Filesystem with NetBSD?</a></b><p>
<b>4.4.4.1 <a href="#4.4.4.1">Why, when I type "ccdconfig ccd0 16 none /dev/wd0a &gt /dev/wd1a", do I get back "ccdconfig: ioctl (CCDIOCSET): /dev/ccd0d: Device not configured"?</a></b><p>
<b>4.4.5 <a href="#4.4.5">I am really new to Unix System Administration. I need some real basic help.</a></b><p>
<b>4.4.5.1 <a href="#4.4.5.1">What is the System Administrator's user name?</a></b><p>
<b>4.4.5.2 <a href="#4.4.5.2">I can't log in as 'su'. What does that message mean when I log in as root.</a></b><p>
<b>4.4.5.3 <a href="#4.4.5.3">Are there any books I can 'bootstrap' myself with?</a></b><p>
<b>4.4.5.4 <a href="#4.4.5.4">How about some code examples?</a></b><p>
<b>4.5.6 <a href="#4.5.6">How do I change the default shell for a user?</a></b><p>
<b>4.5 <a href="#4.5">Daemon questions</a></b><p>
<b>4.5.1 <a href="#4.5.1">I'd like to use amd to mount a file system (/dev/sd0f aka /usr/local) on another machine as "/usr/local". What's the magic?</a></b><p>
<b>4.5.2 <a href="#4.5.2">I am having trouble with my nameserver refusing to accept 'nslookup's from my SunOS machine after I installed the resolver fix. The exact error message is "*** Can't find server name for address 194.100.46.2: Query refused". Can you help?</a></b><p>
<b>4.5.3 <a href="#4.5.3">Are there any alternatives to 'NIS' available for NetBSD, et al.?</a></b><p>
<b>4.6 <a href="#4.6">Adding new and removing old users.</a></b><p>
<b>4.6.1 <a href="#4.6.1">Where can I FTP the 'adduser' program?</a></b><p>
<b>4.6.2 <a href="#4.6.2">Where can I get a 'rmuser' script?</a></b><p>
<b>5.0 <a href="#5.0">Introduction</a></b><p>
<b>5.1 <a href="#5.1">A replacement curses program/library.</a></b><p>
<b>5.2 <a href="#5.2">Floppy Disk problems.</a></b><p>
<b>5.2.1 <a href="#5.2.1">How do I get a bootable floppy?</a></b><p>
<b>5.2.2 <a href="#5.2.2">How do I maximize the space on a mountable floppy disk.</a></b><p>
<b>5.3 <a href="#5.3">Character Device Driver info</a></b><p>
<b>5.3.1 <a href="#5.3.1">Printers</a></b><p>
<b>5.3.2 <a href="#5.3.2">Terminals/Keyboards</a></b><p>
<b>5.3.3 <a href="#5.3.3">Modems/FAX Modems</a></b><p>
<b>5.3.3.1 <a href="#5.3.3.1">How do I add a modem to *BSD:</a></b><p>
<b>5.3.3.4 <a href="#5.3.3.4">Adding a Dial-in/Dial-out FAX to NetBSD or FreeBSD.</a></b><p>
<b>5.3.4 <a href="#5.3.4">What is the trick for getting Kermit to work with rz and sz?</a></b><p>
<b>5.4 <a href="#5.4">Tape Drives</a></b><p>
<b>5.4.1 <a href="#5.4.1">Does the tape need to be formatted?</a></b><p>
<b>5.4.2 <a href="#5.4.2">If I execute the command 'st -f /dev/st0 status', I get: Archive/Tandberg? tape drive, residual=0, blocksize=512 Density: high = 16 (0x10), medium = 15 (0xf), low = 5 (0x5) ds=0 er=0</a></b><p>
<b>5.4.3 <a href="#5.4.3">When is erst0 used?</a></b><p>
<b>5.4.4 <a href="#5.4.4">How is density (bpi) computed? I am using 3M DC 6250 cassettes which have a 250MB capacity on the Viper 150. But computing the bits/inch based on 250MB/tape-length (1020 ft.), I get a density of 171335 bpi, which is nowhere near the 10000 bpi associated with QIC-150 in the st(1) man page. Why the discrepancy?</a></b><p>
<b>5.4.5 <a href="#5.4.5">How is an appropriate block size determined (and in what units are they specified in the st(1) command)?</a></b><p>
<b>5.4.6 <a href="#5.4.6">From the 4.3BSD mtio(4) man page, it sounds like data is typically (traditionally?) stored on tape in eof-terminated sequences of 1K records.</a></b><p>
<b>5.4.6.1 <a href="#5.4.6.1">Is st's notion of "file" the record sequence between two eof marks?</a></b><p>
<b>5.4.6.2 <a href="#5.4.6.2">What about a "record"?</a></b><p>
<b>5.4.6.3 <a href="#5.4.6.3">Is a "record" one "block", as determined by st's "blocksize" command? If not, what is the connection between them?</a></b><p>
<b>5.4.6.4 <a href="#5.4.6.4">Can I change the "record" size?</a></b><p>
<b>5.4.6.5 <a href="#5.4.6.5">When would I want a block size that is different from the default? 1KB is the size of writes used by dd or whatever. QIC specifies 512 byte records (well at least its what people use..) Whatever you write in will be broken into 512 byte sections. They must be multiples of 512 though.</a></b><p>
<b>5.4.7.1 <a href="#5.4.7.1">How do I write several archives to a single tape? I tried without success: $ st -f /dev/rst4 rewind $ tar cf /dev/nst4 archive1 $ st -f /dev/nrst4 weof $ tar cf /dev/nst4 archive2 $ st -f /dev/nrst4 weof</a></b><p>
<b>5.4.7.2 <a href="#5.4.7.2">Later, I would expect to be able to access, say, archive3 via the fsf directive to skip over the first two archives. What is the correct sequence?</a></b><p>
<b>5.4.8 <a href="#5.4.8">Since the Viper 150 writes on QIC-150/120, I guess I don't need to worry about writing variable-length records? How about reading a tape written with variable-length records. Is this possible with the Viper? If so, what's involved?</a></b><p>
<b>5.4.9 <a href="#5.4.9">The very scant documentation that came with my drive mentions a "selectable buffer disconnect size," whose default is 16K. This is evidently the "maximum number of bytes that can be sent over the SCSI bus during a single data transfer phase." What's that? How is it connected st's "blocksize" command? Do I want to use 16K blocks, or might I even want to set the disconnect size to a higher value?</a></b><p>
<b>5.4.10 <a href="#5.4.10">What is "streaming"? When I tar a directory of files to tape, I notice that the tape often stops. Streaming means it doesn't stop? How would I get the viper 150 to stream using tar or cpio or dump?</a></b><p>
<b>5.4.13 <a href="#5.4.13">My tape drive doesn't work.</a></b><p>
<b>5.4.14 <a href="#5.4.14">I am trying to restore a tape from a FreeBSD machine on a Sun. What kinds of problems should I expect?</a></b><p>
<b>5.4.15 <a href="#5.4.15">What are the jumper settings for the Archive Viper tape drive?</a></b><p>
<b>5.4.16 <a href="#5.4.16">My Viper-150 auto-detects fine; however, the first attempt to read a tape fails after a boot due to an "illegal SCSI command". What could be the problem?</a></b><p>
<b>5.4.17 <a href="#5.4.17">Why haven't we changed the defaults in rdump and rrestore to something that makes sense? I was trying to dump a filesystem to a remote tape and ran into an error complaining about being unable to execute /etc/rmt.</a></b><p>
<b>5.5 <a href="#5.5">Network Stuff</a></b><p>
<b>5.5.1 <a href="#5.5.1">How can I get my system to work as a network router?</a></b><p>
<b>5.5.2 <a href="#5.5.2">I recently had a problem where I got a message that said "panic: kmem_malloc: mb_map too small". What is the solution to this problem?</a></b><p>
<b>5.5.3 <a href="#5.5.3">Does anyone have an example of a working gated.conf file? I can't figure these instructions out at all.</a></b><p>
<b>5.5.4 <a href="#5.5.4">How do I set up Multicasting on my system?</a></b><p>
<b>5.6 <a href="#5.6">I want to use my ZIP drive. Are there any weird things I need to know?</a></b><p>
<b>6.0 <a href="#6.0">Working with DOS and BNR/2 related software.</a></b><p>
<b>6.1 <a href="#6.1">Formatting a floppy</a></b><p>
<b>6.2 <a href="#6.2">Sharing the Disk with MS-DOS</a></b><p>
<b>6.2.1 <a href="#6.2.1">How can I partition my drive to support both MS-DOS and *bsd?</a></b><p>
<b>6.2.2 <a href="#6.2.2">I can install using the whole disk, but I can't install when I try to share the drive between *BSD and MS-DOS. Why?</a></b><p>
<b>6.2.4 <a href="#6.2.4">Is there any hope of ever running MS-DOS applications under any of the free BSD systems?</a></b><p>
<b>6.2.5 <a href="#6.2.5">How do I get Linux executables to run under NetBSD?</a></b><p>
<b>6.3 <a href="#6.3">Accessing the MS-DOS filesystem</a></b><p>
<b>6.4 <a href="#6.4">NFS/PC-NFS support</a></b><p>
<b>6.4.1 <a href="#6.4.1">Can I use 8K packets for NFS? When I try, I have all kinds of problems. Specifically, I get 'ring buffer overflows' or the performance is real bad.</a></b><p>
<b>6.4.2 <a href="#6.4.2">How do I get around the NFS "Permission denied" error?</a></b><p>
<b>6.4.3 <a href="#6.4.3">What does the message "BAD MNT RPC: RPC Authentication error; why = Invalid client credential" mean when I try to mount something from another machine?</a></b><p>
<b>6.4.4 <a href="#6.4.4">What does the message "Bad MNT RPC: RPC: Authentication error; why = Client credential too weak" mean when I try to mount something from another machine?</a></b><p>
<b>6.4.5 <a href="#6.4.5">I get a lot of 'ring buffer overflow' messages using NFS and the ed0 driver. Is there a problem?</a></b><p>
<b>6.4.6 <a href="#6.4.6">I am getting really poor performance out of my network, especially when talking to older networks or when performing short file transfers. What's the problem?</a></b><p>
<b>6.4.7 <a href="#6.4.7">Is there any PC software that will allow me to use my enormous PC with all of the unsupported hardware as a PC-NFS server?</a></b><p>
<b>6.5 <a href="#6.5">How can I use mtools with the 'new' floppy naming convention?</a></b><p>
<b>7.0 <a href="#7.0">Communications</a></b><p>
<b>7.1 <a href="#7.1">SLIP/CSLIP</a></b><p>
<b>7.2 <a href="#7.2">PPP</a></b><p>
<b>7.2.1 <a href="#7.2.1">I have a problem with my PPP connection. From time to time, the connection will just 'pause'. If I do something in another window which polls some other external machine, the connection will 'unpause' for a while.</a></b><p>
<b>7.3 <a href="#7.3">TCP/IP</a></b><p>
<b>7.3.1 <a href="#7.3.1">Where can I obtain *BSD source code to add IP Security per the IETF RFCs (RFC-1825 through RFC-1829) to my system ?</a></b><p>
<b>7.4 <a href="#7.4">UUCP</a></b><p>
<b>7.4.1 <a href="#7.4.1">TIP/CU</a></b><p>
<b>7.4.2 <a href="#7.4.2">What is the magic incantation that allows the modem to dial?</a></b><p>
<b>7.4.3 <a href="#7.4.3">My modem on DOS COM3 or DOS COM4 works with DOS, but not with *BSD. It is set up using IRQ 4 (or 3) respectively.</a></b><p>
<p>
<b>7.5 <a href="#7.5">How do I configure my nameserver?</a></b><p>
<b>7.6 <a href="#7.6">Terminals</a></b><p>
<b>7.7 <a href="#7.7">My network manager (or UUCP feed site admin) just informed me that the way I have installed sendmail through my UUCP connection and has caused a sendmail loop. Can you help me get sendmail installed correctly?</a></b><p>
<b>7.8 <a href="#7.8">Can network attached assets be used by/from NetBSD? FreeBSD? OpenBSD?</a></b><p>
<b>7.8.1 <a href="#7.8.1">Is it possible to Network boot a NetBSD machine from a network on a diskless Sparc?</a></b><p>
<b>7.8.2 <a href="#7.8.2">I have been working with FreeBSD 1.5.1 with some machines configured as diskless. How can I do the same for 2.0R (i.e., Which are the magic words to put in the Kernel configuration file?)</a></b><p>
<b>7.8.3 <a href="#7.8.3">How can I get ISDN to work?</a></b><p>
<b>8.0 <a href="#8.0">What hardware works!</a></b><p>
<b>8.3.1 <a href="#8.3.1">How do I configure multiport cards? Is there a possibility of using multiport serial boards? How do you configure an AST/4 in the kernel? It looks like the AST driver only supports 4-port cards, but it looks like it would be easy to add support for 8 ports ... or am I wrong?</a></b><p>
<b>8.3.3 <a href="#8.3.3">What is the difference between baud and bits per second?</a></b><p>
<p>
<b>8.4 <a href="#8.4">Disk Controller Problems</a></b><p>
<b>8.4.2 <a href="#8.4.2">SCSI controller problems</a></b><p>
<b>8.5 <a href="#8.5">SCSI Controllers</a></b><p>
<b>8.6 <a href="#8.6">Network Cards</a></b><p>
<b>8.7 <a href="#8.7">Printers</a></b><p>
<b>8.7.1 <a href="#8.7.1">How can I print big files (especially from SAMBA, the WfWg network program)?</a></b><p>
<b>8.8 <a href="#8.8">Tape Drives.</a></b><p>
<b>8.8.1 <a href="#8.8.1">What are the jumper configurations for the Exabyte 8200 DAT tape drive?</a></b><p>
<b>8.9 <a href="#8.9">QIC-40/80 tape drives</a></b><p>
<b>8.10 <a href="#8.10">CD-ROMs</a></b><p>
<b>8.10.1 <a href="#8.10.1">How can I mount my CD-ROM so that it appears to be writable?</a></b><p>
<b>9.0 <a href="#9.0">What GNU software has been tested and is working with Net/2 derived BSD systems for the 386?</a></b><p>
<b>9.1 <a href="#9.1">Has anyone ever gotten news to work?</a></b><p>
<b>9.1.1 <a href="#9.1.1">I want to make sure I have every set up right for my news partition. What newfs options do I need to use to get this information stored OK without future problems?</a></b><p>
<b>9.3 <a href="#9.3">Has anyone tried to get Postgres to work?</a></b><p>
<b>9.4 <a href="#9.4">Has anyone gotten the Java Developers Kit working?</a></b><p>
<b>9.5 <a href="#9.5">Has anyone ever used any of the BSD systems for a Firewall?</a></b><p>
<b>9.6 <a href="#9.6">How about the BSD Song?</a></b><p>
<p>
<p>
<a name="0.1"><h3>0.1 : A brief history of the *BSD family.</h3>

<p>
	In the beginning, there was Research Unix.  Bell Labs, in a
	moment of utter abandon said "Let us produce progeny of Unix.
	yea verily, that we might garner a market share with this white
	elephant."  In order to beget as many pretenders to the Unix
	throne as possible, they removed most of the copyright notices
	and released huge gobbets of code to Universities throughout the
	United States.  From that humble decision came the very spark of
	what has arguably become the most successful, completely free
	Unix-style operating system you can make money on.
<p>
	There were several version of BSD roaming around, but they all
	had one thing in common.  You HAD to have a source code license
	to the original Unix source to get a working version going.  The
	bulk of the code was written at Berkeley, much of it by
	long-haired computer geeks, complete with bad complexions and
	pocket protectors.  Many Master's Degrees were built on what was
	to follow.
<p>
	Then, suddenly, someone realized the amount of source code from
	the original Unix distribution was pretty much down to zilch.
	They decided that making the distribution available to the whole
	world (not just the select Unix license holders) seemed like a
	pretty 'groovy' (to use the vernacular) idea.  From that came
	the Net distribution.
<p>
	William and Lynne Jolitz, with their standard flair and panache,
	decided to write the pieces that needed to be written.  From
	that decision came 386BSD Version 0.0.  Generally considered to
	be unusable, it was nonetheless a major coup, in that one no
	longer needed the dreaded 'source license' to produce working
	operating system images.  Version 0.1 (generally considered to
	be the progenitor of all of the subsequent PC BSD systems) was
	released on Bastille Day, 1992.
<p>
	386BSD 0.1 eventually came to be.  Linux, the other entrant in
	the Free Unix-style OS family, had been running for about a year
	by then.  Many people, wanting to stick with code that they
	already knew and which was in use in the commercial sector,
	decided to start using (and fixing) the 386BSD 0.1 code.  As such,
	many contributions to the system are provided through interaction
	by people who communicate via many means.  Many new and innovative
	features have been added to 386BSD since it's original release in 
	July of '92.  There was an 'unofficial' patchkit which was available
	from many anonymous FTP sources which made 386BSD more stable and
	usable.  Many problems associated with the use of 386BSD Version 
	0.1 were solved through the application of patches from the 
	patchkit.  Now, more or less overcome by events, the original
	386BSD, with its relationship to the AT&T/Berkeley out-of-court
	settlement, has become a rare piece of code to find.  With some
	of the code considered 'suspect', it was removed from FTP sites
	world-wide.
<p>
	To replace the original 386BSD, three newer versions of the 
	system are available, under new names.  NetBSD is the oldest, 
	FreeBSD followed shortly thereafter.  Both systems have evolved 
	into programs that are superior to their progenitor and both 
	have sizable (if a little rabid) followings.  The third entry in
	the group is a fairly recent entrant, called OpenBSD.  
<p>
	Most of the statements made in this FAQ will apply to all three 
	of the replacement systems, although I will try to differentiate 
	one from another whenever the difference matters.  Any place 
	that says 386bsd either means the original 386bsd 0.1 or any 
	of the members of the PC BSD family.  
<p>
	There have been many attempts to polarize the *BSD development 
	groups in the past.  One of the reasons that I am still 
	maintaining the FAQ is that it simply is a good source for
	historical information, as well as a reasonable source for 
	information that is specific to the implementations of NetBSD, 
	FreeBSD, and OpenBSD.
<p>
	It should be remembered that when the *BSD family started out, Bill
	and Lynne used a source called the "Berkeley Net Release/2" tape 
	as their foundation.  While this provided a stable starting point, 
	it also built a possible bomb into the system.  Due to a legal 
	battle (which has now been resolved) the following files are 
	identified as 'encumbered' in the BNR/2 source tree.  These
	kernel files are identified as the 'binary only' files in the
	BSDI distribution, and either have been or must be replaced
	before we can have a truly free OS family.  These files are the
	primary reason you won't find the original 386BSD Version 0.1
	available for FTP anymore.
<p>
<p>
<a name="0.1.1"><h3>0.1.1 : How close is NetBSD (or FreeBSD) to BSD 4.4?</h3>

<p>
	If you take a look at the README files that accompany each of
	these packages, you will find that each is based as closely as
	possible to BSD 4.4-Lite.  The core development team for FreeBSD 
	used the 4.4 Lite distribution and re-engineered the missing 
	pieces to come up with the the current version of FreeBSD.  The
	NetBSD developers started with the existing 386BSD files, and
	compared them to the unencumbered, freely releasable files from
	BSD 4.4.  For both groups, any files which were not available
	(through being encumbered) were written from scratch to provide
	the functionality that was needed.  Either way, both systems are
	close to BSD 4.4.  Of course, each has differences that make it
	different from the other, and different from regular BSD 4.4.  
<p>
<p>
<a name="0.1.3"><h3>0.1.3 : Where can I get more information about the *BSD family of Operating Systems?</h3>

<p>
	Here are the current members of the *BSD family.  These are
	presented in alphabetical order, to avoid implying anything.
<p>
	386BSD - An older version of BSD now targeted exclusively at 
	the research and academic community.  CD distributions only, 
	sold by Dr. Dobb's Journal.
<p>
	FreeBSD - A version of BSD for Intel platforms only and targeted 
	at a broad user base.  See <a href="http://www.freebsd.org">http://www.freebsd.org</a> for details or 
	<a href="ftp://ftp.freebsd.org/pub/FreeBSD">ftp://ftp.freebsd.org/pub/FreeBSD</a> for the latest release.
<p>
	NetBSD - A version of BSD for many different platforms, from 
	Intel to the 68K to the DEC ALPHA.  See <a href="http://www.netbsd.org">http://www.netbsd.org</a> for 
	more details or <a href="ftp://ftp.netbsd.org/pub/NetBSD">ftp://ftp.netbsd.org/pub/NetBSD</a> for the latest 
	release.
<p>
	OpenBSD - Another version of BSD.  See <a href="http://www.openbsd.org">http://www.openbsd.org</a> for 
	more details or <a href="ftp://ftp.openbsd.org/pub/OpenBSD">ftp://ftp.openbsd.org/pub/OpenBSD</a> for the latest 
	release.
<p>
<p>
<a name="0.2"><h3>0.2 : About this FAQ.</h3>

<p>
	This FAQ consists of several parts:
<p>
	 <a href="#section_0">Section 0</a>.  Basic FAQ information
<br>

	 <a href="#section_1">Section 1</a>.  General Network Information
<br>

	 <a href="#section_2">Section 2</a>.  Common installation questions
<br>

	 <a href="#section_3">Section 3</a>.  Kernel Building and Maintenance
<br>

	 <a href="#section_4">Section 4</a>.  Kernel Additions
<br>

	 <a href="#section_5">Section 5</a>.  Kernel Replacement Parts
<br>

	 <a href="#section_6">Section 6</a>.  Interaction with MS-DOS
<br>

	 <a href="#section_7">Section 7</a>.  System Communication
<br>

	 <a href="#section_8">Section 8</a>.  NetBSD for the Mac FAQ
<br>

	 <a href="#section_9">Section 9</a>.  NetBSD for the Amiga FAQ
<br>

		...
<br>
		Section n.  NetBSD for the Timex Sinclair FAQ
<br>
<p>
	It has been suggested that I remove some of the older, less 
	relevant information from this FAQ.  I have given it some 
	thought, and I might.  Of course, if someone were to do it for 
	me, it sure wouldn't break my heart.
<p>
<p>
<a name="0.2.1"><h3>0.2.1 : I want to start up a thread about why *BSD is or isn't as good as some other operating system. Can anyone suggest a good reason why I shouldn't?</h3>

<p>
	Jordan Hubbard, one of the FreeBSD core team members, has
	offered this missive on that very subject:
<p>
	[ Note:  You could very well simply substitute the word
	"NetBSD", "OpenBSD", or "Windows 95"  for "Linux" in the 
	argument that follows ]
<p>
	From time to time, a thread in both the comp.os.386bsd.misc and 
	comp.os.linux.misc groups flares up regarding which operating
	system is "better", FreeBSD or Linux.  This generally provokes 
	controversy from users on both sides, with one group claiming
	that their OS is "better" for some reason and the other group
	claiming that the first group doesn't know what the heck it's
	talking about.
<p>
	Both arguments are a waste of time.
<p>
	Rather than trying to win a rather questionable debate on
	relative (and constantly changing) technical merits, we should
	be asking ourselves what both groups are REALLY about and what
	they represent.  This is naturally going to be a matter of
	personal opinion, but I believe even the most seriously at-odds
	members would agree that both operating systems represent a
	unique and long-awaited opportunity: The ability to run a fully 
	featured operating system on popular, easily affordable
	hardware and for which all source code is freely available.
	Those who have been in computing for awhile will remember when
	the term `operating system' referred almost exclusively to
	something provided solely by the hardware vendor, with very
	little in the way of alternative options.  It was never EVER
	given out with source code, and true "wizard" status could only
	be achieved by exerting mind-numbing amounts of effort and
	patience in digging through forbidden bits of binary data.  By 
	comparison, the situation today seems almost too good to be
	true!  Certainly, the feeling of achievement that came from
	finally ferreting out some esoteric bit of information from a
	4MB printed system dump was high, but I don't think that anyone
	would argue that it was hardly the most optimal way of truly
	getting to know your operating system! :-)
<p>
	So now, within a very short space of time, we're almost spoiled
	for choice in having machines several times more powerful than
	the first multi-user VAX machines and available for under
	$2000, and we've got not one but SEVERAL perfectly reasonable
	free operating systems to chose from.  We are in a comparative 
	paradise, and what are some of us doing?  *Complaining* about 
	it!  I suppose too much is never enough, eh? :-)
<p>
	So, my essential point is simply this:  For the first time ever
	we have what previous computing generations could only dream
	about; powerful computers at a reasonable prices and a
	wonderful selection of things to run on them.  Be happy, read
	the source code you're so privileged to now have available
	(*believe* me!  What I wouldn't have given, even 5 years ago!)
	and spend your energy in making constructive use of it, not in 
	arguing with the guys on the other side of the fence!
<p>
	Additionally, it should be said that none of the FreeBSD team
	has anything but the highest degree of respect for Linus
	Torvalds and his "team" of dedicated volunteers (and we
	occasionaly exchange gripe mail about the huge volume of
	messages each of us gets as a direct result of being insane
	enough to volunteer to do something like this :-).  Our common 
	commitment to the Intel platform also gives us more common
	ground (and interests) than one might think and, if anything,
	it's a pity that we do not endeavor to share more code and
	effort - ideologically, at least, I'd say we share pretty
	similar goals.
<p>
	As to which is "best", I have only one standard reply: Try them
	both, see for yourself, think for yourself.  Both groups have
	given you something for free, at considerable personal effort,
	and the least you can do is give them the benefit of exerting
	enough effort to try what they're offering out before passing 
	judgment (or worse, blindly accepting someone else's!).
<p>
	Whichever you run, you're getting a great deal - enjoy!
<p>
				Jordan Hubbard
<br>
<p>
<p>
<a name="0.3"><h3>0.3 : Are there any resources on the Net (like URLs) associated with the BSD family of operating systems?</h3>

<p>
	Yup:
<p>
	<a href="http://www.public.iastate.edu:~gendalia/FAQ/FAQ.list.html">http://www.public.iastate.edu:~gendalia/FAQ/FAQ.list.html</a>
	<a href="http://www.freebsd.org/">http://www.freebsd.org/</a>
	<a href="http://www.openbsd.org/">http://www.openbsd.org/</a>
 	<a href="http://rfhs1012.fh.uni-regensburg.de/~feyrer/">http://rfhs1012.fh.uni-regensburg.de/~feyrer/</a>
	<a href="http://www.cd.chalmers.se/~nh/netbsd.html">http://www.cd.chalmers.se/~nh/netbsd.html</a>
	<a href="http://www.flame.org/netbsd/projects">http://www.flame.org/netbsd/projects</a>
	<a href="ftp://ftp.uni-regensburg.de/pub/NetBSD-Amiga/.index.html">ftp://ftp.uni-regensburg.de/pub/NetBSD-Amiga/.index.html</a>
	<a href="ftp://ftp.cdrom.com:/pub/FreeBSD/packages/WWW.tgz">ftp://ftp.cdrom.com:/pub/FreeBSD/packages/WWW.tgz</a>
	<a href="ftp://ftp.netbsd.org:pub/NetBSD/mailing-lists">ftp://ftp.netbsd.org:pub/NetBSD/mailing-lists</a>
	<a href="ftp://flick.lerc.nasa.gov:~ftp/pub/NetBSD/packages/i386">ftp://flick.lerc.nasa.gov:~ftp/pub/NetBSD/packages/i386</a>
	<a href="ftp://ftp.iastate.edu:/pub/Netbsd/FAQ">ftp://ftp.iastate.edu:/pub/Netbsd/FAQ</a>
	<a href="http://sirius.ics.es.osaka-u.ac.jp/~kamahara/NetBSD-X68060">http://sirius.ics.es.osaka-u.ac.jp/~kamahara/NetBSD-X68060</a>
	<a href="http://wwwipd.ira.uka.de/~frueauf/FAQ/NetBSD-Amiga-X-FAQ.txt">http://wwwipd.ira.uka.de/~frueauf/FAQ/NetBSD-Amiga-X-FAQ.txt</a>
<p>
	IF you are going to be using IRC in the near future and want to
	talk to some of the movers and shakers in NetBSD, the next time
	you log in look for one of the following people:
<h2><pre>
</h2>
		Handle		Channel
<br>
		'hubertf' 	#netbsd
<br>
<h2></pre>
</h2>
<p>
<a name="0.4"><h3>0.4 : How to add your pet answer to the FAQ.</h3>

<p>
	This is the trickiest part of this section of the FAQ.  There are 
	only two criteria for getting an entry made into the FAQ:
<p>
	1.  Your answer should answer a question that seems to come up
	    with some regularity, or at least perplexes a group of
	    people from time to time.
<p>
	2.  Your answer should be technically correct.  In other words,
	    answers like 'RTFM' and 'everybody knows that' are not really
	    good candidates for the FAQ.  These answers should spell out,
	    in a reasonable level of detail, precisely how to fix the
	    the question asked, or explain the basis for the answer and
	    leave the implementation of the answer to the questioner.
<p>
	All answers MUST include a question.  This is not as obvious as 
	it would seem at first glance.  An answer could solve many 
	problems, especially in the realms of system halts or other 
	catastrophes. 
<p>
	Since I (Dave) am no Unix guru, I rely HEAVILY on the input of 
	other people to make the FAQ a success.  Many questions in the 
	FAQ have been made largely irrelevant through the patchkits, but 
	that doesn't means they may not reappear.  That is why the old 
	FAQ questions are still here.
<p>
	New FAQ questions should be added.  I will try to attribute the 
	question/answer to the author, but I personally think this is a 
	waste of good disk space.  As long as the answers get out, that 
	should be reward enough :-)
<p>
<p>
<a name="0.5"><h3>0.5 : Administrivia.</h3>

<p>
	Send all question/answer pairs to <a href="mailto:burgess@cynjut.neonramp.com">burgess@cynjut.neonramp.com</a>,  
	If you are going to post the Q/A to the net, then do that, but 
	be sure to mark it as a FAQ entry.  I will get it from the net 
	as easily as I do my E-Mail.  Your Q/A will be formatted to 
	look more or less like the others and be added.  Corrections, 
	deletions, flames, snivels, and whines should be addressed 
	directly to me here.  Either way, I will be sure to send out a 
	reply letting you know what I have done with your submission.
<p>
	One last thing.  I will assume that I am infalible. :-)  I will 
	not notice any mistakes that you may find.  If you find a 
	mistake and don't tell me, it will very likely stay a mistake.
	After all, if I didn't notice it before, why should I notice
	it now?
<p>
<p>
<a name="0.6"><h3>0.6 : Does anyone reading this have any sense of humor at all?</h3>

<p>
	I'm not sure.  While reasearching the great 'Linux vs. everyone
	else sucks' debate, I received this in E-Mail.  The author's
	identity has been removed to protect him from the mail-bombs.
	For the humor impaired, stop reading now!
<p>
<hr>
<p>
	Many people ask the question "Which is better?  FreeBSD, NetBSD, 
	OpenBSD, or Linux?"  Up until now, not many people are willing 
	to answer thoroughly and give reasons.  I, being a brave soul, 
	am.  This mini-FAQ lists the most significant differences 
	between Linux, NetBSD, and FreeBSD in a fair and evenhanded 
	manner.  Permission is given to redistribute this mini-FAQ 
	freely, with attribution.  If anyone wants to take the burden 
	of posting it periodically on the appropriate newsgroups, be 
	my guest.
<p>
	This is based on a message I wrote some months ago.  I've 
	tried to update it substantially to reflect the changing 
	nature of x86 OS's.
<p>
<hr>
	Q) Which is better?  NetBSD, OpenBSD, Linux, or FreeBSD?
<p>
<p>
	A) NetBSD is the best of the three because of it's superb 
	error handling capabilities (this is the "Net" referred to 
	in the name).  With NetBSD, it's almost impossible to make 
	a mistake, either in installation, or operation, because the 
	system will "catch" you as you "fall".  NetBSD works on a 
	wide range of processors, including the Intel 386, 486, and 
	586, the Sun, Sparc, SGI, MIPS, Macintosh, Motorola 6809, 
	Krupf, ADC Kentrox, Whirlpool, Amana, Zilog Z80, 
	Timex-Sinclair, and the Braun.  Currently, the NetBSD team 
	is devoting all of their energies towards finishing the 
	all-important IBM RT port.
<p>
<p>
	Linux is the successor to an operating system called "Minix".  
	Linux was developed by Linus Pauling, a Finnish communist.  
	Linux tries to uphold traditional Marxist values in several 
	ways; firstly by using GNU tools from the FSF foundation 
	wherever possible.  The Linux kernel is developed by committee, 
	and the operating system reflects this:  rather than having one 
	"init" process which fathers all others, a group of co-resident 
	processes with equal powers are created simultaneously.  "Kill" 
	commands are treated as formal protests.  Linux networking has 
	come a long way since it's implementation, and there is no truth 
	whatsoever to the rumor that sudden losses of IP connectivity 
	are in any way related to future plans to limit users to 1.5 
	hours of SLIP or PPP unless they send in the registration fee.
<p>
<p>
	FreeBSD was a radical offshoot of the Linux project; you could 
	consider it to be of the Trotskyite school.  FreeBSD supports 
	an extremely wide range of PC hardware, as long as it was 
	obtained at less than cost.  FreeBSD is used by Amnesty 
	International and many other human rights organizations.  
	FreeBSD supports every peripheral available for the IBM PC 
	except the ones you have.  The FreeBSD team was actually 
	responsible for porting  "Doom" to Linux, in a successful 
	effort to slow down constructive work by distracting the 
	central committee with frivolous games.  FreeBSD has the 
	nicest installation of any of the x86 unices -- you install 
	the boot disks, which then initialize the modem and call 
	Jordan "Perky" Hubbard, who then comes to your house with the 
	rest of the disks and completes the installation.  The FreeBSD 
	CD-ROM plays various Nick Cave and Tom Waits songs Jordan is
	known to be fond of.
<p>
	386bsd was written by Bill Jolitz in a fit of pique.  It was 
	based entirely on Sun's widely-respected "Solaris" operating 
	system, as revenge against Sun's Bill Joy, who rudely chose a 
	name with the same initials as Jolitz.  A new version of 386bsd 
	will be released very soon.  Unfortunately, it will only run on 
	386es, and thus is unsuitable for anyone with a 486 or Pentium.  
	486bsd should be released "sometime in 2138," according to 
	industry insider James Monroe, Sr.
<p>
	DID YOU KNOW?
	=============
<p>
	1) The Free and Net BSD teams split up in the year 1632.  The 
	cause of the split is uncertain, but it seems to have something 
	to do with someone named "Janice."  They still get together for 
	drinks occasionally, and remember old times.  Every so often, 
	after tying on a few too many, they end up waking up next to 
	each other and feel ashamed over their night of pleasure.  The 
	kids still blame themselves.
<p>
	2) The Linux kernel has actually not changed at all since January, 
	'94?   Linus just increments "version.c" once every 48 hours and 
	unleashes the "change" on an unsuspecting Internet, bringing FTP 
	servers to their knees.  A book, "The Design and Implementation 
	of the Linux Operating System," by Gary Marshall James T. Kirk 
	McUsenet, was rejected by Addison-Wesley on the grounds that they 
	didn't feel the public was prepared to purchase a book written 
	on looseleaf paper with diagrams in crayon.
<p>
	3) All three systems claim to be "POSIX" compliant.  However, the 
	POSIX people have denied knowing anything about it.  Scuttlebutt 
	in the industry is that POSIX will soon be outdated, and will be 
	replaced by GNOPIX, a FSF standard which implements the TOPS-20 
	operating system in Scheme. 
<p>
<p>
<p>
<a name="section_1"><h2>Section 1. (General Network Information)
</h2>
<h2>General information
</h2>
<p>
	This section of the FAQ is about the electronic support network 
	that exists for 386bsd and its off-spring.  
<p>
<a name="1.0"><h3>1.0 : I just downloaded all of 386bsd version 0.1 and I can't get [some feature] to work? Do you have any suggestions?</h3>

<p>
	Yes.  Get FreeBSD, OpenBSD, or NetBSD.
<p>
<p>
<a name="1.1"><h3>1.1 : Minimum hardware configuration recommended</h3>

<p>
	There has been considerable debate about what the REAL minimum 
	configuration for *BSD is.  Some would claim that it is the 
	smallest computer that an installation will succeed on.  Others 
	claim that it is the smallest usable computer (based on RAM and 
	speed constraints) and others would claim that it should be 
	based on using 'X'-windows.
<p>
	The smallest installable platform is an 80386, using an MGA card, 
	with at least 4Meg of RAM and a 40 Megabyte hard disk.  While not 
	all SCSI cards (especially EISA) are supported, a great many are 
	either in the base distribution or through patches.  Thanks to
	the shared library code in FreeBSD and NetBSD, a 40Meg 
	installation should be easier now (in spite of the more advanced
	functionality) than it ever was before.
<p>
	A comfortable installation which includes source and binary 
	distributions, as well as other utilities will work in about 
	100Meg of hard drive.  
<p>
	'X' requires at least a Hercules MGA; for masochists only, from 
	what I understand.
<p>
	See section 8 for more details.
<p>
<p>
<a name="1.4"><h3>1.4 : Where to get the source and binaries</h3>

<p>
<a name="1.4.1"><h3>1.4.1 : Where can I get the distribution on CD ROM?</h3>

<p>
	In a new joint venture, John Cargille, DiscNet, Inc., and 
	InfoMagic, Inc. are pleased to announce their joint release 
	of the BSDisc.  This collaboration should be beneficial to 
	all of our customers, since it brings to bear more experience, 
	more support capability, and economies of scale in production.
<p>
	The BSDisc is scheduled to ship every six months or so.  The
	current (November 1995) disk is a two CD set with the following:
<p>
	- NetBSD 1.1
		- distribution sets for x86, sparc, mac68k, and amiga
<br>
		- expanded source tree for all architectures
<br>
	- FreeBSD 2.1.5
		- distribution sets for x86
<br>
		- expanded source and binary trees for x86
<br>
	- XFree86 binaries for both FreeBSD and NetBSD
	- X11R6 (xc as well as contrib)
	- BSD-related news archive
	- various Answers to Frequently asked Question (FAQs)
<p>
	The BSDisc is available both for single-issue purchases, or on 
	a buying plan.  Single-issue price is $35.00; subscription pricing 
	is $19.50 (or less) per issue, for a minimum length of 3 issues.  
	(Those prices do not include S/H.)
<p>
	For single-issue purchases, contact InfoMagic at:
<h2><pre>
</h2>
                                                       +1-800-800-6613
	InfoMagic, Inc.                           Tel: +1-602-526-9565
	PO Box 30370                              Fax: +1-602-526-9573
	Flagstaff, AZ  86003-0370         e-mail: <a href="mailto:orders@Infomagic.com">orders@Infomagic.com</a>
                                                    <a href="mailto:info@infomagic.com">info@infomagic.com</a>
<h2></pre>
</h2>
	For information about subscriptions, contact DiscNet at:
<h2><pre>
</h2>
<p>
	DiscNet, Inc.                                   +1-608-846-9838
	841 Acker Pkwy
	DeForest, WI  53532	 email: <a href="mailto:bsdisc-info@grilled.cs.wisc.edu">bsdisc-info@grilled.cs.wisc.edu</a>
                                        <a href="mailto:bsdisc-orders@grilled.cs.wisc.edu">bsdisc-orders@grilled.cs.wisc.edu</a>
<h2></pre>
</h2>
<p>
        European subscriptions, email: <a href="mailto:bsdisc@altona.ppp.net">bsdisc@altona.ppp.net</a>
<p>
	I received this note from Jordan back in 1993.  It is now sorely
	out of date, since there have been many releases of FreeBSD
	since then.  The ordering info is still correct.
<p>
	While I will _always_ encourage obtaining FreeBSD through "free" 
	channels (the Internet, friends, suspicious individuals in dark 
	alleys), and given that none of us will make any money from CD 
	sales, or ever have from FreeBSD in general given that WC's 
	sponsorship is confined to the loan of centralized development 
	hardware and network access, I still hope that some of you will 
	find the CD distribution medium convenient enough to order a 
	FreeBSD CD from Walnut Creek, thus indirectly supporting our 
	future development work.
<p>
	If this marriage between commercial and free software interests 
	proves to be mutually beneficial (which still remains to be seen, 
	from Walnut Creek's point of view), it is my hope that it may serve 
	as a model for similar future endeavors.  It is an unfortunate fact 
	that developing free software at this scale costs money, even with 
	the developers donating their time and efforts, and financing some 
	of it through the sale of convenient distribution media is one of 
	the least venal ways I know of going about it.
<p>
	This CD contains a full FreeBSD 1.0.2 source & binary release, the
	sources and binaries for XFree86 2.0, and numerous sources from the
	FreeBSD "ports collection".  Where space permitted, sources were
	provided in both "packed" and "unpacked" forms for easy access both 
	as an on-line resource and as a source for compressed downloads in BBS
	or release-construction situations.  The CD is fully ISO9660 compatible
	and has been mastered using RockRidge extensions for long filenames on
	systems that support it (like FreeBSD! :-).
<p>
	It is, of course, possible to install the system off the CD from 
	scratch, given some basic willingness to read a little documentation 
	and a few blank floppy disks.  [ Ed Note.  You would be surprised the
	number of people that do not see this paragraph...DBB]
<p>
	For the sake of convenience, I append the ordering information 
	distilled from FreeBSD's /usr/src/RELNOTES.FreeBSD below.
<p>
<h2><pre>
</h2>
	Ordering information:
<p>
        Walnut Creek CDROM
        4041 Pike Lane, Suite D
        Concord CA  94520
        1-800-786-9907, +1-510-674-0783, +1-510-674-0821 (fax)
<h2></pre>
</h2>
<p>
	Or via the Internet from <a href="mailto:orders@cdrom.com">orders@cdrom.com</a>.  A current catalog can
	be obtained via ftp from ftp.cdrom.com:/cdrom/catalog.
<p>
	They accept Visa, Mastercard, American Express, and ship COD 
	within the United States.  California residents please 
	add 8.25% sales tax.
<p>
	<a href="mailto:roman@public.btr.com">roman@public.btr.com</a> (Roman Yanovsky  <a href="mailto:roman@btr.com">roman@btr.com</a>) sent in this
	note.  I have edited it down some, but left in the bulk of the
	stuff in case you need more information:
<p>
	Subject: Linux Slackware and FreeBSD CD-ROM with X-windows etc.
<p>
	Trans-Ameritech presents "The best Linux plus FreeBSD CDROM ever"
<p>
	[ Linux stuff deleted ]
<p>
	* For hacker's reference an uncompressed FreeBSD source tree is 
	provided.
<p>
	* On the BSD side there is a full source and binary distribution 
	of the "final" FreeBSD 1.0
<p>
	* If you have questions or problems Trans-Ameritech provides free
	support via e-mail within 24 hours.
<p>
	* We ship the same day as we get the order.
<p>
	The new CDROM is available for $30 plus shipping/handling. If you 
	are a current customer, it is only $20.  New releases will be 
	available every 3 month. Subscription is available.
<p>
<h2><pre>
</h2>
		Trans-Ameritech Enterprises, Inc.
<br>
		2342A Walsh Ave.
<br>
		Santa Clara, CA 95051
<br>
<p>
		Tel. 408/727-3883
<br>
		FAX: 408/727-3882
<br>
<h2></pre>
</h2>
<p>
	This information is offered with no warranties, guarantees, 
	franchise offers, or recommendations.
<p>
<p>
<a name="1.5.3"><h3>1.5.3 : *BSD system mailing lists.</h3>

<p>
	With the elimination of the old 386bsd mailing lists, the only
	mailing lists that are still available are the ones for FreeBSD 
	and NetBSD.  Information about the NetBSD lists and how to use 
	majordomo (the list handler) is available by mailing to 
	<a href="mailto:majordomo@sun-lamp.cs.berkeley.edu">majordomo@sun-lamp.cs.berkeley.edu</a>.
<p>
<h2><pre>
</h2>
	There are four mailing lists for FreeBSD and they are:
<p>
	FreeBSD-hackers:	for hackers
	FreeBSD-questions:	misc questions
	FreeBSD-bugs:		bug reports
	FreeBSD-current:	discussion of -current (in development)
<h2></pre>
</h2>
<p>
	Send to <a href="mailto:FreeBSD-hackers-request@freefall.cdrom.com">FreeBSD-hackers-request@freefall.cdrom.com</a> to be added 
	to the hackers list, and *<a href="mailto:-questions-request@freefall">-questions-request@freefall</a>... to be 
	added to the questions list.
<p>
	For information about the NetBSD mailing lists, see the NetBSD
	Mailing List FAQ that is posted regularly by Chris Demetriou in
	comp.os.386bsd.announce.
<p>
<p>
<a name="1.5.4"><h3>1.5.4 : System Updates.</h3>

<p>
	There are at least two different ways of getting the updates
	for the current source tree for both FreeBSD and NetBSD.  The
	first is the traditional FTP method, and the other is using a 
	utility called 'sup'.  This program keeps a log of the source 
	modules that have been updated and sends out only those files 
	that have been changed.  Included below are some sample 
	instructions from John Brezak &lt<a href="mailto:brezak@apollo.hp.com">brezak@apollo.hp.com</a>&gt on how to 
	run sup for NetBSD.  The sup procedures for FreeBSD are similar 
	and are available via ftp from freefall.cdrom.com in the 
	~/ftp/pub/sup directory.  This directory contains the sup 
	program, a man page, a sample sup-file and full instructions 
	for maintaining your sources via 'sup.
<p>
<p>
<a name="1.6"><h3>1.6 : Documentation available</h3>

<p>
	There are two types of documentation for *BSD.  First is the 
	set that covers the operation and theory used in BSD-Unix.  
<p>
<p>
<a name="1.6.1"><h3>1.6.1 : BSD manuals</h3>

<p>
	The full set of BSD documentation is available via anonymous FTP 
	via <a href="ftp://ocf.berkeley.edu/pub/Library/Computer/doc4.3.">ftp://ocf.berkeley.edu/pub/Library/Computer/doc4.3.</a>  To print 
	this documentation on *BSD systems, replace the ditroff 
	references in the Makefile with 'groff -e -t -msU {SRC} &gtout.ps' 
	to generate PostScript format files.  Use different options to 
	make the output conform to other print styles.
<p>
	The etc distribution also comes with a documentation directory
	/usr/share/doc which has nearly 3Meg of documentation about *BSD.
<p>
	In addition, on-line manuals are available in the binary 
	distribution set.  It contains specific information on the use 
	of UNIX utilities and commands.  Type "man man" for information 
	on the online manual.
<p>
<p>
<a name="1.6.2"><h3>1.6.2 : BSD books</h3>

<p>
	For learning how to work in the Unix environment, the standard text
	is "The Unix Programming Environment,"  by Kernighan and Pike.
<p>
	For Unix Administration, the best is "Unix System Administration
	Handbook," by Nemeth, Snyder and Seebass.
<p>
	For systems level programming (i.e., systems calls), I recommend
	"Advanced Unix Programming," by Marc Rochkind.  Unfortunately it is
	out-dated and oriented towards System V.  
<p>
	A new book "Advanced Programming in the Unix Environment," by W.
	Richard Stevens is very	up-to-date, and an excellent reference,
	especially for dealing with POSIX standards issues.
<p>
	For network programming, "Unix Network Programming," by W. Richard
	Stevens is highly regarded.
<p>
	The 4.3BSD Unix Manuals contain loads of invaluable tutorials and
	historical papers in addition to hard copies of on-line documentation.
	The six volume set is available from Usenix for $60.00 (email:
	<a href="mailto:office@usenix.org">office@usenix.org</a>)
<p>
	The 4.4 BSD Unix Manuals are the authoritative source for
	information about the 4.4 BSD release, and by inference the
	NetBSD and FreeBSD systems.  They are available from O'Reilly
	and Associates (the Nutshell series people).  In addition the
	the six volume set, there is a CD included (at a price) of the
	entire 4.4 release.  Combine this with the NetBSD 1.0 or FreeBSD
	2.0 systems, and you should have a commercial quality operating
	system available in no time.
<p>
	I recommend you look at "The AWK Programming Language," by 
	Aho, Weinberger and Kernighan.  This is a very nice prototyping 
	language - powerful and easy to use.
<p>
	Another excellent reference book for *BSD is "The Design and 
	Implementation of the 4.3BSD UNIX Operating system" by  Samuel J. 
	Leffler, Marshall Kirk McKusick, Michael J. Karels, John S. 
	Quarterman, 1989, Addison-Wesley, ISBN 0-201-06196-1.  While this 
	book is out of date in many sections, it is purported to be an 
	excellent source of historical information, if nothing else.  
	Chris Demetriou recommends the sections on the treatment of 
	file systems, caching and the networking layer.  The sections in 
	this books which do not apply to *BSD include the VM section, 
	bootstrapping, and autoconfig.
<p>
	Here is a list from Hellmuth Michaelis (duplicative as it may seem
	to have all of these lists) for more information on *BSD:
<p>
<h2><pre>
</h2>
	UNIX AND UNIX DEVICE DRIVERS
<hr>
<p>
	Bell Telephone Laboratories, Inc. "UNIX Programmer's Manual, Seventh
		Edition, Volume 2". Revised and Expanded Version.
<br>
		Holt, Rinehart and Winston 1983
<br>
<p>
<p>
	George Pajari, "Writing Unix Device Drivers"
		Addison Wesley 1992
<br>
<p>
<p>
	Janet I. Egan and Thomas J. Teixeira, "Writing a UNIX Device Driver"
		John Wiley & Sons 1989, especially the 30 page appendix
<br>
		handling the unique features of the BSD system.
<br>
<p>
<p>
	Janet I. Egan and Thomas J. Teixeira, "Writing a UNIX Device Driver"
		Second Edition. John Wiley &*BSD1992
<br>
<p>
<p>
	Leffler, McKusick, Karels, Quarterman, "The Design and Implementation
		of the 4.3BSD UNIX Operating System"
<br>
		Addison Wesley 1988, corrected Reprint 1989
<br>
<p>
<p>
	Leffler, McKusick, "The Design and Implementation of the 4.3BSD UNIX
		Operating System, Answer Book"
<br>
		Addison Wesley 1991
<br>
<p>
<p>
	Leffler, McKusick, Karels, Quarterman, "The Design and Implementation
		of the 4.4BSD UNIX Operating System"
<br>
		available in fine book stores everywhere
<br>
<p>
<p>
	Maurice J. Bach, "The Design of the UNIX Operating System"
		Prentice-Hall 1986
<br>
<p>
<p>
	Sun Microsystems Inc., "Writing Device Drivers"
		Part No. 800-3851-10, Revision A of 27 March 1990
<br>
<p>
<p>
	Hewlett-Packard Company, "HP-UX Driver Development Guide",
		Part No. 98577-90013, First Edition 07/91
<br>
<p>
<p>
	W. Richard Stevens, "Advanced Programming in the UNIX Environment",
		Addison Wesley 1992
<br>
<p>
<p>
	Phillip M. Adams, Clovis L. Tondo, "Writing Unix Device Drivers in C",
		Prentice Hall 1993
<br>
<p>
	Peter Kettle, Steve Statler, "Writing Device Drivers for SCO UNIX,
		A Practical Approach", Addison Wesley 1993
<br>
<p>
<h2></pre>
</h2>
	In addition, there are many other books which, for one reason or 
	another, have not made it into this brief list.  Rest assured that 
	this is not intended to be an exhaustive list by any means. 
<p>
	There is also some documentation associated with the pcvt
	console driver.  Since this documentation is part of the normal
	distribution on both FreeBSD and NetBSD, and DOES document a
	device driver, it should be considered a good source for more
	insight into writing device drivers.
<p>
<p>
<a name="1.6.6"><h3>1.6.6 : The O'Reilly and Associates BSD 4.4 Set.</h3>

<p>
	O'Reilly and Associates puts out a five book series that
	includes all of the documentation for BSD 4.4.  In addition,
	they also sell a CD-ROM with all of the publicly releasable
	BSD-4.4 code that is available.  These books are good references
	(perhaps not perfect, since many changes to the system have been
	made even since these books were produced) but they do provide a
	great deal of background and rationale for the system and the
	history for much of the system. 
<p>
<p>
<a name="1.6.7"><h3>1.6.7 : Other FAQ's on the net that are relevant</h3>

<p>
	Most FAQs are available by anonymous FTP from rtfm.mit.edu and 
	via Usenet News in news.answers and/or comp.answers.  This FAQ
	is no exception (I hope). 
<p>
<p>
<a name="1.7.1"><h3>1.7.1 : Official distribution sites</h3>

<p>
	FreeBSD's 'home' is FreeBSD.cdrom.com (the home disk of Walnut
	Creek).  The portions of FreeBSD (versions less than 2.0) that
	were encumbered are distributed with the tolerance of
	AT&T/USL/Novell/SCO/whoever owns the source for SysV this 
	week.  All FreeBSD versions (with version number &gt= 2.0) are 
	based solely on the freely redistributable BSD 4.4 sources.
<p>
	NetBSD's 'home' is now ftp.NetBSD.Org.  All versions of
	NetBSD since 0.9 have replaced the kernel code from the 4.3 
	distribution with the source from the 4.4 distribution.  The
	only code still in NetBSD from the 4.3 distribution is some user
	program code that was uncontested in the USL/UCB agreement.
<p>
	OpenBSD's 'home' is ftp.openbsd.org.  It was based on NetBSD
	Version 1.0, so it is (by definition) clean.  There are (at
	least) two things which differentiate OpenBSD from NetBSD.  
	One big difference here is that nearly anyone can write 
	changes to the kernel code in the -current line and make 
	their updates available.  Another is OpenBSD is hosted in
	Canada, and therefore has no export restrictions on any of it's
	code (specifically the encryption code for DES).
<p>
<p>
<p>
<a name="section_2"><h2>Section 2.	(Common installation questions)
</h2>
<p>
<p>
<a name="2.0"><h3>2.0 : Install process</h3>

<p>
	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. NetBSD uses the .fs 
	file extension for its floppy images.  FreeBSD uses the .flp 
	extension.
<p>
	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.
<p>
	If the disk boots, type install and proceed to use the 
	INSTALL.NOTES to get more information.
<p>
	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.
<p>
	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:
<p>
	- 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.
<p>
	- 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 bin01.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.  
<p>
	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.
<p>
	For those of you that have received your system on a CD-ROM,
	you will need to find at least three things.  One is this file. 
	Since you are reading it, I assume that you got it already. :-)  
	If you can't read this file (you got it from the newsgroup, for 
	example) there is one thing that you need to know so you don't 
	look like a complete idiot on the net.
<p>
	There is no such thing as a Unix CD-ROM.  They are all in 
	something called the ISO CD-ROM format.  You can read them as 
	the D: drive in DOS, or mount them on your Sun or SVR4 system 
	or whatever.
<p>
	Second, you will need to find the directory with the bootable
	disk images in it.  They will have self explanatory names like:
<p>
<h2><pre>
</h2>
	kerncopy.fs
	base0-9.fs
	fred.fs
	genericaha.fs
	boot-me-first.fs
	this-is-the-file-with-the-fs-extension.fs
<h2></pre>
</h2>
<p>
	You get the idea, right?  Look for the MS-DOS program
	"RAWRITE.EXE".  It should be right near the file system (.fs) 
	files.  Another clue for the truly lost will be that the file 
	system files will all be 1.2 Meg big.  These files will fit 
	onto either a 1.2Meg 5.25 inch diskette, or a 1.44Meg 2.5 inch 
	diskette.  Use rawrite to write the fs files to diskettes and
	boot from the diskettes.
<p>
	The FreeBSD system uses a system 'pretty much' the same as this,
	except that the filesystem files are 1.2 Meg files and they all
	have a '.flp' extension.  Other than that, the instructions
	apply.
<p>
	You did back your system up, right?
<p>
	For those of you trying to build installation floppies, you
	will need to verify the media type on the 'dd' and 'disklabel'
	commands in the Makefile.  The default is to build to 1.2 Meg
	disks (being the smallest in terms of room).  Change the 12100
	and floppy5 entries to 14410 and floppy3 (respectivly).
<p>
<p>
<a name="2.0.1"><h3>2.0.1 : Boot disks (versions and media formats)</h3>

<p>
<a name="2.0.1.1"><h3>2.0.1.1 : I have the base system installed, and now I want to install the rest of the system. Where did the 'extract' program go?</h3>

<p>
	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.
<p>
	There is also an install procedure that FreeBSD 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'.
<p>
	Failing that, you can use the following process to extract the
	sources.
<p>
	    -   First, 'cd' to where your files are.
	    -   Assuming you want to extract the kernel sources, use the 
	    following command to extract the files:
<p>
	    "cat ksrc* | tar -xvf - -C /"
<p>
	This will combine the pieces, feed them to tar, and load the
	files in the 'standard' place.
<p>
<a name="2.0.1.2a"><h3>2.0.1.2a : The floppy booted, but now the hard disk won't boot?</h3>

<a name="2.0.1.2b"><h3>2.0.1.2b : I am trying to reinstall. I run install and it loops asking me if I want to use the whole disk?</h3>

<p>
	The most likely culprit is your hard disk controller.  If you
	have an IDE or EIDE 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.  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 
	that this is a nearly required step for all NetBSD and 
	FreeBSD installs.  You need to know what the disk geometry 
	is before the BIOS messes with it.  If you start having these 
	kinds of installation problems, I can virtually assure you that 
	it is because your controller geometry and your disklabel 
	geometry are different.
<p>
	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.  
<p>
	But on the other hand, maybe not...
<p>
	See section 2.5.5 below for a detailed set of instructions about
	getting NetBSD (and by implication 386BSD and FreeBSD) to work with 
	a system that uses full time translation.
<p>
<p>
<a name="2.0.1.4"><h3>2.0.1.4 : What are the options on the boot prompt?</h3>

<p>
	The most amazing thing about the boot process in *BSD is the
	boot up alternatives that are available.  There is little that
	a person can NOT do from the boot prompt.  The boot diskette or
	disk can be selected (fd(1,a) for fd1a (my B: drive is DOS))
	can be the source of my kernel.  In addition, the name of the
	kernel can be chosen (this allows you to boot with a test
	kernel or reboot an older kernel if the new one gets hosed).
	Finally, there are three choices for options that may or may
	not work, depending on the age and proclivities of your boot
	blocks.  These options are documented in 2.5.9 below.
<p>
<p>
<a name="2.0.1.5"><h3>2.0.1.5 : I just used the '-s' option on the boot, but I can't write anything onto the disk. What is wrong? If I use a plain 'mount' command it tells me that my root file system is read-only.</h3>

<p>
	In single-user (system booted with -s or an error in one of 
	the processes started by /etc/rc) the root filesystem mounts 
	as read-only by default. This was intended so that some range 
	of problems would not be made worse by writes to the disk.
<p>
	The 'dos' partitions mount as read-only in that there are 
	reservations as to how well some of the FreeBSD tools work with 
	the pcfs.  The same kind of reservations exist with NetBSD and 
	the '-t msdosfs' option.  These options (-r for read-only, -w
	for read-write) can be set in /etc/fstab.
<p>
	The status of both can be changed with 'mount -wu /{mount.dir}'
	(where {mount-dir} is the name of the directory that the 
	offending partition is mounted) to read-write.  Particularly for 
	the dos filesystem, the man page for mount should be read in 
	detail and the 'noexec' option examined.
<p>
	Note that mounting the file systems using the '-a' option will
	mount all of the file systems that are normally mounted with
	their usual read-write bits set normally.  Using this option
	makes your root partition writable, and also mounts the rest of
	the partitions in your /etc/fstab that are normally mounted
	during boot-up.
<p>
<p>
<a name="2.1"><h3>2.1 : Binary distribution</h3>

<a name="2.1.1"><h3>2.1.1 : I want to install by NFS but I am having all kinds of problems connecting to the Sun server where the files are.</h3>

<p>
	There is an unusual problem when installing over NFS.  This
	solution may have been corrected in the documentation that comes
	with FreeBSD and NetBSD, but if not, here it is.
<p>
	The most common problem seems to be that FreeBSD (and by
	inference NetBSD and all the other 4.4 based systems) do not
	send out NFS requests over privileged ports.  Sun's NFS
	implementation (and others, once again by inference) expect
	precisely the opposite.  These systems will quietly fail if you
	try to NFS to them.
<p>
	The usual error message (which may ONLY appear in
	/var/adm/messages) is "nfs_server: weak authentication, source
	IP address=xx.xx.xx.xx"
<p>
	SunOS is particularly insidious at this point.  The mount
	succeeds, but then everything else after that fails.  This means
	that your FreeBSD or NetBSD system will return an EACCESS error
	whenever you try to grab a file from the NFS filesystem.  The
	solution (tested in FreeBSD) is to include the 'resvport' flag
	like this:
<p>
<h2><pre>
</h2>
	# mount -o resvport server:/fs /mnt_point
<p>
<h2></pre>
</h2>
	or to use the -P flag (which does the same thing).  See the
	mount and mount_nfs man pages for the details.
<p>
	In fact, the -P flag provides a solution to the FreeBSD NFS
	installation problem.  When prompted for server/filesystem, type
	in the flag before the server/filesystem pair:
<p>
<h2><pre>
</h2>
	  -P server:/fs
<h2></pre>
</h2>
<p>
	If you are using an 8-bit network card, and want to avoid the
	ring buffer overflow problems that seem to come standard with
	this class of cards, you can also include the "-r4096 -w4096"
	flags between the -P and the server.
<p>
<p>
<a name="2.2"><h3>2.2 : Configuration</h3>

<p>
	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.  
<p>
	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 <a href="mailto:rich@Rice.edu">rich@Rice.edu</a>).  
<p>
<hr>
	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.
<p>
	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.  
<hr>
<p>
	Most of these manuals are now included in the standard release of
	NetBSD and FreeBSD in the /usr/share/doc directories.
<p>
<a name="2.2.1"><h3>2.2.1 : Partitions</h3>

<p>
	This section describes many of the questions that people ask about 
	hard disk partitioning.
<p>
	The first is a brief explanation of the BSD system disk partitions.
<p>
<a name="2.2.1.1"><h3>2.2.1.1 : What is a 'disklabel' and why do I need one?</h3>

<p>
	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 referred to as the 'disklabel'.
<p>
	There have been many good articles in both the mailing lists and
	the newsgroups about disk labeling and partitioning.  I have
	included a few of them here.  NOTE:  This information has not
	really changed since 386BSD 0.1.  Some of the specifics may be
	out of date (the use of the d: partition, for example) but the
	steps and information are still pertinent.
<p>
	Phil Nelson (<a href="mailto:pail@cs.wu.edu">pail@cs.wu.edu</a>) writes:
	I have installed several disks that have &gt 1024 cylinders and 
	have used both DOS and NetBSD.  What has worked for me EVERY TIME
	is the following: 
<p>
        a) Tell the BIOS that you have 1023 cylinders and the correct
	geometry for heads and sectors.  (This will limit your DOS part 
	of the disk to be LESS than the first 1023 cylinders.) You need 
	to have ALL of  your partition A (/dev/wd?a) in the first 1023 
	cylinders so that the boot program can read the kernel from
	the root partition using the BIOS routines.  (ed note: You can
	specify the full number of cylinders in some BIOSes and it won't
	make any difference.  The DOS part of the disk will always be less
	than 1023 cylinders.)
<p>
	b) With fdisk, partition your 1023 cylinders as you want them.
<p>
	c) Use the real geometry in NetBSD.  Once the NetBSD kernel is 
	booted, it does not have the 1024 cylinder limit: that is only 
	for the BIOS.  NetBSD only looks at the BSD disklabel, not the 
	DOS disk label.  The two disk labels (DOS and BSD) may not agree
	on the BSD partition size!  This isn't a problem, since each
	system's idea of the disks geometry is based on different
	information.
<p>
	d) Use NetBSD!
<p>
	Chris Jones writes:
<p>
	I was getting different reports of disk geometry from different 
	programs, so I opened up the computer and read the plastic label 
	on the drive.  I then instructed the BIOS (which, when using 
	auto-detect disagreed) what the disk geometry was.  Then, I 
	used pfdisk to create partitions.  The first thing I did with it 
	was to tell it what the geometry really was.  It said something 
	about a symbolic mapping and dealt with it.  Then I was able to 
	specify all partitions in real units instead of virtual ones.  
	NetBSD boots fine, and if memory serves, it is the only program 
	that has recognized the real disk geometry from the beginning.
<p>
	This tutorial is provided by by "Hacksaw" &lt<a href="mailto:hacksaw@user1.channel1.com">hacksaw@user1.channel1.com</a>&gt
	and provides an  excellent overview of the hard disk partitioning 
	procedure from start to finish.
<p>
		"Disk Partitioning for the Compleat Idiot"
<br>
<p>
	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.
<p>
	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.
<p>
	It also does not deal with the vagaries of the DOS partition manager.
	It assumes you have done that as well, if need be...
<p>
	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*??? 
<p>
	The disklabel is used by the kernel and other utilities to tell how
	you want or have the drive set up *logically*. 
<p>
	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. 
<p>
	When you let the installation disk set the disklabel for you first
	drive it comes out like this:
<h2><pre>
</h2>
<p>
	    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 (on the PC version only).
<h2></pre>
</h2>
<p>
	Of these, the only one that could be different is a:... 
<p>
	(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:". )
<p>
	It's possible to divide up the disk a bit differently, but three
	things MUST be:
<p>
	c: must refer to every cylinder you wish 386bsd to use, either
	for your data or the swap space. 
<p>
	b: Must 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.
<p>
	The reason for this is simple: It's hard coded in.
<p>
	"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...
<p>
	Getting past the esoteric explanations, here is a method for figuring
	out and "labeling" your disk.
<p>
	We'll start with the disklabel from my second disk, in the form most
	understandable by humans... #'s signify the start of a comment.
<p>
<h2><pre>
</h2>
	# /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 
<p>
	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)
<h2></pre>
</h2>
<p>
	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 + 1= 502 * 496 = 248992
<p>
	248992 + 198400 + 31744 = 479136 (all the parts should equal the whole)
<p>
	Some things I discovered  (for all you in novice land like me...)
<p>
	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...
<p>
	Note from TSgt Dave:
<p>
	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.
<p>
	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]
<p>
	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.
	Regardless of whether you are using DOS or not, the entire a:
	partition must reside completely within the first 1024 sectors.
	This is a limitation of the PC architecture.
<p>
	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...
<p>
	Note from TSgt Dave:
<p>
	This is a good idea.  Another way to accomplish this is to
	simply not specify it in the map.
<p>
	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...
<p>
	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. 
<p>
	* NOTE:  This is a thumbnail sketch; read the man page to verify all 
	of the options and be sure about how to proceed...
<p>
	5. then fsck the partition: 
	fsck /dev/rwd?x 
<p>
	Don't forget that fsck should be run on the RAW device.
<p>
	6. As long as it checks out, you can then mount it and do disk things
	with it...
<p>
	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. 
<p>
	One last note from TSgt Dave:
<p>
	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. :)
<p>
	A note for those trying to use the CCD: to figure out what the
	disk label should be for your concatenated device, assuming
	your disks are identical, just add up the cylinders (minus the
	ones your reserved for the individual disk labels). I know
	this works for purely concatenated (not striped) IDE disks, I
	am assuming it should work on stripped SCSI disks.
<p>
	Commonly used definitions:
<p>
	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. 
<p>
	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.
<p>
	For further information, find an article that explains the Berkeley
	FFS in more detail.
<p>
	cpg:
	Cylinders Per Group, it determines the cylinder group size, which 
	in turn determines the number and location of the alternate 
	superblocks.
<p>
<p>
<a name="2.2.1.2"><h3>2.2.1.2 : What other kinds of information do I need if I really want to tune my hard drive's performance in conjunction with a newfs?</h3>

<p>
	Having taken Aim's suggestion and changed my newfs values, I 
	think I've now made some empirical observations that suggest 
	that the defaults for newfs should definitely be changed.
<p>
	With all the disks I tested with, -n 1 (which isn't even 
	*documented!*) provided greatly improved performance, as 
	opposed to all other values of -n.  I think that with 
	sector-addressed drives with complex physical geometries, 
	rotational position optimization is a technique which is no 
	longer valid.
<p>
	If _anyone_ has _any_ disk larger than 300MB or so (or even 
	a small disk) manufactured within the last few years for which 
	larger values of -n produce better performance than -n 1, I'm 
	very curious to hear about it.  I'd be particularly interested 
	in any disk for which the default value produces optimal results.
<p>
	Increasing maxcontig seemed to always improve write scores, but 
	values of maxcontig above 16 seemed to have a noticeable _negative_ 
	impact on read performance.  -a 512, for example, on the disk in 
	my machine at home, yielded a peak write rate (4MB file, 8K record 
	size) of 4.7MB/s, much better than the 4.3MB/s value for -a 64, 
	but read performance was reduced from 2.6MB/s to 2.1MB/s.  I do 
	not understand why this is the case, and I'd love suggestions.
<p>
	I believe that with rotational position optimization turned 
	off (-n 1), the value of the -r option is of no consequence.  I 
	believe that the fact that with the default value for -n, the 
	-r option seemed to have little or no impact on performance 
	serves to demonstrate that rotational optimization does not 
	work correctly on modern drives.
<p>
	The default value of the -d option also produces much worse 
	results than -d 0.  I'm probably inexact up above; I believe 
	that -n 1 -d 0 is what turns off rotational position optimization 
	entirely.  I'm all for it. :-)
<p>
	I suggest that the defaults for newfs be changed to:
<p>
<h2><pre>
</h2>
	    -n 1 -d 0 -a 16 -r 5400
<h2></pre>
</h2>
<p>
	The -r value just in case someone decides to try playing with 
	rotational position optimization for some incomprehensible 
	reason.  Though actually, anyone with a disk where said 
	optimization is a win might want -r 3600 after all.
<p>
	If someone can explain why values of -a above 16 seem to 
	negatively impact read performance, I'm all for making -a very 
	very large, like 512 or 1024 -- in this case the filesystem 
	code will automatically limit maxcontig to the maximum transfer 
	size for a given controller/disk, right?  What are some typical 
	such sizes?  Why does -a 512 hurt read performance so much, and 
	how can it be fixed?  From comments by Larry McVoy, a good 
	implementation of UFS with clustering will yield disk speed 
	on writes, and about 25% less on reads.
<p>
	Right now, on my hardware at least, we seem to _surpass_ 
	slightly the speed of raw writes to the disk device on writes, 
	but on reads we lose big as the maxcontig value goes up, and we 
	seem to lose worst on large file/record sizes, where the raw 
	device delivers about 5MB/s in my case, but with -a 512 I get 
	only about 2.5MB/s under UFS.
<p>
	If you can't guess, I'm incredibly curious as to why the value 
	of -a affects reads as much as it does, or at all, for that matter.
<p>
	Still, we don't do so badly -- with -a 16, we pretty much hit 
	Larry's "good" value on reads of 75% efficiency, and we still 
	just barely surpass the raw device write figures.  (I am very, 
	very, very curious as to how this is possible at all.  Anyone?)
<p>
<p>
<a name="2.2.2"><h3>2.2.2 : Common Disk Label Problems.</h3>

<p>
<a name="2.2.2.1"><h3>2.2.2.1 : Increasing the *BSD partition size.</h3>

<p>
	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.
<p>
	If you have compiled in the VNODEPAGER option in your config
	file, you can use vnode files for swap space.   The precise
	details are exaplined in the man pages, but the easiest way to
	start is to include the following line in your /etc/fstab:
<p>
	/dev/vnd0b	swap	swap	sw
<p>
	Defining the file for the vnode is fairly straightforward:
<p>
	vnconfig -c /tmp/swapfile /dev/vnd0b
<p>
	and actually making it swap is as simple as 
<p>
	swapon /dev/vnd0b
<p>
	From there, the rest of your questions should be answerable from
	the vnconfig manpage.
<p>
<p>
<a name="2.2.2.2"><h3>2.2.2.2 : I can access the DOS partition on my second disk from Unix but not DOS? Any suggestions?</h3>

<p>
	One kinky problem that almost got me was when I tried to disklabel 
	my second drive in order to use the DOS partition on it, and use 
	the rest as swap for BSD (FreeBSD-1.0 Eps, SCSI drive on an 
	AHA1542B, to be exact). The DOS partition was visible from UNIX, 
	but *not* from DOS.
<p>
	What I tried to do:
	    Using PFDISK (from DOS), make one big DOS partition at the start 
	    and use the rest for a BSD partition (type 165).  Something that 
	    came out like
<h2><pre>
</h2>
		  1    6    0	69 DOSbi # ..
<br>
		  2    165  70	98 unkno
<br>
<h2></pre>
</h2>
	    for a 99 cyl drive.
<p>
	    Using BSD disklabel generate disk description/label as documented 
	    in the FAQ. Make only 'c' (total BSD DOS part), 'd' (complete disk) 
	    and 'b' (intended swap) BSD partitions.
<p>
	Problem:
	    When writing the label, disklabel would ask about overwriting DOS
	    partition table.  Whether I said y or n, the DOS partition table
	    was screwed up, as seen from DOS (BSD saw the DOS file system
	    very nicely indeed).
<p>
	Cause, solution:
	    BSD disklabel wants to write the label to the start of the 'a' 
	    partition; I had *not* defined an 'a' partition (since I was 
	    only using the disk for swap).  This tells disklabel that the 'a'
	    partition is the start of the disk, which means there is no DOS
	    partition.  Disklabel then writes the label at the start of the 
	    drive, which is why it talks about overwriting (aha!); this is 
	    *bad* for the DOS partition table.  One solution is to have a 
	    non-empty (e.g. one cylinder) 'a' partition at the start of the 
	    BSD part of the disk, and resize the 'b' swap partition 
	    accordingly.  Now everything works just fine.  Note that
	    this solution can be used whenever you want the DOS
	    partition table to be safe and the DOS partition to be
	    mountable.
<p>
	    One other fly in this ointment.  The disklabel program has 
	    historically asked "Overwrite disk with DOS-partition [n]: "
	    then the normal inclination is to believe the prompt and
	    press return for 'no'.  The default answer may or may not be
	    'no'.  There are several versions of disklabel where the
	    default answer is actually 'yes' even though the prompt
	    implies that you can press return and get 'no'.  In this case,
	    it might be best to assume that the default answer doesn't 
	    exist until you have had a chance to actually look at the
	    disklabel code.
<p>
<p>
<a name="2.2.2.3"><h3>2.2.2.3 : I want to use my entire 2 Gig drive as the root partition. Why doesn't it work?</h3>

<p>
	The easiest answer is the architecture of the machine has gotten
	you.  Because of the limitations of the BIOS, everything the
	boot process needs must reside in the first 1023 cylinders on
	the disk.  Most really big drives have more 'real' tracks than
	this, so DOS tries to translate the drive so it doesn't.  The
	*BSD systems don't; they rely on the disk geometry being
	correct, or at least the same as the controller thinks it is.
	Once the system is up and running, the BIOS is disabled.  This
	means that the system no longer has that 1023 track limitation.
	What does this mean to you?  Make sure that the root partition
	(the a: partition above) of your boot drive does not extend 
	beyond track 1023.  If you have a large DOS partition that 
	covers nearly all of that, you may need to make a VERY small 
	root partition to make absolutely certain the root does not 
	extend past 1023.
<p>
<p>
<a name="2.5.3"><h3>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?</h3>

<p>
	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.  
<p>
	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.  
<p>
	Yu-Han Ting provides this tutorial on partitioning and booting
	multiple systems with a single hard disk.
<p>
<p>
<a name="2.2.3"><h3>2.2.3 : How do I get the system to boot from the second hard drive?</h3>

<p>
	Julian Elischer (<a href="mailto:julian@jules.dialix.oz.au">julian@jules.dialix.oz.au</a>) adds:
<p>
	To make the boot code default to drive 1 look in 
	/sys/{arch/}i386/bootboot.c for the following (or similar.  The
	code may have changed a little and may be in a different 
	directory:
<h2><pre>
</h2>
<p>
<h2>loadstart:
</h2>
<p>
	/***************************************************************\
        * 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++];
<p>
<p>
	and change it to:
<p>
<p>
<h2>loadstart:
</h2>
<p>
	/***************************************************************\
	* As a default set it to the first partition of the SECOND	*
	* floppy or hard drive						*
	\***************************************************************/
	part = 0;
	unit = (drive & 0x7F);
	maj = (drive&0x80 ? 0 : 2);             /* a good first bet */
	name = names[currname++];
<p>
<h2></pre>
</h2>
    	This way, whatever drive the boot blocks are loaded from, it has 
	that as default.  In my case, I get wd(0,a) when I have my netbsd 
	drive as C:, and wd(1,a) when I have it as D:.  (I've been 
	swapping drives left right and center the last day getting dos 
	to boot on one drive and netbsd on another).
<p>
<p>
<a name="2.2.4"><h3>2.2.4 : How do I disklabel my second hard drive?</h3>

<p>
	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.
<p>
	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.
<p>
	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.
<p>
	For instance, the following line works for me:
<p>
	  disklabel -w -r sd0 &ltdrive-type&gt
<p>
	assuming of course that the boot block files are in /usr/mdec/ and
	the &ltdrive-type&gt is in the /etc/disktab.
<p>
	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.
<p>
	Also, some folks want to mix SCSI and IDE drive together in the
	same system.
<p>
	A report about someone with an Austin Tower (486DX/50), AMI BIOS, 
	Caviar 2250 IDE, Adaptec 1542CF, and Toshiba SCSI disk (1.2GB)
	posted this set of instructions:
<p>
	The BIOS is configured to boot from the IDE drive as type 47 
	(user defined).  The IDE drive currently has NetBSD 1.0 BETA on it.
<p>
	The 1542CF switches are 1-4 off (open), 5-8 on.  The meaning is as 
	follows:
<p>
<h2><pre>
</h2>
	    1(off)=Termination software controlled.
	    2,3,4(off)=I/O Port x330.
	    5(on)=disable floppy.  I use the Austin floppy controller.
	    6,7,8(on)=disable Adaptec BIOS.
<h2></pre>
</h2>
<p>
	Note that this means the Adaptec 1542CF on-board setup program is 
	also disabled.  If I need to change my SCSI termination, I first 
	have to enable the Adapted BIOS (sw 6,7,8), enter 1542CF setup 
	and change termination, then change switches again.  
<p>
	I could not configure the system to boot from the SCSI drive having 
	the IDE as a secondary drive.
<p>
	(Ed Note: There is more news on this front all of the time.  
	Since I personally don't have much interest in doing this (I 
	boot from my IDE drives and mount my SCSI drives) I don't see 
	the problem. )
<p>
<p>
<a name="2.2.5"><h3>2.2.5 : NetBSD and FreeBSD 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?</h3>

<p>
	It turns out that what *BSD cannot handle is not translation, but
	translation that changes during the boot-up process.  For example,
	the configuration above will work just fine IF the translation
	that the controller uses when it powers up is the same one that it
	uses when it boots.  On many PC clones, the BIOS loads a different
	geometry after it boots to make the geometry agree with one that is
	loaded in CMOS.  This is the fatal flaw for *BSD.  Fortunately, 
	once the problem has been identified, it is relatively easy to
	handle.  Simply make sure that the BIOS is configured to set the
	controller to the translated geometry that the card powers up 
	with.
<p>
	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).
<p>
	An interesting method for dealing with disk geometry comes from 
	Alan Barrett (<a href="mailto:barrett@lucy.ee.und.ac.za">barrett@lucy.ee.und.ac.za</a>):
<p>
	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.
<p>
	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.
<p>
	    0.  Make sure you have adequate backups.
<p>
	    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).
<p>
	    2.  Halt the system.  Boot the NetBSD kernel copy floppy.  
		When it asks you to insert the floppy for the root file 
<br>
		system, switch to the Install-1 floppy and press enter.
<br>
<p>
	    3.  Answer all the installation prompts, using numbers based 
		on the translated geometry.  When it asks if you really 
<br>
		want to label the disk, be brave and say yes.
<br>
<p>
	    4.  Halt the system.  Boot to DOS.  Run a disk editor program, 
		such as Norton utilities.
<br>
<p>
	    5.1.  Verify that the partition sector in {cyl 0, head 0, 
		sec 1} is undamaged.  Verify that the disklabel program 
<br>
		run as part of the NetBSD install has written the NetBSD 
<br>
		primary boot block to {cylinder xx, head 0, sector 1}, 
<br>
		written the disk label to {cyl xx, head 0, sec 2}, and 
<br>
		written the secondary boot program to {cyl xx, head 0, 
<br>
		sectors 3 to 16}.  ("xx" represents the translated 
<br>
		cylinder number you chose for the start of the NetBSD 
<br>
		partition.  You did choose to start on a cylinder boundary, 
<br>
		I hope.)
<br>
<p>
	    5.2.  Verify that the space in {cyl 0, head 0, sectors 2 to 
		16} is still available.  Copy the fifteen sectors containing 
<br>
		the NetBSD disk label and secondary boot block from {cyl 
<br>
		xx, head 0, sectors 2 to 16} to {cyl 0, head 0, sectors 2 
<br>
		to 16}.
<br>
<p>
	    5.3.  Edit the partition table in {cyl 0, head 0, sec 1}.  
		Change the system ID of the NetBSD partition from 0xA5 
<br>
		(decimal 165) to something else (I use 0xA4, decimal 164), 
<br>
		but keep it flagged as bootable.  This will let you boot 
<br>
		to the NetBSD primary boot block.
<br>
<p>
	    5.4.  Edit one of the previously unused partition table entries 
		(I hope you have one), to contain the following information: 
<br>
		{sys id = 0xA5, boot flag = 0, start cylinder/head/sector = 
<br>
		0/0/1, end cylinder/head/sector = anything, initial 
<br>
		offset = 0, total size = anything}.  This will tell the 
<br>
		NetBSD primary boot block, or a NetBSD system booted from 
<br>
		a floppy, that it should look for the NetBSD disk label 
<br>
		in {cyl 0, head 0, sec 2}.
<br>
<p>
	    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.
<p>
	    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.
<p>
<a name="2.2.6"><h3>2.2.6 : I am having trouble installing on the EIDE hard drive. What are some of the things that I need to look into?</h3>

<p>
	Bradley W Mazurek (<a href="mailto:bwm260@skorpio3.usask.ca">bwm260@skorpio3.usask.ca</a>) writes:
<p>
	First, I had to change the IDE translation mode in my BIOS.  
	Rather than using LBA, I used Standard CHS.  When I went in 
	to repartition the disk for DOS, DOS reported that the drive 
	was only 523Mb (1023cyl, 64h, 63sec/tr), rather than the true 
	geometry (2100cyl, 64h, 63sec/tr) but I didn't worry about it. 
<p>
	Next I created my DOS partition.  I partitioned the disk so that 
	cylinders 1-999 were DOS.  That left cylinders 1000-1023 for 
	NetBSD.  Lots of room!  :)  Anyway, on a hunch, a friend and I 
	were hoping NetBSD didn't look at the ending cylinder entry 
	(1023) of the partition table.  Next I calculated the length 
	of the partition from 1000-2100, put this into the partition 
	table using the disk editor.  The numbers weren't consistent in 
	the partition table, but DOS ignored the Non-DOS partition, 
	NetBSD was happy...and we've (DOS, NetBSD and my remaining hair) 
	all lived happily ever after....
<p>
	[Ed.Note.  The partition table needs to correctly identify the
	NetBSD portion of the disk, regardless of whether or not DOS can
	handle it.  See the section on hard drive partitioning for more
	information...]
<p>
	My suggestion is to try to find an IDE translation mode in your 
	BIOS for which the number of heads and number of sectors per track 
	is consistent with the true geometry of your hard drive.  Then 
	perhaps this trick will work.
<p>
 	1. there is _different_ behavior, if one executes
<h2><pre>
</h2>
	    disklabel wd0                           or
	    disklabel /dev/wd0c                     or
	    disklabel /dev/wd0d
<h2></pre>
</h2>
    	It didn't get quite clear to me, what these differences are exactly.
<p>
 	2. Any disklabel write will change not only the data on disk, but
    	also some data-structures in core. For example, if one tries to 
	write a complete different disklabel to a complete different place, 
	say /dev/wd0h, there will be strangeness afterwards.  That means, 
	writing a disklabel and then reading it back, does not have to 
	mean that the write did succeed.  There is an option -r to 
	disklabel which is said to access the disk directly, but, as 
	I noticed, the core-data is updated thereby, too.
<p>
	The following paper explained to me what should happen in sequence 
	on boot: /usr/src/sys/arch/i386/boot/README.386BSD. It says (in 
	short):
<p>
	[...]
<p>
	1/ the BIOS loads the first block of the disk (called the Master 
	Boot Record or MBR) and if it has the correct magic numbers, jumps 
	into it:
<p>
	2/ The  MBR code, looks at the Partition table that is embedded 
	within it, to determine which is the partition to boot from. If 
	you are using the os-bs bootblocks (highly recommended) then it 
	will give you a menu to choose from.
<p>
	3/ The MBR will load the first record of the selected partition 
	and if it has (the same) magic numbers, jumps into it. In 386bsd 
	this is the first stage boot, (or boot1) it is represented in 
	/usr/mdec by wdboot, asboot and sdboot. If the disk has been set 
	up without DOS partitioning then this block will be at block zero, 
	and will have been loaded directly by the BIOS.
<p>
	4/ Boot1 will look at block0 (which might be itself if there are 
	no DOS partitions) and will find the 386bsd partition, and using 
	the information regarding the start position of that partition, 
	will load the next 13 sectors or so, to around 60000 
	(640k - 256k). and will jump into it at the appropriate entry 
	point. Since boot1 and boot2 were compiled together as one file 
	and then split later, boot1 knows the exact position within 
	boot2 of the entry point.
<p>
	Boot 1 also contains a compiled in DOS partition table (in case 
	it is at block 0), which contains a 386bsd partition starting at 
	0. This ensures that the same code can work whether or not boot1 
	is at block 0.
<p>
	[...]
<p>
<a name="2.2.7"><h3>2.2.7 : My disk label is complaining about '256 heads' in the disklabel. This is obviously bogus, but it doesn't seem to be hurting anything. Is it Okay or should I fix it?</h3>

<p>
	Steve Gilbert (<a href="mailto:gilbert@cs.utk.edu">gilbert@cs.utk.edu</a>) provided us with this answer:
<p>
        First, If you do a "fdisk wd1" (It may be wd1d, I don't
	remember what it wanted), it will list out the partition table
	for you.  This is something totally different from BSD's idea
	of a partition, mind you.  The last partition (#3) should be BSD.
	All of those figures are correct except for the "ending head" field
	which is set to 255 (thus, 256 heads).
<p>
	1. BACK UP EVERYTHING!
<p>
	2. fdisk -u wd1
<p>
        ...this will prompt you for the stuff you want to change.
        Remember, everything is correct except for the ending
        head.  Accept all the default values it gives you at first.
        You'll have to tell it that you want to explicitly define
        the beginning and ending values.
<p>
	3. My 420 MB Conner drive has 16 heads, so I just enter 15 as
	   the ending head number.
<p>
	4. When you are back out of fdisk, you can do another fdisk wd1
	   to make sure the values are correct.  Don't worry if you mess up,
	   you can always change it again.  Anything you didn't back up is
	   probably gone by now anyway :-)
<p>
	5. Reboot and watch NO error message pop up!
<p>
	...remember that all you want to do is fdisk the drive.  You do NOT
	want to run disklabel again or newfs the partitions again.  This will
	write the incorrect 256 crap back.  I did this three times before
	I finally got smart and did it right.
<p>
<p>
<a name="2.2.8"><h3>2.2.8 : What are the options for the boot up prompt?</h3>

<p>
	The options are supposed to be as follows:
<p>
<h2><pre>
</h2>
	-s............... boot into single user mode
	-a............... ask the user what device to use as root
			  just before mounting it (Not presently supported)
<br>
	-d............... once you have the kernel loaded and VM and such up
			  and going, drop into the kernel debugger.
<br>
			  (great for debugging probe code)
<br>
<h2></pre>
</h2>
<p>
	A related question concerns the options on the 'reboot' program.
	These flags are as follows:
<h2><pre>
</h2>
	-a	Ask for a file name to reboot from
	-s	Reboot into single user mode
	-b	Don't reboot, just halt
	-r	Use compiled in Root device
	-c	Invoke the user configuration routines
	-d	Transfer control to the kernel debugger, if available
	-v	Print out all potentially important information
<h2></pre>
</h2>
<p>
	As with so many other things in the systems, each of these may
	(or may not) work for FreeBSD or NetBSD.  Your Mileage May Vary.
<p>
	One other note about 'reboot'.  There are some motherboards which
	do not reboot reliably.  Instead of rebooting, they simply hang.
	While this isn't a definitive answer, some folks have noticed
	that have the BIOS relocate option set seems to help them,
	especially with Micronics motherboards.  If you are having
	problems with your system not resetting after a reboot, try
	changing the setting on the BIOS relocation option.
<p>
<p>
<a name="2.2.9"><h3>2.2.9 : I am having trouble installing WRT 'syslogd: bind: Can't assign requested address' errors. What are some of the things I should look at? I also am having trouble with the network: 'starting network ... ifconfig: localhost: badvalue'.</h3>

<p>
	This is caused by incorrect settings in /etc/netstart and/or
	/etc/hosts.
<p>
	In /etc/hosts, you must have a line that says:
<p>
<h2><pre>
</h2>
	127.0.0.1	localhost	localhost.{yourdomainhere}
<h2></pre>
</h2>
<p>
	Errors that will result if you don't do this: ifconfig will not
	be able to figure out what IP address goes with the name
	'localhost' and you'll get 'localhost: bad value.'
<p>
	In /etc/netstart, you must do:
<p>
<h2><pre>
</h2>
	    ifconfig lo0 localhost
	    route add {hostname} localhost
<h2></pre>
</h2>
<p>
	Errors that will result if you don't do this: the loopback
	device will not be properly configured and/or you will have no
	route to it. The result is that programs expecting to have
	networking enabled (including syslog and friends) will get
	horribly confused.
<p>
	*AND*, if you're not going to be directly connected to a
	network, you should change /etc/host.conf to say:
<p>
<h2><pre>
</h2>
	    hosts
	    bind
<h2></pre>
</h2>
<p>
	It's set up the other way around by default. I don't like it
	that way myself.
<p>
	Errors that can result if you don't do this: if you don't have
	a nameserver available to you, the resolver will have trouble 
	translating hostnames into IP addresses.  Bogosity levels will
	be off the scale. (Note also that if you do have access to a 
	nameserver, you need to set up /etc/resolv.conf to point to
	it.)  By changing the order, you'll be telling the resolver to
	check the host files for matches *first*, then roll over to the 
	nameserver (if any) if no match is found.
<p>
	Make sure that:
<p>
	- There are no typos in any of the three files mentioned above.
	- There are no bogus non-ASCII characters in the files
	mentioned above.
	- All three files have their read permission bits set.
<p>
	Lastly, be very careful with /etc/hosts.equiv. If you add a
	hostname to it, say 'otherhost.domain,' then root on
	otherhost.domain will be able to rsh/rlogin to your machine
	without a password.
<p>
	Once you have everything set correctly, you should be able to
	type 'telnet localhost' and establish a connection to yourself. 
	If you get an error such as 'localhost: unknown host' or
	'network unreachable' then you still have work to do.
<p>
<p>
<a name="2.2.10"><h3>2.2.10 : When I start up my system, it hangs for three or four minutes during the 'netstart' program. Our network nameserver is working OK, and I use it all the time; my resolv.conf file says to use the network nameserver. Why would netstart have such problems using it?</h3>

<p>
	When the system is starting, the nameserver hasn't started yet.
	If you are using any names that must be resolved, the system
	will attempt to get the names from the nameserver,  When that
	fails (three timeouts at one minute apiece) the name will be
	resolved from the /etc/hosts file (if the name is available).
<p>
	There are essentially two ways to solve the immediate problem.
	The first is to reduce the number of entries you have in your
	/etc/hosts file to the absolute minimum you need for booting and
	change the order for host resolution from 'bind file' to 'file
	bind'.  If you specify a name in any of your start up files and
	the name server isn't available, you will still have the hang,
	but this is only a small annoyance.
<p>
	The second (and generally more effective) way to deal with the
	problem is to use only numeric addresses  in your /etc/* files.
	This way, the resolver is never called upon to figure out the
	addresses and your boot-up will always 'just work'.  This is
	sometimes more time intensive to set up, since all of the names
	in the files need to be removed and replaced with numbers.
	"C'est la vie".
<p>
<p>
<a name="2.2.11"><h3>2.2.11 : I am having trouble getting net aliases to work. What could some of the problems be?</h3>

<p>
	There are many things which will cause network aliases to not
	work right.  Here are a few:
<p>
	-  Use "netmask 0xffffff00" (or whatever is appropriate) for the 
	   first IP address, and "netmask 0xffffffff" for all aliases that 
	   happen to be in the same (sub)net as the primary one.  The
	   reason this is right (no matter how odd it may seem) is you
	   have multiple interfaces referring to the same network.  You 
	   *have* to chose one of the various interface addresses as the 
	   "gateway" for outgoing packets into this network, you cannot 
	   have them going out through a dozen of addresses simultaneously.  
	   The netmask 0xffffffff prevents the kernel from considering this
	   IP address as a valid gateway (since it's not pointing to any 
	   network at all).
<p>
	The correct syntax in /etc/rc.local for declaring a net address 
	alias (assuming you are updating the eth0 interface) is:
<p>
<h2><pre>
</h2>
	    ifconfig eth0 xx.xx.xx.xx netmask 255.255.255.255 alias
	    route add -host xx.xx.xx.xx localhost
	    arp -s eth0 yy.yy.yy.yy.yy.yy proxy
<h2></pre>
</h2>
<p>
	Where the xx.xx.xx.xx are the host address for the alias and the
	yy.yy.yy.yy.yy.yy is the interface MAC address (if appropriate).
<p>
<p>
<a name="2.2.12"><h3>2.2.12 : I'm having trouble with the networking code (specifically the PPP stuff to my ISP). How can I debug NetBSD's networking?</h3>

<p>
	Bring the PPP connection up again.  Retry whatever-it-is that's 
	failing. 
<p>
	PPP includes a link-level checksum.  Watch the packet counts in 
	the netstat -I ppp? output over time. Check carefully to see 
	whether the PPP driver is recording input errors (frames whose 
	CRC failed.)  Frames with bad checksums are counted in Ierr 
	field.  A non-zero count indicates _something_, possibly 
	overruns, is in fact garbling your PPP traffic.  If the packets 
	are being discarded due to errors at the PPP level, they'll 
	never even get as far as IP.
<p>
<p>
	Also, use netstat (or an SNMP daemon and monitor, if you prefer) 
	to watch the rate of change of bad packets at the IP and TCP 
	level.  I run "netstat -p ip" "netstat -p tcp".  One has to 
	manually compute the rate of change; netstat's -i option means 
	something different to, say, vmstat's.   (Adding  periodic  
	sampling and rate-of-change to netstat would be a Cool Project.)
<p>
	At the IP level, the relevant statistics are
<h2><pre>
</h2>
            0 bad header checksums
            0 with size smaller than minimum
            0 with data size &lt data length
            0 with header length &lt data size
            0 with data length &lt header length
            0 with bad options
            0 with incorrect version number
	    [...]
            0 output packets dropped due to no bufs, etc.
<h2></pre>
</h2>
<p>
	At the TCP level,  look for, e.g.,
<p>
<h2><pre>
</h2>
            0 discarded for bad checksums
            0 discarded for bad header offset fields
            0 discarded because packet too short
<h2></pre>
</h2>
<p>
	Any of these being non-zero would support the hypothesis of a 
	bug in the PPP implementation.  Unlikely, but one never knows.
<p>
	It could be that a TCP ack got munged or dropped by your PPP 
	link; or possibly somewhere else in the Internet.  That's not 
	abnormal on busy links.
<p>
	What OS is your FTP peer running?  Is it a pre-2.0.0 Linux or an
	older version of a commercial Unix? If so, have you tried turning 
	off rfc1323 on your NetBSD machine??
<p>
<p>
<a name="2.2.13"><h3>2.2.13 : I want to hard wire my SCSI devices to a particular device number. Is that possible?</h3>

<p>
	You can do the numbering any way you please.  Say I had two 
	controllers.  You could number them as:
<p>
<h2><pre>
</h2>
	sd10	at scsibus0 target 0 lun ?
	sd11	at scsibus0 target 1 lun ?
	[...]
	sd20	at scsibus1 target 0 lun ?
	sd21	at scsibus1 target 1 lun ?
	[...]
<h2></pre>
</h2>
<p>
	Of course, you will need to add devices to the /dev/ directory
	for each of them, pointing to their correct major and minor
	numbers.
<p>
	You can also hardwire the 'scsibus' numbers, by doing something 
	like the following (assuming "whatever" is the SCSI host adapter 
	driver's name 8-):
<p>
	whatever0	at whateverbus? [whateverbus config info]
	scsibus0	at whatever0
<p>
	then
<p>
<h2><pre>
</h2>
	sd0	at scsibus0 target 0 lun 0
<h2></pre>
</h2>
<p>
	etc.
<p>
<p>
	That syntax won't work on ports which use 'old config,' but I 
	believe an appropriate description of how to do it on them has 
	already been posted.
<p>
	The most common configuration for locked down drive numbers is 
	actually:
<p>
<h2><pre>
</h2>
	sd0	at scsibus0 target 0 lun 0
	sd1	at scsibus0 target 1 lun 0
	sd*     at scsibus? target ? lun ?      # SCSI disk drives
<h2></pre>
</h2>
<p>
	You can do the same thing with your tapes, CDs, and other SCSI
	devices as well.
<p>
<h2><pre>
</h2>
	st0	at scsibus0 target 6 lun 0
	st*     at scsibus? target ? lun ?      # SCSI tape drives
	cd0     at scsibus? target 5 lun 0
	cd*     at scsibus? target ? lun ?      # SCSI CD-ROM drives
	etc.
<h2></pre>
</h2>
<p>
<p>
<a name="2.3"><h3>2.3 : Common installation problems.</h3>

<p>
	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.
<p>
<a name="2.3.2"><h3>2.3.2 : Endless reboot cycles.</h3>

<p>
	Another incarnation of this symptom is that the disk geometry on 
	your disk label (as installed by install) is different than the 
	geometry 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.  
<p>
<p>
<a name="2.4"><h3>2.4 : The computer just sits there, or 'that isn't right'.</h3>

<p>
	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...' 
<p>
	Another incarnation of this problem is that, sometimes, the major
	or minor device numbers for a particular device may not get made
	correctly in the install (or upgrade) procedure.  If you have a
	problem where you can install and everything seems to go well
	until you try to boot onto the hard drive, try running the
	MAKEDEV script that resides in /dev.  More the file to see what
	kind of options you should include (if the sd0a drive needs to
	be fixed, for example, the command './MAKEDEV sd0' should get
	your devices back on the road.  If that doesn't work, try one of
	the many things below.  It could be any (or all) of them....
<p>
<p>
<a name="2.4.1"><h3>2.4.1 : The boot disk works all right on one computer but not another.</h3>

<p>
	This could be a problem with many different pieces, some of which
	are:
<p>
	- 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 many archive sites.
	This installation file may have many names.  Look for something
	kind of obvious (like 'install.notes' or 'readme' or 
	'configuration guide') and you should find it.  Finally, there
	have been many reports (particularly with the BusLogic SCSI
	cards (specifically reported was the BT445C VLB host adapter) 
	where the system seems to boot up, but starts getting
	'stray interrupt c' messages.  This is usually caused by people
	having there SCSI card set up on some IRQ other than the one
	that the kernel expects.  The factory default for this card
	seems to be IRQ 12, but the kernel wants the card at IRQ 11.
	Setting the card (using the configuration program supplied)
	changes the setting so that it matches the kernel and the card
	then works.
<p>
	- Unsupported hardware.  There are several SCSI controllers on the 
	market that are not fully supported by 386bsd.  This is due in
	large part to the way these controllers work.  Instead of using
	a standard interface and command set for the controllers, most
	manufacturers make up their own controller interface language,
	which is then translated into SCSI commands which are
	interpreted by the drives. 
<p>
	- One or more of the devices in the /dev directory on the
	intended root partition was either not created correctly or was
	not created at all.  Run the program MAKEDEV in the /dev/ directory
	to ensure that all of the correct devices are built.
<p>
<p>
<a name="2.4.2"><h3>2.4.2 : Really strange errors in the various *BSD flavors.</h3>

<p>
<a name="2.4.2.2"><h3>2.4.2.2 : Using the new code in NetBSD, I get a "panic: pdti 206067" in pmap_enter(). What should I do?</h3>

<p>
	Increase NKPDE in /sys/i386/include/pmap.h. The largest it should 
	be 31; see question 3.2.8.1 for other useful values.  Be sure to 
	keep the changes around as a patch file, since this is one of the 
	files that will get overwritten during a source code update. 
	Note that in the versions of NetBSD newer than 1.2.1, this value 
	is computed, so you won't need to change it.
<p>
<p>
<a name="2.4.3a"><h3>2.4.3a : I get the error "isr 15 and error: isr 17" on an NE2000 card.</h3>

<a name="2.4.3b"><h3>2.4.3b : I have some card on IRQ2 and it doesn't work; why?</h3>

<a name="2.4.3c"><h3>2.4.3c : I am getting lousy performance out of my network card. What are some of the other possibilities?</h3>

<p>
	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.  Older VGA card 
	used IRQ 2 during vertical retrace to prevent sparklies.
<p>
	One solution would be to plan on not using your Ethernet card
	(or any other card you want on IRQ 2) 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.  
<p>
	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.
<p>
	James Van Artsdalen (<a href="mailto:james@bigtex.cactus.org">james@bigtex.cactus.org</a>) has offered at
	least one solution:
<p>
	    If this is the problem, you can use Scotch tape to cover
	    the IRQ 2 signal on the VGA's ISA connector.
<p>
	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-partite 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.  If 
	this happens, given a choice between alcohol and solder, I vote for 
	alcohol.
<p>
	One other thing to look for (if your video card seems to be the
	culprit) is a jumper which enables or disables the card's IRQ 2. 
	Newer cards may have a jumper of switch which does this, so take
	the time and look for it before you get the razor blade out.
<p>
	Either way, you will probably find that your VGA card uses IRQ 2
	strictly for compatibility with older cards.  With the advent of
	dual-ported memory for video cards, virtually all of these types
	of problems have disappeared.
<p>
<p>
<a name="2.4.4"><h3>2.4.4 : What is the difference between IRQ2 and IRQ9? Are they really the same, or are they really different?</h3>

<p>
	On the XT, there was one interrupt controller, an Intel 8259, which
	handled 8 interrupts numbered IRQ0 through IRQ7.  IRQs 2 through 7
	were accessible via bus lines IRQ2 through IRQ7.
<p>
	The AT had two interrupt controllers.  Due to the design of the 
	8259, one has to be the master and the rest (up to 8) must be 
	slaves.  Each slave controller output its interrupt request to 
	and input on the master controller.  In the case of the AT, the
	master controller handles IRQ0 through IRQ7.  The slave handles
	IRQ8 through IRQ15.  The interrupt request from the slave to the
	master goes through IRQ2, which is termed the cascase input.
	IRQ2 was chosen to allow future compatabilty with the old XT
	hardware; it was the first IRQ that was 'available'.
<p>
	This means. of course, that the bus line for IRQ2 could no longer
	be used for external interrupts.  Instead, the bus line that WAS
	IRQ2 in the XT became IRQ9 on the AT.  This whole issue is 
	confused further by the fact that some vendors refer to this
	external interrupt as IRQ2, while others refer to it as IRQ9.  In
	either case, if you are talking about an external interrupt, it
	means the same thing.
<p>
	BTW, IRQ8 is used for the Real Time Clock, and does not have an
	external interrupt.  Here is a map, in case anyone still needs it:
<p>
<h2><pre>
</h2>
		Internal	External	Function
<br>
		IRQ0		n/a		Refresh/Timer
<br>
		IRQ1		n/a		Keyboard
<br>
		IRQ2		n/a (AT only)	Cascade Input to Master
<br>
		IRQ3		IRQ3		Free (Com port)
<br>
		IRQ4		IRQ4		Free (Com port)
<br>
		IRQ5		IRQ5		Free 
<br>
		IRQ6		IRQ6		Floppy Controller
<br>
		IRQ7		IRQ7		Free (Printer/Sound Card*)
<br>
		IRQ8		n/a		Real Time Clock
<br>
		IRQ9		IRQ2		Free (Network card)
<br>
		IRQ10		IRQ10		Free
<br>
<h2></pre>
</h2>
<p>
		etc.
<br>
	* NOTE:  The IRQ7 entry is spooky.  If you use the Interruptless
	printer driver (either from 386bsd, NetBSD, or FreeBSD) then you
	can still have an interrupting device (like a sound card) on
	interrupt 7.  Basically, you can as many devices on each IRQ as
	you want, but only one of them can be 'actively' interrupting.
<p>
<p>
<a name="2.4.5"><h3>2.4.5 : Some of my SCSI devices (like a tape drive) don't work; why?</h3>

<p>
	Even with the newer systems, you run the risk of having a 
	problem with a SCSI device from time to time.  There are some
	cards (like the new Adaptec 27* series) that software drivers 
	are either not in the works or the documentation is simply
	unavailable.  Another culprit here is that some machines are
	very touchy about the quality and length of cables, as well 
	as SCSI IDs.  There was one report of a older hard drive that
	took a little longer to spin up than the rest of the drives
	in the chain.  Whenever this drive was put early in the ID
	string (like 1 or 2) it would be 'not found' but if it was
	placed near the end (like after the tape drive) it would have
	spun up and been found.
<p>
<p>
<a name="2.4.6"><h3>2.4.6 : I want to use the Adaptec 1542C SCSI controller. What are the problems/tricks you need to know to get it working?</h3>

<p>
	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. 
<p>
	Matthias Urlichs (<a href="mailto:urlichs@smurf.ira.uka.de">urlichs@smurf.ira.uka.de</a>) has provided this 
	description of the types of things that can cause problems for the
	controller and devices attached to it.
<p>
	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.
<p>
	A bad cable is almost any cable which doesn't meet SCSI-2 specs.
<p>
	A bad external terminator is one which doesn't adequately buffer 
	its resistor network.
<p>
	So...
<p>
	- 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.
<p>
	- 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.
<p>
	- 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.)
<p>
	- 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.
<p>
	- 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.
<p>
	- 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.
<p>
	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.
<p>
<p>
<a name="2.4.7"><h3>2.4.7 : Is there a SCSI utility which works to fix up the random problems I sometimes have with my drives?</h3>

<p>
	That depends on the problem.  One of the first things you can
	try is Ian Dell's (<a href="mailto:Ian.Dell@dsto.defence.gov.au">Ian.Dell@dsto.defence.gov.au</a>) SCSI Disk
	Doctor (sdd) package.  There are NetBSD i386 and Sparc
	executables on <a href="ftp://ftp.mono.org/pub/sdd.">ftp://ftp.mono.org/pub/sdd.</a>  FreeBSD uses a
	couple of utilities which come with the system (scsi and
	scsireprobe) to accomplish some of the same operations.  Try one
	of those (obviously based on your system type) and see if they
	don't fix your problem.  If they don't, then the prospects are
	pretty grim for your drive.
<p>
<p>
<a name="2.4.8"><h3>2.4.8 : My system boots OK off the floppy, but once I try to boot from the hard drive, the message "changing root device to sd0a" appears and the system hangs. What is the most likely thing that I have done wrong?</h3>

<p>
	A common cause for this is when all of the right devices aren't 
	created on the root partition.  Since you say you can boot off 
	of a floppy, do so and check to make sure everything in /dev 
	exists.  You might consider running "MAKEDEV all" to be sure 
	everything is created.
<p>
	(Ed.Note: I find that whenever I create a new kernel, it isn't a
	'bad' idea to run a precautionary MAKEDEV to make sure that the
	devices are created correctly.  Since I only build a new kernel
	about once a month, it isn't a very costly insurance policy.)
<p>
	Also, there are known problems with IRQ configurations and the
	PCI bus.  The system hanging right after the changing root device 
	message usually indicates a misconfigured IRQ for the controller.  
	The initial probes by most (all?) drivers are done in polled mode, 
	only when mounting the disk for real does the kernel begin to do 
	interrupt driven I/O and DMA.
<p>
	Is this system a PCI system?  Is the SCSI controller a PCI board?
	If so, make sure the IRQ configured in the PCI BIOS matches the
	IRQ configured for the card.
<p>
	Also, with PCI, forgetting to enable the slot for "master" in the 
	BIOS setup or motherboard jumpers or putting a bus mastering card 
	in a slave only slot will give similar symptoms.  The system may not 
	have problems under DOS because some SCSI BIOS or device drivers 
	don't actually use the DMA or bus mastering features of the 
	card... {sigh}, they run in PIO mode under DOS.
<p>
<p>
<a name="2.5"><h3>2.5 : Other common problems that are attributed to the installation process but are caused other places.</h3>

<p>
<a name="2.5.1"><h3>2.5.1 : I want to use more than 16 Megabytes of memory. Will any of the BSD based systems support it?</h3>

<p>
	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.  There are reports of people having trouble 
	with more than 64Meg of memory, but anyone rich enough to have
	that kind of memory should be paying for his OS. :-)
<p>
	Recently some folks have been reporting that they are getting 
	warnings like these:
<p>
<h2><pre>
</h2>
	    hostname /netbsd: sd0: not queued
	    hostname /netbsd: aha0: DMA beyond end of ISA
	    hostname /netbsd: sd0: not queued aha0: DMA beyond end of ISA
<h2></pre>
</h2>
<p>
	This error is caused when the buffer for I/O is beyond the address
	range that the ISA bus can reach.  With 16M you should be okay,
	however, some motherboards do reclaim all or part of the "lost" 
	384K (from the I/O "hole" from A0000-FFFFF) and put it just beyond 
	the end of the rest of the memory, so you actually get 16M plus a
	little bit.
<p>
	One fix is bounce buffers.  FreeBSD has implemented this, and NetBSD
	will as soon as they come up with a method that is compatible with 
	all of the machines that NetBSD supports.  
<p>
	Another fix is to either turn off the reclaiming of the extra memory 
	(most motherboards that do this allow you to disable it), hack 
	machdep.c to force the physical memory used to 16M, or use a 32 bit 
	bus (EISA, VLB, or PCI) controller.
<p>
	Jordan K Hubbard (<a href="mailto:jkh@thrush.lotus.com">jkh@thrush.lotus.com</a>) has provided this 
	explanation of the distinction:
<p>
	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.
<p>
	For those who may find such a distinction confusing, let me explain:
<p>
	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 &gt16MB is concerned.
<p>
	You can use an EISA controller in "ISA mode", meaning it uses the
	older protocols for compatibility reasons (examples being Adaptec 
	1742 in "standard" mode, DTC 3290 in "Adaptec" mode, etc.) and 
	again, does not use the extra address lines.
<p>
	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, the 
	Ultrastor 24F in EISA (rather than IDE emulation) mode, etc.).
<p>
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<p>
	In addition, several other types of ISA 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. 
<p>
	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.
<p>
<p>
<a name="2.5.2"><h3>2.5.2 : I tried to use a device in my computer that should be there. When I did, I got a "Device not configured error." What do I do now?</h3>

<p>
	Garrett A. Wollman (<a href="mailto:wollman@emba.uvm.edu">wollman@emba.uvm.edu</a>) provides us with this
	brief discussion in answer to a specific question.  It wears well
	as a generic answer as well.
<p>
	When any program tells you ``Device not configured'', it's trying 
	to tell you something very important about what you tried to do:
	namely, that the device you tried to access is not configured 
	into the running operating system.  This is the error message 
	corresponding to ENXIO.
<p>
	There are three major causes for this error:
<p>
	1) The kind of device you requested was not configured into the
	   system.  This is R.W.'s problem; the generic kernels 
	   are not distributed with the Berkeley Packet Filter enabled by 
	   default.  To correct this, you must add the appropriate device or
	   pseudo-device to your kernel configuration file and recompile.  
	   (In this particular case, `pseudo-device bpfilter
	   number-of-network-interfaces'.)
<p>
	2) The kind of device you requested was configured into the system,
	   but either the device you requested would use more than the
	   maximum you configured into the system, or if a physical device,
	   was not found during autoconfiguration.  To solve this, either
	   change your configuration file, or change the I/O settings on the
	   device to match what the file says.
<p>
	3) The major or minor device number specified by the device's
	   entry(ies) in /dev is incorrect.  To solve this, re-MAKEDEV the
	   device (read the MAKEDEV script for more details).  Hopefully
	   whatever change caused the kernel's internal device tables to get
	   changed also updated your MAKEDEV script; otherwise, you will have
	   to grovel through the kernel to see what is going on.
<p>
	4) A special case:  Although the 'c' drive on most BSD disks is
	   the entire disk, in many NetBSD and FreeBSD systems, the
	   entire drive is the 'd' disk.  This special case is wired
	   into many programs, and is recognized by the kernel.  From
	   time to time, folks will try and access the 'c' partition on
	   their harddrive, only to be rebuffed with a 'device not
	   configured' error.  Mostly, the 'c' partition is unavailable
	   simply because the partition type is 'unused' even though it
	   is allocated and has space set aside for it.
<p>
<a name="2.6"><h3>2.6 : Customizing the system to meet my needs.</h3>

<a name="2.6.1"><h3>2.6.1 : How do I get the system to not display the machine name, but display our company name?</h3>

<p>
	Modify the /etc/gettytab file so the default profile uses this:
<p>
<h2><pre>
</h2>
	:im=\r\n  Company Name (%t)\r\n\n:\
<h2></pre>
</h2>
<p>
<p>
<a name="2.6.2"><h3>2.6.2 : I have a program that, under normal circumstances, starts once a second. This regularly causes inetd to terminate the program with a 'server failing (looping), service terminated' error. How do I fix this?</h3>

<p>
	The inetd program has a 40 start per minute limit for all
	programs started out of inetd.conf.  You need to add a 'max
	starts' option on the end of your 'wait' or 'nowait' option.
	For example, try 'nowait.100' if you expect the program to start
	90 times a minute.
<p>
<a name="section_3"><h2>Section 3.	(Kernel Building and Maintenance)
</h2>
<p>
<a name="3.0"><h3>3.0 : System Internals</h3>

<p>
	One of the interesting aspects of *BSD is the fact that it comes 
	with the complete source.  This allows you to make changes to the 
	system, recompile, and test out your new ideas.  This section of 
	the FAQ describes many of the different aspects of this endeavor 
	and common problems and pitfalls that are encountered.  Kevin Lahey 
	provided the substantial portion of this section.  You can contact 
	him via E-Mail at (<a href="mailto:kml@rokkaku.atl.ga.us">kml@rokkaku.atl.ga.us</a>) or contact Dave Burgess 
	(<a href="mailto:burgess@cynjut.neonramp.com">burgess@cynjut.neonramp.com</a>).
<p>
<a name="3.1"><h3>3.1 : Kernel</h3>

<p>
<a name="3.1.1"><h3>3.1.1 : How do I build a kernel?</h3>

<p>
	The kernel can be compiled in a variety of ways to support different 
	devices and configurations.  Compilation is controlled by a config 
	file that specifies the characteristics of the kernel.  A set of 
	different config files is located in /sys/i386/conf or 
	/sys/arch/i386/conf.  The configuration file names are in upper case.
<p>
	To build a particular kernel (in this example, we use the GENERICISA
	configuration file in NetBSD or FreeBSD):
<p>
	% cd /sys/i386/conf
	% config GENERICISA
	% cd /sys/compile/GENERICISA
	% make depend
	% make
<p>
	In NetBSD, since there are multiple architectures supported, there
	is an architecture line in the middle of the path to these files.
	See the build.kernel script in section 3.8 for more information.
<p>
	Remember, when structures in the kernel change, there are some
	programs (ps, top, etc.) that will cease to work correctly.  You
	will need to recompile these programs as well as the new kernel.
	You need to do the following to make sure that your programs get
	updated as well as the kernel:
<p>
	cd /usr/src/include
	make install
	cd /usr/src/lib/libkvm
	make clean && make && make install
	cd /usr/src/bin/ps
	make clean && make && make install
	cd /usr/src/...
<p>
<p>
<a name="3.1.1.1"><h3>3.1.1.1 : Why does the kernel code for NetBSD still use the old K&R style declarations when the ANSI declarations are SO much better?</h3>

<a name="3.1.1.2"><h3>3.1.1.2 : How do I port NetBSD to another platform?</h3>

<p>
	We still use the old style K&R definitions easier, because 
	bringing up a new port on a foreign machine with a brain-damaged 
	compiler can be impossible, or at least very difficult,
	if you don't do it this way.  Remember, NetBSD is multi-platform, 
	and tries to make it as easy as possible to port.  Which means 
	building pieces of the system with someone else's compiler.
<p>
<p>
<a name="3.1.2"><h3>3.1.2 : I want to do one of the following things: * add a device not in the distributed kernel (third com port, additional disk or tape, line printer driver, etc). * use a patch from the net or the patchkit to fix a kernel bug. * add another swap device. * recompile the kernel to remove extraneous devices so that it takes up less space. * configure more pseudo-terminals to allow for more xterms or network logins.</h3>

<p>
	You're going to have to recompile the kernel after you modify the 
	config file.  See section 3.2 below for more information about the 
	config file in general.
<p>
<p>
<a name="3.1.3"><h3>3.1.3 : I want to build and profile a kernel. What do I need to do?</h3>

<p>
	Step 1 is to build a profiled kernel:
<p>
		cd /sys/arch/&ltX&gt/conf
<br>
		config -p CONFIG.FILE.OF.YOUR.CHOICE
<br>
		cd /sys/arch/&ltX&gt/compile/CONFIG.FILE.OF.YOUR.CHOICE
<br>
		make depend
<br>
		make
<br>
		&ltinstall the kernel and reboot&gt
<br>
<p>
	Step 2 is to start the profiling process:
<p>
		log in
<br>
		su to root
<br>
		kgmon -r -h
<br>
		kgmon -b
<br>
<p>
	Step 3 is to run the application in question
<p>
	Step 4 is to stop the profile:
<p>
		kgmon -h
<br>
		kgmon -p  (this produces the gmon.out file, which is the
<br>
				profiles kernel information)
<br>
<p>
	Step 5 is to analyze the output:
<p>
		gprof /{kernel name} gmon.out &gt profile
<br>
<p>
	which produces a hierarchical call graph as well as flat
	profile.  The flat profile is easiest to use for beginners,
	although both are good information sources for kernel code
	performance.
<p>
<p>
<a name="3.1.4"><h3>3.1.4 : Now that I have a kernel, how do I install it?</h3>

<p>
	Your kernel is called /kernel or /netbsd.  Copy the new kernel
	from /sys/compile/GENERICISA/(whatever) to /, assuming that it 
	is in that directory.  If you really screw up the new kernel, 
	you want to have something to fall back on, so be sure to 
	save /kernel to /kernel.old before copying in a new kernel.  
<p>
<p>
<a name="3.1.5"><h3>3.1.5 : My system is complaining about stray interrupt 7. Is my machine going to explode or anything?</h3>

<p>
	No.  They are caused by lots of things.  They are, as far as
	anyone that should be expected to know about this stuff, harmless.
	There are ramifications on them being there, but for MOST users
	they do not pose a real threat to your operations.  For those of
	you that are doing REALLY interrupt intensive stuff, you may want
	to grab a technical reference and figure out why the 8259 is not
	getting reset correctly.
<p>
	In spite of the number of times this has come up (and people have
	even referenced this section) there are still at least two 
	questions on the net about this.  A memorable one was a guy who
	was just vehement that the stray int 7 was what was keeping his
	system from booting.  In fact, he went so far as to say that this
	document was practically worthless because I didn't tell him how
	to fix it.  Of course, once he configured his hard drive controller 
	so that it was on the right interrupt, his booting problem went 
	away.  I have said it before and I will say it again.  For MOST 
	users they do not pose a real threat to your operations.
	I have heard of three people (out of at least 2000) that have
	actually have problems so bad that they couldn't proceed.  They
	bought new computers, and the problem went away.
<p>
	These stray interrupts are caused by something in the PC.  
	I have yet to see a convincing explanation of precisely what,
	but they are definitely caused by something.  There are four
	ways to deal with this problem.
<p>
	1)  Ignore them.  They are spurious and do not effect the
	operation of your computer.
<p>
	2)  Implement the lpt driver.  This way, the driver traps 
	(the lpt driver expects IRQ 7) and then quietly discards them.  
	That is why when folks implement the lpt driver the 'problem' 
	goes away.  The computer is taught how to ignore them.
<p>
	3)  Do what the original 386bsd code did.  Comment out the
	diagnostic and associated code that tries to deal with them so
	you don't see the error message.
<p>
	4)  Buy a new computer that doesn't cause this problem.   It is a
	known hardware problem with the 8259 being reset incorrectly in
	hardware.
<p>
	Kalevi Suominen (<a href="mailto:jks@geom.helsinki.fi">jks@geom.helsinki.fi</a>) offers this technical
	explanation of the 'stray interrupt 7' phenomenon.
<p>
	In the section of the Intel Peripheral Handbook dealing with
	the 8259A there is a description of the 6-step interrupt
	sequence for an 80x86 system (and 7-step for an MCS-80/85),
	and then the following paragraph:
<p>
	"If no interrupt request is present at step 4 of either sequence
	(i.e., the request was too short in duration) the 8259A will
	issue an interrupt level 7. Both the vectoring bytes and the CAS
	lines will look like an interrupt level 7 was requested."
<p>
	This explains how some transient disturbances or improperly
	functioning adapter cards could trigger a stray interrupt 7
	in a system operating in the *level* interrupt mode (such as
	a PS/2 with MCA): An interrupt request will disappear as soon
	as the interrupt line goes inactive.
<p>
	That such interrupts may also occur in a system operating in
	the *edge* triggered mode (such as an ordinary PC/AT with ISA)
	is a little harder to see. Yet it is possible - even without
	malfunctioning hardware - because masking an interrupt request
	will hide its presence from the 8259A as well:
<p>
<p>
	    1. The interrupt flag (IF) of the 80x86 is reset either 
	    directly (e.g., by a "cli" instruction) or because an 
	    interrupt handler is entered. In the latter case the 
	    corresponding in-service (IS) bit of the 8259A is set 
	    (effectively blocking interrupts of lower priority).
<p>
	    2. The 8259A receives an unmasked interrupt request (IRQn), 
	    and, in case an interrupt is being served and has higher 
	    priority than IRQn, the IS bit of the 8259A is reset by 
	    an end of interrupt (EOI) command. (These steps may occur 
	    in either order.) If IRQn has higher priority (e.g. IRQ0), 
	    no EOI is necessary.
<p>
	    3. The 8259A activates the interrupt (INT) line to the 80x86
   	    (which will ignore it - for the moment).
<p>
	    4. The interrupt mask (IM) bit of the 8259A for IRQn is set.
	    (A little late, though. The sequence has already started.)
<p>
	    5. The interrupt flag (IF) of the 80x86 is set (either 
	    directly, or as a consequence of e.g. an "iret" instruction).
<p>
	    6. The 80x86 will now acknowledge the INT request by activating
   	    the INTA line of the 8259A.
<p>
	    7. The 8259A will not see the masked IRQn and will continue
   	    by issuing a spurious interrupt of level 7 instead.
<p>
<p>
	The original interrupt request (IRQn) will not be lost, however.
	It is preserved by the associated edge sense latch of the 8259A,
	and will be acted on after the IM bit has been reset again.
<p>
	The net result is that a single interrupt request will be
	delivered *twice* to the 80x86: first as a stray interrupt 7
	and later as the proper interrupt. In particular, it is perfectly
	safe to ignore the stray interrupt (other than sending an EOI).
	It is just the ghost of an aborted interrupt sequence: the system
	was not prepared for it yet.
<p>
	Bill Roman provides this update, which is so technical I can't
	even figure out what to cut out or how to repackage it so it
	makes sense to people like me.  As an interesting aside, he is
	also a Linux user; thereby proving that I'll accept help the FAQ
	from everyone:
<p>
	First of all, Kalevi Suominen's explanation is correct, but 
	requires just a little more explanation.  Step 4 in the data 
	book concerns the 8259's detection of INTA (interrupt 
	acknowledge) asserted by the processor.  This means that the 
	processor has detected INT (interrupt request) asserted by the 
	8259, the previous instruction has ended, and the interrupt 
	enable flag is true.  The processor has begun its interrupt 
	processing, and the 8259 *must* supply a vector; there is no way 
	for it to tell the processor "never mind".
<p>
	INTA causes the 8259 to examine the currently asserted interrupt 
	requests and return the vector corresponding to the highest 
	current request.  If there is no longer any interrupt request 
	asserted, it supplies vector 7 as a default.  (Intel calls this 
	"DEFAULT IR7" later in the data book.)
<p>
	There is thus a race condition between deassertion of an interrupt 
	request and interrupt servicing by the processor.  An interrupt 
	request which is removed will not always cause DEFAULT IR7 -- 
	only if the request is deasserted after the processor has 
	detected INT and irrevocably decided to act on it, but before 
	the 8259 has detected INTA and prioritized its interrupts.
<p>
	It is easy to see how this could happen when the 8259 is in 
	level triggered mode, but it is counterintuitive that it should 
	happen in edge triggered mode.  To understand this, it is 
	necessary to look at Intel's "Priority Cell--Simplified Logic 
	Diagram" (figure 9 in a 1991 databook I have at hand).  The edge 
	sense latch output is gated by the request; if the request is 
	latched, then deasserted, the 8259 no longer sees it.  There 
	must be a reason Intel did it this way, but it's sure not 
	evident to me.
<p>
	The data book provides a little more information in a later 
	section titled "Edge and Level Triggered Modes".  The most 
	important point is that the corresponding bit in the In Service 
	Register is *not* set when the 8259 generates a DEFAULT IR7.  If 
	the IRQ 7 interrupt service routine sees this condition (i.e., 
	is entered and ISR bit 7 is zero) it should simply execute an 
	interrupt return instruction without sending an End of 
	Interrupt (EOI) command to the 8259.  Also, the IRQ 7 interrupt 
	service routine can be reentered due to this condition.  Intel 
	recommends that the interrupt service routine keep track of 
	whether it is currently active so this can be detected.
<p>
	I don't think that changing the interrupt mask bit can cause the 
	problem, especially if it is changed while the interrupt flag is 
	clear.  As I mentioned, the problem occurs only when the actual 
	interrupt acknowledge process has begun, which can't happen while 
	IF is clear.
<p>
	What can generate DEFAULT IR7 is a device driver that doesn't mask 
	off its device's interrupt (either in the 8259 or in the device 
	itself) while it is performing operations which can cause the 
	device to deassert its interrupt request.  For example: imagine 
	a hypothetical device with an interrupt status register.  This 
	register latches all the device's status which could cause an 
	interrupt, and clears this status when it is read.  If the 
	processor begins executing the instruction which reads this 
	register just as a status bit is set, the device will assert 
	and deassert the request within the space of that instruction.  
	On an x86 architecture processor I have worked with, this did 
	indeed generate a DEFAULT IR7.  All device drivers should make 
	sure that the device's interrupt request is disabled while the 
	device is being serviced.  A well-behaved device will never 
	deassert its request without explicit software action.
<p>
	This leaves only the poor folks who have had to buy new computers 
	to get rid of the problem.  My suspicion in this case is that 
	crosstalk on the mainboard is causing glitches on interrupt 
	request lines.  Remember that the f**king wizards at IBM made 
	the request lines active high instead of active low with a 
	pull-up (which would have allowed wire-or interrupt sharing).  
	Some devices (some serial port cards, I believe) use a 
	tri-state driver to drive the request high, but disable the 
	driver entirely when the request is deasserted, counting on a 
	weak pull-down.  This leaves interrupt request lines floating, 
	although the 8259 has the inputs enabled.  This is all 
	conjecture, though.  
<p>
	Provided by: Bill Roman  (<a href="mailto:roman@songdog.eskimo.com">roman@songdog.eskimo.com</a>)
<p>
<p>
<a name="3.1.6"><h3>3.1.6 : I keep getting "wd0c: extra interrupt". What does it mean?</h3>

<p>
	It means that the drive was already processing a command 
	(active) when it received an interrupt from the system telling 
	it to see if it had anything to do.  This is mostly harmless 
	but could indicate that the drive/controller is having problems 
	if the message appears often.
<p>
<p>
<a name="3.1.7"><h3>3.1.7 : I keep getting silo overflow messages, but the system doesn't seem to mind. Is there a problem?</h3>

<p>
	Not exactly.  This simply means that the First in first out
	buffer is getting too full.  I markedly reduced the incidence 
	of silo overflows on my system by editing dev/isa/com.c to 
	change the FIFO threshold from 8 to 4 characters.  This way, the
	buffer gets more attention and reduces the chance of overflowing
	the buffer.
<p>
	Another possibility is caused when you are using internet over 
	a telephone line via SLIP or PPP.  You might have an unbuffered
	UART on your serial port, like the 8250 or the 16450. With the
	introduction of the IBM PS/2 systems the first 16550 UART's were
	shipped to provide a 16 byte buffer. But unfortunately the buffering
	of the original 16550 did not work. The problem was solved with
	the improved 16550A UART. If you run MSD (under MSDOS!), an
	application that comes with MS-Windows, you can determine the UART
	type of your serial ports (by choosing COMS). The UART type is also
	showed when your UNIX boots up.
<p>
	To solve the `silo overflow' problem you can by a Multi/IO card 
	with a `real' 16550A, or a card with an extra serial port, like 
	the HAYES ESP card. The Hayes card has a DOSSETUP utility to 
	configure its port address and IRQ. The port address can be 
	chosen between 180H and 380H, the IRQ address 3, 4, 5 or 9. 
	Normally COM1 (tty00) and COM2 (tty01) claim IRQ 3 and 4. So
	you can choose (for example) IRQ 9 for the Hayes ESP card.  
	Then you have to add the appropriate lines in your kernel 
	configuration:
<p>
   	    options COM_HAYESP
<p>
   	    device		com0	at isa? port "IO_COM1" irq 4
   	    device		com1	at isa? port "IO_COM2" irq 3
   	    # com2: Hayes ESP serial port
   	    device		com2    at isa? port "IO_COM3" irq 9
<p>
	For more information on com ports in general, try this URL:
<p>
	    <a href="http://comminfo.com/pages/ctsfaq01.htm#q6.">http://comminfo.com/pages/ctsfaq01.htm#q6.</a>
<p>
<p>
<a name="3.1.8"><h3>3.1.8 : I found a bug in the kernel. How do I report it?</h3>

<p>
	Both NetBSD and FreeBSD include a facility called 'bugfiler'.  
	While the instructions are included in both system, there is 
	still some apparent confusion about when to use (and when to
	NOT use) bugfiler.
<p>
	Jordan K. Hubbard (<a href="mailto:jkh@whisker.lotus.ie">jkh@whisker.lotus.ie</a>)  provides us with this
	short article for FreeBSD.
<p>
	To send bug reports, you want to use the sendbug(1) command.
	The entire package for sending and filing these bugs is known 
	as "the bugfiler", which is where the confusion stepped in, 
	but sendbug is definitely the command you want to use.
<p>
	Second, it doesn't take a "net connection" to use sendbug, 
	since all it does is package up your "bug report form" and mail 
	it to us; no direct Internet connectivity is required, just mail.
<p>
	So if you can send Internet mail you can use sendbug, or you can 
	also send mail to the `<a href="mailto:FreeBSD-bugs@freefall.cdrom.com">FreeBSD-bugs@freefall.cdrom.com</a>' address 
	(do NOT send it to FreeBSD.cdrom.com since it will BOUNCE, this 
	is not the place to send bugs to, just to ftp stuff from!).
<p>
	NetBSD has a similar facility, but has a different program and
	host for bug reports.  The program for NetBSD is called send-pr
	and is slightly different in several respects.  It is part of
	the GNATS system, which the NetBSD core developers started using
	in February of 1994.  It is recommended that NetBSD users see the 
	man page on send-pr before filing bug reports.
<p>
	For getting information from GNATS, see the file doc/BUGS.
<p>
	There is a email interface to the NetBSD PR database.  To query 
	the database send mail to "<a href="mailto:query-pr@gnats.netbsd.org">query-pr@gnats.netbsd.org</a>".  The mail 
	server will send a bug database listing back to the user.
<p>
	There are several flags that are useful to send to the mail server.
	The flags are entered in the "Subject" line:
	  --summary	Display an one-line entry for each bug
	  --full 	Display the full entry for each bug	
	  --help	Display a help string containing the rest of the flags.
	  PR		The Problem Report number of a particular bug
<p>
	For example, to send a query about all the bugs:
	  $ Mail -s "--summary" <a href="mailto:query-pr@gnats.netbsd.org">query-pr@gnats.netbsd.org</a> &lt /dev/null
<p>
	If you want to know more about a particular bug, let's say bug 40:
	  $ Mail -s "--full 40" <a href="mailto:query-pr@gnats.netbsd.org">query-pr@gnats.netbsd.org</a> &lt /dev/null
<p>
<p>
	John Conklin is trying to get a page set up at the NetBSD WWW site
	(www.netbsd.org) that will allow people to interactively query the 
	bug database.  It should be operational soon.
<p>
<p>
<a name="3.2"><h3>3.2 : What exactly is this config file, anyway? What are all of these cryptic notations?</h3>

<p>
	The config file is the list of all of the optional (and settings
	for the mandatory) parts of the kernel.  If the system is made
	up of static object files which don't change, then all you
	should ever need to do is modify the config file, reconfigure
	the kernel objects, and relink.  Since both NetBSD and FreeBSD
	are distributed with source, these files are recompiled and a
	kernel is constructed.  Some of these have been deprecated, and
	may not be in use for a particular version of the system
	(i.e. ISO9660 and CD9660 are the same, CD9660 being the newer
	version). 
<p>
<p>
<a name="3.2.1"><h3>3.2.1 : Okay, fine. Why shouldn't I just add every device I can find to the kernel, so I'll never have to recompile this again?</h3>

<p>
	Because it takes up space.  The kernel is wired into memory, so 
	every byte it uses comes out of the pool of memory for everything 
	else.  It can't page out sections that aren't in use.  If your 
	kernel is larger than 640K, then it can't be loaded.  You'll need 
	to use Julian Elischer's bootblocks to put it in high memory, which 
	seem to be fairly complex.  Installing them (once they are 
	compiled) is as easy as using disklabel.
<p>
	Newer versions of the *BSD kith provide the capability to build
	a kernel that is larger than 640K.  Complete instructions are
	provided in the appropriate systems.
<p>
<p>
<a name="3.2.2"><h3>3.2.2 : What should I remove from the kernel?</h3>

<p>
	What do you need?  If you only have an SCSI controller, you don't 
	need the wd0 device;  if you have another kind of disk controller, 
	you don't need sd0.  Unless you actually HAVE more than one Ethernet 
	controller, you should comment out all but one of them.  If you don't 
	have an ethernet controller, you don't need any of the controllers or 
	NFS compiled in.   Without a CD-ROM, ISOFS is kind of pointless.  Just 
	look at what you have and think about what you really need.
<p>
<p>
<a name="3.2.3"><h3>3.2.3 : I can't get enough remote login sessions or xterm sessions. I also can only get four sessions working at a time. What can I do?</h3>

<p>
	Increase the count of pseudo-terminals --
<p>
	pseudo-device	pty	12  # or whatever
<p>
	Every pseudo terminal should have a /dev/pty* entry.  If you have 12
	pseudo terminals, you should also have at least 12 pty devices in the
	/dev directory.  The MAKEDEV script in /dev will create as many pseudo-
	terminals as you tell it to.
<p>
<p>
<a name="3.2.4"><h3>3.2.4 : How do I get ddb, the kernel debugger, compiled into the kernel and running?</h3>

<p>
	If you are using older versions of the 386BSD family, you will
	need to add a line in your config file that looks like this:
<p>
	device-pseudo	ddb
<p>
	If you are using a more recent version (the division is pretty
	unclear about when the switch was made) and do not have any
	device-pseudo entries, you will need to add the line:
<p>
	options 	DDB
<p>
	to your config file.
<p>
	Build the kernel, then run dbsym on it:
<p>
	% dbsym ./kernel
<p>
	Install it and go for it.  Ctl-Alt-Esc drops you into the debugger.
<p>
	Note: DDB as shipped originally is a memory hog, and it is very
	difficult to get a kernel small enough with enough fun things in it
	to debug in 640K
<p>
	On the NetBSD-sparc system, the L1-A is used by the the DDB
	routines to drop you into the debugger.
<p>
<p>
<a name="3.2.5"><h3>3.2.5 : I'm getting all kinds of errors when I try to build a new version of GCC. How can I upgrade GCC to the most current version?</h3>

<p>
	Yes, this will happen on most architectures on the first compile
	of src/gnu/usr.bin/gcc/libgcc.  As was stated in the mailing
	list before, when you get to this error:
	  1) run a 'make' in the gcc directory.  It will error out (most
	     likely) on libgcc.
	  1) Do a 'make install' at this point to install at least gcc, 
	     cpp, and cc1.
	  2) go back and compile in src/gnu/usr.bin/gcc/ WITHOUT doing 
	     a "make clean"
	  3) install everything in src/gnu/usr.bin/gcc
<p>
<p>
<a name="3.2.6"><h3>3.2.6 : Can I patch the current running OS image?</h3>

<p>
	In general, I think, the answer is no.  The prevailing philosophy 
	seems to be that one should use sysctl for such things, but that 
	requires that one has already compiled in the ability to change 
	the specific variable in question.  (I discovered this when I 
	wanted to patch tickadj at runtime; I added it to kernfs, and 
	when I offered the patches (which are quite small) I was told 
	sysctl was the `correct' way.  What's incorrect about /kern was 
	never quite explained; the closest anyone came was to invoke 
	internationalization concerns.  Of course, using /kern also 
	requires having compiled in support for tweaking the variable 
	you want to change.)
<p>
	Besides, unless you've patched securelevel, I don't think there 
	is any good way to twiddle variables in the running kernel.  
	/dev/{,k}mem are, I believe, read-only once init sets securelevel 
	to 1.
<p>
	If you need to know more about the sysctl command, try 
	"sysctl -a | more" to get a list of the parameters that can be
	modified while the system is running.
<p>
<p>
<a name="3.2.7"><h3>3.2.7 : Can I have more than one config file? Should I rename it to something else? Any other hints?</h3>

<p>
	You can create as many (or as few) config files as you desire.  The 
	system, once the patchkit is applied, will have between 10 and 15, 
	each of which implements certain functions or features.  In addition, 
	the normal place for the patchkit to make changes to the config files 
	is in the GENERICISA file.  Since this file should remain unchanged 
	and available, it is always a good idea to copy this file to a 
	meaningful name and modify that file.  In other words, change every 
	reference in 3.1.1 from GENERICISA to HAL (or whatever you call your 
	system).
<p>
	One final note.  Every /sys/compile directory takes up 800K or so;
	you might want to watch to see how big these all get.
<p>
<p>
<a name="3.2.8"><h3>3.2.8 : I have been getting a lot of "virtual memory exhausted" errors when I am compiling a program with a really big static array. I have 128Meg of memory and 8Gig of swap. How can this be happening?</h3>

<p>
	If you are using Csh, you can simply unlimit your processes in 
	your system level /etc/csh.cshrc file or your personal .cshrc 
	file.  You can also modify your kernel so that the
	amount of memory available is less limiting.  J"org Wunsch 
	(<a href="mailto:j@tcd-dresden.de">j@tcd-dresden.de</a>) provides us with this brief description:
<p>
	From a recent posting regarding the problem how much virtual 
	memory one could get.
<p>
	| On the other hand, i've also changed the definitions you
	| mentioned. But i didn't like to modify the header files, and
	| actually, modifying the values is as easy as:
	| 
	| options		"DFLDSIZ='(16 * 1024 * 1024)'"
	| options		"MAXDSIZ='(64 * 1024 * 1024)'"
	| 
	| Include the above lines into your kernel's config file, reconfig
	| and rebuild it.
	| 
<p>
	This has been reported to work well for NetBSD, but causes
	problems in the mkdep step of the kernel compile in FreeBSD.
	Check the FreeBSD Web Site for a more definitive answer.
	&ltInsert address of pointer here&gt.
<p>
	This is just a hint for those people poking around with compiling
	large source files. Especially, due to some gcc problems with large
	static arrays, compiling X applications with huge bitmaps would
	cause virtual memory trouble. Increasing the limits (o'course, as
	long as the h/w resources suffice) could help there.
<p>
	The default definitions for the above parameters are found in
	/usr/include/machine/vmparam.h.
<p>
<p>
<a name="3.2.8.1"><h3>3.2.8.1 : I am running NetBSD and really DO have 128 Meg of memory; but the generic kernel only sees the first 64Meg. How can I fix this?</h3>

<p>
	The EXTMEM_SIZE entry needs to be set for your system.  I'm
	completely clear on the concept, but it goes something like
	this:
<p>
	The value of EXTMEM_SIZE needs to be set to the number of bytes
	in the extended memory range for your system.  Since this
	excludes the first Meg of memory, the value for the machine
	above would be 127 * 1024, for a grand total of 130048.  Once
	you reset that, you will need to either get the -current sources
	(which will do the following for you) or you need to set NKPDE
	to something larger than 12.  For 128Meg, 16 seems to be a
	reasonable number; for 256Meg, 20 would probably work, with 24
	being adequate for 512Meg.
<p>
	Both of these can be set in the source, or you can use the
	"options" method listed in the last paragraph.
<p>
<p>
<a name="3.2.8.2"><h3>3.2.8.2 : How do I dedicate 16Meg of memory to nothing but disk buffers?</h3>

<p>
	Set BUFPAGES to the number of 4K buffers you want to allocate.
	For 16Meg, you would use "options	BUFPAGES=4096".
<p>
<p>
<a name="3.2.9"><h3>3.2.9 : Where can I learn more about all this?</h3>

<p>
	We've skipped over a lot of details here;  the straight dope comes 
	from "Building Berkeley UNIX Kernels with Config", by Samuel J. 
	Leffler and Michael J. Karels. 
<p>
<p>
<a name="3.3"><h3>3.3 : Other kernel related kind of questions.</h3>

<a name="3.3.1"><h3>3.3.1 : Has the method for system call changed in NetBSD?</h3>

<p>
	Q.  Is there something special with the order I need to update 
	binaries and libraries in?  If I drop in the new libc, everything 
	gives me a bus error.  Both shared and static do this.
<p>
	A.  On the port-i386 list, Charles Hannum discussed changing the 
	system call mechanism (doing it via an INT instead of a call 
	gate).  Looking at src/lib/libc/arch/i386/sys/syscall.S, it looks 
	like this change is in.   Your binaries are (if you are using an 
	old kernel) probably crashing at each system call now.
<p>
	So.. first compiling a new kernel with COMPAT_10 in it should make 
	your newly linked binaries work, I guess (have not recompiled since 
	the update myself yet). Also don't forget that you need to use 
	config.new now.
<p>
	So, the answer is Yes, the mechanism for system calls has
	changed, but the old method (using a call gate) is still
	available by specifying COMPAT_10 in your configuration file.
<p>
<p>
<a name="3.3.2"><h3>3.3.2 : Does anyone have a system building script that takes things like building a new config and multiple config files into account?</h3>

<p>
	The program I use to rebuild my kernel is available from 
	<a href="http://cynjut.neonramp.com/build-kernel">http://cynjut.neonramp.com/build-kernel</a>
<p>
<p>
<a name="3.3.3"><h3>3.3.3 : How do I upgrade from my release version of NetBSD (and probably FreeBSD) to the '-current' development sources?</h3>

<p>
	Your best method _by far_ would to to pull down a snapshot
	(assuming one exists for your arch) & install all except the etc
	tarfile, then diff the etc tarfile contents with your setup to
	check for any updates you should make.
<p>
	If you really want to do it the hard way, here is your map.
<p>
	# Remember to make yourself a new config (not config.old) kernel 
	# config file.
	#
	# This means any old config file you may have had from
	# V1.1 needs to have the mainbus changes made. See GENERICADP and look
	# for the isa0,eisa0,pci0 at root add the mainbus0 stuff and attached
	# your buses to it.  For updates to V1.2, you will need to make
	# certain the COMPAT_* options are correct.
	#
	# Make sure you have COMPAT_11 as part of your kernel config 
	# options.
	#
	# This assumes that the -current source is in /usr/src
<p>
	(cd /usr/src/usr.sbin/config ; make && make install && make cleandir)
<p>
	# if you don't do this, config of your kernel config file will
	# fail with errors in files.i386
<p>
	(cd /usr/src/gnu/usr.bin/gas ; make && make install && make cleandir)
<p>
	# if you don't do this, you won't be able to build locore.s, with
	# errors about cpuid instruction not found
<p>
	(cd /sys/arch/i386/conf ; config BCC13)
	(cd /sys/arch/i386/compile/BCC13 ; make depend && make)
<p>
	# copy  new kernel to /, and boot off it
<p>
	(cd /usr/src/share/mk ; make install)
<p>
	# if you don't do this, you'll get errors building gcc, when it
	# doesn't know how to make the manual pages (don't know how to 
	# make gcc.0)
	#
	# Rebuild yacc first or the yacc from v1.1 dies on Error Code 1 when
	# it hits %expect 34 in /usr/src/gnu/gcc/common/c-parse.y. The
	# new yacc included with V1.1B handles it, build and install it
	# before it gets used in the gcc building.
	#
	# ***
	#
	(cd /usr/src/usr.bin/yacc; make && make install && make cleandir)
	#
	# The build now uses a new tsort option (-q) when it gets to the 
	# point of 'building standard cc1 library'. At this point if using 
	# the tsort that comes with V1.1 it dies on a Error 1 and no 
	# obvious explanation. Going to the common sub-directory under 
	# gcc (ie.  /usr/src/gnu/usr.bin/gcc/common)
	# and typing 'make' will reveal the full error.
	#
	(cd /usr/src/usr.bin/tsort; make && make install && make cleandir)
	#
	#
	cd /usr/src/gnu/usr.bin/gcc
	make
	#
	# Build will die here on libgcc
	#
	(cd cc; make install)
	(cd cc1; make install)
	(cd cc1obj; make install)
	(cd cc1plus; make install)
	(cd cpp; make install)
	(cd g++; make install)
	(cd libgcc; make; make install)
	(cd libobjc; make; make install)
	(cd /usr/src/gnu/usr.bin/gcc ; make && make install && make cleandir)
	#
	# Bernd Wiserner says that the ld.so that will be built next will
	# work only with libc.so.12.0, not with libc.so.12.3
	# His instructions to make a working ld.so follow:
	# Do NOT run ldconfig while doing the folowing 5 lines ...
	#
	(cd /usr/src/include ; make && make includes)
	#
	cp -p /usr/libexec/ld.so /usr/libexec/ld.so.good
	(cd /usr/src/gnu/usr.bin/ld ; make && make install && make cleandir)
	cp -p /usr/libexec/ld.so.good /usr/libexec/ld.so
	#
	# Then build ld.so again ...
	(cd /usr/src/gnu/usr.bin/ld ; make && make install && make cleandir)  
	# Thanks, Bernd...
<p>
	# And now the libraries
	(cd /usr/src/lib ; make && make install && make cleandir)
<p>
	(cd /usr/src/bin/sh ; make && make install &&  make cleandir)
<p>
	# and now back to the beginning and make the world
	#
	(cd /usr/src/bin ; make && make install && make cleandir)
	(cd /usr/src/sbin ; make && make install && make cleandir)
<p>
	mkdir /usr/share/doc/usd/13.viref
	# otherwise "make install" in /usr/src/usr.bin will fail because
	# the destination directory doesn't exist - from Tom Thai
<p>
	# if you're using the obj directory hierarchy, use the
	# initscan.c from the obj directory, otherwise use the initscan.c
	# that was created here.
<p>
	cd /usr/src/usr.bin/lex
	if test -d /usr/src/usr.bin/lex/obj ; then
       	    cp initscan.c obj/scan.c
	else
       	    cp initscan.c scan.c
	fi
<p>
	# if you don't, then lex won't be built
<p>
	(cd /usr/src/usr.bin ; make && make install && make cleandir)
	(cd /usr/src/usr.sbin ; make && make install && make cleandir)
	(cd /usr/src/libexec ; make && make install && make cleandir)
	(cd /usr/src/gnu ; make && make install && make cleandir)
	(cd /usr/src/share ; make && make install && make cleandir)
<p>
	mkdir /usr/share/doc/usd/30.rogue /usr/share/doc/usd/31.trek
	# otherwise "make install" in /usr/src/games might fail
	# if the dirs weren't already there
<p>
	(cd /usr/src/games ; make && make install && make cleandir)
<p>
<p>
<a name="3.3.4"><h3>3.3.4 : Is there a Makefile that does all that happy world-building stuff?</h3>

<p>
	There is one in the /usr/src directory.  Unfortunately, it
	seldom gets sent down unless you are using sup to get -current.
	If you need it for NetBSD, you can FTP to ftp.netbsd.org and 
	get it from the src archive.
<p>
	<a href="ftp://ftp.netbsd.org/pub/NetBSD-current/src/Makefile">ftp://ftp.netbsd.org/pub/NetBSD-current/src/Makefile</a>
<p>
	The same can be said for FreeBSD and OpenBSD, but obviously you
	will need to get it from their FTP sites; not NetBSD's.
<p>
<p>
<a name="3.3.5"><h3>3.3.5 : Can NetBSD do cross compilation?</h3>

<p>
	Sure.  Check out the cross-compiling howto for MacBSD for an
	example.  All of the NetBSD ports should be capable of doing
	'pretty much' the same thing.
<p>
	You can find Colin Wood's MacBSD cross compilation howto at 
	the following URL:
<p>
	<a href="http://www.macbsd.com/macbsd/howto/cc-HOWTO">http://www.macbsd.com/macbsd/howto/cc-HOWTO</a>
<p>
<a name="3.3.6"><h3>3.3.6 : My network memory seems to be leaking. The numbers just keep increasing slowly over time. Is there a problem I need to worry about?</h3>

<p>
	Probably not.  When the system starts, the kernel malloc pool is
	not backed by real memory.  As these pages are allocated, real
	memory is assigned to them, increasing your memory usage.  As
	these pages are released, they are returned to the malloc pool,
	but the memory is never returned to the system.  Eventually,
	your malloc area will reach a point of statis, where new pages
	are not needed from real memory; the releases to the malloc area
	should cover the new pages needed.
<p>
<p>
<a name="3.4"><h3>3.4 : X11/XFree86/XS3</h3>

<a name="3.4.1"><h3>3.4.1 : What options should I define to get the X extensions included?</h3>

<p>
	Once you have applied the patch kit, the only thing left to do is to
	modify the config file to include the following line:
<p>
	options	XSERVER, UCONSOLE
<p>
	recompile the kernel and the kernel should support X.
<p>
<a name="3.4.2"><h3>3.4.2 : Where can I get the FAQ for 'X'?</h3>

<p>
	Steve Kotsopoulos' general 'X on Intel-based Unix' FAQ
	available by anonymous ftp from export.lcs.mit.edu in 
	/contrib/faq/Intel-Unix-X-faq. 
<p>
<p>
<a name="3.4.3"><h3>3.4.3 : Why does X drop characters when using xdm? When I run xdm from the console, it keeps losing keystrokes and the shift keys don't always work. Why?</h3>

<p>
        You need to run xdm with the -nodaemon flag.  The reason is
        xdm normally detaches from the keyboard.  This allows other
        processes (like getty) to return to reading from the keyboard.
        A race condition results, where some keystrokes are sent to
        xdm and others are sent to other processes.  Using the
        -nodaemon flag causes xdm to stay attached to the keyboard
        so no other process can use it.  This answer comes from Michael 
        C. Newell (<a href="mailto:root@wanderer.nsi.nasa.gov">root@wanderer.nsi.nasa.gov</a>)
<p>
	This bit of trivia is also covered in detail in the X FAQ and 
	the README that accompanies XFree86.
<p>
<p>
<a name="3.4.4"><h3>3.4.4 : What can I do to figure out why 'X' doesn't work with NetBSD?</h3>

<p>
	The best way to debug problems with starting 'X' is to redirect
	the output of the 'startx' program to a file:
<p>
	% startx &gt& startx.log	   # csh
	% startx 2&gt&1 &gt startx.log # sh
<p>
	With the output from this, the problems should be fairly easy to
	identify and (hopefully) fix.
<p>
<p>
<a name="3.4.5"><h3>3.4.5 : Under NetBSD and FreeBSD, xlock (or any other program that uses passwords) fails to validate user passwords. Anyone know why?</h3>

<p>
	OK, first off, make sure you're using the latest version of 
	xlock. If you've pulled it out of the /ports/ distribution then 
	you've got version 1.14. This is woefully ancient, so get the 
	latest, which at the time of writing is 2.7 (just do an archie 
	search for 'xlockmore-2.7' to find it).
<p>
	Get this, compile it up and *make sure it's setuid root*. So, 
	after you've copied it into /usr/X11R6/bin or wherever, do the 
	following:
<p>
	    # chown root.wheel ./xlock
	    # chmod 4755 ./xlock
<p>
	After that, it should work fine. The problem is that without 
	being setuid root xlock cannot read the real system passwords. 
	If you look in /etc/passwd you'll see that the passwords are 
	all '*'d out, because FreeBSD and NetBSD use shadow passwords.
<p>
	That's what worked for me. A couple of other suggestions were 
	raised last time this problem cropped up:
<p>
	  o If you're using a pre-compiled xlock then it might have 
	  been linked against the USA encryption libraries. If you're 
	  outside the States then the encryption libraries are different, 
	  and a US xlock will not be able to read the passwords. The fix 
	  is to get the sources and recompile.
<p>
	  o If you've compiled it from source, made it setuid root, and 
	  it still doesn't work, someone suggested changing the size of 
	  the constant PASSLENGTH in xlock.c from '20' to '40'. I haven't 
	  had to do this, and in v2.7 it's '64' anyway, so it shouldn't 
	  be a problem.
<p>
<p>
<a name="3.5"><h3>3.5 : I want to run 'XYZA' which is dynamically linked and from 'some other operating system'. What special things do I have to do to get it working?</h3>

<p>
	For NetBSD:
	Assuming you are trying to simulate a SVR4 system, you want to 
	create the '/emul/svr4' directory.  You will also want to ensure
	the "COMPAT_SVR4" option is in your kernel config file.  This
	option will change in 1.3-current and later, so be sure to check
	out the config files included with those versions to ensure you
	have the right options.
<p>
	Note that there are known problems when trying to run a
	staically linked Linux ELF executable and you have SVR4
	emulation built into your kernel.  THe problem is the order in
	which ELF executables are processed through the kernel tables.
	The SVR4 emulation gets processed first, thus causing the LInux
	ELF executable to be improperly processed.  This may cause
	certain Linux static ELF executables to fail under the *BSD
	systems.  The way to fix this is to remove SVR4 emulation from
	the kernel or switch to a real SVR4 executable.
<p>
	Also note that newer versions of NetBSD do not make a
	distinction between Linux ELF executables and SVR4 ELF
	executables.  The only difference (from the 1.3 kernel's
	viewpoint) is whether they are 32 or 64 bit ELF executables.
<p>
	With this accomplished, you will need to copy several files into
	the emulation directoy.  A live example might be best at this
	point.  Most of this information is include in the
	'compat_linux(8)' manpage.
<p>
	First, set up the '/emul/linux' directory.  Within this
	directory (and virtually all of the emulation directories) you
	will need the following:
<p>
		etc/	(the emulated /etc directory)
<br>
		lib/	(the emulated /lib directory)
<br>
		usr/	(the emulated /usr directory)
<br>
<p>
	From there, the simplest way to populate these directories is to
	use a program like 'cpio' or 'tar' to build an archive.  Having
	a linux machine available will greatly simplify this.  Copy
	(basically everything from the Linux (or whatever) /etc and /lib
	directories.
<p>
	Any executables that you need from the Linux system should then
	be copied into an appropriate place in the usr/ directory.  For
	example, when creating the Linux Doom system on NetBSD, you need
	to have the following files (which should all come from the
	Linux Doom distribution).
<p>
	usr/X11R6/lib
		libX11.so.6.0
<br>
<p>
	usr/bin:
		as86
<br>
		ld86
<br>
<p>
	usr/games/doom
		README.linuxx
<br>
		doom1.wad
<br>
		linuxxdoom
<br>
		sndserver.old
<br>
<p>
	With Doom specifically, you may need to set 'DOOMWAD' (or
	whatever it is) to usr/games/doom for it to work correctly.  
<p>
	In addition to the 'X' version, the native version should also
	work (with recent versions of NetBSD (1.1+)
<p>
	It is generally accepted that NetBSD's emulation of the other
	systems is pretty close *except for* sound.  The audio drivers
	in NetBSD are not a robust (yet) as they probably should be.
	Don't be surprised if sound emulation works badly, if at all,
	for any of the other operating systems emulation works for.
<p>
	The good news is that work under way (early 1997) in the
	-current version of NetBSD (pre 1.3) should fix most of this.
	The sound subsystem has been modified so that machine
	independent components are seperated from the machine dependent
	stuff, and each of the machine dependent parts is getting a
	facelist.  Ultimately, the NetBSD sounds system should be 100%
	compatible with the one from FreeBSD (that was the design goal)
	and probably Linux as well. 
<p>
<p>
<a name="3.6"><h3>3.6 : You promised to talk about timezones below. Are you going to?</h3>

<p>
	&gtI've seen lots of stuff about timezone's being a bit dodgy,
	&gtespecially with most European timezones changing over to DST on 
	&gtthe 27th March.  I must say that that was NOT the case for me - 
	&gtpumpy (the author's system) is running off the 
	&gt/usr/share/zoneinfo/GB-Eire timezone file, (symbolically) linked 
	&gtto /etc/localtime, the CMOS clock is running off GMT, and the 
	&gtkernel is compiled with "timezone 0".
<p>
	For a full discussion of this problem, check out the
	'options(4)' manpage.  It describes the DST and TIMEZONE options
	in detail.
<p>
	In newer kernels, the problems are far less dramatic than they
	used to be (see below):
<p>
	The problems with timezones and real-time clocks is that most
	386 hardware is just stupid.  It doesn't recognize DST, even
	when told to.  It can't use network system time during DST
	because it makes all the PC clocks off by an hour.  
<p>
	For machines that dual boot DOS and *BSD, one of the simplest
	solutions involves using a program called 'clock372' from
	Simtelnet (the exact site is not available).  After you install
	it, you add a couple of lines to your DOS CONFIG.SYS and set the
	hardware clock to DST.  From there, you build a kernel with DST
	and TIMEZONE set to 0 and your whole system "just works".
<p>
	In older kernels the following works:
<p>
	I use /usr/share/zoneinfo/MET as /etc/localtime and have the 
	kernel configured as
<p>
		timezone        -1 dst 4
<br>
<p>
	(My wife is running DOS on this machine for doom sometimes ;-)
<p>
	I set this strange dst value after diging in some old ultrix(?) 
	man pages.  There were several dst-changing-method listed and 4 
	was the code for the central europe one.
<p>
	This gave me an idea... I use an Ultrix box every day, so why not...
<p>
	Now, I don't know how closely this applies to NetBSD since 
	Ultrix is based on a much older version of BSD, and this isn't 
	for the kernel config, but for an envar of timezone values, but 
	it's at least somewhat enlightening on possible meanings for 
	these things.  Could someone in the know shed light on how 
	accurately this models the timezone stuff in the kernel config?  
	When I did "man timezone" this is what I got (portion of this 
	quoted from the DEC MIPS Ultrix 4.3a timezone(3) manpage, 
	slightly hacked by me (Michael L. VanLoon (<a href="mailto:michaelv@iastate.edu">michaelv@iastate.edu</a>))
<p>
<p>
		 STD offset [DST [offset][,start[/time],end[/time]]]
<br>
<p>
	     the components of the string have the following meaning:
<p>
	STD and DST	Three or more characters that are the 
			designation for the standard (STD) or 
<br>
			summer (DST) time zone. Only STD is required; 
<br>
			if DST is missing, then summer time does not apply 
<br>
			in this locale. Upper- and lowercase letters are 
<br>
			explicitly allowed.  Any characters except a 
<br>
			leading colon (:), digits, comma (,), minus (-), 
<br>
			plus (+), and ASCII NUL are allowed.
<br>
<p>
     	offset		Indicates the value to be added to the local 
			time to arrive at Coordinated Universal Time. The 
<br>
			offset has the form:
<br>
<p>
			hh[:mm[:ss]]
<br>
<p>
			The minutes (mm) and seconds (ss) are optional. 
<br>
			The hour (hh) is required and may be a single 
<br>
			digit.	The offset following STD is required. If 
<br>
			no offset follows DST, summer time is assumed to 
<br>
			be one hour ahead of standard time.  One or more 
<br>
			digits may be used; the value is always
<br>
			interpreted as a decimal number.  The hour must 
<br>
			be between 0 and 24, and the minutes (and
<br>
			seconds) - if present - between zero and 59. If 
<br>
			preceded by a "-", the time zone is east of the 
<br>
			Prime Meridian; otherwise it is west (which may
<br>
			be indicated by an optional preceding "+").
<br>
<p>
     start and end	Indicates when to change to and back from summer
     			time. Start describes the date when the change
			from standard to summer time occurs and end 
<br>
			describes the date when the change back
<br>
			happens.  The format of start and end must be
<br>
			one of the following:
<br>
<p>
			Jn	The Julian day n (1 &lt n &lt 365). Leap
<br>
				days are not counted.  That is, in all
<br>
				years, including leap years, February
<br>
				28 is day 59 and March 1 is day 60.  It
<br>
				is impossible to explicitly refer to
<br>
				the occasional February 29.
<br>
<p>
			n	The zero-based Julian day (0 &lt n &lt
<br>
				365).  Leap days are counted, and it is	
<br>
				possible to refer to February 29.
<br>
<p>
			Mm.n.d	The nth d day of month m (1 &lt n &lt 5, 
<br>
				0 &lt d &lt 6, 1 &lt m &lt 12).  When n is 5 it 
<br>
				refers to the last d day of month m.
<br>
				Day 0 is Sunday.
<br>
<p>
     			time	The time field describes the time when,
				in current time, the change to or from
<br>
				summer time occurs. Time has the same
<br>
				format as offset except that no leading
<br>
				sign (a minus (-) or a plus (+) sign)
<br>
				is allowed. The default, if time is not
<br>
				given, is 02:00:00.
<br>
<p>
	As an example of the previous format, if the TZ environment
	variable had the value EST5EDT4,M4.1.0,M10.5.0 it would	describe 
	the rule, which went into effect in 1987, for the Eastern time
	zone in the USA.  Specifically, EST would be the designation for
	standard time, which is 5 hours behind GMT.  EDT would be the 
	designation for DST, which is 4 hours behind GMT.  DST starts
	on the first Sunday in April and ends on the last Sunday in
	October.  In both cases, since the time was not specified, the
	change to and from DST would occur at the default time of 2:00 AM.
<p>
	The timezone call remains for compatibility reasons only; it is 
	impossible to reliably map timezone's arguments (zone, a
	`minutes west of GMT' value and DST, a `daylight saving time in
	effect' flag) to a time zone abbreviation.
<p>
<p>
<a name="3.6.1"><h3>3.6.1 : How do you change the timezone on NetBSD (FreeBSD also?)?</h3>

<p>
	Relink /etc/localtime.  This will correct the difference from
	GMT (or its trendy equivelant) to your local timezone.  In
	addition, the kernel needs to be modified to take the clock
	time in your CMOS into account.  Since most folks that run DOS
	prefer to have their clocks set to local time, the timezone
	hack was introduced to allow the kernel to adjust the CMOS
	clock time to GMT.  Once GMT has been computed, the
	/etc/localtime file can be referenced to determine the
	corrected local time.
<p>
	All generic kernels are built using the offset from California
	(why is anyone's guess:-) so just about everyone's clock will
	be off by their timezone offset from Berkeley.
<p>
	Also, it may pay to actually copy the correct timezone file
	rather than link it.  That way, you clock will be correct even
	in single users mode (when the /usr partition is not even
	mounted.  The disadvantage of this is that anytime the timezone
	file gets updated, you will need to make certain that the file
	is copied into the /etc directory.
<p>
<p>
<a name="3.6.2"><h3>3.6.2 : The translation between seconds-since-the-epoch and date differs by about 18 seconds between BSD and other Unixes when running ntp; why?</h3>

<p>
	See ntp FAQ. Apparently, the time correction takes leap seconds
	into account twice.  The timezone files in our system take the 
	leap seconds into account in the kernel, and nntp takes the
	same 18 leap seconds into account when syncing the time.
	Because of that, the time will appear to be off by eighteen
	seconds.  (Henning Schulzrinne)
<p>
<p>
<a name="3.7"><h3>3.7 : How can I implement CVS to track MY changes to the kernel source tree, yet still follow the -current development tree?</h3>

<p>
	I'll append the scripts I use, but be warned, they may bite you if 
	you are careless...
<p>
	The main reason I use cvs import is to handle updates from the 
	``vendor''.  The best way I've found is to import _exactly_ what 
	was shipped.  This means unconfigured, and I put config.h, etc, 
	in .cvsignore.  If I have to modify configure.in then obviously 
	I commit them :-)
<p>
<h2>#!/bin/sh
</h2>
<h2># This is a shell archive.
</h2>
<h2># remove everything above the "#!/bin/sh" line
</h2>
<h2># and feed to /bin/sh
</h2>
<h2># Use -c option to overwrite existing files
</h2>
<h2>#
</h2>
<h2># Contents: 
</h2>
<h2>#	README.import
</h2>
<h2>#	import.sh
</h2>
<h2>#	prune.sh
</h2>
<h2>#
</h2>
<h2># packed by: &lt<a href="mailto:sjg@zen.void.oz.au">sjg@zen.void.oz.au</a>&gt on Sat Jun 17 20:00:34 EST 1995
</h2>
<h2>#
</h2>
<h2>PATH=/bin:/usr/bin:/usr/ucb ; export PATH
</h2>
<h2>if test -f README.import -a x$1 != x-c ; then
</h2>
  echo shar: Will not over-write existing file \"README.import\"
<h2>else
</h2>
  echo shar: Extracting \"README.import\" \(2902 characters\)
  sed 's/^X//' &gtREADME.import &lt&lt '!EOF'
<h2>XThe following may be of use to others wanting to use CVS to merge
</h2>
<h2>XNetBSD sources with local changes but are not confident that they have
</h2>
<h2>Xinterpreted the documentation accurately.
</h2>
<h2>X
</h2>
<h2>XMuch thanks to Chris Demetriou (cgd) for taking the time to spell out
</h2>
<h2>Xthe steps he used when merging NetBSD sources without which I might
</h2>
<h2>Xnot have taken the plunge myself :-) The following is based on Chris'
</h2>
<h2>Xtips, though of course any errors are mine.
</h2>
<h2>X
</h2>
<h2>XOk.  My NetBSD sources are kept in usr.src, if NetBSD is all
</h2>
<h2>Xyou use CVS for you might want to simply call it src.
</h2>
<h2>X
</h2>
<h2>XI unpack tar files and/or sup into a directory /d2/current.
</h2>
<h2>X
</h2>
<h2>XTo import the entire tree I:
</h2>
<h2>X
</h2>
<h2>Xcd /d2/current/src
</h2>
<h2>X
</h2>
<h2>Xcvs import "-I! " -m "from netbsd-current as of 950508" usr.src NetBSD \
</h2>
<h2>XNetBSD-950508 &gt /tmp/cvs.out 2&gt&1
</h2>
<h2>X
</h2>
<h2>XWhere:
</h2>
<h2>Xusr.src		is the repository where the imported data goes (so set it
</h2>
<h2>X		according to your own needs), 
</h2>
<h2>XNetBSD		is a vendor tag.
</h2>
<h2>XNetBSD-950508	is a release tag (there can be multiple release tags given).
</h2>
<h2>X
</h2>
<h2>XI use "-I! " as otherise some files that you need (like
</h2>
<h2>Xbin/csh/USD.doc/csh.a) will be ignored..  The space after the ! is
</h2>
<h2>Xneeded.
</h2>
<h2>X
</h2>
<h2>XIt takes quite a while.  It is a good idea to save the output to a file.
</h2>
<h2>X
</h2>
<h2>XAt the end you may well get a message like:
</h2>
<h2>X
</h2>
<h2>X	cvs checkout -jNetBSD:yesterday -jNetBSD usr.src
</h2>
<h2>X
</h2>
<h2>XThis means there were some conflicts between your local sources and
</h2>
<h2>Xthe import.  So I do what it says - but not in my working tree.
</h2>
<h2>X
</h2>
<h2>Xcd /d2/tmp
</h2>
<h2>Xcvs checkout -jNetBSD:yesterday -jNetBSD usr.src &gt /tmp/merge.out 2&gt&1
</h2>
<h2>X
</h2>
<h2>XYou can then go find all the files with conflicts.
</h2>
<h2>XEither grep '^C' /tmp/merge.out or find usr.src -name '.#*' -print
</h2>
<h2>XGo edit them to resolce the conflicts.  This is usually obvious.
</h2>
<h2>X
</h2>
<h2>XWhen happy. 
</h2>
<h2>X
</h2>
<h2>Xcd /d2/tmp/usr.src
</h2>
<h2>Xcvs commit -m"merged local changes with NetBSD-950508"
</h2>
<h2>Xcd ..
</h2>
<h2>Xrm -rf usr.src
</h2>
<h2>X
</h2>
<h2>XOk. Now if you are brave you can:
</h2>
<h2>X
</h2>
<h2>Xcd /usr.src (or whereever your working sources are)
</h2>
<h2>Xcvs update
</h2>
<h2>X
</h2>
<h2>XFinally, you should occasionally make sure you remove old files.
</h2>
<h2>X
</h2>
<h2>XI use a script to do this.  It does a diff between files on the NetBSD
</h2>
<h2>Xbranch looking for the latest release tag (eg. NetBSD-950508). 
</h2>
<h2>XIf cvs diff remports that a file does not have that tag, it is because
</h2>
<h2>Xit was not present in the import (ie removed). 
</h2>
<h2>X
</h2>
<h2>XThe command sequence is:
</h2>
<h2>X
</h2>
<h2>Xcvs diff -s -r NetBSD -r NetBSD-950508 &gt /tmp/prune.out 2&gt&1
</h2>
<h2>X
</h2>
<h2>X# check that all went well...
</h2>
<h2>Xcat /tmp/prune.out | awk '/Diffing/ { dir=$NF } 
</h2>
<h2>X/NetBSD-/ { file=$NF; print dir "/" file }'  &gt /tmp/pruned
</h2>
<h2>X
</h2>
<h2>Xcat /tmp/pruned | xargs cvs tag -d NetBSD
</h2>
<h2>Xcat /tmp/pruned | xargs rm -f
</h2>
<h2>Xcat /tmp/pruned | xargs cvs delete
</h2>
<h2>X
</h2>
<h2>XNote that this is a slow process on a 486DX33!  So don't plan on
</h2>
<h2>Xmerging everything very often.  Folk who mainly hack the kernel can do
</h2>
<h2>Xsrc/sys more frequently.  The sequence is analogous eg.
</h2>
<h2>X
</h2>
<h2>Xcd /d2/current/src/sys
</h2>
<h2>X
</h2>
<h2>Xcvs import "-I! " -m "from netbsd-current as of 950508" usr.src/sys NetBSD \
</h2>
<h2>XNetBSD-950508 &gt /tmp/cvs.out 2&gt&1
</h2>
<h2>X
</h2>
<h2>Xetc.
</h2>
<h2>X
</h2>
<h2>XHope this helps.
</h2>
<h2>X
</h2>
<h2>X--sjg
</h2>
<h2>!EOF
</h2>
  if test 2902 -ne `wc -c &lt README.import`; then
    echo shar: \"README.import\" unpacked with wrong size!
  fi
<p>
<h2>fi
</h2>
<h2>if test -f import.sh -a x$1 != x-c ; then
</h2>
  echo shar: Will not over-write existing file \"import.sh\"
<h2>else
</h2>
  echo shar: Extracting \"import.sh\" \(290 characters\)
  sed 's/^X//' &gtimport.sh &lt&lt '!EOF'
<h2>X:
</h2>
<h2>Xtoday=`date '+%y%m%d'`
</h2>
<h2>X
</h2>
<h2>Xrep=${1:-usr.src}
</h2>
<h2>X
</h2>
<h2>X# -I! doesn't work, it needs a space after the !
</h2>
<h2>Xcvs import "-I! " -m "from netbsd-current as of $today" $rep NetBSD NetBSD-$today
</h2>
<h2>X
</h2>
<h2>X# cd somewhere
</h2>
<h2>X# cvs checkout -jNetBSD:yesterday -jNetBSD usr.src &gt /tmp/cvs.out 2&gt&1
</h2>
<h2>X# merge changes and commit
</h2>
<h2>!EOF
</h2>
  if test 290 -ne `wc -c &lt import.sh`; then
    echo shar: \"import.sh\" unpacked with wrong size!
  fi
  chmod +x import.sh
<h2>fi
</h2>
<h2>if test -f prune.sh -a x$1 != x-c ; then
</h2>
  echo shar: Will not over-write existing file \"prune.sh\"
<h2>else
</h2>
  echo shar: Extracting \"prune.sh\" \(491 characters\)
  sed 's/^X//' &gtprune.sh &lt&lt '!EOF'
<h2>X:
</h2>
<h2>Xthen=${1:-`date '+%y%m%d'`}
</h2>
<h2>XTF=/tmp/prune.$$
</h2>
<h2>XTF2=/tmp/prune2.$$
</h2>
<h2>X#S=-s
</h2>
<h2>XS=
</h2>
<h2>X
</h2>
<h2>Xcase `echo -n .` in -n*) N=; C="\c";; *) N=-n; C=;; esac
</h2>
<h2>X
</h2>
<h2>Xask () { echo $N "${2:-$1?} "$C; read $1; }
</h2>
<h2>X  
</h2>
<h2>Xcvs diff $S -r NetBSD -r NetBSD-$then &gt $TF 2&gt&1 || cat $TF &gt&2
</h2>
<h2>X
</h2>
<h2>Xcat $TF | awk '/Diffing/ { dir=$NF } /NetBSD-/ { file=$NF; print dir "/" file }' &gt $TF2
</h2>
<h2>X
</h2>
<h2>Xcat $TF2
</h2>
<h2>Xask proceed
</h2>
<h2>Xcase "$proceed" in
</h2>
<h2>X[yY]*)
</h2>
<h2>Xcat $TF2 | xargs cvs tag -d NetBSD
</h2>
<h2>Xcat $TF2 | xargs rm -f
</h2>
<h2>Xcat $TF2 | xargs cvs delete
</h2>
<h2>X;;
</h2>
<h2>Xesac
</h2>
<h2>Xrm -f $TF $TF2
</h2>
<h2>!EOF
</h2>
  if test 491 -ne `wc -c &lt prune.sh`; then
    echo shar: \"prune.sh\" unpacked with wrong size!
  fi
  chmod +x prune.sh
<h2>fi
</h2>
<h2>exit 0
</h2>
<p>
<p>
<p>
<a name="3.8"><h3>3.8 : Optional Op-codes for NetBSD, FreeBSD, and other systems.</h3>

<p>
	MNEMONIC	INSTRUCTION
<hr>
	AAC		Alter All Commands
	AAR		Alter At Random
	AB		Add Backwards
	AFVC		Add Finagle's Variable Constant
	AIB		Attack Innocent Bystander
	AWTT		Assemble With Tinker Toys
	BAC		Branch to Alpha Centauri
	BAF		Blow All Fuses
	BAFL		Branch And Flush
	BBIL		Branch on Blown Indicator Light
	BBT		Branch on Binary Tree
	BBW		Branch Both Ways
	BCF		Branch and Catch Fire
	BCIL		Branch Creating Infinite Loop
	BDC		Break Down and Cry
	BDT		Burn Data Tree
	BEW		Branch Either Way
	BF		Belch Fire
	BH		Branch and Hang
	BOB		Branch On Bug
	BOD		Beat On the Disk
	BOI		Bite Operator Immediately
	BPDI		Be Polite, Don't Interrupt
	BPO		Branch on Power Off
	BRSS		Branch on Sunspot
	BST		Backspace and Stretch Tape
	BW		Branch on Whim
	CDC		Close Disk Cover
	CDIOOAZ		Calm Down, It's Only Ones and Zeros
	CEMU		Close Eyes and Monkey with User space
	CH		Create Havoc
	CLBR		Clobber Register
	CM		Circulate Memory
	CML		Compute Meaning of Life
	COLB		Crash for Operators Lunch Break
	CPPR		Crumple Printer Paper and Rip
	CRASH		Continue Running After Stop or Halt
	CRB		Crash and Burn
	CRN		Convert to Roman Numerals
	CS		Crash System
	CSL		Curse and Swear Loudly
	CU		Convert to Unary
	CVG		Convert to Garbage
	CWOM		Complement Write-Only Memory
	CZZC		Convert Zone to Zip Code
	DBZ		Divide By Zero
	DC		Divide and Conquer
	DMNS		Do what I Mean, Not what I Say
	DMPK		Destroy Memory Protect Key
	DPMI		Declare Programmer Mentally Incompetent
	DPR		Destroy Program
	DTC		Destroy This Command
	DTE		Decrement Telephone Extension
	DTVFL		Destroy Third Variable From Left
	DW		Destroy World
	ECO		Electrocute Computer Operator
	EFD		Emulate Frisbee Using Disk Pack
	EIAO		Execute In Any Order
	EIOC		Execute Invalid Opcode
	ENF		Emit Noxious Fumes
	EO		Execute Operator
	EROS		Erase Read-Only Storage
	FLI		Flash Lights Impressively
	FSM		Fold, Spindle and Mutilate
	GCAR		Get Correct Answer Regardless
	GDP		Grin Defiantly at Programmer
	GFM		Go Forth and Multiply
	IAE		Ignore All Exceptions
	IBP		Insert Bug and Proceed
	ISC		Insert Sarcastic Comments
	JTZ		Jump to Twilight Zone
	LCC		Load and Clear Core
	MAZ		Multiply Answer by Zero
	MLR		Move and Lose Record
	MWAG		Make Wild-Assed Guess
	MWT		Malfunction Without Telling
	OML		Obey Murphy's Laws
	PD		Play Dead
	PDSK		Punch Disk
	PEHC		Punch Extra Holes on Cards
	POCL		Punch Out Console Lights
	POPI		Punch Operator Immediately
	RA		Randomize Answer
	RASC		Read And Shred Card
	RCB		Read Command Backwards
	RD		Reverse Directions
	RDA		Refuse to Disclose Answer
	RDB		Run Disk Backwards
	RIRG		Read Inter-Record Gap
	RLI		Rotate Left Indefinitely
	ROC		Randomize Opcodes
	RPB		Read, Print and Blush
	RPM		Read Programmer's Mind
	RSD		On Read Error Self-Destruct
	RWCR		Rewind Card Reader
	SAI		Skip All Instructions
	SAS		Sit and Spin
	SCCA		Short Circuit on Correct Answer
	SFH		Set Flags to Half mast
	SLMTU=x		SLIP MTU size
	SLP		Sharpen Light Pen
	SPS		Set Panel Switches
	SPSW		Scramble Program Status Word
	SQPC		Sit Quietly and Play with your Crayons
	SRDR		Shift Right Double Ridiculous
	STA		Store Anywhere
	TARC		Take Arithmetic Review Course
	TPF		Turn Power Off
	TPN		Turn Power On
	UCB		Uncouple CPU and Branch
	ULDA		Unload Accumulator
	UP		Understand Program
	WBT		Water Binary Tree
	WHFO		Wait Until Hell Freezes Over
	WI		Write Illegibly
	WSWW		Work in Strange and Wondrous Ways
	XSP		Execute Systems Programmer
	ZAR		Zero Any Register
<p>
	If you have gotten this far, you deserved some humor.
<p>
<a name="section_4"><h2>Section 4.	(System Additions)
</h2>
<p>
<a name="4.0"><h3>4.0 : Introduction</h3>

<p>
	If you have written some addition to the kernel or some other 
	part of the system, or know of one that feel should be mentioned, 
	send mail to Dave Burgess (<a href="mailto:burgess@cynjut.neonramp.com">burgess@cynjut.neonramp.com</a>) with all 
	the relevant information, and it will be added for the next 
	release.
<p>
<a name="4.1"><h3>4.1 : Common (sort of) Kernel-related problems</h3>

<p>
<a name="4.1.1"><h3>4.1.1 : Sometimes I have trouble with my system resetting the terminal to seven bit mode. Isn't BSD eight bit clean?</h3>

<p>
	The answer is "sort of".  The problem seems to come from the
	fact that the &ltsgtty.h&gt interface is not guaranteed to be eight
	bit clean.  The &lttermios.h&gt interface is better, and should be
	eight bit clean in all cases.  If you find an application that
	uses the &ltsgtty.h&gt interface, you should either contact the
	author and try and get them to use the termios interface or port
	the code yourself.
<p>
	See section 5 for more Terminfo/Termlib information, as well as
	a discussion of the new curses library that is available.
<p>
<p>
<a name="4.1.2"><h3>4.1.2 : How do you implement quotas on Net/2 derived BSD systems?</h3>

<p>
	From: <a href="mailto:tinguely@plains.NoDak.edu">tinguely@plains.NoDak.edu</a> (Mark Tinguely)
<p>
 	maybe you did not complete the setup, here is a step-by-step 
 	instructions to get them to work:
<p>
	1)  make a kernel with "options QUOTA" installed
<p>
	2)  edit /etc/fstab and include the kinds of quotas you want, 
	    below I used "userquota", you could also add "groupquota".
<p>
	/dev/wd0h		/usr		ufs	rw,userquota 1 2
<p>
	3)  for each filesystem that is in /etc/fstab that uses quota,
	    create the file "quota.user" (and "quota.group if appropriate).
	    Above I have user quotas in the /usr filesystem, so I would:
<p>
	    # touch /usr/quota.user
<p>
	4)  scan filesystem for files ownership (and/or group ownership).
<p>
	    # quotacheck -a
<p>
	5)  now you can add individual quota limits, if you want to add 
	    the same quotas to the many people, then make a template and 
	    replicate the template.  If they change for each user, then 
	    edit seperately.
<p>
	    # edquota tinguely
<p>
	 (an editor is kicked up and says something like:
<p>
	Quotas for user tinguely:
	  /usr: blocks in use: 11876, limits (soft = 0, hard = 0)
	        inodes in use: 891, limits (soft = 0, hard = 0)
<p>
	 a limit of 0 means "unlimited".  Change these to the appropriate 
	 number of blocks.  A soft limit generates a warning, and can be 
	 exceed for period of time (7 days?), after which time a soft limit 
	 is treated like a hard limit.  A hard limit denies new writes.
<p>
 	to replicate a template (for this example let us assume "tinguely" 
 	is the template):
<p>
	    # edquota -p tinguely user1 user2 user3 ... userN
<p>
	6)  turn quotas on (usually done in the /etc/rc file, but turn it 
	    on manually so you do not have to reboot right now:
<p>
	    # quotaon
<p>
	that should take care of setting up quotas.  You can look at the 
	status of use of files with repquota, the -a option lists all 
	filesystems with quotas.
<p>
<a name="4.1.3"><h3>4.1.3 : What are the correct permissions for the /tmp, /usr/tmp, and /var/tmp directories?</h3>

<p>
	All of these directories should be owned by bin, group bin, mode
	1777.  This turns on the sticky bit, so that the only people who
	can remove a file from these directories are the owner and root.
<p>
<p>
<a name="4.2"><h3>4.2 : Available kernel add-ons</h3>

<p>
<a name="4.2.1"><h3>4.2.1 : Loadable Kernel Modules</h3>

<p>
	Several strides have been made in the past to reduce the amount
	of 'cruft' that gets into the default kernel.  One way is to
	make the kernel so hard to use that practically no one but a
	person with precisely the 'right' hardware would be able to use
	the system
<p>
	Another way is to implement something called 'LKM's or "Loadable
	Kernel Modules".  These are run-time extensions to the system
	that allow the distribution kernel to not include things that
	people might want, but not nxbeed until they get the system up
	and running.  While the security concerns of LKMs are valid,
	their implementation is such a win that the research to
	implement them is well worth it.
<p>
	It was really _very_ simple to make these, so this is nothing
	spectacular.  Just something to keep from having to recompile just to
	add msdosfs support to a machine.  ;)
<p>
	To try this:
<p>
		1)  get <a href="ftp://ftp.flame.org/pub/netbsd/lkm.tar.gz">ftp://ftp.flame.org/pub/netbsd/lkm.tar.gz</a>
<br>
<p>
		2)  untar it somewhere.  It will create a subdirectory 
<br>
		    called lkm and all extracted files will go in it. 
<br>
		    (I use /usr/src, but that may be a bad place)
<br>
<p>
		3)  follow the directions in lkm/README
<br>
<p>
	Please mail suggestions, and (especially) fixes and more 
	modules to Michael Graff &lt<a href="mailto:explorer@flame.org">explorer@flame.org</a>&gt.  Once it is 
	clean enough, I'll send it in as a send-pr and see what 
	happens.  :)
<p>
	One question which still needs to be resolved is where should 
	these *.o LKM's be installed?  The directory '/usr/lkm' would 
	be a good idea, with the output (modload's -o option) in 
	/var/run/lkm or something like that.
<p>
<p>
<a name="4.3"><h3>4.3 : Other program building type problems.</h3>

<p>
<a name="4.3.1"><h3>4.3.1 : I am building a program that requires access to the crypt library. Either I have it and it isn't getting copied into the executable, or I don't have it; why?</h3>

<p>
	This is actually two separate questions, but they are close enough
	to the same that I can answer them here.  The first problem that
	anyone building a 'crypt' aware program needs to remember is that
	the crypt library is a separate library and requires a '-lcrypt' 
	to be added at the end of the link line.  The other half of the 
	problem is the 'US Non Export' policy for DES encryption.  There 
	are several good sources (about one per country) for non-US
	crypt libraries.  IF you are outside the US and need one, look 
	around on some of the NetBSD/FreeBSD/OpenBSD FTP sites in the 
	'local area'.  By the way. I don't have any good URLs for Mars,
	so you might be out of luck.
<p>
	OpenBSD doesn't appear to have this problem, since it is a
	"Canadian" product rather than an American one.  Thanks to this,
	there is no restriction on exporting (or importing) the crypt
	library, so it is no longer needed.  With version 2.1 of
	OpenBSD, the crypt library doesn't even exist; it is included in
	the standard library for the system.  
<p>
<p>
<a name="4.3.2"><h3>4.3.2 : I am having trouble with long file names in my libraries. It seems like there is a 16 character limit in the library somewhere.</h3>

<p>
	There is a 16 character limit, sort of.  The most likely symptom
	for this is that the header for the file _after_ the long file
	name will be mangled.  It turns out that there is a "T" option
	that may not be documented very well that provides the correct
	functionality for long filename support in ar.
<p>
<a name="4.3.3"><h3>4.3.3 : I'm getting annoyed with having this "conflicting types for `sys_errlist'" problem show up nearly every time I build a program. What do I need to do?</h3>

<p>
	Remove the sys_errlist reference in the source you're compiling.
	You can either delete it (there are advantages to just deleting
	it) or you can wrap a "#ifdef __NetBSD__/#endif" (obviously only
	if you are running NetBSD, FreeBSD and OpenBSD have a similar
	mechanism) pair around it.  There are religious issues 
	regarding the use of sys_errlist that involve either system 
	security (most declaration allow the error list to be written 
	to) or system internals (there's already a well-defined 
	library call that performs the sys_errlist lookup).  An 
	anonymous example is included below:
<p>
	Most stupid packages such as GCC expects extern 
	(char*)sys_errlist[] whereas 4.4Lite based systems have more 
	secure extern const (char*) const sys_errlist[] declaration.  
	Just kick that "cccp.c" in the butt and modify the suspicious 
	line.  Hard to believe GCC still doesn't do that.  You're going 
	to have to do lots of this modification as you encounter more of 
	such programs.
<p>
<p>
<a name="4.4"><h3>4.4 : System Administration Questions</h3>

<a name="4.4.1"><h3>4.4.1 : Where can I get good books about NetBSD or FreeBSD?</h3>

<p>
	There is a set of books produced by O'Reilly and associates that
	describe in some detail the 4.4 BSD system.  The six volume set
	includes a book on system administration which directly pertains
	to the operation and management of NetBSD and FreeBSD.  Also see
	the <a href="#section_1">Section 1</a> for a good list of the books that folks use for

	the system.  There is also a good list of books (specifically
	about writing device drivers) in the 'pcvt' distributions in
	NetBSD, FreeBSD, and OpenBSD.  It is in a file called
	'Bibliography' and contains the pcvt author's list of device
	driver books.
<p>
<p>
<a name="4.4.2"><h3>4.4.2 : I am concerned about system security. What should I do to protect my system from net attacks?</h3>

<p>
	With the release of the System Administrators Tool for Analyzing
	Networks (SATAN), network security has suddenly become a serious
	issue.  There are a few things you can do.
<p>
	--  Get, read, and understand the CERT advisories
	--  Get SATAN and run it against your own system or network.
	Fix whatever it finds as holes
	--  Get courtney, a program that was written to recognize a
	SATAN attack pattern and notify you whenever someone tries to
	probe your system
	--  Log all failed login attempts (see below)
<p>
<p>
<a name="4.4.3"><h3>4.4.3 : How can I log failed login attempts?</h3>

<p>
	Failed logins are logged (without the attempted login name) at
	LOG_NOTICE priority.  Failed logins are logged _with_ the 
	attempted login name at LOG_NOTICE priority, and with the 
	LOG_AUTHPRIV facility.
<p>
	If you set up some lines in syslog.conf like:
<p>
	# The authpriv log file should be restricted access;
	# these messages shouldn't go to terminals or publically-readable files.
	authpriv.*                                      /var/log/secure
<p>
	Make absolutely sure, though, that it's really what you want:  
	logging actual supplied logins is often a great way to offer 
	cleartext passwords to an adversary...
<p>
	Which is why you have 
	    authpriv.*			/var/log/secure
	...,authpriv.none,...		/var/log/messages
<p>
	So none of the authpriv messages (those that actually display 
	the failed login) goto /var/log/messages, but they do go to
	/var/log/secure (which you have with 600 perms.)  Bear in mind
	that this still does not prevent someone that has hacked into
	your system with root privs from reading them.  See 4.4.2 for
	more information.
<p>
<p>
<a name="4.4.4"><h3>4.4.4 : Can I use a Concatenated Filesystem with NetBSD?</h3>

<p>
	The "ccd" device (in -current) provides the capability to span a
	file system across multiple hard drive partitions.  Jason Thorpe
	&lt<a href="mailto:thorpej@nas.nasa.gov">thorpej@nas.nasa.gov</a>&gt has been working on it; if you try it and 
	have problems, here are the debug instructions:
<p>
<p>
<a name="4.4.4.1"><h3>4.4.4.1 : Why, when I type "ccdconfig ccd0 16 none /dev/wd0a &gt /dev/wd1a", do I get back "ccdconfig: ioctl (CCDIOCSET): /dev/ccd0d: Device not configured"?</h3>

<p>
	Considering that the error comes froom the ioctl (rather than the 
	open) I'm tempted to say it comes from either the vn_open() or 
	subsequent VOP_*() operations on the components.  If you compile 
	your kernel with `options CCDDEBUG' and set the ccddebug variable 
	(near the top of ccd.c or with the ddb) to 0x03, you should be able 
	to see where it fails.  If you could send me that information, 
	that would be most helpful.
<p>
	Might be the same problem I had; it turns out that the partitions 
	that you build your concatenated disk device from must not be 
	marked "unused" in their native disks' labels.  This "device not 
	configured" is the way ccdconfig informs you of this condition...  :-)
<p>
	Actually, I guess this indicates a need for a special "ccd 
	component" type entry for disklabel?  Or should the partition 
	simply be marked as a "raw" partition, sharing this type with 
	database log partitions etc?
<p>
	'Der Mouse' (<a href="mailto:mouse@collatz.mcrcim.mcgill.edu">mouse@collatz.mcrcim.mcgill.edu</a>) adds:
<p>
	Personally, I think ccd has no business looking at those 
	partition types.  But I definitely think a special ccd-component 
	partition type is _not_ the way to go; if nothing else, it makes 
	life hard for people running ports using non-NetBSD disk 
	partitions.  For example, under NetBSD/sparc on a disk with 
	a SunOS label, there are no partition types in the label, so 
	it would be impossible to use a ccd that insisted on a special 
	partition type on such a disk.
<p>
<p>
<a name="4.4.5"><h3>4.4.5 : I am really new to Unix System Administration. I need some real basic help.</h3>

<p>
<a name="4.4.5.1"><h3>4.4.5.1 : What is the System Administrator's user name?</h3>

<a name="4.4.5.2"><h3>4.4.5.2 : I can't log in as 'su'. What does that message mean when I log in as root.</h3>

<p>
	Both of these indicate a newness to Unix System Administration
	that many of the core team members don't even remember.  The
	sysadmin user-id is "root", although you typically don't want to 
	log in directly as root.  A better solution is to log in as root 
	once, create a user-id and password for yourself.  Once you are 
	done with that, you need to modify the /etc/groups file.  This
	identifies the users that are allowed to be part of particular
	groups.  Add your UID to the "wheel" group and log off.  With a
	real UID and password and your UID identified as a "wheel"
	member. you will be able to use the 'su' command to log in as
	yourself and then "switch users" to root.  That, by the way, is
	also what that cryptic message "Don't log in as 'root', use 'su'
	instead." means.
<p>
<a name="4.4.5.3"><h3>4.4.5.3 : Are there any books I can 'bootstrap' myself with?</h3>

<p>
	Yes.  Here are a couple:
<p>
<p>
	(1) Nemeth, Snyder, and Seebass, "Unix System Administration i
		Handbook"
<br>
<p>
	(2) Horspool, "The Berkeley Unix Environment"
<p>
<p>
<a name="4.4.5.4"><h3>4.4.5.4 : How about some code examples?</h3>

<p>
<p>
	<a href="ftp://ftp.sterling.com:/usenet/alt.sources/">ftp://ftp.sterling.com:/usenet/alt.sources/</a>        
	<a href="ftp://ftp.sterling.com:/usenet/comp.sources/misc">ftp://ftp.sterling.com:/usenet/comp.sources/misc</a>
	<a href="ftp://ftp.sterling.com:/usenet/comp.sources.unix">ftp://ftp.sterling.com:/usenet/comp.sources.unix</a>
<p>
	<a href="ftp://wuarchive.wustl.edu:/usenet/alt.sources/articles/">ftp://wuarchive.wustl.edu:/usenet/alt.sources/articles/</a>
 	                          /usenet/comp.sources.misc/
 	                          /usenet/comp.sources.unix/
<p>
	<a href="ftp://src.doc.ic.ac.uk:/usenet/alt.sources/articles/">ftp://src.doc.ic.ac.uk:/usenet/alt.sources/articles/</a>
 	                       /usenet/comp.sources.misc/
 	                       /usenet/comp.sources.unix/
<p>
<p>
<a name="4.5.6"><h3>4.5.6 : How do I change the default shell for a user?</h3>

<p>
	There are three ways, listed here from most difficult to least
	difficult:
<p>
	1)  Use 'vi' to edit the /etc/master.passwd.  Once you have
	changed the entry you want modified, run the program 
	"pwd_mkdb -p /etc/master.passwd".  This will rebuild the
	password database and update your /etc/passwd file.  Cd to the
	/var/yp directory and run a "make" to update your 'NIS' database
	(important only if you are using NIS).
<p>
	2)  Use the 'vipw' program and make your change.  This
	automatically rebuilds the password database and the /etc/passwd
	file.  You still need to update the 'NIS' database on your own.
<p>
	3)  Use 'chpass', 'chfn', or 'chsh' programs to update the
	appropriate entry in the password database.  These have the
	advantage of update the NIS stuff automatically.
<p>
<p>
<a name="4.5"><h3>4.5 : Daemon questions</h3>

<a name="4.5.1"><h3>4.5.1 : I'd like to use amd to mount a file system (/dev/sd0f aka /usr/local) on another machine as "/usr/local". What's the magic?</h3>

<p>
	There are several ways to achieve 'amd nirvana'.  Each of these
	elements below is an important consideration for getting amd to
	work correctly.
<p>
	The "-" means use these as defaults, so you need an entry without 
	a "-".  Also, I think one "-..." overrides the previous one 
	completely.
<p>
	As a start, you can use the following in your amd.project file:
<p>
	usr/local	opts:=rw;type:=nfs;rhost:=hostname;rfs:=/usr/local
<p>
	Then run "amd /usr/local /your/map/name -type:=direct".
<p>
	One word of warning, however.  In NetBSD 1.0, I couldn't get direct
	mount points to work for some reason.  I don't know if this has been
	fixed or not.
<p>
	If you are using a NetBSD 1.0 (or earlier) system, make /usr/local 
	a real symbolic link into an automount filesystem.
<p>
	Another instance of the amd.project file might look like this:
	/defaults type:=nfs;opts:=rw,soft,intr,grpid
	local	\
		host==hostname;type:=link;fs=/usr/local ||\
<br>
		host!=hostname;rhost:=hostname;rfs:=/usr/local
<br>
<p>
	You amd.master file might look like this:
	/project amd.project
<p>
	Here's another example which auto-mounts /usr/src from another 
	machine:
<p>
	grizu% ls -lad /usr/src
	lrwxr-xr-x  1 root  wheel  29 Dec 30 15:33 \ (split by ed.)
		/usr/src -&gt /tmp_mnt/mounts/src10/usr/src
<br>
<p>
	grizu% cat /etc/amd/master
	/net            /etc/amd/net
	/tmp_mnt/mounts /etc/amd/src
<p>
	grizu% cat /etc/amd/net
	/defaults       type:=host;fs:=${autodir}/${rhost};rhost:=${key}
	*               opts:=ro,soft,intr
<p>
	grizu% cat /etc/amd/src
	/defaults       type:=host;fs:=${autodir}/${rhost};
	src10           opts:=rw,soft,intr;rhost:=rfhu1001
<p>
	grizu% grep ^amd /etc/netstart
	amd=YES
	amd_dir=/tmp_mnt                # AMD's mount directory
	amd_master=/etc/amd/master      # AMD 'master' map
<p>
	grizu% ls -la /tmp_mnt
	total 9
	drwxr-xr-x   5 root  wheel   512 Jan  3 12:09 .
	drwxr-xr-x  26 root  wheel  1024 Jan  3 12:09 ..
	dr-xr-xr-x   3 root  wheel   512 Nov 20 19:29 ftp.uni-regensburg.de
	dr-xr-xr-x   2 root  wheel   512 Jan  4 10:43 mounts
	dr-xr-xr-x   4 root  wheel   512 Dec 11 08:18 rfhu1001
<p>
	grizu% ls -la /tmp_mnt/mounts
	total 3
	dr-xr-xr-x  2 root  wheel  512 Jan  4 10:43 .
	drwxr-xr-x  5 root  wheel  512 Jan  3 12:09 ..
<p>
	I guess that's all. rfhu1001 is the NFS server, grizu the client.
<p>
<p>
<a name="4.5.2"><h3>4.5.2 : I am having trouble with my nameserver refusing to accept 'nslookup's from my SunOS machine after I installed the resolver fix. The exact error message is "*** Can't find server name for address 194.100.46.2: Query refused". Can you help?</h3>

<p>
  	From the README file in the BIND distribution:
<p>
	    Versions of NSLOOKUP up through BIND 4.8.3's used IQUERY to 
	    ask the local server for information about the server's own 
	    name.  I assume that this was done in a "what the heck, 
	    nothing uses these, how can we contrive a need?" sort of 
	    spirit.  I removed this code as of BIND 4.9's NSLOOKUP and 
	    had it use the standard gethostbyaddr() mechanisms (which 
	    depend on normal queries of PTR data).  Disabling INVQ and 
	    putting "options fake-iquery" in the boot file will cause 
	    IQUERY to be answered bogusly but in a way that old nslookup 
	    programs won't trip on.  INVQ is disabled by default in 
	    conf/options.h.
<p>
	So, your options are:
<p>
	    -   Add "options fake-iquery" to named.boot and restart the 
		server
<br>
<p>
	    -   Replace your old, broken nslookup with the one in the 
	        4.9.3 BIND distribution.
<p>
	    --  Enable INVQ in conf/options.h, then rebuild and re-install 
		named.  This latter option isn't guaranteed to work.  If 
<br>
		you point an old version of nslookup at a server, and the 
<br>
		server either is not authoritative for a zone containing 
<br>
		the A RR matching the address you are sending the query to, 
<br>
		or if this A RR is not in it's cache, then nslookup will 
<br>
		still fail even if the server has the INVQ option turned on.
<br>
<p>
<p>
<a name="4.5.3"><h3>4.5.3 : Are there any alternatives to 'NIS' available for NetBSD, et al.?</h3>

<p>
	Yes, there is 'hesiod' which provides (according to Ted Lemon 
	&lt<a href="mailto:mellon@fugue.com">mellon@fugue.com</a>&gti)another way of distributing databases like
	/etc/passwd, /etc/services, /etc/groups, and so on.  It uses
	DNS, which is (IMHO) slightly more robust and less easily
	subverted than NIS, and doesn't claim to provide authentication
	(authentication is Kerberos's job), so as part of a complete
	system, I think it's a much better solution.  It certainly has 
	a smaller installed base than NIS, though.
<p>
	There is also Kerberos IV, which provides similar functionality.
	It is now fully integrated into the all of the *BSD systems and
	works well for network wide authentication.
<p>
<p>
<a name="4.6"><h3>4.6 : Adding new and removing old users.</h3>

<a name="4.6.1"><h3>4.6.1 : Where can I FTP the 'adduser' program?</h3>

<p>
	There is one you can FTP (see the URL below).  You will need to
	be able to use 'vipw' to make it work, but that shouldn't be a
	big problem for most people.
<p>
	    <a href="ftp://ftp.quick.com.au/pub/unix/adduser.sh">ftp://ftp.quick.com.au/pub/unix/adduser.sh</a>
<p>
	The man page is there too..
<p>
	    <a href="ftp://ftp.quick.com.au/pub/unix/adduser.8">ftp://ftp.quick.com.au/pub/unix/adduser.8</a>
<p>
<p>
<a name="4.6.2"><h3>4.6.2 : Where can I get a 'rmuser' script?</h3>

<p>
	There is a Perl script called 'removeuser' which should be
	available from one of the 'CPAN' sites.  As soon as someone has
	a URL, let me know.
<p>
	There is also a FreeBSD 2.2 'rmuser' program which does
	everything the remove program does, plus removes crontab and at
	command entries.
<p>
<a name="section_5"><h2>Section 5.	(Kernel Replacements)
</h2>
<p>
<a name="5.0"><h3>5.0 : Introduction</h3>

<p>
<a name="5.1"><h3>5.1 : A replacement curses program/library.</h3>

<p>
	It is generally accepted that the NetBSD curses can be easily
	replaced by the ncurses package.  It is more complete and offers
	much better support for shared libraries and other advanced
	features.  The current (early 1995 version) is 1.8.5 and is
	available from <a href="ftp://ftp.netcom.com:/pub/zm/zmbenhal/ncurses/">ftp://ftp.netcom.com:/pub/zm/zmbenhal/ncurses/</a>
<p>
	OpenBSD comes with a different curses package, called XSI
	curses and uses the termlib library for user code.  The original
	curses code is still available in the &ltocurses.h&gt include file
	and the -locurses library.  The code in the termlib library is
	smart enough to recognize and handle both termcap and termlib
	database parsing.
<p>
	(Ed.Note)  The X/Open curses standard is becoming the de facto
	standard (or perhaps imposed standard) for curses under Unix
	systems.  XSI implements this X/Open curses completely, and is
	being used by lots of folks.  FreeBSD and NetBSD will either
	develop their own compatible version or will use XSI like
	OpenBSD does.
<p>
<p>
<a name="5.2"><h3>5.2 : Floppy Disk problems.</h3>

<p>
<a name="5.2.1"><h3>5.2.1 : How do I get a bootable floppy?</h3>

<p>
	Several ways, ranging from brain-dead-but-works to simplest.  
	Classification into categories is left to the reader (is there 
	really a difference between 'brain-dead' and 'simple'?:')
<p>
	1) rawrite (or dd) dist.fs (or fixit.fs) to a disk,
	   mount it, cd to the mount point, and execute:
<p>
		rm -rf .
<br>
<p>
	   you now have a bootable floppy!;^}
<p>
	2) Take your existing dist.fs or fixit.fs boot disk and
	   diskcopy it on a DOS machine.  Mount and rm as in 1)
	   above.  Again, you have a bootable floppy!;^}
<p>
	3) Run disklabel on the floppy, e.g.:
<p>
		disklabel -w -r fd0a floppy5
<br>
<p>
	   where 'floppy5' is a 'name' for an entry in the /etc/disktab
	   file.  You'll get a couple of ioctl errors because writing a 
	   label to a floppy isn't supported (yet?), but the boot blocks 
	   have indeed been written.
<p>
	4) Write the boot blocks to the floppy:
<p>
		cat /usr/mdec/fdboot /usr/mdec/bootfd | dd of=/dev/rfd0a
<br>
<p>
	   or, more simply:
<p>
		cat /usr/mdec/fdboot /usr/mdec/bootfd &gt /dev/rfd0a
<br>
<p>
	Methods 3) and 4) require you to run newfs on the floppy, e.g.:
<p>
	newfs /dev/rfd0a floppy5
<p>
	If you have a floppy that was originally bootable, but the boot
	blocks were somehow damaged, you can use method 3) or 4) to
	restore boot-ability (do _NOT_ run newfs).  You _could_, through
	the convolutions of copying a floppy whose boot blocks are damaged
	to a temporary location and then re-copying to a bootable floppy,
	use method 1) or 2) (if you really want to!;^})
<p>
	5)  If the disk is already newfs'ed and is otherwise ready to use,
	disklabel will write the boot blocks on the disk.  Read the man page
	for disklabel.
<p>
<p>
<a name="5.2.2"><h3>5.2.2 : How do I maximize the space on a mountable floppy disk.</h3>

<p>
	As you all know, when you are working with a floppy, it is usually
	more important that the floppy have a lot of room, rather than a
	lot of other 'stuff'.  Here is the magic incantation that will
	maximize the amount of free space on the disk.
<p>
		newfs -Tfloppy[35] -i[4096 | 8192] -c 80 /dev/fd[0|1]a
<br>
<p>
	This leaves the disk with fewer inodes and only one cylinder group.
<p>
<p>
<a name="5.3"><h3>5.3 : Character Device Driver info</h3>

<p>
	These devices are also often referred to as character devices.
<p>
<a name="5.3.1"><h3>5.3.1 : Printers</h3>

<p>
	NetBSD and FreeBSD both include both an interrupt and
	non-interrupt driven parallel driver in their stock 
	manifestations.
<p>
	It is possible to connect a serial printer to either.  This brief
	tutorial is provided by Daryl Berryhill 
	(<a href="mailto:djberry2@b25info.b25.ingr.com">djberry2@b25info.b25.ingr.com</a>)
<p>
	The way I got my printer to work.
<p>
	1) connect a 25 pin to 9 pin null modem cable to printer and 
	   computer.
	2) set printer to 9600 baud, 7 data bits, even parity.
	3) configure /dev/com1 (DOS COM2) port the same way as the printer
	4) add a line to /etc/printcap that says:
	       lp|local line printer:\
		  :lp=/dev/com2:wq:sd=/var/spool/lpd:lf=/var/log/lpd-errs:\
<br>
		  :br#9600
<br>
	5) type "lpr &ltadd filename here&gt"
	6) type "lpd"
	   and it should start printing.
<p>
	An obvious point, but make sure that you do NOT start a getty on 
	on the com port.  Check the /etc/ttys file and make sure that 
	the com port you select is not active.
<p>
	There have been many reports in the past of people not being able 
	to get their parallel port printer working.  One of the problems
	seems to be cables.  Another problem may be with the hardware.  
	A seemingly stupid suggestion is to replace your printer card with
	the cheapest parallel port card you can find.  I am using a $10
	single parallel, two serial port card that I got from Altex.  
	Works great.
<p>
	In addition, there are people that want to set up multiple printer
	queues using the BSD queuing mechanism.  Here is a brief tutorial:
<p>
	Lpf is mainly intended for processing text and nroffed output...it 
	isn't anything clean...it will do certain games that will mess up 
	PCL output.
<p>
	If you're producing straight PCL or PostScript (assuming your LJ 
	takes it), then you want to print directly to the printer w/o any 
	processing.  
<p>
	What you really want is a "physical" queue that does no processing, 
	and several logical queues that map back to the physical queue and 
	do processing...or one "smart" queue that does file content 
	recognition and then maps to the raw queue.
<p>
	I do something like this for my DeskJet.  There is one raw queue 
	and several logical queues (some postscript that do different 
	resolutions and color depth, some text that do various formatting, 
	etc).  When I get the time I'll be trying to set up a "smarter" 
	queue using aps and maybe some bits from flexfax.
<p>
	To map logical to physical queues either use a filter that pipes 
	back into lpr -P&ltrawqueue&gt itself, or just point it at the "raw" 
	queue using something like:
<p>
	textlp|Text Printing:\
	    :lp=/dev/null:\
	    :if=/usr/libexec/lpr/lpf:\
	    :rm=localhost:\
	    :rp=lj.raw:
<p>
	And other entries as needed, you get the idea...to use an output 
	filter instead of the rm/rp approach (more efficent), you can get 
	away with something like:
<p>
	    :of=/usr/local/bin/printraw:
<p>
	where /usr/local/bin/printraw looks like this:
<p>
	#!/bin/sh
	cat | lpr -h -Plj.raw
<p>
<p>
<a name="5.3.2"><h3>5.3.2 : Terminals/Keyboards</h3>

<p>
	Terminals are relatively simple to add.  It involves making sure
	the /etc/ttys file identifies the com port (com0, com00, or tty00 
	depending on your configuration) as an active port and a getty is
	running.  The man page for ttys and getty help explain this.
<p>
	Many people report that there are sometimes problems running some
	programs on a remote terminal.  There are some known bugs in the
	terminal handler where the parity and bits per character are 
	concerned.  They are being worked on.
<p>
<p>
<a name="5.3.3"><h3>5.3.3 : Modems/FAX Modems</h3>

<p>
<a name="5.3.3.1"><h3>5.3.3.1 : How do I add a modem to *BSD:</h3>

<p>
<a name="5.3.3.4"><h3>5.3.3.4 : Adding a Dial-in/Dial-out FAX to NetBSD or FreeBSD.</h3>

<p>
	First, here is the known working configuration for these 
	instructions:
<p>
	  - HylaFAX 3.0 beta 100. 
	  - Zoom VFX V.32bis Faxmodem; 
	  - Rockwell datapump.
<p>
	1: Start faxq from rc.local, no options on the command line.
<p>
	Add a line to your /etc/rc.local which starts up the faxq
	program.  Do not include any options on the command line.
<p>
	2: Stary faxgetty from init, i.e. a line in /etc/ttys.
<p>
	I use the non modem control device; however, it's nonstandard
	hardware and I've modified the driver to always return sighup
	on lost carrier to solve some sticky problems with non modem
	control devices never getting SIGHUP's.
<p>
	Basically, I just did as the directions said to do. I ran 
	'faxaddmodem' script to configure the type of modem. I did 
	have to simplify some lines in the script (the ones executed 
	in a subshell) since I think my version of bash doesn't handle 
	subshells correctly.
<p>
	RTFM and you should be OK unless your modem is brain dead and
	stupid, not too unlikely to given the current state of Fax
	modems... B^(.
<p>
<p>
<a name="5.3.4"><h3>5.3.4 : What is the trick for getting Kermit to work with rz and sz?</h3>

<p>
	Add these lines to your .kermrc file.  They should do the trick.
<p>
	define sz !sz \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 &lt \v(line) &gt \v(line)
	define rz !rz \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 &lt \v(line) &gt \v(line)
<p>
<p>
<a name="5.4"><h3>5.4 : Tape Drives</h3>

<p>
	This section should help out for those of you that have either
	never used tape drives before, or only have experience with them
	as non-Unix devices.
<p>
<p>
<a name="5.4.1"><h3>5.4.1 : Does the tape need to be formatted?</h3>

<p>
	It depends, but I think usually not.  And when it is necessary,
	I don't know how it would be done.  One thing is for certain, 
	though, first....  NEVER use the block devices..  erase them and 
	forget you ever saw them.  All operations on tape should be to 
	the character device (rst0).
<p>
<p>
<a name="5.4.2"><h3>5.4.2 : If I execute the command 'st -f /dev/st0 status', I get: Archive/Tandberg? tape drive, residual=0, blocksize=512 Density: high = 16 (0x10), medium = 15 (0xf), low = 5 (0x5) ds=0 er=0</h3>

<p>
	so to write to tape at high-density (QIC-150), presumably I want 
	to use a device with minor number +4 (in st.c, density is computed as
	minor &gt&gt 2 & 0x03, where low density == 3 and high == 1):
<p>
	You have the idea.. density is controlled by bits 2 and 3
<p>
		00 = default
<br>
		01 = hi density
<br>
		10 = medium density
<br>
		11 = low density, 
<br>
<p>
	Unless the driver knows about you kind of drive the density values
	may need to be set by hand before they make any sense.
<p>
<p>
<a name="5.4.3"><h3>5.4.3 : When is erst0 used?</h3>

<p>
	e stands for 'eject' and is bit 1 of the minor.. 
	e.g. eject on close.. many devices can't actually do this.
<p>
	There is actually a method to this whole thing:
<p>
		r = raw		(rst0)
<br>
		e = eject	(erst0)
<br>
		n = No rewind	(nrst0 or maybe nerst0)
<br>
<p>
<p>
<a name="5.4.4"><h3>5.4.4 : How is density (bpi) computed? I am using 3M DC 6250 cassettes which have a 250MB capacity on the Viper 150. But computing the bits/inch based on 250MB/tape-length (1020 ft.), I get a density of 171335 bpi, which is nowhere near the 10000 bpi associated with QIC-150 in the st(1) man page. Why the discrepancy?</h3>

<p>
	These cartridge tapes are written in narrow tracks which 
	alternately begin at opposite ends of the tape.  Track 0 starts 
	at the beginning of the tape, and Track 1 starts at the other 
	end, etc.
<p>
	So, how many times does the tape go backwards and forwards?  If 
	there are 17 tracks, your density is 170000 bpi if it is 10000
	bpi per track.  The more tracks, the lower the bpi/track.
<p>
<p>
<a name="5.4.5"><h3>5.4.5 : How is an appropriate block size determined (and in what units are they specified in the st(1) command)?</h3>

<p>
	QIC 150 and below should stick to 512 byte blocks a write of 
	1024 bytes from the program will be written as 2 512 byte blocks 
	with no speed penalty.  dd will think it's writing a 1024 byte 
	block but on tape it's 2 x 512.
<p>
	Stick to 512 on QIC 150 or less if you ever hope to swap data 
	with anyone else.
<p>
<p>
<a name="5.4.6"><h3>5.4.6 : From the 4.3BSD mtio(4) man page, it sounds like data is typically (traditionally?) stored on tape in eof-terminated sequences of 1K records.</h3>

<p>
<a name="5.4.6.1"><h3>5.4.6.1 : Is st's notion of "file" the record sequence between two eof marks?</h3>

<p>
<a name="5.4.6.2"><h3>5.4.6.2 : What about a "record"?</h3>

<p>
<a name="5.4.6.3"><h3>5.4.6.3 : Is a "record" one "block", as determined by st's "blocksize" command? If not, what is the connection between them?</h3>

<p>
<a name="5.4.6.4"><h3>5.4.6.4 : Can I change the "record" size?</h3>

<a name="5.4.6.5"><h3>5.4.6.5 : When would I want a block size that is different from the default? 1KB is the size of writes used by dd or whatever. QIC specifies 512 byte records (well at least its what people use..) Whatever you write in will be broken into 512 byte sections. They must be multiples of 512 though.</h3>

<p>
	If you have written to a tape, a close will automatically append a 
	filemark (eof mark).  You may read the 512 byte blocks back as 
	512 byte records or as 1024 byte records (in which case you'll 
	get 2 at once).  The bigger the unit, the more efficient.
<p>
<a name="5.4.7.1"><h3>5.4.7.1 : How do I write several archives to a single tape? I tried without success: $ st -f /dev/rst4 rewind $ tar cf /dev/nst4 archive1 $ st -f /dev/nrst4 weof $ tar cf /dev/nst4 archive2 $ st -f /dev/nrst4 weof</h3>

<p>
	First:  throw away the block devices.
<p>
	'n' stands for 'No-Rewind-on-close' and will leave the tape 
	positioned ready for another file e.g.
<p>
		tar -cf /dev/nrst0 archive1
<br>
		tar -cf /dev/nrst0 archive2
<br>
<p>
<p>
<a name="5.4.7.2"><h3>5.4.7.2 : Later, I would expect to be able to access, say, archive3 via the fsf directive to skip over the first two archives. What is the correct sequence?</h3>

<p>
		st -f /dev/nrst0 rewind
<br>
		st -f /dev/nrst0 fsf 2
<br>
		tar -xf /dev/rst0 {files}
<br>
<p>
<p>
<a name="5.4.8"><h3>5.4.8 : Since the Viper 150 writes on QIC-150/120, I guess I don't need to worry about writing variable-length records? How about reading a tape written with variable-length records. Is this possible with the Viper? If so, what's involved?</h3>

<p>
<p>
	Who would have written it? :-)
<p>
	Presently you can't.  You`re right.  Don't worry about it.
<p>
	The new 'st' changes will change this somewhat, though.
<p>
<p>
<a name="5.4.9"><h3>5.4.9 : The very scant documentation that came with my drive mentions a "selectable buffer disconnect size," whose default is 16K. This is evidently the "maximum number of bytes that can be sent over the SCSI bus during a single data transfer phase." What's that? How is it connected st's "blocksize" command? Do I want to use 16K blocks, or might I even want to set the disconnect size to a higher value?</h3>

<p>
	This suggests that 32 512 blocks will be written at a time.
	This jives with the tape format for some of the lower density 
	cartridges (QIC-40 and 80, for example).  The tape is written 
	in blocks of 32 512-byte blocks, with the last three being used
	for Error Correction Codes.  
<p>
	Use dd or tar with 16 k blocks and 32 x 512 byte blocks will be 
	written.
<p>
	Also see 5.4.15 (below) for more information if you are using an
	Archive Viper tape drive.
<p>
<p>
<a name="5.4.10"><h3>5.4.10 : What is "streaming"? When I tar a directory of files to tape, I notice that the tape often stops. Streaming means it doesn't stop? How would I get the viper 150 to stream using tar or cpio or dump?</h3>

<p>
	Use a bigger write size... (more efficient)  Try 16k blocks.
<p>
<a name="5.4.13"><h3>5.4.13 : My tape drive doesn't work.</h3>

<p>
	OK.  There are lots of reasons why it may not.  The most obvious is
	that there are no devices associated with the device in the kernel.
	You can check this through the use of the 'dmesg' command.  Look
	for tape drives.
<p>
	If your tape drive is connected to your floppy controller, it may
	or may not be supported.  Several manufacturers of QIC-40/QIC-80
	mini-cartridge drives are supported natively in FreeBSD and 
	experimentally in NetBSD.  Some aren't (mine for example, is not).
<p>
<p>
<a name="5.4.14"><h3>5.4.14 : I am trying to restore a tape from a FreeBSD machine on a Sun. What kinds of problems should I expect?</h3>

<p>
	The default blocksize should not be a problem, since they are
	both 20K.  You may need to use "dd if=/dev/rst0 conv=swab |
	&ltarchiver&gt" instead of extracting directly from tape, just
	in case the byte order causes a problem.  This is especially
	true if you don't use the 'a' and 'c' options in cpio, for
	example.
<p>
<p>
<a name="5.4.15"><h3>5.4.15 : What are the jumper settings for the Archive Viper tape drive?</h3>

<p>
	Vipers can't do auto-detection. You have to create different 
	devices for different densities. Minor number 8 = 120Mb, 
	4 = 150Mb and 12 = QIC-24 (60Mb).  At least this is the only 
	way it works for me, and since it do I haven't bothered to 
	find out why minor 0 doesn't.  If you have a 2525 (525Mb) 
	it uses  ST_Q_SENSE_HELP quirk but it might not work.
<p>
	The cfg0-2 switches is for setting the disconnect size, e.g. 
	the maximum size transfered before disconnect to allow other 
	SCSI devices to access the bus. Jumper in sets bit to 1.
<p>
		0 = 2kb
<br>
		1 = 4kb
<br>
		2 = 6kb
<br>
		3 = 8kb
<br>
		4 = 12kb
<br>
		5 = 16kb
<br>
		6 = 24kb
<br>
		7 = 32kb
<br>
<p>
	I'm using my viper at id 4 and disconnect size 16k. Works 
	perfectly.
<p>
<a name="5.4.16"><h3>5.4.16 : My Viper-150 auto-detects fine; however, the first attempt to read a tape fails after a boot due to an "illegal SCSI command". What could be the problem?</h3>

<p>
	I assume that the driver is trying to use some SCSI-2 
	command to set the default density -- but after that, the 
	drive is perfectly happy to do the tedious density check and 
	off it goes.  I've read all three densities on the drive.  Once
	the drive is set up and the driver realizes there is no density
	command, it just brute forces the drive density and off it goes.
<p>
<p>
<a name="5.4.17"><h3>5.4.17 : Why haven't we changed the defaults in rdump and rrestore to something that makes sense? I was trying to dump a filesystem to a remote tape and ran into an error complaining about being unable to execute /etc/rmt.</h3>

<p>
	Of course, if you get this error, this program doesn't exist.  
	This information comes from ../src/sbin/dump/pathnames.h.  The 
	reason we still use /etc/rmt and /dev/rmt8 is because the 
	rdump and rrestore protocol call for those names.  
<p>
	This problem usually won't show up unless the original
	installation of the system was done before NetBSD 0.9 *AND* the
	etc.tar.gz distribution was never done.  This distribution fixes
	this problem by creating the symbolic link from where rmt lives
	to /etc/rmt.  The Makefile for rmt should also create this link
	(I'd check before assuming it does.)
<p>
<p>
<a name="5.5"><h3>5.5 : Network Stuff</h3>

<p>
	Network devices for NetBSD and FreeBSD include many types of
	Ethernet cards, as well as Serial Line IP and Point to Point
	Protocol.
<p>
<p>
<a name="5.5.1"><h3>5.5.1 : How can I get my system to work as a network router?</h3>

<p>
	The first hurdle to overcome is that the default kernels do not
	have the GATEWAY option compiled in.  Without this, it is very
	nearly impossible to use the kernel as a router.
<p>
	Once you have the GATEWAY option compiled in, all sorts of things
	magically start to work.  If you haven't got the GATEWAY option
	enabled, you can also use 'sysctl -w net.inet.ip.forwarding=1'
	if you are using FreeBSD or NetBSD versions that support that.
	Remember, once you build the new kernel, you will need to
	install it in the root directory and reboot.
<p>
	Once you have the forwarding option set, you will need to make
	certain that you have not included the '-q' option to routed.
	This should be in the routed_flags keyword in /etc/netstart.  If
	you are using multiple internal LANs, you may also want to
	invest in gated instead (see below).
<p>
	For those folks that are not using routed, you will need to make
	certain that you have a static route to your network provider
	established.  
<p>
	To test your network capability, try running the following
	command:
<p>
		traceroute -s YOUR_ETHERNET_ADDRESS 129.186.150.150
<br>
<p>
	Check to see where your packets are hanging up.  It might be
	that someone upstream from you has something broken instead of
	simply assuming it is your fault.
<p>
<p>
<a name="5.5.2"><h3>5.5.2 : I recently had a problem where I got a message that said "panic: kmem_malloc: mb_map too small". What is the solution to this problem?</h3>

<p>
	The second hurdle is that sometimes you run out of cluster 
	allocation space in the kernel. This is probably network-related 
	and usually shows up when something is being done using the 
	network (like NFS).  The way to get around this would be to 
	change the value of NMBCLUSTERS in your config file. NMBCLUSTERS 
	is set at 256 by default, and increased to 512 when the GATEWAY 
	option is active. To be very safe, you could add
<p>
		options	 NMBCLUSTERS=1024
<br>
<p>
	to your config file, and recompile. This is reported to work
	with systems that crashed as soon as a large number of people 
	(75+) were connected to it.
<p>
<p>
<a name="5.5.3"><h3>5.5.3 : Does anyone have an example of a working gated.conf file? I can't figure these instructions out at all.</h3>

<p>
	Here is a sample config file for a machine which has two cards, 
	one of the cards has an alias created like so: 
<p>
	ifconfig de1 inet 199.232.137.65 mask 255.255.255.192 alias
<p>
	Gated is running with this config:
<p>
	interfaces {
	    interface de0 passive;
	    interface de1 passive;
	};
<p>
	ospf yes {
	    backbone {
		networks {
<br>
		    199.232.136.0 mask 255.255.255.0;
<br>
		    199.232.137.0 mask 255.255.255.0;
<br>
		};
<br>
		interface de0;
<br>
	    };
	};
<p>
	export proto ospfase {
		proto direct {
<br>
			199.232.136.160 mask 255.255.255.224;
<br>
			199.232.137.0 mask 255.255.255.0;
<br>
		};
<br>
	};
<p>
	All routing and networking is fine right after I start gated.  
	However, if I leave out the 'interface passive' section, gated 
	shuts down the two routes on de1 after a couple of minutes.  
<p>
<p>
<a name="5.5.4"><h3>5.5.4 : How do I set up Multicasting on my system?</h3>

<p>
	If you're trying to join the Mbone, you need to find someone 
	willing to provide you with a "feed", and that person's router 
	will be at the other end of your tunnel. If you're just trying to 
	set up your own private little multicast domain, then you need to 
	set up other such routers on other subnets and interconnect them 
	with tunnels. If you just want to run a little multicast testbed 
	on a single subnet, you don't need any multicast routers at all! 
	See the Mbone FAQ at: 
<p>
	   <a href="http://www.mediadesign.co.at/newmedia/more/mbone-faq.html">http://www.mediadesign.co.at/newmedia/more/mbone-faq.html</a>
<p>
	for more detailed information on all of this...
<p>
<p>
<a name="5.6"><h3>5.6 : I want to use my ZIP drive. Are there any weird things I need to know?</h3>

<p>
	One of the things that "just work" are ZIP drives.  The -current
	code for both FreeBSD and NetBSD handle ZIP drives very cleanly.
	One of the unusual things about ZIP drives is that most people
	don't know (and the man page is deliberately vague about) is
	once a person has permission to write to the ZIP drive, they can
	mount it onto a directory in their space.  This is new with the
	adoption of BSD 4.4, so it isn't really surprising that it is
	new.
<a name="section_6"><h2>Section 6.	(Interaction with MS-DOS)
</h2>
<p>
<a name="6.0"><h3>6.0 : Working with DOS and BNR/2 related software.</h3>

<p>
	This section is designed to cover some of the more common 
	problems that DOS will have when interacting with BNR/2.
	There are other sections of the FAQ that deal with 
	indirectly with this .  Try looking in sections 0, 1, and 2
	to see if something in there (particularly when talking 
	about DOS and *BSD coexisting on a single drive).
<p>
<p>
<a name="6.1"><h3>6.1 : Formatting a floppy</h3>

<p>
	Formatting a floppy under NetBSD is possible through the the patch 
	file stored at <a href="ftp://cynjut.neonramp.com/pub/fdformat.patch">ftp://cynjut.neonramp.com/pub/fdformat.patch</a> 
<p>
	This patch appears to be for NetBSD 1.2 (release).  Obviously,
	use it at your own risk.
<p>
	FreeBSD (and I think OpenBSD) both have floppy formatting built
	into their systems in fairly recent versions.
<p>
<p>
<a name="6.2"><h3>6.2 : Sharing the Disk with MS-DOS</h3>

<p>
	There are a myriad of questions about how to share a disk between
	*BSD and MS-DOS.  They all boils down to one of the &ltn&gt following
	questions:
<p>
	1)  How can I partition my drive for both MS-DOS and *BSD?
	2)  I can install using the whole disk, but I can't install when 
	I try to share the drive between *BSD and MS-DOS.  Why?
	3)  I can use either MS-DOS or *BSD on my hard drive,
	but shutdown -todos doesn't seem to work.
<p>
<p>
<a name="6.2.1"><h3>6.2.1 : How can I partition my drive to support both MS-DOS and *bsd?</h3>

<p>
	NOTE:  Before attempting to install *bsd on a computer with an
	active DOS partition, ALWAYS back up your hard drive.  No one on 
	the net, no matter how talented, can help you recover a hosed 
	MS-DOS file system.  If you lose all of your data, it is YOUR
	fault.
<p>
	During the install phase, you need to have un-allocated space left
	on your disk drive.  This allows the install program to correctly
	install the *bsd partition in the partition table and DOS to
	peacefully co-exist with *bsd.
<p>
	If you do not have any space available on your hard drive, you will
	not be able to install both.  Re-fdisk your hard drive and make
	sure you have left un-allocated space in the partition table.  
	This WILL wipe out your DOS partition - Permanently.
<p>
	Even though the partition table procedure above may have worked, 
	there are still no guarantees that your system will boot after
	the install.  This problem most often manifests itself as one of
	the endless reboot problems.  You would normally be able to boot
	DOS from the hard disk, but not *bsd (once that partition is
	marked as active).
<p>
	Once the partition table has been correctly defined with both
	DOS and *bsd, there can still be problem.  One of the most
	common is that the disk drive works in some sort of translation
	mode.  This is particularly common with drives that physically have
	more than 1024 cylinders.  DOS cannot access a drive with more than
	1024 cylinders.  Translation mode will have to be turned off, usually
	by redefining your hard drive in SETUP as one of the user definable
	types.  This change will normally trash your hard drive, or at least
	render your DOS partition unreadable.
<p>
	The solution to this problem is to install *bsd at the end of the
	hard drive.  While DOS cannot use cylinders above 1024, *bsd has
	no such limitations, once it has booted.  During the boot-up phase,
	some of the newer boot blocks will refer to the BIOS for some
	services.  Specifically, the disk is checked for a bad sector map
	on the last track.  Since the BIOS cannot deal with cylinders
	higher than 1024, your bad sector map will be incorrectly
	identified as 1023 if the number of cylinders is larger than that.
	This problem is being worked on, and I hope to change this section
	with better news later.
<p>
	NOTE:  The only people that this problem will effect are those 
	MFM and ESDI users that have drives with more than 1023 tracks.  
	While drives of this type are not the overwhelming majority, 
	neither are they an anomaly.  People are working on it.
<p>
	As an example, if your hard disk physically has 8 heads, 16 sectors 
	per track, and 2000 cylinders (128M); you MUST use some sort of disk
	translation in order to use the entire drive.  An obvious geometry
	for this drive (for DOS) would be 16 heads, 16 sectors, and 1000
	cylinders.  Unfortunately, *bsd operates using the disk drives
	native geometry as reported during the probe phase of boot up.  This
	will probably be 8/16/2000, and will NOT agree with your translated
	disk geometry.  This causes an endless reboot cycle.  If you change
	the geometry so that the drive agrees with the disklabel, your DOS
	partition is toast.
<p>
	The best way to operate in this case would be to (for example)
	split the disk in half.  That leaves 64M for DOS, using a 
	geometry of 8 heads, 16 sectors per track, and the first 1000 
	cylinders for DOS.  The second 1000 cylinders could then safely
	be used for *bsd.  The DOS partition table may even be capable of
	showing this partition as it actually exists.
<p>
		ACCESSING MS-DOS PARTITIONS FROM NetBSD-i386
<br>
<p>
	First off, it's important to understand BSD disklabels.  The 
	disklabel is a description of the Unix partition layout and other 
	disk parameters stored on-disk, usually somewhere in the first 
	couple of sectors.  There is a maximum of 8 partitions, labelled 
	"a" thru "h".  Typically partition "a" is assigned to the root 
	partition, partition "b" is configured as a swap area, and 
	partition "c" is defined as the whole disk.  You can change these, 
	but it's a good idea to stick with this scheme, as many programs 
	assume that's the way things are going to be.
<p>
	If you're whole disk is dedicated to Unix, then that's all you 
	need to know.  But if you're sharing your disk with DOS, then 
	there are a few magical things happening.
<p>
	DOS has it's own partitioning scheme.  The way NetBSD co-exists 
	with this is to fit all of the Unix partitions into one DOS 
	partition.  So partitions a-h all fit inside one DOS partition, 
	which has a partition type of 165 (each MS-DOS partition has a 
	"partition type" associated with it.  The BSD partition type is 
	165).  In this setup, partition "c" refers to the entire BSD 
	partition.  But in this scheme, partition "d" refers to the ENTIRE 
	disk, MS-DOS partitions and all.
<p>
	So, if you want to access your MS-DOS partition from NetBSD, first 
	you'll have to create a partition that points to the MS-DOS 
	partition.  You'll want to run the command:
<p>
	disklabel -e -r /dev/r??0d	(fill in with your disk type).
<p>
	You'll get popped into an editor with all the disklabel stuff in 
	it.  Go down to the bottom.  You should see something like:
<p>
	6 partitions:
	#        size   offset    fstype   [fsize bsize   cpg]
  	a:    30720   409600    4.2BSD     1024  8192    16   # (Cyl...
  	b:   129024   440320      swap                        # (Cyl...
  	c:  1617920   409600    unused        0     0         # (Cyl...
  	d:  2029568        0    unused        0     0         # (Cyl...
  	e:    61440   569344    4.2BSD     1024  8192    16   # (Cyl...
  	f:  1396736   630784    4.2BSD     1024  8192    16   # (Cyl...
<p>
	(or whatever it appropriate for your disk).  Note that partition 
	"a" starts on cylinder 200.  That's where my BSD partition starts 
	on my disk.  Also note that partition "c" starts at 200 as well 
	and goes to the end of the disk.  You'll also note that partition 
	"d" goes from sector 0 all the way to the end of the disk.
<p>
	Add a new line that looks something like:
<p>
  	g:   409568       32    MS-DOS                  # (Cyl.    0*- 199*)
<p>
	(The comment on the end isn't necessary.  Only the partition 
	letter, size, offset, and partition type are needed.  You can 
	put unused in instead of MS-DOS if you want).
<p>
	*NOTE* Be sure to change the line that says "6 partitions" to the 
	new number of partitions that you have!!!  Otherwise you'll get an 
	obscure error.  In my case I'd change that line to be "7 partitions".  
	If you aren't sure what your MS-DOS partition size and offsets are, 
	you can use the NetBSD fdisk to find them out.  Don't forget that 
	there's a maximum of 8 partitions.  
<p>
	Once you do that and you have MSDOSFS configured into your kernel, 
	you can just do something like "mount -t msdos /dev/sd0g /msdos".  
	Or you can put a line like this in your fstab:
<p>
	/dev/sd0g /msdos msdos rw 0 0
<p>
	If you want to access a DOS-only HD from NetBSD, here are some 
	instructions posted by Charles Hannum a while back.  I haven't 
	tried them myself, but they seem like they would work.
<p>
	Assuming you don't have something (like OS-BS) which uses the extra
	sectors in the boot track, you can do the following:
<p>
	1) Use the NetBSD `fdisk' or DOS `pfdisk' to create a NetBSD 
	partition in the MBR which spans the entire disk.
<p>
	2) Save a copy of the MBR:
<p>
		dd if=/dev/rsd0d of=my-mbr bs=1b count=1
<br>
<p>
	3) Use `disklabel' to create a NetBSD label with the DOS partition 
	and whatnot.  Answer `y' when it asks you if you want to `overwrite 
	[a] disk with [a] DOS partition table'.
<p>
	4) Put back the saved copy of the MBR:
<p>
		dd if=my-mbr of=/dev/rsd0d bs=1b count=1
<br>
<p>
	This works for me.  Your mileage may vary.
<p>
	Luke Mewburn &lt<a href="mailto:zak@rmit.edu.au">zak@rmit.edu.au</a>&gt has provided the following tutorial on 
	using the pfdisk program and making your *bsd/NetBSD partitions
	peacefully coexist with DOS.  While this is kind of a 'cookbook' 
	approach, please keep in mind that this is probably easily 
	transferable to all BNR derived Unices.
<p>
<p>
<a name="6.2.2"><h3>6.2.2 : I can install using the whole disk, but I can't install when I try to share the drive between *BSD and MS-DOS. Why?</h3>

<p>
	This is an extension of the question above.  The most common 
	reason for this is, once again, disk translation problems.  If 
	the disklabel does not agree with the disk geometry, the install 
	will fail.  Other incarnations of this problem are that you can 
	install DOS, then *BSD, and DOS will be hosed, or vice versa.
<p>
	There are more than a couple of people who will blithely suggest 
	that this is a good thing, and you should install *BSD exclusively,
	job not withstanding.
<p>
<p>
<a name="6.2.4"><h3>6.2.4 : Is there any hope of ever running MS-DOS applications under any of the free BSD systems?</h3>

<p>
	There is currently a project in development to port the Windows 
	program environment to Linux and the *BSD systems.  Here is an
	excerpt from the original message announcing the project:
<p>
	As many of you already know, we are in the process of creating a
	Windows emulator.  This emulator is similar to Sun's Wabi product, 
	but is being developed completely independent of them.  Many of 
	you are anxious to hear the latest status of the project.  I have 
	created a mailing list for those of you.  To join the list, simply 
	send mail to:
<p>
	<a href="mailto:wine-project-info@amscons.com">wine-project-info@amscons.com</a>
<p>
	If your mailing address is not easy to deduce from the mail 
	headers, then place the following line in the body of the message 
	that you send.
<p>
	Reply-To: <a href="mailto:youraddress@yourmachine">youraddress@yourmachine</a>
<p>
	where <a href="mailto:youraddress@yourmachine">youraddress@yourmachine</a> should be replaced by your actual 
	mailing address.
<p>
<p>
<a name="6.2.5"><h3>6.2.5 : How do I get Linux executables to run under NetBSD?</h3>

<p>
	First, you need to make certain your kernel has LINUX_COMPAT as
	one of the options for your kernel.  Second, you will need the
	libraries for Linux.  You can find the Linux supporting binaries 
	for NetBSD i386 at <a href="ftp://ftp.enigma.net/pub/netbsd_i386.">ftp://ftp.enigma.net/pub/netbsd_i386.</a>  There
	are instructions there to tell you how to get the libraries
	working correctly.  
<p>
	With VERY new versions of NetBSD (NetBSD 1.3A and above) the
	kernel option for Linux compatibility have changed.  All ELF and
	COFF executables, as well as native Linux executables will be
	included as part of the same option.
<p>
<p>
<a name="6.3"><h3>6.3 : Accessing the MS-DOS filesystem</h3>

<p>
	One of the most common MS-DOS related questions (with the possible
	exception of 6.2 above) is how to access the DOS disk partitions
	from *BSD.  
<p>
<hr>
		How to mount your DOS partition from FreeBSD
<br>
<p>
	1. First, be root.  The following won't work as an ordinary user.
<p>
	2. Second, use 'fdisk' to see where your DOS partition starts.  
	It will be labeled as type DOS.  On my system, 'fdisk /dev/sd0d' 
	produces the following:
<p>
		... (extraneous output, not of interest) ...
<br>
	The data for partition 0 is:
	sysid 6,(Primary 'big' DOS (&gt 32MB))
	    start 32, size 306400 (149 Meg), flag 0
	        beg: cyl 0/ sector 1/ head 1;
	        end: cyl 149/ sector 32/ head 39
<p>
	    This shows me that my DOS partition starts at sector 32, and 
	is 306400 (512 byte) sectors long.
<p>
	NOTE:  If you're trying to mount a DOS `EXTENDED' partition, then 
	you need to add the number of sectors per track to this start 
	address you got from fdisk in subsequent calculations, I.E. in 
	the above example (assuming it was an EXTENDED partition rather 
	than the Primary), you'd use `start 64, size 306400'.
<p>
	[Ed.Note.  This example assumes a SCSI disk.  For disks with a 
	number of sectors per track which is different than 32, you will
	probably see the 32s above replaced with your number of sectors
	per track. IDE, MFM, and ESDI drives are all examples where the
	number of sectors per track is likely to NOT be 32.]
<p>
	3. Next, using this information, you craft a new disk entry in your
	   /etc/disktab file that assigns one of your unused "UNIX" 
	   partitions to this DOS region.  Again, using my system as a 
	   default, you see I've created:
<p>
	disk0|DEC 5501:\
		:ty=winchester:dt=SCSI:se#512:nt#8:ns#256:nc#1001:rm#3600:\
<br>
		:pa#956416:oa#307200:ba#8192:fa#1024:ta=4.2BSD:\
<br>
		:pb#131072:ob#1263616:tb=swap:\
<br>
		:pc#1087488:oc#307200:tc=UNUSED:\
<br>
		:pe#306400:oe#32:te=MSDOS:
<br>
<p>
	   As you can see, partition 'e' now points to the DOS partition as
	   pointed out by fdisk.
<p>
	   [Ed.Note again.  Remember what I said about the 32 above...]
<p>
	   Also, there may be a problem with some versions of disklabel
	   not recognizing the MSDOS (or MS-DOS, depending) in the te:
	   entry above.  You may need to run a "disklabel -e" to get the
	   partition type to 'stick'. 
<p>
	4. Now we have to actually stick the label on the disk, which is done
	   with disklabel.  Using my example, this would be:
<p>
	    disklabel -r -w sd0 disk0 SCSI /usr/mdec/sdboot /usr/mdec/bootsd
<p>
	5. Reboot your system to see the new disk label.
<p>
	6. Mount the DOS partition.  I do:
<p>
		mount -t pcfs /dev/sd0e /dos_c
<br>
<p>
	   Where /dos_c is just a convenient directory to mount it.
<p>
	7. You're set!
<p>
	With the exception that the '-t' option is msdos in NetBSD, these 
	instructions seem to work with the same facility for NetBSD.  I
	also received a note a couple of weeks ago (that I promptly deleted
	because I new that I would remember what it said) that DOS extended
	partitions are readable if you skip the first 'n' blocks in your 
	computations (where 'n' is your number of sectors per track).  This 
	way, you skip over the 'new' part of the DOS file system.  That means 
	that instead of the oe:32 above, you would need an oe:48 instead.  
<p>
	Also remember that the compressed file system in DOS 6 will probably
	be completely Greek to your NetBSD/FreeBSD system.  I seriously 
	doubt that you will be able to read the compressed DOS file system
	anytime in the foreseeable future.
<p>
<p>
<a name="6.4"><h3>6.4 : NFS/PC-NFS support</h3>

<p>
	The problems normally associated with PC-NFS are also associated 
	with NFS in general.  
<p>
<p>
<a name="6.4.1"><h3>6.4.1 : Can I use 8K packets for NFS? When I try, I have all kinds of problems. Specifically, I get 'ring buffer overflows' or the performance is real bad.</h3>

<p>
	In addition to the NE2000 card, this problem can also manifest 
	itself on other ISA networks cards that have a limited amount of
	memory.  Ken Raeburn (<a href="mailto:raeburn@cambridge.cygnus.com">raeburn@cambridge.cygnus.com</a>) has identified 
	a common problem with the NE2000 card and provided us with a work
	around:
<p>
<hr>
	I reported previously that I was seeing problems reading files over
	NFS using the NE2000 driver; timeouts would eventually be reported, no
	data would be read.  Listing files and directories (small ones
	anyway) were not a problem.
<p>
	In the meantime, mounting NFS file systems with "rsize=1024" does get
	rid of this problem.
<p>
	Ken
<hr>
<p>
	As a matter of policy, specifying "rsize=1024,wsize=1024" works 
	very well also, and makes the transfers seem to run faster.  This 
	is probably because there are fewer collisions.  The disadvantage 
	of this method comes from the kernel 'sync'ing after all NFS 
	writes.  This can slow NFS accesses considerably.  As with most 
	generalizations, this one too can do nearly as much harm as good.  
	If you have trouble, reduce your default packet size until the 
	problem goes away.
<p>
	With the newer drivers (especially the ed driver) most of these 
	problems are solved automagically.  If you are still using the
	original 386bsd 0.1 release, you REALLY need to upgrade.
<p>
	See section 6.4.5 on 'ring buffer overflows' and the 3C503 for
	more discussion on this problem.
<p>
<p>
<a name="6.4.2"><h3>6.4.2 : How do I get around the NFS "Permission denied" error?</h3>

<p>
	The problem is not the configuration of the server (unless there is
	no real requirement to run it in "secure" mode, and you happen to
	be running it that way anyway).  The problem is the fact that,
	even though mount request are sent on a privileged port, NFS
	connections are not.
<p>
<p>
<a name="6.4.3"><h3>6.4.3 : What does the message "BAD MNT RPC: RPC Authentication error; why = Invalid client credential" mean when I try to mount something from another machine?</h3>

<p>
	Hellmuth Michaelis (<a href="mailto:hm@hcshh.hcs.de">hm@hcshh.hcs.de</a>) offers the solution to this
	relatively common problem:
<p>
	You have to make sure that the user "root" is not present in more
	than 8 entries in the "/etc/group" - file on the *BSD machine.
	Simply remove some entries and the NFS mounts will succeed.  
<p>
<p>
<a name="6.4.4"><h3>6.4.4 : What does the message "Bad MNT RPC: RPC: Authentication error; why = Client credential too weak" mean when I try to mount something from another machine?</h3>

<p>
	This problem is a standard NFS problem; it simply means that your 
	user number is not one of the ones that can mount this NFS.  
	Normally, you will get this message when you are trying to mount 
	a filesystem from a machine that allows 'root' to mount an NFS,
	but limits other users.
<p>
	Another documented problem with "client credentials being too
	weak" is the dichotomy of SunOS and 4.4 based systems.  SunOS,
	and other commercial systems, do not allow NFS commands to come
	in on anything but a reserved port.  There are several places
	that need to be addressed if weak credentials are a problem.
	The first is the mount command.  The mount itself may work, but
	all references to files in the NFS will fail.  This is usually
	the most common symptom of this problem.  The solution for this
	is to either include the '-o resvport' keyword pair on the mount
	command, or the -P option.  In addition to the resvport command
	on the mount, it may become important to include an NFS volume
	in your fstab.  If this is the case, you will need to ensure
	that the resvport keyword is added on the mount line in the
	fstab.  Finally, if you are using the automounter, you will need
	to make absolutely certain that you have included the resvport
	option in your automount maps as the default.
<p>
<p>
<a name="6.4.5"><h3>6.4.5 : I get a lot of 'ring buffer overflow' messages using NFS and the ed0 driver. Is there a problem?</h3>

<p>
	David Greenman (<a href="mailto:davidg@implode.rain.com">davidg@implode.rain.com</a>), the original author of 
	the ed0 driver, provides us with some insight into the inner 
	workings of the ed0 driver.
<p>
	   It always surprises me that people don't just ask the original 
	author these questions. :-) Anyway, the reason these are happening 
	is that the access to the 8bit boards shared memory simply isn't 
	fast enough to deal with full wire speeds...but the driver tries 
	hard...so even though packets get dropped, your performance only 
	drops to about what the ethernet board is capable of (should be 
	in the 400-600k range with an 8bit card). NFS is especially bad 
	because the UDP window is quite large (40k last time I looked), 
	so the overflow condition can happen easily. I've explained this
	for the most part in the release notes for the driver, but these 
	didn't make it into either the FreeBSD or NetBSD releases (we 
	couldn't find an appropriate place to put them).
<p>
	&gtFrom the release notes:
<p>
	receive
<hr>
	   The 8390 implements a shared memory ring-buffer to store 
	incoming packets.  The 8bit boards (3c503, and 8003) usually have 
	only 8k bytes of shared memory.  This is only enough room for about 
	4 full size (1500 byte) packets. This can sometimes be a problem, 
	especially on the original WD8003E and 3c503.  This is because these 
	boards' shared memory access speed is also quite slow compared to 
	newer boards - typically only about 1MB/second. The additional 
	overhead of this slow memory access, and the fact that there is 
	only room for 4 full-sized packets means that the ring-buffer 
	will occasionally overflow.  When this happens, the board must 
	be reset to avoid a lockup problem in early revision 8390's.  
	Resetting the board will cause all of the data in the ring-buffer 
	to be lost - requiring it to be re-transmitted/received...slowing 
	things even further.  Because of these problems, maximum throughput 
	on boards of this type is only about 400-600k per second. The 16bit 
	boards (8013 series), however, have 16k of memory as well as much 
	faster memory access speed. Typical memory access speed on these 
	boards is about 4MB/second. These boards generally have no problems 
	keeping up with full ethernet speed. The only problem I've seen 
	with these boards is related to the (slow) performance of the
	system's malloc code when additional mbufs must be added to the 
	pool. This can sometimes increase the total time to remove a 
	packet enough for a ring-buffer overflow to occur.  
<p>
	With NFS, the problem is really bad, though.  The 3c503 does not 
	have enough memory on the card to support the default 8k packets 
	that NFS and other protocols use as their default.  The solution 
	for folks that are having a problem with ring buffer overflows 
	in NFS is for them to either use the -r and -w flags to limit 
	the packet size or use the define "NFS_BOOT_RWSIZE=8192".  If 
	NFS doesn't work with this defined, the code will automatically 
	step down to the next smaller increment.  If you KNOW that you 
	will always be running a 3c503, you can set this define to 4096 
	instead, just to make sure.  This should eliminate the bulk of 
	the ring buffer overflows in NFS.
<p>
<p>
<a name="6.4.6"><h3>6.4.6 : I am getting really poor performance out of my network, especially when talking to older networks or when performing short file transfers. What's the problem?</h3>

<p>
	Try turning off rfc1323 support:
<p>
		sysctl w net.inet.tcp.rfc1323=0
<br>
<p>
	only in newer builds. In older versions you have to edit a kernel 
	config file.  RFC1323 is not yet supported by all networks, and
	can cause TCP performance degradation when tried.  This, for
	example, is a known problem on older Sun and VAX hosted
	networks, and on many networks which are using Linux as an
	intermediate host.
<p>
<p>
<a name="6.4.7"><h3>6.4.7 : Is there any PC software that will allow me to use my enormous PC with all of the unsupported hardware as a PC-NFS server?</h3>

<p>
	Yes.  It is called SOSS, and is available from MANY FTP sources.
	You will need the aforementioned Clarkson Packet Drivers for it
	to work, but that shouldn't cause too many problems for most 
	people.
<p>
<p>
<a name="6.5"><h3>6.5 : How can I use mtools with the 'new' floppy naming convention?</h3>

<p>
	With the adoption of BSD 4.4, there is a new way of accessing
	the floppy disk drive types.  The method uses the minor device
	number to specify different media sizes and densities.  These
	densities are established by a table from the file 
	/usr/src/sys/arch/i386/isa/fd.c in NetBSD (your mileage may
	vary).  The table in FreeBSD's fd.c is likely to be slightly
	different.
<p>
	The order of the entries defines the order of the minor
	numbers, so the table below has the following characteristics:
<p>
	    /dev/fd0a	0	/* default disk type */
 	    /dev/fd0b	1	/* 1.44MB diskette */ 
	    /dev/fd0c	2	/* 1.2 MB AT-diskettes */ 
	    /dev/fd0d	3	/* 360KB in 1.2MB drive */ 
	    /dev/fd0e	4	/* 360KB PC diskettes */ 
	    /dev/fd0f	5	/* 3.5" 720KB diskette */ 
	    /dev/fd0g	6	/* 720KB in 1.2MB drive */ 
	    /dev/fd0h	7	/* 360KB in 720KB drive */
<p>
	struct fd_type fd_types[] = {
        	{ 18,2,0xff,0xcf,0x1b,0x6c,80,2880,1,FDC_500KBPS,2,"1.44MB"  },
        	{ 15,2,0xff,0xdf,0x1b,0x54,80,2400,1,FDC_500KBPS,2,"1.2MB"   },
        	{  9,2,0xff,0xdf,0x23,0x50,40, 720,2,FDC_300KBPS,2,"360KB/AT"},
        	{  9,2,0xff,0xdf,0x2a,0x50,40, 720,1,FDC_250KBPS,2,"360KB/PC"},
        	{  9,2,0xff,0xdf,0x2a,0x50,80,1440,1,FDC_250KBPS,2,"720KB"   },
        	{  9,2,0xff,0xdf,0x23,0x50,80,1440,1,FDC_300KBPS,2,"720KB/x" },
        	{  9,2,0xff,0xdf,0x2a,0x50,40, 720,2,FDC_250KBPS,2,"360KB/x" },
	};
<p>
	In order to add a new device (such as a 2.44 Meg floppy) new
	tables entries are theoretically all that would be needed.  As
	new entries are created, the minor device numbers would
	increase and the associated device names would be added.
<a name="section_7"><h2>Section 7.	(System Communication and Network Information)
</h2>
<p>
<a name="7.0"><h3>7.0 : Communications</h3>

<p>
<a name="7.1"><h3>7.1 : SLIP/CSLIP</h3>

<p>
	Serial Line I/P is supported in all versions of BSD.
<p>
	Brian &lt<a href="mailto:brian@awfulhak.demon.co.uk">brian@awfulhak.demon.co.uk</a>&gt provides us with a rather
	good explanation of some of the hurdles that must be overcome
	for a working slip interface.
<p>
	The idea is (overview) that you make a serial line connection to 
	the host, set the line discipline, and tell your router to use 
	this interface as your gateway.  You also should set the gateway 
	up as a nameserver.
<p>
	You will need the information in 7.4.1 below to make sense to
	you before you proceed much further.  I suggest you read that
	now.
<p>
	Sounds easy ? - well it is if you've done it before.
<p>
	The _usual_ way of doing this is as follows:
<p>
	Both server and client must know each others inet addresses.  Set 
	these up in /etc/hosts with lines saying
	    11.22.33.44 host.my.domain.name host
	    11.22.33.55 client.my.domain.name client
<p>
	where 11.22.33.?? is your inet number, and the following name is 
	the full machine name (and is followed by any number of aliases).
<p>
	SERVER:
 	  Create a login - usually Sclientname - and run `sliplogin` as 
 	  its shell.  I've looked at the docs for sliplogin, and it seems
 	  fairly straightforward.  [Ed.Note - I have; it is.]
 	  A fairly common problem on the server is an error that is 
 	  caused by the lack of a 'sliplogin' entry in the /etc/shells
 	  file.  Be sure to add sliplogin to your shells file.
<p>
	CLIENT:
	  Set up /etc/resolv.conf to say the following (for the nameserver)
		domain client.my.domain.name
<br>
		nameserver 11.22.33.55
<br>
<p>
	  ** traditional method **
	  - Log on to the server.  This is usually done via kermit or
	    some such program.
	  - Exit the program (or background it if your line wants to
	    drop once the device is closed).
	  - Run `slattach /dev/comport` for whatever "comport" is.  On most
	    BSD derived systems, this may be either com0, or cua01, or
	    whatever the correct name is for your site.
<p>
	  If you run into an error that says 'not configured' in it, your 
	  kernel either does not recognize your port (dmesg will verify that)
	  or your kernel does not have the slip interface built in.  See 
	  below for the latter.  The former could be caused by any one of 
	  a dozen problems, including conflicting or incorrectly identified 
	  IRQs or port addresses.
<p>
	  - Run `ifconfig sl0 net clientname servername netmask 0xffffff00`
	  - Run `route add default servername`.
<p>
	    "servername" is your server and "clientname" is your client.
<p>
	  It should now be possible to `ping host`
<p>
	** my method **
	  Configure /etc/remote
	  Configure /etc/host.dial
	  Run `slip host`.
<p>
	/etc/remote contains an extended `tip` entry.  /etc/host.dial 
	contains a login script (and is named in /etc/remote).
<p>
	Oh yes, don't forget to have a line in your kernel config saying
<p>
	pseudo-device sl 2
<p>
	Without this line, you may get a 'device not configured' or 
	'TIO...' error because the slip driver is not built into the 
	kernel.
<p>
	Someone else mailed me their instructions for using a SLIP
	service.  Here they are, in all their glory.
<p>
	Hi, I thought I'd drop you this email outlining how I have 
	SLIP set up to dial and communicate, as I remember this being 
	an area in the FAQ which needed some expansion/clarification. 
	What I outline works for me dialing up under NetBSD 0.9. 
	Though I don't know the specific nuances of FreeBSD (e.g. the 
	boot-up configuration of the interfaces - /etc/hostname.sl&ltn&gt 
	for NetBSD) this'll be easy for someone to add to, hopefully 
	before you release it (I know there's nothing I hate more
	than having to convert one setup's info into another nearly,
	but not quite, the same setup :-)
<p>
	In the last quoted script file (slip-off) the unlock line should 
	read:
<p>
	/usr/local/etc/unlock LCK..$DEVICE
<p>
	1) Configuring the SLIP interface.
<p>
	Ensure that the sl device is present in your kernel (default with 
	the generic kernels). In NetBSD 0.9 they get assigned in turn 
	with each 'slattach'.
<p>
	Put your own hostname and ip number, and that of your dial up 
	gateway, into your /etc/hosts. This is an example:-
<p>
	   127.0.0.1     localhost
<p>
	   158.152.1.65    gate gate.demon.co.uk
	   158.152.26.67   blodwen blodwen.demon.co.uk
<p>
	Ensure that your /etc/resolv.conf is set up appropriately, to 
	point to the nameserver of your dial-up provider/link.  This is 
	what I use:-
<p>
	   domain demon.co.uk
	   nameserver 158.152.1.65
	   nameserver 158.152.1.193
<p>
	(you can have up to three nameservers, they -must- be listed by
	number.  If you wish to look in several domains, you can use 
	'search demon.co.uk,foo.other.domain' etc. up to the limit (a 
	finite length specified in resolver(5).)  Also, for more
	flexibility, there is a nameserver switch package that allows
	you to change the resolver profiles on the fly; see below.
<p>
	Your sl interface needs to be configured using ifconfig(1) as a 
	link from your own hostname to that of your dial-up host.  Manually 
	this can be done by:-
<p>
	   /sbin/ifconfig sl0 &ltyour-machine&gt &ltdial-up-machine&gt
<p>
	on NetBSD this can be done at boot-time, by having the following 
	in /etc/hostname.sl0:-
<p>
	   inet blodwen.demon.co.uk 255.255.255.0
	   dest gate.demon.co.uk
<p>
	(You can substitute sl0 for sl&ltn&gt if this will after another 
	slattach e.g. for a local machine on a fixed cable)
<p>
	The netmask value (255.255.255.0 in this case) is pretty 
	irrelevant to SLIP because you cannot have a subnet broadcast 
	(so I am informed).
<p>
	I use the chat(1) program (currently available in the 
	FreeBSD-current/ports/ directory) to dial up and enter 
	passwords, etc. My modem is setup for hardware handshaking 
	(a necessity really, for performance), and I use the following 
	sh scripts to do the work.  Calling 'demon' dials up and connects. 
	Calling 'demon-down' when on-line shuts it all off. Those who 
	use PPP should be able to work out the changes from the original 
	ppp-on and off scripts.
<p>
	[I call it 'demon' for simplicity]
<p>
	   #!/bin/sh
   	   #
	   # attach slip and route (calls slip-on script)
	   if /usr/local/etc/slip-on
	           then
	           # this adds the default route to 'gate' which is 
		   # my dial-up host
<br>
	           route add default gate
<p>
	           # put anything here to be run when you are connected
	           # slurp news
	           /usr/local/etc/slurp news.demon.co.uk &
	           # send outgoing news
	           /usr/local/news/bin/nntpsend
<p>
	           # kick outgoing email
	           sendmail -q0m
<p>
	   else
	           # slip-on failed
<p>
	   fi
<p>
	[ here's my /usr/local/etc/slip-on ]
<p>
	Note that you may need to adjust the chat command to deal with the
	prompts you have to answer or that your modem produces, and the final
	message (my provider sends HELLO to signify that they are ready. The
	 -v to chat makes it send syslog .info messages, which I then send to
	my /dev/console. You can remove this if you wish.
<p>
	The following is a modified version of the ppp-on script that comes
	with chat, altered to set the serial line correctly for the modem. I
	dial-up at 38400bps on a modem on tty03, you might want to change that
	too (and make sure that the stty line is all kept on one line).
<p>
	   #
	   #       slip-on
	   #
	   #       Set up a SLIP link
	   #
<p>
	   LOCKDIR=/var/spool/lock
	   DEVICE=tty03
<p>
	   PHONE=&ltphone number here&gt
	   USER=&ltyour login&gt
	   PASSWORD=&ltyour password&gt
<p>
	   if [ -f $LOCKDIR/LCK..$DEVICE ]
	   then
	       echo "SLIP device is locked"
	       exit 1
	   fi
<p>
	   /usr/local/etc/fix-cua $DEVICE
	   sleep 16000 &lt /dev/$DEVICE &
	   /bin/stty -f /dev/$DEVICE
	gfmt1:cflag=4b00:iflag=c00:lflag=3:oflag=6:discard=f:dsusp=19:eof=4:
	eol=ff:eol2=ff:erase=0:intr=3:kill=0:lnext=16:quit=1c:reprint=12:
	start=11:status=ff:stop=13:susp=1a:werase=17:ispeed=38400:ospeed=38400
<p>
	   (
	     if chat -v -l LCK..$DEVICE ABORT "NO DIALTONE" \
	     ABORT "NO CARRIER" ABORT BUSY "" ATZ OK 
	     ATDT$PHONE "CONNECT 38400" "" "ogin:" "$USER" \
	         "word:" "\\q$PASSWORD" "HELLO"
	           then
	           /sbin/slattach -h -c -s 38400 $DEVICE
	           exit 0
	       else
	           echo "SLIP call failed" 1&gt&2
	           # remove the sleep holding serial line open
	           /bin/kill -KILL `/bin/ps -ax | /usr/bin/egrep " sleep 16000" \
	             | /usr/bin/egrep -v "egrep" | /usr/bin/sed 's/^\([ 0-9]*\)
	.*/\1'/`
	           exit 1
	       fi
	   ) &lt /dev/$DEVICE &gt /dev/$DEVICE
<p>
<p>
	When it comes to switching off the line, I use the following. Don't
	forget to adjust the sl0 as appropriate
<p>
	[ I call it demon-down for simplicity]
<p>
	   #!/bin/sh
	   #  stop script
	   #
	   /usr/local/etc/slip-off
	   /sbin/ifconfig sl0 down
<p>
	[ and /usr/local/etc/slip-off ]
<p>
	and adjust the DEVICE line as well.
<p>
	   #!/bin/sh
<p>
	   DEVICE=tty03
<p>
	   kill -KILL `ps -ax | egrep "slattach.*${DEVICE}" | egrep -v "egrep" \
	     | sed 's/^\([ 0- 9]*\) .*/\1'/`
	   kill -KILL `ps -ax | egrep " sleep 16000" | egrep -v "egrep" \
	     | sed 's/^\([ 0-9]* \) .*/\1'/`
	   # switch line back to normal (closes line)
	   /bin/stty -f /dev/$DEVICE -clocal
	   # unlock the device
	   /usr/local/etc/unlock LCK..$DEVICE
<p>
	   exit 0
<p>
<p>
	And that should do it. Happy SLIPping!
<p>
<p>
<a name="7.2"><h3>7.2 : PPP</h3>

<p>
	Implementations of Point to Point Protocol are also available.  PPP
	has been available since the 0.9 release of NetBSD and is in the 
	current releases of FreeBSD, OpenBSD,  and NetBSD.
<p>
	It should also be noted that there is a newsgroup that covers the 
	PPP protocol exclusively.  It is comp.protocols.ppp.
<p>
	Here is some information for people desiring to set up PPP in
	there systems:
<p>
<p>
	A simple way to do this is to use the "chat" and a chat file.  I 
	use the following command to initiate a connection :
<p>
    	    root# pppd tty01 19200 connect 'chat -v -f chat.my-isp'
<p>
	And in the chat.my-isp file:
<p>
            ABORT BUSY
	    ABORT ERROR
	    ABORT 'NO DIALTONE'
	    ABORT 'NO CARRIER'
	    '' ATZ OK ATDT1234567 CONNECT \d
	    TIMEOUT 5
	    ogin:\s--ogin:\s mylogin ssword: mypasswd prompt:\s /usr/lib/ppp/ppp
<p>
	This dials, connects and negotiates the addresses from just one 
	line entered.
<p>
	To kill the connection:
	    root # kill `cat /var/run/ppp0.pid`
	which has the added advantage of hanging up the phone if the modem 
	is set up appropriately.
<p>
	The biggest problem that I ever had with this was working out the 
	chat script and that was debugged by adding the following line in 
	/etc/syslog.conf:
<p>
	    # Hand chat debug messages to root
	    local2.debug            root
<p>
	The PPP.FAQ was helpful, but I ignored quite a bit of it and depended 
	more on the online manuals.
<p>
	For setting up the PPP daemon, here is some more information:
<p>
	For NetBSD, it turned out that I needed to rebuild the kernel with
	the following line in my config file,
<p>
	    pseudo-device ppp 1
<p>
	This line adds a device driver to the kernel that does the ppp 
	protocol.  Once I had that built in, everything worked the first time.
<p>
	This is the kind of sequence I go through to start ppp:
<p>
	1. Connect with kermit to my ppp account and login.  The account 
	tells me when it starts ppp.
<p>
	2. "Suspend" kermit (i. e. put it in the background). This gets me
	back to the shell prompt. (You can get kermit back using the "fg" 
	command)
<p>
	3. Start "pppd".  When the shell prompt returns, I then have 
	Internet access!
<p>
	That's it.  This procedure will get you access to machines by using 
	their IP address numbers.  You still have to configure a name server 
	in "resolv.conf" in order to get DNS functionality.  My resolv.conf 
	looks like this:
<p>
	domain umd.edu			# Maryland's domain name
	nameserver      128.8.5.2	# These are the IP addresses of three 
	nameserver      128.8.126.2	#  hosts that can act as name servers
	nameserver      128.8.126.3
<p>
	The name servers should be as "close" as possible.  Whatever machine 
	manages the modem pool your on would be the best but any machine on 
	your local loop will give you good performance.
<p>
	If your Internet Service Provider uses dynamic addressing,  You 
	don't even have to worry about this.  It's the point of PPP.  It's 
	actually a good thing from a security point of view.  Your IP address 
	changes w.r.t. to the rest of the net periodically.  By the way, 
	don't forget passwords on all your accounts!!  When your on PPP, 
	the rest of the net can see you too, you look like a full Internet 
	host.
<p>
<p>
	It is important to look into the following to see if any of them
	apply to you, if you still have questions:
<p>
<p>
	Here is a sample PPP config.
<p>
	1)  Make /etc/ppp directory, then populate as follows:
<p>
	2)  Include the following in '/etc/ppp/options':
<p>
	crtscts
	modem	/* This option opens the port with O_NONBLOCK if there
		   is a connect options specified, and resets CLOCAL when
<br>
		   the connection is closed */
<br>
	19200
	defaultroute
	netmask 255.255.255.0
	ipcp-accept-local
	ipcp-accept-remote
	noipdefault
	connect "/usr/sbin/chat -v -f /etc/ppp/sample.chat"
<p>
	3)  Make sure the modem line (in the '/etc/ttys' file) doesn't
	have the 'local' or 'softcar' options included.  With 'local;, CLOCAL
	will be set for that line and SIGHUP may or may not be sent,
	apparently based on the age of the software.  The "modem" option
	in the 'options' file (above) should clear that, but it may or
	may not ever work.  If you have "softcar" in /etc/ttys, then the
	SIGHUP (in fact, almost all of the signals)  will never work
	because the modem lines are effectively ignored, thereby leaving
	the modem in whatever mode it is in.
<p>
	4)  Include the following in '/etc/ppp/sample.chat':
<p>
	ABORT BUSY ABORT 'NO CARRIER'
	'' atdt5551212
<p>
	rname: {sample}
	sword: crack-me
	annex: {whatever}
	PPP.
<p>
<p>
	This setup uses LCP and IPCP (parts of PPP) to negotiate the
	dynamic IP addresses.  This setup assumes an ISP which uses an
	annex terminal server.  It prompts for "Annex username:" and 
	"Annex password:".  You then get to the command line prompt: 
	"annex:", at which point "PPP" starts the PPP session.  You 
	will have to edit this to suit.  If your ISP uses a system where
	you are automatically connected to PPP when you log in, your
	'/etc/ppp/sample.chat' file might look like this:
<p>
	ABORT BUSY ABORT 'NO CARRIER'
	'' atdt5551212
<p>
	rname: {sample}
	sword: crackme
<p>
	To implement a 'permanent PPP' dial-up connection, the following
	has been used (by me specifically!)  This works in NetBSD 1.1 or
	higher, OpenBSD, and perhaps recent versions of FreeBSD:
<p>
<p>
	The following line in /etc/ttys works wonders for making a 
	permanent link:
<p>
	tty01   "/usr/sbin/pppd"                unknown on rtcsts
<p>
	The file '/etc/ppp/options' looks like:
<p>
	/dev/tty01
	115200
	connect "/usr/sbin/chat '' 'atdt1' 'ogin:' 'x' 'sword:' 'x'"
	crtscts
	defaultroute
	lock
	netmask 255.255.255.0
	n.n.n.n:n.n.n.n
	-ip
	modem
	mtu 1500
	-detach
<p>
	You will, of course, have to make some changes if you have 
	multiple ppp connections.  The key here is the '-detach' to 
	make the pppd remain connected to the controlling terminal 
	(the modem).  The basic idea is if the link drops (i.e. loses 
	carrier), a hangup signal will be sent to pppd, causing it to 
	exit, and init will restart it.
<p>
	You can also try 'demand dialed PPP' by getting the iij-ppp
	package from the following:
<p>
	<a href="ftp://ftp.iij.ad.jp/pub/network/iij-ppp0.94beta2.tar.gz)">ftp://ftp.iij.ad.jp/pub/network/iij-ppp0.94beta2.tar.gz)</a> 
<p>
	It supports BSDI's BSD/386 1.1, FreeBSD-2.0, and NetBSD-1.0, but 
	it should be really easy to make it work with NetBSD-1.1 (it 
	comes with a patched NetBSD-1.0 tun driver... to get it working
	with 1.1 or -current you will need to make the same patches to 
	NetBSD-1.1's tun driver).  You can also try 'dp' at:
<p>
	<a href="ftp://phoenix.acn.purdue.edu/dp/dp-4.0.tar.gz">ftp://phoenix.acn.purdue.edu/dp/dp-4.0.tar.gz</a>
<p>
<p>
<a name="7.2.1"><h3>7.2.1 : I have a problem with my PPP connection. From time to time, the connection will just 'pause'. If I do something in another window which polls some other external machine, the connection will 'unpause' for a while.</h3>

<p>
	There are two possibilities.  One is that the Van-Jacobsen
	compression is messing up one of the computers on the link.
	Test this by disabling VJ compression on the PPP link (change
	the options file to use '-vjccomp').  
<p>
	The other possibility is one of the machine in the circuit is
	not processing handshaking correctly.  Check the &k setting (for
	hardware handshaking) and makre sure it is set correctly.  Also
	check your cables (if appropriate).  
<p>
	Usually, this problem is caused by a handshaking error; either
	the computer can't get the modem to stop sending data, or vice
	versa.
<p>
<p>
<a name="7.3"><h3>7.3 : TCP/IP</h3>

<p>
	TCP/IP is an integral part of BSD 4.4 Lite.  There are at least 
	five different network card drivers.  TCP/IP is fully supported 
	and is available to all users of all derived BSD systems.  In 
	fact, many people believe that this area is one of the primary 
	advantages that BSD has over Linux.  After all, TCP/IP was
	invented in BSD.
<p>
<a name="7.3.1"><h3>7.3.1 : Where can I obtain *BSD source code to add IP Security per the IETF RFCs (RFC-1825 through RFC-1829) to my system ?</h3>

<p>
	People in the US can get source code for this from
	<a href="http://web.mit.edu/network/isakmp/">http://web.mit.edu/network/isakmp/</a> by following the instructions
	on the web download form.  The NRL IPsec+IPv6 distribution
	there includes IPsec for IPv4 and IPsec for IPv6 and the
	PF_KEY Key Management Socket API extension.  Needless to
	say, folks inexperienced in building kernels ought not
	be trying this.
<p>
	People outside the US can get the NRL source code
	from <a href="ftp://ftp.ripe.net/ipv6/nrl/">ftp://ftp.ripe.net/ipv6/nrl/</a>
<p>
	The NRL code comes pre-ported to BSDI and NetBSD.
	A FreeBSD port is possible but would take a little work.
<p>
	(thanks to <a href="mailto:rja@inet.org">rja@inet.org</a>)
<p>
<p>
<a name="7.4"><h3>7.4 : UUCP</h3>

<p>
	There is an excellent document included in the UUCP directory
	that describes in detail, what needs to be done to get a
	working UUCP for derived BSD systems.  Look in the 
	/usr/src/gnu/libexec/uucp directory for more information.  You 
	can also look in the /usr/share/doc/smm/09.uucpimpl and 
	/usr/share/doc/smm/21.uucpnet if yours are populated.
<p>
<p>
<a name="7.4.1"><h3>7.4.1 : TIP/CU</h3>

<p>
	First thing you need to do is...
<p>
		vi /etc/remote
<br>
<p>
	Then remove the two lines at the bottom of the file that mention 
	com1, and com2.  Now add the following lines:
<p>
		tty00:dv=/dev/tty00:br#9600:
<br>
		tty01:dv=/dev/tty01:br#9600:
<br>
<p>
	That tells tip/cu where to find your com ports.  Next you need 
	to be logged in as root and do a:
<p>
		chown uucp.dialer /dev/tty00
<br>
		chown uucp.dialer /dev/tty01
<br>
		touch /var/log/aculog
<br>
		chown uucp.dialer /var/log/aculog
<br>
<p>
	Make sure that, if you are running newsyslog, you change the 
	owner.group entry in the newsyslog.conf file so that the file
	ownership is maintained correctly.
<p>
	Then you should be all set, remember "DOS Com1" = tty00, and 
	"DOS Com2" = tty01.  So, if your modem is at 0x2F8/IRQ=3 and 
	you access it as the COM2: port from DOS, you would do..
<p>
		tip tty01
<br>
<p>
	To exit, type &ltRETURN&gt~.&ltRETURN&gt
<p>
	Many people have other problems with cu.  The lock open: 
	procedure is one of them.   If you receive the error:
<p>
	lock open: no such file or directory
	all ports busy
<p>
	You need to create a directory: /var/spool/lock, owned by uucp.  If
	this file already exists and is owned correctly, make sure that the
	lock file in the directory is deleted.
<p>
	If you receive the error "cu: write: Input/output error"
<p>
	You may be able to fix this by creating an /etc/uucp/ports file 
	(see Taylor UUCP docs).
<p>
	In addition, those of you using cu version 1.04 may need to add the
	following to their susyem:
<p>
	create an /etc/uucp/ports file that looked like this:
<p>
	port mymodem
		type modem
<br>
		device /dev/tty01
<br>
		speed 19200
<br>
<p>
	Now cu knows that the line is connected to a modem it does the 
	right thing regarding setting CLOCAL on the line.  You don't 
	even have to have either of local or softcar set in /etc/ttys.
<p>
	Since cu's behavior seems to be correct, I'm happy now.  All I 
	need to really make my day though is to have John or Martin to 
	tell me that cu 1.04 still works for them even though they don't 
	have an /etc/uucp/ports (or equivalent HDB or V2 uucp config) 
	file ... :-)
<p>
<p>
<a name="7.4.2"><h3>7.4.2 : What is the magic incantation that allows the modem to dial?</h3>

<p>
	Try 'stty -f /dev/tty0? clocal'.  Change the '?' for whatever 
	character is appropriate for your tty port.  Remember, DOS COM1 = 
	/dev/tty00 and DOS COM2 = /dev/tty01...
<p>
	Some other things that might cause some problems are the entries
	in the /etc/remotes file.  Try 'com?:dv=/dev/tty0?:br#19200:pa=none'
	and see if that helps.  Remember to replace the '?' with '[01234]'
	as appropriate.
<p>
	NetBSD-current has implemented the 'ttyflags' program.  This
	will set your com ports according to the options specified in
	the /dev/ttys files.  This is an even better solution than the
	'stty ... clocal' fix from above!
<p>
	FreeBSD sets this up a little bit differently by having separate
	dial in and dial out devices available.  The /dev/cua?? devices
	all have clocal set by default to allow the system to dial out
	without having a carrier present.  If you are using FreeBSD and
	don't have any cua devices in the /dev/ directory, you need to
	run the ./MAKEDEV script.  See the man page for more information.
<p>
<p>
<a name="7.4.3"><h3>7.4.3 : My modem on DOS COM3 or DOS COM4 works with DOS, but not with *BSD. It is set up using IRQ 4 (or 3) respectively.</h3>

<p>
	One of the MAJOR differences between DOS and *BSD is that *BSD
	actually USES the IRQ lines (*gasp*)...  That means that every 
	device on the ISA bus has to have it's own IRQ.  Since COM1 and
	COM2 (/dev/tty00 and /dev/tty01) are already defined using IRQs
	4 and 3 respectively, that means that COM3 and COM4 (/dev/tty02 
	and /dev/tty03) need to be put onto different IRQs.  The default
	GENERICAHA kernel defines the third com port (COM3 or /dev/tty02)
	to be on IRQ5.  You need to reconfigure your com port (for 
	external modems) or modem (for internal modems) to use IRQ5.  
	The GENERICBBT kernel defines the COM4 port to be on IRQ9 (or 2).
	If you have to put your devices on other ports, you will need to
	recompile the kernel.
<p>
<a name="7.5"><h3>7.5 : How do I configure my nameserver?</h3>

<p>
	There are several systems that implement /etc/nsswitch.conf
	instead of the /etc/resolver.conf database.  Each has advantages
	and disadvantages, and both have been implemented for NetBSD.
	If you want to use nsswitch, you can get it at '<a href="ftp://?/?'.">ftp://?/?'.</a>
<p>
<a name="7.6"><h3>7.6 : Terminals</h3>

<p>
	Since the target machine for most BSD machines is a 386 with 
	no more than a couple of serial ports, most people do not bother 
	with serial terminals.  For most problems, a quick perusal of the 
	man pages for the ttys file and getty are enough to get them 
	started.  Other than that, most terminal problems are limited to
	peculiarities of particular terminals.
<p>
	One common problem that appears to crop up from time to time is
	which wires need to be connected at each end of the cable.  Most
	cables do not, in fact, pass through all lines.  If your terminal 
	uses XON/XOFF (DC1/DC3) protocol, a cable of the appropriate 
	twist, either straight through or null modem, can have as few as
	three lines connecting the two devices.  Assuming DB-25 connections
	at each end, the lines need to go from 2 to 3, 3 to 2, and 7 to 7.
	These lines are Rx, Tx, and gnd.  Other lines that may or may not
	be required include 4 and 5; and 6, 8, and 20.  Normally, these 
	lines would be connected within the 'hood' of the cable (4 to 5 
	and 6 and 8 to 20) to simulate the functionality of the full 
	blown cable.  While full support for CTS/RTS is not available 
	(yet), other support for the remainder of these lines is available 
	or is being worked on in all BSD derived systems.  Without this
	handshaking (particularly pins 6, 8, and 20) your ports may appear
	to be dead.  This is because most of the tty driver for *BSD 
	systems require a Data Carrier Detect to be active before the
	port will work.
<p>
	For those folks that have hardware flow control working, you need
	to look in the man page for 'stty' and look around for the 
	-clocal and -ctrcrts options.
<p>
	Once the cable is set up, you will need to make sure that your
	system is ready.  The first thing you will need to do is make all
	of the devices in the /dev/ directory.  A program, called MAKEDEV,
	is available in the /dev directory.  Running this program with 
	the argument 'tty' will make all of the physical tty devices.
<p>
	With that done, arranging for a 'getty' on the port is the next 
	order of business.  You will need to edit the '/etc/ttys' file
	and make one of the tty devices available.  If you have 
	connected your terminal to DOS COM1, you will be enabling 
	/dev/tty00.  Similarly, if you are connected to COM2:, you will
	be enabling /dev/tty01 (see the pattern?).  There are other
	names for those ports as well, but when you are talking about 
	terminals, be sure to use the '/dev/tty*' names.  If not, you 
	will be completely ignored and treated as an outcast because 
	you obviously have not done any of your homework.
<p>
	One of the other common problems with the SIO driver is that 
	people will often disable all handshaking, and then complain
	that they cannot get a reliable connection above 9600 baud.  
	Handshaking is the solution to most of these problems.
<p>
<p>
<a name="7.7"><h3>7.7 : My network manager (or UUCP feed site admin) just informed me that the way I have installed sendmail through my UUCP connection and has caused a sendmail loop. Can you help me get sendmail installed correctly?</h3>

<p>
	(1) Go into sendmail's source directory tree
<p>
	    cd /usr/src/usr.sbin/sendmail/cf/cf
<p>
	(2) Make the missing obj directory first, you need it later...
<p>
	    mkdir obj
<p>
	(3) Create a sendmail master configuration file (.mc file). Name 
	it yourname.mc
<p>
	    vi yourname.mc
<p>
	(4) Contents of the yourname.mc file:
<p>
	#---------------------------------------------------------------
	divert(-1)
	#
	#  This is the prototype for a site with only a uucp connection
	#  to the world, where smarthost and uucp relay are the same ...
	#  Replace "yourname" with your machines nodename without domain
	#  Replace "smarthost" with your uucp neighbours nodename without 
	#  domain i.e. here is myname "knobel" and my smarthost is "gomel", 
	#  to which I'm connected with uucp via dialup modem.
<p>
	divert(-1)
	VERSIONID(`yourname.mc 1.0')
<p>
	include(`../m4/cf.m4')
<p>
	OSTYPE(bsd4.4)
<p>
	FEATURE(nodns)dnl
<p>
	MAILER(local)dnl
	MAILER(smtp)dnl
	MAILER(uucp)dnl
<p>
	define(`UUCP_MAX_SIZE', 2000000)dnl
	define(`SMART_HOST', `uucp-dom:smarthost')dnl
	define(`UUCP_RELAY', `uucp-dom:smarthost')dnl
	#--------------------------------------------------------------
<p>
	In the siteconfig directory (.../sendmail/cf/siteconfig)
	create a file uucp.yourname
<p>
	Put a list of machines into this file to which you have active
	uucp/mail connection. Generally only the name of your smarthost 
	....  Unknown addresses are routed to your smarthost ....
<p>
	siteconfig/uucp.yourname:
	#----------------------------------------------------------------------
	SITE(nodename_of_your_smarthost)
	#----------------------------------------------------------------------
<p>
	(5) create the new sendmail configuration file, which will be 
	stored under obj/yourname.cf, by typing
<p>
	    make yourname.cf
<p>
	(6) After that copy obj/yourname.cf to /etc/sendmail.cf
<p>
	(7) It's up to you to browse through the systems global aliases
 	file ((etc/aliases), where important mail aliases are stored.
	After editing this file you should invoke the command newaliases 
	to update the corresponding database file
<p>
	newaliases
<p>
	(8) Then create/edit the file "/etc/sendmail.cw".   This file 
	contains alias names of your system (a list of additional names 
	under that your system might receive e-mail):
<p>
	yourname
	yourname.uucp
	yourname.domain
<p>
	(9) Then create a file /etc/mailertable:
	Here you have to say what else (uucp addresses, too)
	has to be sent to your smarthost ...
<p>
	.uucp		uucp-uudom:name_of_your_uucp_smarthost
<p>
	(10) Create the hash table the following way:
<p>
	makemap hash /etc/mailertable.db &lt /etc/mailertable
<p>
 	Remember, if you make any changes you have to rebuild the
 	aliases database by typing:
<p>
	    newaliases
<p>
	(11) BTW: You do not need to create a frozen config file,
	since sendmail on FreeBSD 1.X and NetBSD aren't compiled with 
	that option turned on.
<p>
	(12) ``Hot files'' with more information (see sendmail src tree):
    	FAQ KNOWNBUGS RELEASE_NOTES cf/README
<p>
<p>
<a name="7.8"><h3>7.8 : Can network attached assets be used by/from NetBSD? FreeBSD? OpenBSD?</h3>

<p>
	Yes, they can, assuming the machine at the other end of the 
	connections is reasonably cooperative.  The specifics are up to
	the remote machine, but a couple of things that you can start 
	looking for that will help are provided below:
<p>
		-  Ask the system administrator of the machine in
<br>
		   question if it is OK for you to use whatever it is 
<br>
		   you need.  This is more a matter of manners than a 
<br>
		   technical issue. 
<br>
<p>
		-  For NFS mounted disk drives, make sure that you are 
<br>
		   not prevented from using the assets by the 
<br>
		   /etc/exports (or equivalent) file.  This goes for 
<br>
		   CD-ROMs as well as regular mounted disks.
<br>
<p>
		-  There are a completely different set of concerns for
<br>
		   tapes and printers.  Each system implements these in
<br>
		   slightly different ways.  Check with your system 
<br>
		   manager or documentation for more information.
<br>
<p>
		-  Diskless booting is possible for all three systems,
<br>
		   for a little more detail, see below.
<br>
<p>
	Note that not all network clients are created equal.  There may
	be semantic differences between what you EXPECT to happen and
	what actually happens.  Your best bet at that point is to get
	with the local system manager and talk to him or her about what
	you should be expecting on the system and what is actually
	happening.  An excellent example is the semantics of file group
	accounts when a new file is created on an NFS machine.  The
	semantics of the create will be based on the OS on the SERVER,
	so it will be whatever SysV or Sun thinks is correct, not what
	we expect from the BSD side.
<p>
	There is a package available which can also be used by *BSD
	which will allow your machine to be visible to LanManager or
	Windows NT clients.  The package is called 'SAMBA' and includes
	information about how to configure the package to work with
	NetBSD, OpenBSD, and FreeBSD.  Works good for me.
<p>
<p>
<a name="7.8.1"><h3>7.8.1 : Is it possible to Network boot a NetBSD machine from a network on a diskless Sparc?</h3>

<p>
	Yes, it's even more than possible, it actually works!  Since
	OpenBSD tracks NetBSD closely, it is also possible to do this
	with OpenBSD.
<p>
	Anders Magnusson (<a href="mailto:ragge@ludd.luth.se">ragge@ludd.luth.se</a>) has run it on diskless
	SLCs, and the only problem they had was when the machine got
	heavily loaded it ran out of mbufs (also sometimes a problem for
	regular systems).  It is reportedly faster than SunOS4 as long
	there was lots of free memory in the machine.
<p>
	For the most part, setting up a diskless client is fairly
	straightforward.  The FreeBSD diskless FAQ gives step by step
	instructions for setting up bootp and the other programs that
	need to be configured.
<p>
<p>
<a name="7.8.2"><h3>7.8.2 : I have been working with FreeBSD 1.5.1 with some machines configured as diskless. How can I do the same for 2.0R (i.e., Which are the magic words to put in the Kernel configuration file?)</h3>

<p>
	In FreeBSD, there is a file called Diskless.FAQ in the
	usr/share/FAQ directory.  It describes the procedures for
	diskless booting of an i386 on FreeBSD.
<p>
	Please note that netboot.[cr]om programs from FreeBSD 1.1.5.1 
	do not work with 2.0 and vice versa.
<p>
	Note that this is just a pointer to the Diskless FAQ.  You can
	get the file from ftp.freebsd.org.
<p>
<p>
<a name="7.8.3"><h3>7.8.3 : How can I get ISDN to work?</h3>

<p>
	It depends.  There are several levels of ISDN, all of which seem
	to be incomaptible.  One of the highly regarded packages for
	adding most ISDN connectivity is the bisdn package available
	from muc.ditec.de.
<p>
<p>
<a name="section_8"><h2>Section 8.	("Supported" Hardware List)
</h2>
<p>
<a name="8.0"><h3>8.0 : What hardware works!</h3>

<p>
	The problem with this section of the FAQ is that software is 
	the only reason that every PC card on the planet does not work.
<p>
	EISA cards are not directly supported; when and if EISA
	is directly supported, they will give a significant performance
	advantage to EISA bus machines.  As it happens, users who desire 
	more than 16Meg of memory must use either VESA or EISA systems.
	Even with an EISA system, many users will not be able to use the
	address space above 16Meg unless their system uses only EISA 
	cards for those devices that need access to DMA.  The limitations
	are covered in another section of the FAQ.
<p>
	Many EISA cards operate in an ISA emulation mode.  Notably, the
	Ultrastore 24F SCSI controller operates in an IDE emulation mode 
	that allows the card to be used in the current system without 
	modification.  Most EISA cards that operate in ISA mode will 
	work with 386BSD, NetBSD, or FreeBSD.
<p>
	Like EISA, MCA is unsupported currently; unlike EISA, it can't
	work until it is supported, as it doesn't fall back to ISA
	operation.  If you want to work on this problem, I'm sure that
	many people will appreciate it; you will probably need an ISA or
	EISA machine to do the work, however.
<p>
	On top of all of that, NetBSD (being the 'horizontal' entry in
	the *BSD family) supports about 13 CPUs.
<p>
<p>
<a name="8.3.1"><h3>8.3.1 : How do I configure multiport cards? Is there a possibility of using multiport serial boards? How do you configure an AST/4 in the kernel? It looks like the AST driver only supports 4-port cards, but it looks like it would be easy to add support for 8 ports ... or am I wrong?</h3>

<p>
	From: "Martin Husemann" &lt<a href="mailto:martin@euterpe.owl.de">martin@euterpe.owl.de</a>&gt 
	All AST 8 port Cards I have seen simply were two AST-4-port on 
	one board. You would configure them like this:
<p>
	 master	ast0	at isa? port 0x1a0 tty irq 5 vector astintr
	 master	ast1	at isa? port 0x2a0 tty irq 7 vector astintr
<p>
	With that said, the discussion about these cards continues with
	how to make older versions of *BSD react correctly to your AST
	4 or 8 port cards.
<p>
	The AST/4 and its clone multiport cards can run on 386BSD using 
	patchkit 0.2.4 and later, NetBSD, and FreeBSD.  The only
	problems seem to be that the code in older versions of
	sioprobe() and sioattach() in sio.c needs to be hacked to get
	it to properly detect the ports and then recognize the type 
	of UARTs installed (16550As).  The code segment that is causing 
	the problem is included below:
<p>
	A configuration for this is when two AST Four Port cards
	are actually used in a system.  The configuration for that looks
	like this:
<p>
<p>
	#device  sio0    at isa? port "IO_COM1" tty irq 4 vector siointr
	#device  sio2    at isa? port "IO_COM3" tty irq 5 vector siointr
<p>
	device   sio1    at isa? port 0x2a0 tty flags 0x0481
	device   sio2    at isa? port 0x2a8 tty flags 0x0481
	device   sio3    at isa? port 0x2b0 tty flags 0x0481
	device   sio4    at isa? port 0x2b8 tty irq 5 flags 0x0481 
				vector siointr
<br>
<p>
	device   sio5    at isa? port 0x1a0 tty flags 0x0881
	device   sio6    at isa? port 0x1a8 tty flags 0x0881
	device   sio7    at isa? port 0x1b0 tty flags 0x0881
	device   sio8    at isa? port 0x1b8 tty irq 4 flags 0x0881 
				vector siointr
<br>
<p>
<p>
	This is one of the areas where FreeBSD and NetBSD have
	diverged.  The actual semantics of the multiport boards have
	changed since this section was originally written (the flags
	are either no longer needed or are different in current NetBSD
	implementations, for example).
<p>
<p>
<a name="8.3.3"><h3>8.3.3 : What is the difference between baud and bits per second?</h3>

<p>
	It's important to remember that we're transmitting symbols. Does
	this apply to digital transmissions?  Yes. A digital message is
	simply an ordered sequence of symbols from a discreet source. This
	source has an alphabet 'M' of 2 or more symbols, and produces
	the symbols at some rate 'r'.
<p>
	If we allocate a finite amount time alloted to a symbol, and call
	that time 'D', we can for once and ever define what baud is. Having
	'D', our "signaling rate" is:
<p>
	    r = 1/D                       (1)
<p>
	measured in _symbols_per_second_ or baud. For binary transmissions,
	we have a bit duration Tb, and our "bit rate" is:
<p>
	    rb = 1/Tb                     (2)
<p>
	measured in _bits_per_second_, (bps, or b/s).
<p>
	Now we note that in the special binary (M=2) case, each bit is
	a symbol and thus D=Tb, and by (1) and (2) we have:
<p>
	    r (baud) = rb (bps)           (3)
<p>
	or in English, for *binary* transmissions, we have "the signalling
	rate, measured in baud, is the same as the bit rate, which is
	measured in bps."  For all other transmissions, the signalling
	rate (baud) is not equal to the bit rate (bps).
<p>
	-Ade "never wants to see this again" Barkah
<p>
<p>
<a name="8.4"><h3>8.4 : Disk Controller Problems</h3>

<p>
	There is no real list of supported wd-driver controllers.  The listx
	would be far longer than I am willing to type.  Suffice it to say 
	that virtually every know IDE/ESDI/MFM/RLL hard drive controller
	available works.  There are occasional reports that the driver
	for this particular type of disk drive is "broken", but it is hard
	to substantiate this.  There are a few known "gotchas" with this
	particular controller type, but they are fixed as soon as they are 
	found.
<p>
<p>
<a name="8.4.2"><h3>8.4.2 : SCSI controller problems</h3>

<p>
	Every once on a great while, someone will post a problem with a
	SCSI controller.  Almost all of these are attributed to either
	a) bad cables (or out of spec cables), b) bad termination, or
	c) incorrect irq/drq setup.  Here is an excerpt of a message
	that provides some insight into one man's problems with the
	Adaptec controller, and one with the BusLogic 445.
<p>
<p>
	From: <a href="mailto:witr@rwwa.com">witr@rwwa.com</a> (Robert Withrow)
<p>
	Problem: When the bus hangs, all devices have their access
	lights off, the AHA his its light on. 
<p>
	Being in a hurry, I made several changes and the problem went
	away. Normally, I would change one thing at a time, but, like I
	said, I was in a hurry.  Below, I list the changes I made:
<p>
	  1) I replaced the AHA with an older one I keep as a spare.
<p>
	  2) I *inserted* the the ``synchronous negotiation'' jumper in 
	  the aha.
<p>
	  3) I removed the terminator power jumper from two of the hard
	  drives. 
<p>
	  4) I removed and reinserted all of connectors into all of the
	  drives. 
<p>
	If I had to guess, I bet #2 was the thing that fixed the
	problem.
<p>
	The system has compiled X11 three times as well as done all 
	sorts of other things including all of the drives (cdrom, disk, 
	and tape) for three days now without a single hang.
<p>
	<a href="mailto:wjw@ebh.eb.ele.tue.nl">wjw@ebh.eb.ele.tue.nl</a> (Willem Jan Withagen) writes:
<p>
	=&gt  =&gt  The BT kernel requires the controller to be configured 
	=&gt  =&gt  for IRQ 12.  That is a strange default.  The default for 
	=&gt  =&gt  the BT445S is 11, the same as for the 1542.  You probably 
	=&gt  =&gt  just need to reconfigure the controller.
	=&gt  
	=&gt  So I redid the switches and the BT kernel recognizes it on 
	=&gt  int 12.  Either with or without EISA DMA (switch 2-10)
	=&gt  
	=&gt  it no longer generates the stray interrupt 7.
	=&gt  But it still doesn't boot after the message 
	=&gt  	'changing root device to fd0d'
	=&gt  
	=&gt  So what's going on here. Is there anyway to find out more?
	=&gt  Or should I go to one of the FreeBSD lists and discuss it there?
<p>
	I was browsing thru the hardware manual of the BT 445S and there 
	it was on the next page :-( I was just misguided by the nice 
	switches on the card edge. 
<p>
	To set the interrupts not only the dip-switches need to be changed.
	More important is the actual and physical connection of intr 12 to
	the ISA bus connector.
<p>
	After taking the board out, and really connecting intr 12, the 
	system booted the BT kernel without a glitch.  I'm now compiling a 
	new kernel with all our options set as we'd like them to be. 
<p>
	The current config:
		16 Mb
<br>
		BT 445S with intr 12 and switch 2-10 in default state, 
<br>
		giving DMA on channel 5.
<br>
<p>
	Things I'm going to test:
		toggling the 2-10 switch
<br>
		adding 16 MB more.
<br>
<p>
<p>
<a name="8.5"><h3>8.5 : SCSI Controllers</h3>

<p>
	The list of "supported" hard drive controllers is very short.
	Basically, it is any hard drive controller that emulates a
	standard IDE/ESDI/MFM controller and a few SCSI controllers.  
	The short list is included below:
<p>
	These boot with the kcaha floppy:
		Adaptec 1522		ISA	SCSI	Experimental
<br>
		AIC-6260 based		ISA	SCSI	
<br>
		AIC-6360 based		ISA	SCSI
<br>
		Adaptec 1540[ABC]	ISA	SCSI	No Floppy
<br>
		Adaptec 1542[ABC]	ISA	SCSI
<br>
		Adaptec 174x		EISA	SCSI
<br>
		Adaptec 294x		????	SCSI	Not supported
<br>
		Ultrastore 14F		ISA	SCSI
<br>
		Ultrastore 24F		EISA	SCSI
<br>
		Ultrastore 34F		VLB	SCSI
<br>
		Buslogic BT542		ISA	SCSI	
<br>
		Buslogic BT545		ISA	SCSI	(Old ones only)
<br>
		Buslogic BT946C		PCI	SCSI
<br>
		NCR 53C810 based	PCI	SCSI
<br>
<p>
	These boot with the kcbt floppy:
		Buslogic BT742A		EISA	SCSI
<br>
		Buslogic BT747A		EISA	SCSI	(modified 742 driver)
<br>
		Buslogic BT445S		VLB	SCSI
<br>
<p>
	Note that the Ultrastore 24F is supported with an experimental
	driver or in IDE emulation mode only.  Any controller that
	purports to be a clone of one of the cards listed above will
	usually work as well.
<p>
	The '{something} based' cards above are special in that many 
	controllers use these controller chips as the basis for their 
	implementation.  The AIC-6260 is the chip set in the Adaptec 
	1522 series controllers, and the AIC-6360 is the chipset used 
	in the Soundblaster SCSI controller.  There are several PCI 
	controllers that are using the NCR chipset.
<p>
	In addition, there is a special note for Buslogic card users.
<p>
	The card should be configured to use ioaddr 0x330 and IRQ 12.
	There are two places the IRQ needs to be set.  The first is a
	bank of dip switches, and te next is a jumper.  See your hard
	drive controller documentation for the exact settings.
<p>
	Once you've got the controller on the right settings.  As it
	says in the README.INSTALL file, after all:
<p>
	BT742 SCSI Cntlr.       0x330   12               [kcopy-bt-floppy]
<p>
	So I can only conclude that you've probably not configured the
	card for EISA DMA!  From the /usr/src/KNOWNBUGS file:
<p>
	/sys/1/isa/bt742a.c
            The Bt445S and Bt747 controllers can cause problems when
	    ISA DMA is selected as an option.  With the EISA controller
	    the remedy is easy - simply turn it off using your EISA 
	    configuration utility.  With the Bt445S, which is a VLB
	    card, you must switch the undocumented "SW10" on "SB2" to
	    the off position.  Also note that certain revisions of the
	    Buslogic board (Revision C or earlier, firmware revision
	    &lt3.37) will cause DATA CORRUPTION with systems containing
	    more than 16MB of memory.  If you find this to be the case, 
	    temporarily remove your extra memory and contact Buslogic
	    for an upgrade!
<p>
	The BT946C PCI card works flawlessly.  The only thing that needs
	to be done to it is to ensure that the the two jumpers that
	control how and if to autoconfig are removed.  This allows the
	system to autoconfigure everything in the card.  The best thing
	to do is simply set the card to use the "Autoconfig to default"
	option.
<p>
<p>
<a name="8.6"><h3>8.6 : Network Cards</h3>

<p>
	Common misconception number 1: Why does BSD still support such 
	a small selection of network cards?
<p>
	Depends on what you mean by `small'.  Here is the 'short list'.
<p>
	3c501                   isa     if_el           (<a href="mailto:kimmel@cs.umass.edu">kimmel@cs.umass.edu</a>)
	3c503			isa	if_el		(mycroft) 
	3C507			isa	if_el		(mycroft) 
	3c509  			isa	if_ep   bnc/aui/utp.      (tdr)
	3c579			eisa	if_ep		  (tdr)
	WD 8390-based cards 	isa	if_ed		  (mycroft)
	SMC 8390-based cards 	isa	if_ed		  (mycroft)
	NE1000, NE2000    	isa	if_ed		  (mycroft)
	NE2100/BICC Isolan/DEPCA isa	if_le		  (mycroft)
	AT&T StarLAN (82586-based cards)		  (mycroft)
<p>
	These are all in NetBSD, and FreeBSD (by inference)
<p>
   	Common question number 2: I have a 3Com 3c509 - is it supported?
<p>
	The 3C509 works well under NetBSD-current, and has been clocked
	at full ethernet speed.  To use the UTP connection, you will need
	to specify the link0 and link1 options in the ifconfig command.
<p>
		-link0  disable AUI/UTP. enable BNC.
<br>
		link0   disable BNC. enable AUI.
<br>
		link1   if the card has a UTP connector, and link0 is
<br>
			set too, then you get the UTP port.
<br>
<p>
<p>
<a name="8.7"><h3>8.7 : Printers</h3>

<p>
	First, set up your printer so it uses the 'LF' code as its 
	CR+LF (End of line) character.  If you use your machine for 
	operations in more than one OS (like some of us that HAVE 
	to use DOS :-( ) then you can include a control sequence in 
	the 'ff' control in your /etc/printcap file.
<p>
	Here is an example printcap to show you how simple it is:
<p>
	lp|ljgpc_deskjet|HP DeskJet Plus:\
		:lp=/dev/lpt0:mx#0:\
<br>
		:sd=/var/spool/ljgpc_deskjet:\
<br>
		:lf=/var/log/lpd-errs:\
<br>
		:ff=\033E\033&k2G:fo:sh:tr=\033E:
<br>
<p>
<p>
	For the HP LaserJet III (running PostScript) or the Deskjet 540 
	printers, the sequence is a little more involved:
<p>
	First, it looks like you will need to install ghostscript.  I have 
	a Desk Jet 540 that I use with the printcap entry and filter 
	included below.  You could hack the filter slightly to produce 
	output for your Laser Jet III (try changing "-sDEVICE=djet500" to 
	"-sDEVICE=ljet3").
<p>
	You'll need perl and gs installed on your system.  You also need to
	ensure that gs has the ljet3 driver installed.  You can find out by
	running "gs -h" and looking to see if the driver is listed.
<p>
	--- printcap entry ---
	lp|HP Deskjet 540:\
	    :lo=/var/spool/lpd/lp-lock:\
	    :lp=/dev/lpt0:\
	    :lf=/var/log/lpd-errs:\
	    :of=/var/spool/ps-filter:\
	    :sd=/var/spool/lpd:\
	    :sh:
<p>
	--- /var/spool/ps-filter ---
	#!/usr/bin/perl
	# Filter which detects postscript files and appends cr to lines of text.
	# $Id: ps-filter,v 1.3 1995/02/14 01:05:59 brian Exp $
<p>
	$cat="/bin/cat";
	$gs="/usr/local/bin/gs";
<p>
	$_ = &ltSTDIN&gt;
	if (/^%!/)
	    {
    	    # Pipe the file as-is to the ghostscript interpreter.
    	    # Postscript files have their pages reversed because my
    	    # DeskJet 540 stacks them in reverse order if I don't.
    	    $old_dir=`pwd`;
    	    $tmp_dir = "/tmp/lp-gs.$$";
    	    mkdir($tmp_dir,0700);
    	    chdir $tmp_dir;
    	    open(PIPE, "|$gs -q -sDEVICE=djet500 -sOutputFile=%03d.lj -")
		|| die "$0: can't run ghostscript: $!";
<br>
    	    print PIPE $_;
    	    while (&ltSTDIN&gt)
    	    {
		print PIPE $_;
<br>
    	    }
    	    close PIPE;
    	    @pages=reverse(sort(&lt*.lj&gt));
    	    system $cat, @pages;
    	    unlink @pages;
    	    chdir $old_dir;
    	    rmdir $tmp_dir;
	}
	elsif (&isprint() && !/\r\n$/)
	{
    	    # Send the text to the printer with trailing lf converted to crlf.
    	    s/([^\r])?\n$/\1\r\n/;
    	    print;
    	    while (&ltSTDIN&gt)
    	    {
		s/([^\r])?\n$/\1\r\n/;
<br>
		print;
<br>
    	    }
	}
	else
	{
    	    print;
    	    while (&ltSTDIN&gt)
    	    {
        	print;
    	    }
	}
	sub isprint
	{
    	    ($c) = split(//,$_);
    	    return ($c =~ /[\s\n]/) || (ord($c) &gt= 32 && ord($c) &lt 127);
	}
<p>
	If you are having trouble with the JetDirect card, this entry
	should work adequately for you, although printing and querying
	may not be completely solid:
<p>
		laser: \
<br>
        		:rm=laser.kew.utl: \
			:rp=lp: \
<br>
			:sd=/usr/spool/lpd/laser: \
<br>
			:lf=/var/log/lpd-errs: \
<br>
			:sh: \
<br>
			:rs: \
<br>
			:ff=: \
<br>
			:fo
<br>
<p>
<p>
<a name="8.7.1"><h3>8.7.1 : How can I print big files (especially from SAMBA, the WfWg network program)?</h3>

<p>
	First step:  Add ":mx#0:" to the printer's entry in /etc/printcap.
<p>
	Once you have "mx#0" in your /etc/printcap entry, make
	sure you have enough disk space in the "/var" filesystem to 
	handle the job.  Also beware that "lpr -s" can fail obscurely
	if the file you are printing (and the path to it) are not accessible
	by the user daemon.
<p>
<p>
<a name="8.8"><h3>8.8 : Tape Drives.</h3>

<a name="8.8.1"><h3>8.8.1 : What are the jumper configurations for the Exabyte 8200 DAT tape drive?</h3>

<p>
	Jumpers/switches are on the MX board. I think that the top of the 
	case and the board must be removed to access jumpers/switches.  
	Per a November 1989 8200 Spec there are at least two different MX 
	boards. Level 1, part no 724021-xxx has jumpers. Level 2, part no 
	724022-xxx has switches.
<p>
	Level 1 Jumper Configuration:
<p>
	J1 L-M Bypass Memory Test - 8 Second Startup
    	   M-R Run Memory Test - 65 Second Startup
<p>
	J2 L-M Parity Checking Enabled
   	   M-R Parity Checking Disabled
<p>
	J3 L-M Even Byte Disconnect
           M-R Odd or Even Byte Disconnect
<p>
	J4 L-M No Busy Enable
           M-R Report Busy Status
<p>
	J5 L-M P6 Cartridge Type - Domestic
    	   M-R P1 Cartridge Type - International
<p>
	J6 L-M Reserved for future use
<p>
	J7 L-M Normal Operations
   	   M-R No Disconnect in Data Phase
<p>
	J8 L-M Fixed Block Mode on Power Up
   	   M-R Variable Block Mode on Power Up
<p>
	Level 2 Switch Configuration:
<p>
	SW1 Off Run Memory Test - 65 Second Startup
    	    On Bypass Memory Test - 8 Second Startup
<p>
	SW2 Off Parity Checking Disabled
     	    On Parity Checking Enabled
<p>
	SW3 Off Odd or Even Byte Disconnect
    	    On Even Byte Disconnect
<p>
	SW4 Off Report Busy Status
    	    On No Busy Enable
<p>
	SW5 Off Fixed Block Mode on Power Up
    	    On  Variable Block Mode on Power Up
<p>
	SW6 Off Normal Operations
    	    On No Disconnect in Data Phase
<p>
	SW7 Off Reserved for Future Use
    	    On 
<p>
	SW8 Off P6 Cartridge Type - Domestic
    	    On P1 Cartridge Type - International
<p>
<p>
<a name="8.9"><h3>8.9 : QIC-40/80 tape drives</h3>

<p>
	Steve Gerakines has released a series of patches for FreeBSD that
	allow the use of the QIC-40/80 tape drives through the floppy
	controller.  Get them from ftp.gte.com:/pub/ft/dist0.3/dist0.3.tgz
	or a similar mirror site, if there are any.  Archie will be able
	to tell you for certain.
<p>
<p>
<a name="8.10"><h3>8.10 : CD-ROMs</h3>

<p>
	The Sony CDU 561 works well, as do the Toshiba 401 and 4101.  The
	4101 is a double speed SCSI-2 device and allows 'grabbing' of
	music tracks.
<p>
	Many folks have announced that they had problems with Mitsumi
	CD-ROM drives.  It seems that there are nearly as many releases
	of the firmware as there were drives sold.  Many of the firmware
	versions were incompatible with each other.  A generic Mitsumi
	driver will be a hard act to accomplish, if it is possible at all.
	The current Mitsumi driver seems to work well with all of the
	Mitsumi controllers (FD-001x and older).
<p>
	There are native (non-EIDE) Mitsumi CD-ROM drivers for NetBSD and 
	FreeBSD.  They are available in the latest release version of each.
	If your CD-ROM is not recognized by the kernel, and uses a Mitsumi
	controller, you will need to make changes to the mcd.c source
	file to change the behavior of the first getreply() function.
	Instead of exiting immediately, the check for whether the
	getreply was successful should be commented out and assumed to
	be correct.  While this is a brute force method (it may find a
	CD-ROM that isn't even there) it will help many Mitsumi
	controllers probe correctly.  
<p>
	The EIDE ATAPI CD-ROM drive is now supported in the -current
	versions of FreeBSD and OpenBSD, and is supported experimentally 
	in NetBSD Version 1.2 and higher.
<p>
	FreeBSD also supports the Matsushita (Panasonic) CD-ROM drives.  
<p>
	The only other commonly available CD-ROM drive that is not
	supported is the SONY CD-ROM.  
<p>
<p>
<a name="8.10.1"><h3>8.10.1 : How can I mount my CD-ROM so that it appears to be writable?</h3>

<p>
	There are two ways.  If the version of *BSD you have supports
	the union file system, you can use the following:
<p>
	    mount -t union -o -b /cdrom/ports /usr/ports
	    cd /usr/ports
	    make all install
<p>
	If you want to use an fstab entry, try this:
<p>
	    /cdrom/ports /usr/src union rw,-b 0 0
<p>
	If your version of *BSD doesn't support union file systems, you
	could use something like this:
<p>
	    mount /dev/cd0a /cdrom
	    mkdir /usr/ports
	    cd /usr/ports
	    lndir /cdrom/ports .
	    &ltwait for dirs to link up&gt
<p>
	    cd /usr/ports/mail/elm
	    make all install
<p>
<a name="section_9"><h2>Section 9	("Supported" Software List).
</h2>
<p>
<a name="9.0"><h3>9.0 : What GNU software has been tested and is working with Net/2 derived BSD systems for the 386?</h3>

<p>
	Just about all of it.
<p>
<p>
<a name="9.1"><h3>9.1 : Has anyone ever gotten news to work?</h3>

<p>
	The program 'news' running on 386bsd.  Here is a quick summary of 
	the major places to stumble:
<p>
	1)  get bash, gmake, gcc 2.X, cnews, trn (or your favorite reader).
<p>
	2)  Make uucp work. (Read the info files that come with the
	    original distribution for the whole scoop on configuration 
	    files.)
<p>
	Ed Note:  This step is not needed if you are implementing SLIP,
	PPP, or are directly connected to a network.
<p>
	3)  Edit all the scripts which come with cnews and replace every 
	occurrence of /bin/sh with /usr/local/bin/bash (or wherever you put 
	it).
<p>
	4)  Build cnews using bash, gmake and gcc 2.x
<p>
	5)  Install cnews in the directories you want it.  Some hand-hacking 
	of the install scripts is required (Too long ago to remember the 
	details).
<p>
	6)  Change the permissions on all the scripts from execute only to 
	read-execute for group and other.  (On 386bsd, if you can't read 
	a script, you can't execute it).
<p>
	7)  Set up uucp to accept news
<p>
	8)  Post an article and steal it out of the uucp queue before it 
	gets sent.  Feed it to your rnews (as user uucp) instead and make 
	sure that it does not bomb out with permission denied or some such.
<p>
	9)  Have fun!
<p>
	Implementing innd is even easier.  The configure script that comes 
	with the system has been modified to work more correctly with
	Net/2 derived BSD systems.  The first is that the LINTLIBSTYLE
	option in config.data needs to be set to NONE, since NetBSD and 
	FreeBSD don't come with lint.  With that changed, the system
	should work right out of the box.
<p>
	If you are running with memory mapped files, you will also need
	to make the following patch:
<p>
	--- icd.c.orig  Tue Feb  7 13:36:50 1995
	+++ icd.c       Tue Feb  7 14:56:27 1995
	@@ -366,7 +366,9 @@
	 ICDwriteactive()
	  {
	   #if    defined(ACT_MMAP)
	   -    /* No-op. */
	   +    if (msync(ICDactpointer, 0)) {
	   +       syslog(L_ERROR, "msync error on active file: %m");
	   +    }
<p>
	    #else
<p>
<a name="9.1.1"><h3>9.1.1 : I want to make sure I have every set up right for my news partition. What newfs options do I need to use to get this information stored OK without future problems?</h3>

<p>
	There has been a lot of discussion of the years about the default
	options for newfs.  If you have "modern" disks and you created 
	your filesystems with 1.0, or with a pre-9412 -current, then 
	you may want to back them up and then re-create them.  u
	Filesystems created with the current defaults should be much 
	faster.
<p>
	The newfs(8) defaults are equivalent to `-a 8 -d 0 -n 1'.
<p>
	To make you news server software work better, you should
	increase the number of inodes available, you should include
	either '-i 512' or '-i 1024' depending on the normal size of the
	files in the filesystem.  News partitions are often the
	repository for many files which are very small, averaging less
	than 512 bytes per file.  By quadrupling the number of inodes
	(using -i 512 instead of the default 2048) you make it more
	likely that you will run out of disk SPACE before you run out of
	disk INODES. 
<p>
<p>
<a name="9.3"><h3>9.3 : Has anyone tried to get Postgres to work?</h3>

<p>
	Jim Bachesta and his crew have gotten Postgres 4.2 working in
	the i386 version of NetBSD 1.0.  The netbsd source tree is
	available from:
<p>
	<a href="ftp://charon.amdahl.com:pub/agc/postgres-4.2-src-netbsd-v2.tar.gz">ftp://charon.amdahl.com:pub/agc/postgres-4.2-src-netbsd-v2.tar.gz</a>
<p>
	The regular postgres distribution is available from:
<p>
	<a href="ftp://s2k-ftp.cs.berkeley.edu:pub/postgres">ftp://s2k-ftp.cs.berkeley.edu:pub/postgres</a>
<p>
	Get the standard distribution and then overlay the NetBSD source
	distribution over it for a complete system.
<p>
	There is also work in progress to get Postgres95 working.
	Check the following URL for more information:
<p>
	<a href="ftp://s2k-ftp.cs.berkeley.edu/pub/postgres95/postgres95-1.0.tar.gz">ftp://s2k-ftp.cs.berkeley.edu/pub/postgres95/postgres95-1.0.tar.gz</a>
<p>
	It works fine on NetBSD/i386 1.1. I've heard that it works 
	fine on the sparc port, too, so there don't seem to be any 
	byte-order funnies in there (although take a look in the 
	www/bugs/p*.html for 14 patches that should be applied to 
	the 1.0 sources - at least one of them deals with 
	order-dependencies when the backend is on a different 
	byte-ordered machine to the client program).
<p>
	Someone mentioned that you need dynamic loading, and so you 
	may be out of luck if you're on one of the more esoteric 
	ports.  I'm not sure about this, and would say that pg95 
	should run fine, albeit with reduced functionality, without 
	dynamic loading - it just means that you can't define C 
	functions for the backend to load at will. However, I 
	haven't tried this.  (From memory, the previous v4r2 port 
	didn't have support for dynamic loading, and most of the 
	regression tests ran fine.)
<p>
<p>
<a name="9.4"><h3>9.4 : Has anyone gotten the Java Developers Kit working?</h3>

<p>
	There are a couple of ways to go about this.  The first is just
	use either the FreeBSD or Linux version and load up the /emul
	directory.
<p>
	The second is to load Penguin or Kaffe, both Java replacements.
<p>
<p>
	    <a href="http://coriolan.amicus.com/penguin.html">http://coriolan.amicus.com/penguin.html</a>
<p>
        i386 FreeBSD 2.0.5R & 2.1.0R            (tested)
        i386 Linux 1.2.13                       (tested)
        i386 NetBSD 1.1R                        (untested)
        i386 Solaris 2.4                        (untested)
<p>
	The source for the most recent version of Kaffe can be found at 
	the following location:
<p>
            <a href="ftp://ftp.sarc.city.ac.uk/pub/kaffe/kaffe.tgz">ftp://ftp.sarc.city.ac.uk/pub/kaffe/kaffe.tgz</a>
<p>
	This version has extensive improvements over version 0.1 (see the 
	README in the distribution), and is now distributed using a 
	Berkeley style license so can be used for both personal and 
	commercial purposes.
<p>
	In addition to Kaffe, there is a Java Bytecode compiler called
	"Guavac" which works with NetBSD, FreeBSD, and OpenBSD.
<p>
	* Java, Javasoft, and Java Virtual Machine are registered 
	trademarks of Sun Microsystems, Inc.
<p>
<p>
<a name="9.5"><h3>9.5 : Has anyone ever used any of the BSD systems for a Firewall?</h3>

<p>
	In my experience, most of the commercial firewall systems
	started out as BSD systems.  
<p>
	There are several choices when it comes to firewalls for *BSD
	systems.  There is Juniper, a "transparent p[ass through" system
	that allows non-routable networks to lurk behind the firewall
	and block traffic from the outside.  Another is the TIS Firewall
	Toolkit.  <a href="Http://puma.macbsd.com/macbsd.howto/fwtk-faq.html">Http://puma.macbsd.com/macbsd.howto/fwtk-faq.html</a> has
	an excellent set of instructions on using and building a
	firewall using TIS.
<p>
	There are several other offerings out there; nearly all of them
	will easily lay on top of an existing BSD installation.  After
	all, BSD was where TCP-IP was invented.
<p>
<p>
<a name="9.6"><h3>9.6 : How about the BSD Song?</h3>

<p>
	In a dark dim machine room
	Cool A/C in my hair
	Warm smell of silicon
	Rising up through the air
	Up ahead in the distance
    	I saw a Solarian(tm) light
    	My kernel grew heavy, and my disk grew slim
    	I had to halt(8) for the night
    	The backup spun in the tape drive
    	I heard a terminal bell
    	And I was thinking to myself
    	This could be BSD or USL
    	Then they started a lawsuit
    	And they showed me the way
    	There were salesmen down the corridor
    	I thought I heard them say
<p>
    	Welcome to Berkeley California
    	Such a lovely place
    	Such a lovely place (backgrounded)
    	Such a lovely trace(1)
    	Plenty of jobs at Berkeley California
    	Any time of year
    	Any time of year (backgrounded)
    	You can find one here
    	You can find one here
<p>
    	Their code was definitely twisted
    	But they've got the stock market trends
    	They've got a lot of pretty, pretty lawyers
    	That they call friends
    	How they dance in the courtroom
    	See BSDI sweat
    	Some sue to remember
    	Some sue to forget
    	So I called up Kernighan
    	Please bring me ctime(3)
    	He said
    	We haven't had that tm_year since 1969
    	And still those functions are calling from far away
    	Wake up Jobs in the middle of the night
    	Just to hear them say
<p>
    	Welcome to Berkeley California
    	Such a lovely Place
    	Such a lovely Place (backgrounded)
    	Such a lovely trace(1)
    	They're livin' it up suing Berkeley California
    	What a nice surprise
    	What a nice surprise (backgrounded)
    	Bring your alibis
<p>
    	Windows NT a dreaming
    	Pink OS on ice
    	And they said
    	We are all just prisoners here
    	Of a marketing device
    	And in the judge's chambers
    	They gathered for the feast
    	They diff(1)'d the source code listings
    	But they can't kill -9 the beast
    	Last thing I remember
    	I was restore(8)'ing | more(1)
    	I had to find the soft link back to the path I was before
    	sleep(3) said the pagedaemon
    	We are programmed to recv(2)
    	You can swap out any time you like
    	But you can never leave(1)
<p>
    	[ substitute whirring of disk and tape drives for guitar solo ]
<p>
	Written by David Barr &lt<a href="mailto:barr@pop.psu.edu">barr@pop.psu.edu</a>&gt
	and Ken Hornstein &lt<a href="mailto:kenh@physci.psu.edu">kenh@physci.psu.edu</a>&gt
	and a little help from Greg Nagy &lt<a href="mailto:nagy@cs.psu.edu">nagy@cs.psu.edu</a>&gt
<p>
	and thanks to the lyrics archive at cs.uwp.edu
<p>

<hr>

</body></html>

--------------167E2781446B--

