Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[comp.unix.bsd] NetBSD, FreeBSD, and OpenBSD FAQ (Part 1 of 10)

1 view
Skip to first unread message

Dave Burgess

unread,
Sep 27, 1997, 3:00:00 AM9/27/97
to

Posted-By: auto-faq 3.1.1.2
Archive-name: 386bsd-faq/part1

<pre>
Frequently Asked Questions
386BSD, NetBSD, FreeBSD, OpenBSD and
other BSD derived Operating
Systems.


EXTREMELY UNOFFICIAL


Original FAQ by:
Terry Lambert

New New FAQ by:
Dave Burgess

bur...@cynjut.neonramp.com


Last Update: 26 Jun 1997
</pre>

Section -1. (Where else to look)

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 Section 1 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.


Section 0. (Basic FAQ information)

0.0 Master Index.

0.0 Master Index.
0.1 A brief history of the *BSD family.
0.1.1 How close is NetBSD (or FreeBSD) to BSD 4.4?
0.1.3 Where can I get more information about the *BSD family
of Operating Systems?
0.2 About this FAQ.
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?
0.3 Are there any resources on the Net (like URLs)
associated with the BSD family of operating systems?
0.4 How to add your pet answer to the FAQ.
0.5 Administrivia.
0.6 Does anyone reading this have any sense of humor at all?

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?

1.1 Minimum hardware configuration recommended
1.4 Where to get the source and binaries
1.4.1 Where can I get the distribution on CD ROM?
1.5.3 *BSD system mailing lists.
1.5.4 System Updates.
1.6 Documentation available
1.6.1 BSD manuals
1.6.2 BSD books
1.6.6 The O'Reilly and Associates BSD 4.4 Set.
1.6.7 Other FAQ's on the net that are relevant
1.7.1 Official distribution sites
2.0 Install process
2.0.1 Boot disks (versions and media formats)
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?
2.0.1.2a The floppy booted, but now the hard disk won't boot?
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?
2.0.1.4 What are the options on the boot prompt?
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.
2.1 Binary distribution
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.
2.2 Configuration
2.2.1 Partitions
2.2.1.1 What is a 'disklabel' and why do I need one?
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?
2.2.2 Common Disk Label Problems.
2.2.2.1 Increasing the *BSD partition size.
2.2.2.2 I can access the DOS partition on my second disk from
Unix but not DOS? Any suggestions?
2.2.2.3 I want to use my entire 2 Gig drive as the root
partition. Why doesn't it work?
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?
2.2.3 How do I get the system to boot from the second hard
drive?
2.2.4 How do I disklabel my second hard drive?
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?
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?
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?
2.2.8 What are the options for the boot up prompt?
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'.
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?
2.2.11 I am having trouble getting net aliases to work. What
could some of the problems be?
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?
2.2.13 I want to hard wire my SCSI devices to a particular
device number. Is that possible?
2.3 Common installation problems.
2.3.2 Endless reboot cycles.
2.4 The computer just sits there, or 'that isn't right'.
2.4.1 The boot disk works all right on one computer but not
another.
2.4.2 Really strange errors in the various *BSD flavors.
2.4.2.2 Using the new code in NetBSD, I get a "panic: pdti
206067" in pmap_enter(). What should I do?
2.4.3a I get the error "isr 15 and error: isr 17" on an NE2000
card.
2.4.3b I have some card on IRQ2 and it doesn't work; why?
2.4.3c I am getting lousy performance out of my network card.
What are some of the other possibilities?
2.4.4 What is the difference between IRQ2 and IRQ9? Are they
really the same, or are they really different?
2.4.5 Some of my SCSI devices (like a tape drive) don't work;
why?
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?
2.4.7 Is there a SCSI utility which works to fix up the random
problems I sometimes have with my drives?
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?
2.5 Other common problems that are attributed to the
installation process but are caused other places.
2.5.1 I want to use more than 16 Megabytes of memory. Will any
of the BSD based systems support it?
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?
2.6 Customizing the system to meet my needs.
2.6.1 How do I get the system to not display the machine name,
but display our company name?
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?
3.0 System Internals
3.1 Kernel
3.1.1 How do I build a kernel?
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?
3.1.1.2 How do I port NetBSD to another platform?
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.
3.1.3 I want to build and profile a kernel. What do I need to
do?
3.1.4 Now that I have a kernel, how do I install it?
3.1.5 My system is complaining about stray interrupt 7. Is my
machine going to explode or anything?
3.1.6 I keep getting "wd0c: extra interrupt". What does it
mean?
3.1.7 I keep getting silo overflow messages, but the system
doesn't seem to mind. Is there a problem?
3.1.8 I found a bug in the kernel. How do I report it?
3.2 What exactly is this config file, anyway? What are all
of these cryptic notations?
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?
3.2.2 What should I remove from the kernel?
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?
3.2.4 How do I get ddb, the kernel debugger, compiled into the
kernel and running?
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?
3.2.6 Can I patch the current running OS image?
3.2.7 Can I have more than one config file? Should I rename it
to something else? Any other hints?
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?
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?
3.2.8.2 How do I dedicate 16Meg of memory to nothing but disk
buffers?
3.2.9 Where can I learn more about all this?
3.3 Other kernel related kind of questions.
3.3.1 Has the method for system call changed in NetBSD?
3.3.2 Does anyone have a system building script that takes
things like building a new config and multiple config
files into account?
3.3.3 How do I upgrade from my release version of NetBSD (and
probably FreeBSD) to the '-current' development sources?

3.3.4 Is there a Makefile that does all that happy
world-building stuff?
3.3.5 Can NetBSD do cross compilation?
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?
3.4 X11/XFree86/XS3
3.4.1 What options should I define to get the X extensions
included?
3.4.2 Where can I get the FAQ for 'X'?
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?
3.4.4 What can I do to figure out why 'X' doesn't work with
NetBSD?
3.4.5 Under NetBSD and FreeBSD, xlock (or any other program
that uses passwords) fails to validate user passwords.
Anyone know why?
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?
3.6 You promised to talk about timezones below. Are you
going to?
3.6.1 How do you change the timezone on NetBSD (FreeBSD
also?)?
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?
3.7 How can I implement CVS to track MY changes to the
kernel source tree, yet still follow the -current
development tree?
3.8 Optional Op-codes for NetBSD, FreeBSD, and other
systems.
4.0 Introduction
4.1 Common (sort of) Kernel-related problems
4.1.1 Sometimes I have trouble with my system resetting the
terminal to seven bit mode. Isn't BSD eight bit clean?
4.1.2 How do you implement quotas on Net/2 derived BSD
systems?
4.1.3 What are the correct permissions for the /tmp, /usr/tmp,
and /var/tmp directories?
4.2 Available kernel add-ons
4.2.1 Loadable Kernel Modules
4.3 Other program building type problems.
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?
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.
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?
4.4 System Administration Questions
4.4.1 Where can I get good books about NetBSD or FreeBSD?
4.4.2 I am concerned about system security. What should I do
to protect my system from net attacks?
4.4.3 How can I log failed login attempts?
4.4.4 Can I use a Concatenated Filesystem with NetBSD?
4.4.4.1 Why, when I type "ccdconfig ccd0 16 none /dev/wd0a >
/dev/wd1a", do I get back "ccdconfig: ioctl (CCDIOCSET):
/dev/ccd0d: Device not configured"?
4.4.5 I am really new to Unix System Administration. I need
some real basic help.
4.4.5.1 What is the System Administrator's user name?
4.4.5.2 I can't log in as 'su'. What does that message mean when
I log in as root.
4.4.5.3 Are there any books I can 'bootstrap' myself with?
4.4.5.4 How about some code examples?
4.5.6 How do I change the default shell for a user?
4.5 Daemon questions
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?
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?
4.5.3 Are there any alternatives to 'NIS' available for
NetBSD, et al.?
4.6 Adding new and removing old users.
4.6.1 Where can I FTP the 'adduser' program?
4.6.2 Where can I get a 'rmuser' script?
5.0 Introduction
5.1 A replacement curses program/library.
5.2 Floppy Disk problems.
5.2.1 How do I get a bootable floppy?
5.2.2 How do I maximize the space on a mountable floppy disk.
5.3 Character Device Driver info
5.3.1 Printers
5.3.2 Terminals/Keyboards
5.3.3 Modems/FAX Modems
5.3.3.1 How do I add a modem to *BSD:
5.3.3.4 Adding a Dial-in/Dial-out FAX to NetBSD or FreeBSD.
5.3.4 What is the trick for getting Kermit to work with rz and
sz?
5.4 Tape Drives
5.4.1 Does the tape need to be formatted?
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
5.4.3 When is erst0 used?
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?
5.4.5 How is an appropriate block size determined (and in what
units are they specified in the st(1) command)?
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.
5.4.6.1 Is st's notion of "file" the record sequence between two
eof marks?
5.4.6.2 What about a "record"?
5.4.6.3 Is a "record" one "block", as determined by st's
"blocksize" command? If not, what is the connection
between them?
5.4.6.4 Can I change the "record" size?
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.
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
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?
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?
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?
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?
5.4.13 My tape drive doesn't work.
5.4.14 I am trying to restore a tape from a FreeBSD machine on
a Sun. What kinds of problems should I expect?
5.4.15 What are the jumper settings for the Archive Viper tape
drive?
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?
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.
5.5 Network Stuff
5.5.1 How can I get my system to work as a network router?
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?
5.5.3 Does anyone have an example of a working gated.conf
file? I can't figure these instructions out at all.
5.5.4 How do I set up Multicasting on my system?
5.6 I want to use my ZIP drive. Are there any weird things I
need to know?
6.0 Working with DOS and BNR/2 related software.
6.1 Formatting a floppy
6.2 Sharing the Disk with MS-DOS
6.2.1 How can I partition my drive to support both MS-DOS and
*bsd?
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?
6.2.4 Is there any hope of ever running MS-DOS applications
under any of the free BSD systems?
6.2.5 How do I get Linux executables to run under NetBSD?
6.3 Accessing the MS-DOS filesystem
6.4 NFS/PC-NFS support
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.
6.4.2 How do I get around the NFS "Permission denied" error?
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?
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?
6.4.5 I get a lot of 'ring buffer overflow' messages using NFS
and the ed0 driver. Is there a problem?
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?
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?
6.5 How can I use mtools with the 'new' floppy naming
convention?
7.0 Communications
7.1 SLIP/CSLIP
7.2 PPP
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.
7.3 TCP/IP
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 ?
7.4 UUCP
7.4.1 TIP/CU
7.4.2 What is the magic incantation that allows the modem to
dial?
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.

7.5 How do I configure my nameserver?
7.6 Terminals
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?
7.8 Can network attached assets be used by/from NetBSD?
FreeBSD? OpenBSD?
7.8.1 Is it possible to Network boot a NetBSD machine from a
network on a diskless Sparc?
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?)
7.8.3 How can I get ISDN to work?
8.0 What hardware works!
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?
8.3.3 What is the difference between baud and bits per second?

8.4 Disk Controller Problems
8.4.2 SCSI controller problems
8.5 SCSI Controllers
8.6 Network Cards
8.7 Printers
8.7.1 How can I print big files (especially from SAMBA, the
WfWg network program)?
8.8 Tape Drives.
8.8.1 What are the jumper configurations for the Exabyte 8200
DAT tape drive?
8.9 QIC-40/80 tape drives
8.10 CD-ROMs
8.10.1 How can I mount my CD-ROM so that it appears to be
writable?
9.0 What GNU software has been tested and is working with
Net/2 derived BSD systems for the 386?
9.1 Has anyone ever gotten news to work?
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?
9.3 Has anyone tried to get Postgres to work?
9.4 Has anyone gotten the Java Developers Kit working?
9.5 Has anyone ever used any of the BSD systems for a
Firewall?
9.6 How about the BSD Song?


0.1 A brief history of the *BSD family.

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.

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.

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.

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.

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.

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.

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.

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.

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.


0.1.1 How close is NetBSD (or FreeBSD) to BSD 4.4?

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.


0.1.3 Where can I get more information about the *BSD family of
Operating Systems?

Here are the current members of the *BSD family. These are
presented in alphabetical order, to avoid implying anything.

386BSD - An older version of BSD now targeted exclusively at
the research and academic community. CD distributions only,
sold by Dr. Dobb's Journal.

FreeBSD - A version of BSD for Intel platforms only and targeted
at a broad user base. See http://www.freebsd.org for details or
ftp://ftp.freebsd.org/pub/FreeBSD for the latest release.

NetBSD - A version of BSD for many different platforms, from
Intel to the 68K to the DEC ALPHA. See http://www.netbsd.org for
more details or ftp://ftp.netbsd.org/pub/NetBSD for the latest
release.

OpenBSD - Another version of BSD. See http://www.openbsd.org for
more details or ftp://ftp.openbsd.org/pub/OpenBSD for the latest
release.


0.2 About this FAQ.

This FAQ consists of several parts:

Section 0. Basic FAQ information
Section 1. General Network Information
Section 2. Common installation questions
Section 3. Kernel Building and Maintenance
Section 4. Kernel Additions
Section 5. Kernel Replacement Parts
Section 6. Interaction with MS-DOS
Section 7. System Communication
Section 8. NetBSD for the Mac FAQ
Section 9. NetBSD for the Amiga FAQ
...
Section n. NetBSD for the Timex Sinclair FAQ

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.


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?

Jordan Hubbard, one of the FreeBSD core team members, has
offered this missive on that very subject:

[ Note: You could very well simply substitute the word
"NetBSD", "OpenBSD", or "Windows 95" for "Linux" in the
argument that follows ]

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.

Both arguments are a waste of time.

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! :-)

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? :-)

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!

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.

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!).

Whichever you run, you're getting a great deal - enjoy!

Jordan Hubbard


0.3 Are there any resources on the Net (like URLs) associated with
the BSD family of operating systems?

Yup:

http://www.public.iastate.edu:~gendalia/FAQ/FAQ.list.html
http://www.freebsd.org/
http://www.openbsd.org/
http://rfhs1012.fh.uni-regensburg.de/~feyrer/
http://www.cd.chalmers.se/~nh/netbsd.html
http://www.flame.org/netbsd/projects
ftp://ftp.uni-regensburg.de/pub/NetBSD-Amiga/.index.html
ftp://ftp.cdrom.com:/pub/FreeBSD/packages/WWW.tgz
ftp://ftp.netbsd.org:pub/NetBSD/mailing-lists
ftp://flick.lerc.nasa.gov:~ftp/pub/NetBSD/packages/i386
ftp://ftp.iastate.edu:/pub/Netbsd/FAQ
http://sirius.ics.es.osaka-u.ac.jp/~kamahara/NetBSD-X68060
http://wwwipd.ira.uka.de/~frueauf/FAQ/NetBSD-Amiga-X-FAQ.txt

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:
<pre>
Handle Channel
'hubertf' #netbsd
</pre>

0.4 How to add your pet answer to the FAQ.

This is the trickiest part of this section of the FAQ. There are
only two criteria for getting an entry made into the FAQ:

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.

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.

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.

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.

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 :-)


0.5 Administrivia.

Send all question/answer pairs to bur...@cynjut.neonramp.com,
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.

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?


0.6 Does anyone reading this have any sense of humor at all?

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!

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

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.

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.

-------------
Q) Which is better? NetBSD, OpenBSD, Linux, or FreeBSD?


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.


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.


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.

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.

DID YOU KNOW?
=============

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.

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.

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.


--
Dave Burgess Network Engineer - Nebraska On-Ramp, Inc.
*bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom
"Just because something is stupid doesn't mean there isn't someone that
doesn't want to do it...."

Dave Burgess

unread,
Sep 27, 1997, 3:00:00 AM9/27/97
to

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

Section 2. (Common installation questions)


2.0 Install process

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.

Once the bootable images are written onto the floppies, insert
the dist.fs disk into the A: drive and reboot. If the system
does not boot, see section 2.5 below for more information.

If the disk boots, type install and proceed to use the
INSTALL.NOTES to get more information.

Problems with the install are either related to hardware (i.e.
Do you want to install on your T.V.?) or software. Of the
hardware issues, the most common FAQs are usually straight out
of the installation notes. Of the software issues, there are
only two that really concern us. The first is bad files.

On some systems, files that are loaded from floppy appear to
'go bad' when they arrive on the hard disk. Try some of these
solutions:

- You forgot binary. Don't get insulted. Those of us that FTP
for a living forget sometimes. If so, the distribution will
come out with all different sizes and install will complain
about every disk.

- One or two of the files are no good. Try getting them again.
As a precaution, rename the bad files on your hard drive to
names like foo.1 and bob.23. Copy the files again from floppy.
If they are still bad, rename the file, and the one immediately
before the first bad file (bin01.23 if 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.

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.

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.

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.

Second, you will need to find the directory with the bootable
disk images in it. They will have self explanatory names like:

<pre>
kerncopy.fs
base0-9.fs
fred.fs
genericaha.fs
boot-me-first.fs
this-is-the-file-with-the-fs-extension.fs
</pre>

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.

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.

You did back your system up, right?

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).


2.0.1 Boot disks (versions and media formats)

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?

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

There is also an install procedure that 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'.

Failing that, you can use the following process to extract the
sources.

- First, 'cd' to where your files are.
- Assuming you want to extract the kernel sources, use the
following command to extract the files:

"cat ksrc* | tar -xvf - -C /"

This will combine the pieces, feed them to tar, and load the
files in the 'standard' place.

2.0.1.2a The floppy booted, but now the hard disk won't boot?
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?

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.

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

But on the other hand, maybe not...

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


2.0.1.4 What are the options on the boot prompt?

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.


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.

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.

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.

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.

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.


2.1 Binary distribution
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.

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.

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.

The usual error message (which may ONLY appear in
/var/adm/messages) is "nfs_server: weak authentication, source
IP address=xx.xx.xx.xx"

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:

<pre>
# mount -o resvport server:/fs /mnt_point

</pre>
or to use the -P flag (which does the same thing). See the
mount and mount_nfs man pages for the details.

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:

<pre>
-P server:/fs
</pre>

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.


2.2 Configuration

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

A less frequently asked question is "Where can I get info on how
to configure a kernel?" The answer to this question has been
provided by Richard Murphey (Email address ri...@Rice.edu).

--------------------------------------------------------------------
Ready-to-print PostScript files for each section of the net2 system
maintainer's manual are on nova.cc.purdue.edu in
pub/386bsd/submissions/bsd.manuals.

smm.02.config.ps.Z describes kernel configuration for the VAX,
however some of it is relevant to 386BSD. There is no freely
available rewrite for 386BSD that I know of.
--------------------------------------------------------------------

Most of these manuals are now included in the standard release of
NetBSD and FreeBSD in the /usr/share/doc directories.

2.2.1 Partitions

This section describes many of the questions that people ask about
hard disk partitioning.

The first is a brief explanation of the BSD system disk partitions.

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

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

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.

Phil Nelson (pa...@cs.wu.edu) writes:
I have installed several disks that have > 1024 cylinders and
have used both DOS and NetBSD. What has worked for me EVERY TIME
is the following:

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.)

b) With fdisk, partition your 1023 cylinders as you want them.

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.

d) Use NetBSD!

Chris Jones writes:

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.

This tutorial is provided by by "Hacksaw" <hac...@user1.channel1.com>
and provides an excellent overview of the hard disk partitioning
procedure from start to finish.

"Disk Partitioning for the Compleat Idiot"

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

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

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

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

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

In a beautiful world, we might have a very free hand at this set-up
and expect it to work. Unfortunately, the authors of the software
dealing with the hard drives either decided or were forced by
circumstance to make certain things about the disklabel inviolate.

When you let the installation disk set the disklabel for you first
drive it comes out like this:
<pre>

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).
</pre>

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

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

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

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

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.

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

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

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

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

<pre>
# /dev/rwd1d:
type: ESDI
disk: maxtor7245
label:
flags:
bytes/sector: 512
sectors/track: 31
tracks/cylinder: 16
sectors/cylinder: 496
cylinders: 967
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # milliseconds
track-to-track seek: 0 # milliseconds
drivedata: 0

5 partitions:
# size offset fstype [fsize bsize cpg]
a: 198400 0 4.2BSD 512 4096 16 # (Cyl. 0 - 399)
b: 31744 447392 swap # (Cyl. 902 - 965)
c: 479136 0 unused 0 0 # (Cyl. 0 - 965)
d: 479136 0 unused 0 0 # (Cyl. 0 - 965)
e: 248992 198400 4.2BSD 512 4096 16 # (Cyl. 400 - 901)
</pre>

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

248992 + 198400 + 31744 = 479136 (all the parts should equal the whole)

Some things I discovered (for all you in novice land like me...)

1. As you can see this disk has 967 cylinders, but I only refer to 966
of them, 0 - 965... This is because it's good practice to leave the
"Landing Zone" cylinder out of it... This is usually the last
cylinder, and it's where the read/write heads hang out when your disk
is off...

Note from TSgt Dave:

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

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

On the boot drive (The drive that actually contains the kernel), a:
is the boot partition. On all other drives, it is a regular partition.
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.

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

Note from TSgt Dave:

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

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

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

* NOTE: This is a thumbnail sketch; read the man page to verify all
of the options and be sure about how to proceed...

5. then fsck the partition:
fsck /dev/rwd?x

Don't forget that fsck should be run on the RAW device.

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

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

One last note from TSgt Dave:

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

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.

Commonly used definitions:

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

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

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

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


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?

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.

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.

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.

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.

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.

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. :-)

I suggest that the defaults for newfs be changed to:

<pre>
-n 1 -d 0 -a 16 -r 5400
</pre>

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.

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.

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.

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.

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?)


2.2.2 Common Disk Label Problems.

2.2.2.1 Increasing the *BSD partition size.

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.

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:

/dev/vnd0b swap swap sw

Defining the file for the vnode is fairly straightforward:

vnconfig -c /tmp/swapfile /dev/vnd0b

and actually making it swap is as simple as

swapon /dev/vnd0b

From there, the rest of your questions should be answerable from
the vnconfig manpage.


2.2.2.2 I can access the DOS partition on my second disk from Unix but not
DOS? Any suggestions?

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.

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
<pre>
1 6 0 69 DOSbi # ..
2 165 70 98 unkno
</pre>
for a 99 cyl drive.

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.

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).

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.

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.


2.2.2.3 I want to use my entire 2 Gig drive as the root partition. Why
doesn't it work?

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.


2.5.3 How do I set up the system so that I can boot from more than one
operating system/file-loader without using floppies?

There are many people that wish to be able to boot DOS or 386bsd
at will. There are several programs that allow this. The
program "os-bs" is one such program, "BOOTEASY" is another, and
there are three or four others. There are problems in some
configurations using the os/2 boot manager for this, so beware.

In addition to being able to boot from either of two partitions,
some people want to operate more than one disk drive (and perhaps
boot from either as well). Christoph Robitschko provided one
description of this. Since there are virtually limitless
possibilities for configurations for BSD systems, it will be
impossible to answer all of the possible questions about these
features. Many people operate with multiple disk drives on one
or more controllers.

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


2.2.3 How do I get the system to boot from the second hard drive?

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

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:
<pre>

loadstart:

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


and change it to:


loadstart:

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

</pre>
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).


2.2.4 How do I disklabel my second hard drive?

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

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

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

For instance, the following line works for me:

disklabel -w -r sd0 <drive-type>

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

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

Also, some folks want to mix SCSI and IDE drive together in the
same system.

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:

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.

The 1542CF switches are 1-4 off (open), 5-8 on. The meaning is as
follows:

<pre>
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.
</pre>

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.

I could not configure the system to boot from the SCSI drive having
the IDE as a secondary drive.

(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. )


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?

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.

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

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

This sort of problem happens when you try to install NetBSD in a
partition of a disk whose controller does geometry translation. I
have not had time to find the bug that causes the problem. One
option is to disable the geometry translation: Use ide_conf to
find the true geometry, use the CMOS setup program to tell your
BIOS about the true geometry, and reformat everything. I
successfully did that on one of my systems.

If you are not able to, or do not wish to, disable the geometry
translation then the following work-around might work for you.
This requires that the disk have unused space on {cylinder 0,
head 0}, from sector 2 to sector 16. Almost all DOS disks that
I have ever seen satisfy this condition, because they usually
start the DOS partition in {cylinder 0, head 0, sector 1},
leaving most of {cylinder 0, head 0} unused apart from the
partition sector in {cylinder 0, head 0, sector 1}. However,
many partitioning programs like to hide this fact from you,
and pretend that the DOS partition starts at the front of the
disk; don't believe them until you have checked with a raw
disk editor.

0. Make sure you have adequate backups.

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

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

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

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

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

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

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

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

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

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

2.2.6 I am having trouble installing on the EIDE hard drive. What are
some of the things that I need to look into?

Bradley W Mazurek (bwm...@skorpio3.usask.ca) writes:

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.

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....

[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...]

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.

1. there is _different_ behavior, if one executes
<pre>
disklabel wd0 or
disklabel /dev/wd0c or
disklabel /dev/wd0d
</pre>
It didn't get quite clear to me, what these differences are exactly.

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.

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):

[...]

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:

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.

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.

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.

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.

[...]

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?

Steve Gilbert (gil...@cs.utk.edu) provided us with this answer:

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).

1. BACK UP EVERYTHING!

2. fdisk -u wd1

...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.

3. My 420 MB Conner drive has 16 heads, so I just enter 15 as
the ending head number.

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 :-)

5. Reboot and watch NO error message pop up!

...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.


2.2.8 What are the options for the boot up prompt?

The options are supposed to be as follows:

<pre>
-s............... boot into single user mode
-a............... ask the user what device to use as root
just before mounting it (Not presently supported)
-d............... once you have the kernel loaded and VM and such up
and going, drop into the kernel debugger.
(great for debugging probe code)
</pre>

A related question concerns the options on the 'reboot' program.
These flags are as follows:
<pre>
-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
</pre>

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.

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.


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'.

This is caused by incorrect settings in /etc/netstart and/or
/etc/hosts.

In /etc/hosts, you must have a line that says:

<pre>
127.0.0.1 localhost localhost.{yourdomainhere}
</pre>

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.'

In /etc/netstart, you must do:

<pre>
ifconfig lo0 localhost
route add {hostname} localhost
</pre>

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.

*AND*, if you're not going to be directly connected to a
network, you should change /etc/host.conf to say:

<pre>
hosts
bind
</pre>

It's set up the other way around by default. I don't like it
that way myself.

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.

Make sure that:

- 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.

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.

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.


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?

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).

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.

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".


2.2.11 I am having trouble getting net aliases to work. What could
some of the problems be?

There are many things which will cause network aliases to not
work right. Here are a few:

- 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).

The correct syntax in /etc/rc.local for declaring a net address
alias (assuming you are updating the eth0 interface) is:

<pre>
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
</pre>

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).


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?

Bring the PPP connection up again. Retry whatever-it-is that's
failing.

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.


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.)

At the IP level, the relevant statistics are
<pre>
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
[...]
0 output packets dropped due to no bufs, etc.
</pre>

At the TCP level, look for, e.g.,

<pre>
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
</pre>

Any of these being non-zero would support the hypothesis of a
bug in the PPP implementation. Unlikely, but one never knows.

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.

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??


2.2.13 I want to hard wire my SCSI devices to a particular device
number. Is that possible?

You can do the numbering any way you please. Say I had two
controllers. You could number them as:

<pre>
sd10 at scsibus0 target 0 lun ?
sd11 at scsibus0 target 1 lun ?
[...]
sd20 at scsibus1 target 0 lun ?
sd21 at scsibus1 target 1 lun ?
[...]
</pre>

Of course, you will need to add devices to the /dev/ directory
for each of them, pointing to their correct major and minor
numbers.

You can also hardwire the 'scsibus' numbers, by doing something
like the following (assuming "whatever" is the SCSI host adapter
driver's name 8-):

whatever0 at whateverbus? [whateverbus config info]
scsibus0 at whatever0

then

<pre>
sd0 at scsibus0 target 0 lun 0
</pre>

etc.


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.

The most common configuration for locked down drive numbers is
actually:

<pre>
sd0 at scsibus0 target 0 lun 0
sd1 at scsibus0 target 1 lun 0
sd* at scsibus? target ? lun ? # SCSI disk drives
</pre>

You can do the same thing with your tapes, CDs, and other SCSI
devices as well.

<pre>
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.
</pre>


2.3 Common installation problems.

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

2.3.2 Endless reboot cycles.

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.


2.4 The computer just sits there, or 'that isn't right'.

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

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....


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

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

- Misconfigured hardware. The iomem, IRQ, and other board
settings must match the ones listed in the INSTALL.NOTES.
Unfortunately, the INSTALL.NOTES are on the disk that will
not boot. You can grab them via FTP from 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.

- 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.

- 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.


2.4.2 Really strange errors in the various *BSD flavors.

2.4.2.2 Using the new code in NetBSD, I get a "panic: pdti 206067" in
pmap_enter(). What should I do?

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.


2.4.3a I get the error "isr 15 and error: isr 17" on an NE2000 card.
2.4.3b I have some card on IRQ2 and it doesn't work; why?
2.4.3c I am getting lousy performance out of my network card. What are
some of the other possibilities?

The description of this problem is that one of the cards in your
system (most likely the VGA card) is either generating interrupts
or is causing the IRQ 2 to be actively disabled. Older VGA card
used IRQ 2 during vertical retrace to prevent sparklies.

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.

From time to time, this problem will manifest itself as a general
tendency of the network card to transfer either very sporadically
or very slowly. It is precisely the same problem.

James Van Artsdalen (ja...@bigtex.cactus.org) has offered at
least one solution:

If this is the problem, you can use Scotch tape to cover
the IRQ 2 signal on the VGA's ISA connector.

There has been some discussion as to whether scotch tape is really
appropriate inside a card slot. My answer would be "yes". This is
because the alternate solution of cutting the trace on the video
board seems, to my mind, to reduce the value of the board. It is
possible that, in the future, with a bi-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.

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.

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.


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

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.

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'.

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.

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:

<pre>
Internal External Function
IRQ0 n/a Refresh/Timer
IRQ1 n/a Keyboard
IRQ2 n/a (AT only) Cascade Input to Master
IRQ3 IRQ3 Free (Com port)
IRQ4 IRQ4 Free (Com port)
IRQ5 IRQ5 Free
IRQ6 IRQ6 Floppy Controller
IRQ7 IRQ7 Free (Printer/Sound Card*)
IRQ8 n/a Real Time Clock
IRQ9 IRQ2 Free (Network card)
IRQ10 IRQ10 Free
</pre>

etc.
* 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.


2.4.5 Some of my SCSI devices (like a tape drive) don't work; why?

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.


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?

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

Matthias Urlichs (url...@smurf.ira.uka.de) has provided this
description of the types of things that can cause problems for the
controller and devices attached to it.

The problem is that the Adaptec 1542C has (a) rather powerful line
drivers, and (b) is sensitive to transient signals which can be
induced by them via either a bad cable or a bad external terminator.

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

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

So...

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

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

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

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

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

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

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


2.4.7 Is there a SCSI utility which works to fix up the random
problems I sometimes have with my drives?

That depends on the problem. One of the first things you can
try is Ian Dell's (Ian....@dsto.defence.gov.au) SCSI Disk
Doctor (sdd) package. There are NetBSD i386 and Sparc
executables on ftp://ftp.mono.org/pub/sdd. 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.


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 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.

(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.)

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.

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.

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.


2.5 Other common problems that are attributed to the installation
process but are caused other places.

2.5.1 I want to use more than 16 Megabytes of memory. Will any of the
BSD based systems support it?

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. :-)

Recently some folks have been reporting that they are getting
warnings like these:

<pre>
hostname /netbsd: sd0: not queued
hostname /netbsd: aha0: DMA beyond end of ISA
hostname /netbsd: sd0: not queued aha0: DMA beyond end of ISA
</pre>

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.

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.

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.

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

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

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

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

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

The only way to get full EISA, 32MB-of-memory-and-everything, mode
is to use an EISA controller in full EISA mode (for Adaptec 1742,
this is "enhanced" mode, for DTC 3290 it's "DTC" mode, the
Ultrastor 24F in EISA (rather than IDE emulation) mode, etc.).

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

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.

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.


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?

Garrett A. Wollman (wol...@emba.uvm.edu) provides us with this
brief discussion in answer to a specific question. It wears well
as a generic answer as well.

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.

There are three major causes for this error:

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'.)

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.

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.

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.

2.6 Customizing the system to meet my needs.
2.6.1 How do I get the system to not display the machine name, but
display our company name?

Modify the /etc/gettytab file so the default profile uses this:

<pre>
:im=\r\n Company Name (%t)\r\n\n:\
</pre>


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?

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.

Dave Burgess

unread,
Sep 27, 1997, 3:00:00 AM9/27/97
to

Posted-By: auto-faq 3.1.1.2
Archive-name: 386bsd-faq/part6

Section 5. (Kernel Replacements)

5.0 Introduction

5.1 A replacement curses program/library.

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 ftp://ftp.netcom.com:/pub/zm/zmbenhal/ncurses/

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 <ocurses.h> 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.

(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.


5.2 Floppy Disk problems.

5.2.1 How do I get a bootable floppy?

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'?:')

1) rawrite (or dd) dist.fs (or fixit.fs) to a disk,
mount it, cd to the mount point, and execute:

rm -rf .

you now have a bootable floppy!;^}

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!;^}

3) Run disklabel on the floppy, e.g.:

disklabel -w -r fd0a floppy5

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.

4) Write the boot blocks to the floppy:

cat /usr/mdec/fdboot /usr/mdec/bootfd | dd of=/dev/rfd0a

or, more simply:

cat /usr/mdec/fdboot /usr/mdec/bootfd > /dev/rfd0a

Methods 3) and 4) require you to run newfs on the floppy, e.g.:

newfs /dev/rfd0a floppy5

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!;^})

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.


5.2.2 How do I maximize the space on a mountable floppy disk.

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.

newfs -Tfloppy[35] -i[4096 | 8192] -c 80 /dev/fd[0|1]a

This leaves the disk with fewer inodes and only one cylinder group.


5.3 Character Device Driver info

These devices are also often referred to as character devices.

5.3.1 Printers

NetBSD and FreeBSD both include both an interrupt and
non-interrupt driven parallel driver in their stock
manifestations.

It is possible to connect a serial printer to either. This brief
tutorial is provided by Daryl Berryhill
(djbe...@b25info.b25.ingr.com)

The way I got my printer to work.

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#9600
5) type "lpr <add filename here>"
6) type "lpd"
and it should start printing.

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.

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.

In addition, there are people that want to set up multiple printer
queues using the BSD queuing mechanism. Here is a brief tutorial:

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.

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.

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.

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.

To map logical to physical queues either use a filter that pipes
back into lpr -P<rawqueue> itself, or just point it at the "raw"
queue using something like:

textlp|Text Printing:\
:lp=/dev/null:\
:if=/usr/libexec/lpr/lpf:\
:rm=localhost:\
:rp=lj.raw:

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:

:of=/usr/local/bin/printraw:

where /usr/local/bin/printraw looks like this:

#!/bin/sh
cat | lpr -h -Plj.raw


5.3.2 Terminals/Keyboards

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.

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.


5.3.3 Modems/FAX Modems

5.3.3.1 How do I add a modem to *BSD:

5.3.3.4 Adding a Dial-in/Dial-out FAX to NetBSD or FreeBSD.

First, here is the known working configuration for these
instructions:

- HylaFAX 3.0 beta 100.
- Zoom VFX V.32bis Faxmodem;
- Rockwell datapump.

1: Start faxq from rc.local, no options on the command line.

Add a line to your /etc/rc.local which starts up the faxq
program. Do not include any options on the command line.

2: Stary faxgetty from init, i.e. a line in /etc/ttys.

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.

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.

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^(.


5.3.4 What is the trick for getting Kermit to work with rz and sz?

Add these lines to your .kermrc file. They should do the trick.

define sz !sz \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)
define rz !rz \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)


5.4 Tape Drives

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.


5.4.1 Does the tape need to be formatted?

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).


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

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 >> 2 & 0x03, where low density == 3 and high == 1):

You have the idea.. density is controlled by bits 2 and 3

00 = default
01 = hi density
10 = medium density
11 = low density,

Unless the driver knows about you kind of drive the density values
may need to be set by hand before they make any sense.


5.4.3 When is erst0 used?

e stands for 'eject' and is bit 1 of the minor..
e.g. eject on close.. many devices can't actually do this.

There is actually a method to this whole thing:

r = raw (rst0)
e = eject (erst0)
n = No rewind (nrst0 or maybe nerst0)


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?

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.

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.


5.4.5 How is an appropriate block size determined (and in what units
are they specified in the st(1) command)?

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.

Stick to 512 on QIC 150 or less if you ever hope to swap data
with anyone else.


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.

5.4.6.1 Is st's notion of "file" the record sequence between two eof marks?

5.4.6.2 What about a "record"?

5.4.6.3 Is a "record" one "block", as determined by st's "blocksize" command?
If not, what is the connection between them?

5.4.6.4 Can I change the "record" size?
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.

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.

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

First: throw away the block devices.

'n' stands for 'No-Rewind-on-close' and will leave the tape
positioned ready for another file e.g.

tar -cf /dev/nrst0 archive1
tar -cf /dev/nrst0 archive2


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?

st -f /dev/nrst0 rewind
st -f /dev/nrst0 fsf 2
tar -xf /dev/rst0 {files}


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?


Who would have written it? :-)

Presently you can't. You`re right. Don't worry about it.

The new 'st' changes will change this somewhat, though.


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?

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.

Use dd or tar with 16 k blocks and 32 x 512 byte blocks will be
written.

Also see 5.4.15 (below) for more information if you are using an
Archive Viper tape drive.


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?

Use a bigger write size... (more efficient) Try 16k blocks.

5.4.13 My tape drive doesn't work.

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.

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).


5.4.14 I am trying to restore a tape from a FreeBSD machine on a Sun.
What kinds of problems should I expect?

The default blocksize should not be a problem, since they are
both 20K. You may need to use "dd if=/dev/rst0 conv=swab |
<archiver>" 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.


5.4.15 What are the jumper settings for the Archive Viper tape drive?

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.

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.

0 = 2kb
1 = 4kb
2 = 6kb
3 = 8kb
4 = 12kb
5 = 16kb
6 = 24kb
7 = 32kb

I'm using my viper at id 4 and disconnect size 16k. Works
perfectly.

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?

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.


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.

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.

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.)


5.5 Network Stuff

Network devices for NetBSD and FreeBSD include many types of
Ethernet cards, as well as Serial Line IP and Point to Point
Protocol.


5.5.1 How can I get my system to work as a network router?

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.

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.

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).

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.

To test your network capability, try running the following
command:

traceroute -s YOUR_ETHERNET_ADDRESS 129.186.150.150

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.


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?

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

options NMBCLUSTERS=1024

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.


5.5.3 Does anyone have an example of a working gated.conf file? I
can't figure these instructions out at all.

Here is a sample config file for a machine which has two cards,
one of the cards has an alias created like so:

ifconfig de1 inet 199.232.137.65 mask 255.255.255.192 alias

Gated is running with this config:

interfaces {
interface de0 passive;
interface de1 passive;
};

ospf yes {
backbone {
networks {
199.232.136.0 mask 255.255.255.0;
199.232.137.0 mask 255.255.255.0;
};
interface de0;
};
};

export proto ospfase {
proto direct {
199.232.136.160 mask 255.255.255.224;
199.232.137.0 mask 255.255.255.0;
};
};

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.


5.5.4 How do I set up Multicasting on my system?

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:

http://www.mediadesign.co.at/newmedia/more/mbone-faq.html

for more detailed information on all of this...


5.6 I want to use my ZIP drive. Are there any weird things I need
to know?

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.

Dave Burgess

unread,
Sep 27, 1997, 3:00:00 AM9/27/97
to

Posted-By: auto-faq 3.1.1.2
Archive-name: 386bsd-faq/part8

Section 7. (System Communication and Network Information)

7.0 Communications

7.1 SLIP/CSLIP

Serial Line I/P is supported in all versions of BSD.

Brian <br...@awfulhak.demon.co.uk> provides us with a rather
good explanation of some of the hurdles that must be overcome
for a working slip interface.

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.

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.

Sounds easy ? - well it is if you've done it before.

The _usual_ way of doing this is as follows:

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

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).

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.

CLIENT:
Set up /etc/resolv.conf to say the following (for the nameserver)
domain client.my.domain.name
nameserver 11.22.33.55

** 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.

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.

- Run `ifconfig sl0 net clientname servername netmask 0xffffff00`
- Run `route add default servername`.

"servername" is your server and "clientname" is your client.

It should now be possible to `ping host`

** my method **
Configure /etc/remote
Configure /etc/host.dial
Run `slip host`.

/etc/remote contains an extended `tip` entry. /etc/host.dial
contains a login script (and is named in /etc/remote).

Oh yes, don't forget to have a line in your kernel config saying

pseudo-device sl 2

Without this line, you may get a 'device not configured' or
'TIO...' error because the slip driver is not built into the
kernel.

Someone else mailed me their instructions for using a SLIP
service. Here they are, in all their glory.

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<n>
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 :-)

In the last quoted script file (slip-off) the unlock line should
read:

/usr/local/etc/unlock LCK..$DEVICE

1) Configuring the SLIP interface.

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'.

Put your own hostname and ip number, and that of your dial up
gateway, into your /etc/hosts. This is an example:-

127.0.0.1 localhost

158.152.1.65 gate gate.demon.co.uk
158.152.26.67 blodwen blodwen.demon.co.uk

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:-

domain demon.co.uk
nameserver 158.152.1.65
nameserver 158.152.1.193

(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.

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:-

/sbin/ifconfig sl0 <your-machine> <dial-up-machine>

on NetBSD this can be done at boot-time, by having the following
in /etc/hostname.sl0:-

inet blodwen.demon.co.uk 255.255.255.0
dest gate.demon.co.uk

(You can substitute sl0 for sl<n> if this will after another
slattach e.g. for a local machine on a fixed cable)

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).

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.

[I call it 'demon' for simplicity]

#!/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
route add default gate

# 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

# kick outgoing email
sendmail -q0m

else
# slip-on failed

fi

[ here's my /usr/local/etc/slip-on ]

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.

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).

#
# slip-on
#
# Set up a SLIP link
#

LOCKDIR=/var/spool/lock
DEVICE=tty03

PHONE=<phone number here>
USER=<your login>
PASSWORD=<your password>

if [ -f $LOCKDIR/LCK..$DEVICE ]
then
echo "SLIP device is locked"
exit 1
fi

/usr/local/etc/fix-cua $DEVICE
sleep 16000 < /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

(
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>&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
) < /dev/$DEVICE > /dev/$DEVICE


When it comes to switching off the line, I use the following. Don't
forget to adjust the sl0 as appropriate

[ I call it demon-down for simplicity]

#!/bin/sh
# stop script
#
/usr/local/etc/slip-off
/sbin/ifconfig sl0 down

[ and /usr/local/etc/slip-off ]

and adjust the DEVICE line as well.

#!/bin/sh

DEVICE=tty03

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

exit 0


And that should do it. Happy SLIPping!


7.2 PPP

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.

It should also be noted that there is a newsgroup that covers the
PPP protocol exclusively. It is comp.protocols.ppp.

Here is some information for people desiring to set up PPP in
there systems:


A simple way to do this is to use the "chat" and a chat file. I
use the following command to initiate a connection :

root# pppd tty01 19200 connect 'chat -v -f chat.my-isp'

And in the chat.my-isp file:

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

This dials, connects and negotiates the addresses from just one
line entered.

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.

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:

# Hand chat debug messages to root
local2.debug root

The PPP.FAQ was helpful, but I ignored quite a bit of it and depended
more on the online manuals.

For setting up the PPP daemon, here is some more information:

For NetBSD, it turned out that I needed to rebuild the kernel with
the following line in my config file,

pseudo-device ppp 1

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.

This is the kind of sequence I go through to start ppp:

1. Connect with kermit to my ppp account and login. The account
tells me when it starts ppp.

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)

3. Start "pppd". When the shell prompt returns, I then have
Internet access!

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:

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

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.

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.


It is important to look into the following to see if any of them
apply to you, if you still have questions:


Here is a sample PPP config.

1) Make /etc/ppp directory, then populate as follows:

2) Include the following in '/etc/ppp/options':

crtscts
modem /* This option opens the port with O_NONBLOCK if there
is a connect options specified, and resets CLOCAL when
the connection is closed */
19200
defaultroute
netmask 255.255.255.0
ipcp-accept-local
ipcp-accept-remote
noipdefault
connect "/usr/sbin/chat -v -f /etc/ppp/sample.chat"

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.

4) Include the following in '/etc/ppp/sample.chat':

ABORT BUSY ABORT 'NO CARRIER'
'' atdt5551212

rname: {sample}
sword: crack-me
annex: {whatever}
PPP.


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:

ABORT BUSY ABORT 'NO CARRIER'
'' atdt5551212

rname: {sample}
sword: crackme

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:


The following line in /etc/ttys works wonders for making a
permanent link:

tty01 "/usr/sbin/pppd" unknown on rtcsts

The file '/etc/ppp/options' looks like:

/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

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.

You can also try 'demand dialed PPP' by getting the iij-ppp
package from the following:

ftp://ftp.iij.ad.jp/pub/network/iij-ppp0.94beta2.tar.gz)

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:

ftp://phoenix.acn.purdue.edu/dp/dp-4.0.tar.gz


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.

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').

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).

Usually, this problem is caused by a handshaking error; either
the computer can't get the modem to stop sending data, or vice
versa.


7.3 TCP/IP

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.

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 ?

People in the US can get source code for this from
http://web.mit.edu/network/isakmp/ 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.

People outside the US can get the NRL source code
from ftp://ftp.ripe.net/ipv6/nrl/

The NRL code comes pre-ported to BSDI and NetBSD.
A FreeBSD port is possible but would take a little work.

(thanks to r...@inet.org)


7.4 UUCP

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.


7.4.1 TIP/CU

First thing you need to do is...

vi /etc/remote

Then remove the two lines at the bottom of the file that mention
com1, and com2. Now add the following lines:

tty00:dv=/dev/tty00:br#9600:
tty01:dv=/dev/tty01:br#9600:

That tells tip/cu where to find your com ports. Next you need
to be logged in as root and do a:

chown uucp.dialer /dev/tty00
chown uucp.dialer /dev/tty01
touch /var/log/aculog
chown uucp.dialer /var/log/aculog

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.

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..

tip tty01

To exit, type <RETURN>~.<RETURN>

Many people have other problems with cu. The lock open:
procedure is one of them. If you receive the error:

lock open: no such file or directory
all ports busy

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.

If you receive the error "cu: write: Input/output error"

You may be able to fix this by creating an /etc/uucp/ports file
(see Taylor UUCP docs).

In addition, those of you using cu version 1.04 may need to add the
following to their susyem:

create an /etc/uucp/ports file that looked like this:

port mymodem
type modem
device /dev/tty01
speed 19200

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.

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 ... :-)


7.4.2 What is the magic incantation that allows the modem to dial?

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...

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.

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!

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.


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.

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.

7.5 How do I configure my nameserver?

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 'ftp://?/?'.

7.6 Terminals

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.

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.

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.

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.

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.

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.


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?

(1) Go into sendmail's source directory tree

cd /usr/src/usr.sbin/sendmail/cf/cf

(2) Make the missing obj directory first, you need it later...

mkdir obj

(3) Create a sendmail master configuration file (.mc file). Name
it yourname.mc

vi yourname.mc

(4) Contents of the yourname.mc file:

#---------------------------------------------------------------
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.

divert(-1)
VERSIONID(`yourname.mc 1.0')

include(`../m4/cf.m4')

OSTYPE(bsd4.4)

FEATURE(nodns)dnl

MAILER(local)dnl
MAILER(smtp)dnl
MAILER(uucp)dnl

define(`UUCP_MAX_SIZE', 2000000)dnl
define(`SMART_HOST', `uucp-dom:smarthost')dnl
define(`UUCP_RELAY', `uucp-dom:smarthost')dnl
#--------------------------------------------------------------

In the siteconfig directory (.../sendmail/cf/siteconfig)
create a file uucp.yourname

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 ....

siteconfig/uucp.yourname:
#----------------------------------------------------------------------
SITE(nodename_of_your_smarthost)
#----------------------------------------------------------------------

(5) create the new sendmail configuration file, which will be
stored under obj/yourname.cf, by typing

make yourname.cf

(6) After that copy obj/yourname.cf to /etc/sendmail.cf

(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

newaliases

(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):

yourname
yourname.uucp
yourname.domain

(9) Then create a file /etc/mailertable:
Here you have to say what else (uucp addresses, too)
has to be sent to your smarthost ...

.uucp uucp-uudom:name_of_your_uucp_smarthost

(10) Create the hash table the following way:

makemap hash /etc/mailertable.db < /etc/mailertable

Remember, if you make any changes you have to rebuild the
aliases database by typing:

newaliases

(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.

(12) ``Hot files'' with more information (see sendmail src tree):
FAQ KNOWNBUGS RELEASE_NOTES cf/README


7.8 Can network attached assets be used by/from NetBSD? FreeBSD?
OpenBSD?

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:

- Ask the system administrator of the machine in
question if it is OK for you to use whatever it is
you need. This is more a matter of manners than a
technical issue.

- For NFS mounted disk drives, make sure that you are
not prevented from using the assets by the
/etc/exports (or equivalent) file. This goes for
CD-ROMs as well as regular mounted disks.

- There are a completely different set of concerns for
tapes and printers. Each system implements these in
slightly different ways. Check with your system
manager or documentation for more information.

- Diskless booting is possible for all three systems,
for a little more detail, see below.

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.

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.


7.8.1 Is it possible to Network boot a NetBSD machine from a network
on a diskless Sparc?

Yes, it's even more than possible, it actually works! Since
OpenBSD tracks NetBSD closely, it is also possible to do this
with OpenBSD.

Anders Magnusson (ra...@ludd.luth.se) 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.

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.


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?)

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.

Please note that netboot.[cr]om programs from FreeBSD 1.1.5.1
do not work with 2.0 and vice versa.

Note that this is just a pointer to the Diskless FAQ. You can
get the file from ftp.freebsd.org.


7.8.3 How can I get ISDN to work?

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.

Dave Burgess

unread,
Sep 27, 1997, 3:00:00 AM9/27/97
to

Posted-By: auto-faq 3.1.1.2
Archive-name: 386bsd-faq/part7

Section 6. (Interaction with MS-DOS)

6.0 Working with DOS and BNR/2 related software.

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).


6.1 Formatting a floppy

Formatting a floppy under NetBSD is possible through the the patch
file stored at ftp://cynjut.neonramp.com/pub/fdformat.patch

This patch appears to be for NetBSD 1.2 (release). Obviously,
use it at your own risk.

FreeBSD (and I think OpenBSD) both have floppy formatting built
into their systems in fairly recent versions.

6.2 Sharing the Disk with MS-DOS

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 <n> following
questions:

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.


6.2.1 How can I partition my drive to support both MS-DOS and *bsd?

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.

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.

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.

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).

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.

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.

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.

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.

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.

ACCESSING MS-DOS PARTITIONS FROM NetBSD-i386

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.

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.

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.

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:

disklabel -e -r /dev/r??0d (fill in with your disk type).

You'll get popped into an editor with all the disklabel stuff in
it. Go down to the bottom. You should see something like:

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...

(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.

Add a new line that looks something like:

g: 409568 32 MS-DOS # (Cyl. 0*- 199*)

(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).

*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.

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:

/dev/sd0g /msdos msdos rw 0 0

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.

Assuming you don't have something (like OS-BS) which uses the extra
sectors in the boot track, you can do the following:

1) Use the NetBSD `fdisk' or DOS `pfdisk' to create a NetBSD
partition in the MBR which spans the entire disk.

2) Save a copy of the MBR:

dd if=/dev/rsd0d of=my-mbr bs=1b count=1

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'.

4) Put back the saved copy of the MBR:

dd if=my-mbr of=/dev/rsd0d bs=1b count=1

This works for me. Your mileage may vary.

Luke Mewburn <z...@rmit.edu.au> 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.


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?

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.

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.


6.2.4 Is there any hope of ever running MS-DOS applications under any of
the free BSD systems?

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:

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:

wine-pro...@amscons.com

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.

Reply-To: youraddress@yourmachine

where youraddress@yourmachine should be replaced by your actual
mailing address.


6.2.5 How do I get Linux executables to run under NetBSD?

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 ftp://ftp.enigma.net/pub/netbsd_i386. There
are instructions there to tell you how to get the libraries
working correctly.

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.


6.3 Accessing the MS-DOS filesystem

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.

--------------------------------------------------------------------
How to mount your DOS partition from FreeBSD

1. First, be root. The following won't work as an ordinary user.

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:

... (extraneous output, not of interest) ...
The data for partition 0 is:
sysid 6,(Primary 'big' DOS (> 32MB))
start 32, size 306400 (149 Meg), flag 0
beg: cyl 0/ sector 1/ head 1;
end: cyl 149/ sector 32/ head 39

This shows me that my DOS partition starts at sector 32, and
is 306400 (512 byte) sectors long.

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'.

[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.]

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:

disk0|DEC 5501:\
:ty=winchester:dt=SCSI:se#512:nt#8:ns#256:nc#1001:rm#3600:\
:pa#956416:oa#307200:ba#8192:fa#1024:ta=4.2BSD:\
:pb#131072:ob#1263616:tb=swap:\
:pc#1087488:oc#307200:tc=UNUSED:\
:pe#306400:oe#32:te=MSDOS:

As you can see, partition 'e' now points to the DOS partition as
pointed out by fdisk.

[Ed.Note again. Remember what I said about the 32 above...]

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'.

4. Now we have to actually stick the label on the disk, which is done
with disklabel. Using my example, this would be:

disklabel -r -w sd0 disk0 SCSI /usr/mdec/sdboot /usr/mdec/bootsd

5. Reboot your system to see the new disk label.

6. Mount the DOS partition. I do:

mount -t pcfs /dev/sd0e /dos_c

Where /dos_c is just a convenient directory to mount it.

7. You're set!

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.

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.

6.4 NFS/PC-NFS support

The problems normally associated with PC-NFS are also associated
with NFS in general.


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.

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 (rae...@cambridge.cygnus.com) has identified
a common problem with the NE2000 card and provided us with a work
around:

--------------------------------------------------------------------
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.

In the meantime, mounting NFS file systems with "rsize=1024" does get
rid of this problem.

Ken
--------------------------------------------------------------------

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.

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.

See section 6.4.5 on 'ring buffer overflows' and the 3C503 for
more discussion on this problem.


6.4.2 How do I get around the NFS "Permission denied" error?

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.

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?

Hellmuth Michaelis (h...@hcshh.hcs.de) offers the solution to this
relatively common problem:

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.


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?

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.

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.


6.4.5 I get a lot of 'ring buffer overflow' messages using NFS and the
ed0 driver. Is there a problem?

David Greenman (dav...@implode.rain.com), the original author of
the ed0 driver, provides us with some insight into the inner
workings of the ed0 driver.

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).

>From the release notes:

receive
-------
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.

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.


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?

Try turning off rfc1323 support:

sysctl w net.inet.tcp.rfc1323=0

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.


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?

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.


6.5 How can I use mtools with the 'new' floppy naming convention?

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.

The order of the entries defines the order of the minor
numbers, so the table below has the following characteristics:

/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 */

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" },
};

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.

0 new messages