Amiga Plus 1995 #2/Amiga Plus CD - 1995 - No. 2.iso/internet/faq/englisch/comp.os.386bsd

Text File | 1995-04-11 | 406.2 KB | 10,491 lines

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


            Frequently Asked Questions
               386BSD, NetBSD, FreeBSD, and
               other BSD derived Operating
                         Systems.


                  EXTREMELY UNOFFICIAL


  Original FAQ by:
    Terry Lambert
    [e-mail]
    [e-mail]


  New FAQ by:
    TSgt Dave Burgess
    NCOIC, Configuration Management Section, US Strategic Command
    Instructor, Computer Science Dept, Nebraska College of Business
    President, Configuration Management Svcs, Inc.

    [e-mail]
    [e-mail]


               Last Update:  26 Feb 1995


Section 0.  (Basic FAQ information)

0.0    Master Index.

    0.0          Master Index.
    0.1          Introduction
    0.2          About this FAQ.
    0.2a         What are the differences between *BSD and (your favorite
             operating system name here)?
    0.2b         Which is better, (your favorite operating system name
             here) or *BSD?
    0.2c         Is 386bsd better than (your favorite operating system
             name here)?
    0.2.1        So what ARE the differences between the *BSD family and
             Linux?
    0.2.2        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.2.3        Are all of the Berkeley derived systems binary
             compatible? If not, what are the differences?
    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.
    1.0          What is 386BSD? (Taken from the original INSTALL.NOTES
             by the Jolitz's, specifically Lynne)
    1.0.1        What are these other Free BSD systems?
    1.0.2        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          Feature summary
    1.2          The future of 386BSD.
    1.3          386BSD software projects in progress
    1.3.1        Contacting software authors
    1.4          Minimum hardware configuration recommended
    1.5          Where to get the source and binaries
    1.5.1        Forms available (floppy, FTP, CD-ROM)
    1.5.1.1      Where can I get the distribution on floppy or tape?
    1.5.1.2      Where can I get the distribution via FTP?
    1.5.1.3      Where can I get the distribution on CD ROM?
    1.6          Electronic Information Groups for 386BSD
    1.6.1        Usenet newsgroups
    1.6.2        Newsgroup archives.
    1.6.3        386bsd Derived mailing lists.
    1.6.4        Other electronic resources.
    1.6.5        System Updates.
    1.7          Documentation available
    1.7.1        BSD manuals
    1.7.2        BSD books
    1.7.3        The Jolitz Book
    1.7.4        Dr. Dobbs' journal
    1.7.5        Documentation that comes with most of the distributions.

    1.7.6        Other FAQ's on the net that are relevant
    1.8          FTP sites for 386BSD
    1.8.1        FTP Site List
    1.8.2        Official distribution sites
    1.8.3        Reference sites
    1.8.4        Unofficial archive sites that have neat stuff!
    1.8.5        X for 386BSD 0.1 Ported Software List
    1.8.6        Motif for the *BSD family. (Infomercial to follow)
    2.0          Install process
    2.0.1        Boot disks (versions and media formats)
    2.0.1.1      Where does extract go when I reboot?
    2.0.1.2      I put the floppy in and try to boot, and nothing
             happens. What now?
    2.0.1.3a     The floppy booted, but now the hard disk won't boot?
    2.0.1.3b     I am trying to reinstall. I run install and it loops
             asking me if I want to use the whole disk?
    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.0.2        Fix-it boot disk
    2.1          Binary distribution
    2.1.1        I want to install by NFS but I am having all kinds of
             problems.
    2.2          Source distribution
    2.3          Additional software distribution
    2.4          Patch-kit
    2.5          Configuration
    2.5.1        Partitions
    2.5.1.1      What is a 'disklabel' and why do I need one?
    2.5.2        Common Disk Label Problems.
    2.5.2.1      Swap space.
    2.5.2.2      Increasing the 386bsd partition size.
    2.5.2.3      I can access the DOS partition on my second disk from
             Unix but not DOS? Any suggestions?
    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.5.4        How do I disklabel my second hard drive?
    2.5.5        386bsd/NetBSD/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.5.6        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.5.7        What are the options for the bootup prompt?
    2.5.8        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.6          Common installation problems.
    2.6.1        Swap space not identified correctly.
    2.6.2        Endless reboot cycles.
    2.7          The computer just sits there, or 'that isn't right'.
    2.7.1        The boot disk works all right on one computer but not
             another.
    2.7.2        Really strange errors in the various *BSD flavors.
    2.7.2.1      I am using the original 386bsd 0.1 with no patches
             installed and I get flashing multicolored characters and
             a "ptdi 81061" prompt error?
    2.7.2.2      Using the new code in NetBSD, I get a "panic: pdti
             206067" in pmap_enter(). What should I do?
    2.7.3a       I get the error "isr 15 and error: isr 17" on an NE2000
             card.
    2.7.3b       I have some card on IRQ2 and it doesn't work; why?
    2.7.3c       I am getting lousy performance out of my network card.
             What are some of the other possibilities?
    2.7.4        What is the difference between IRQ2 and IRQ9? Are they
             really the same, or are they really different?
    2.7.5        Some of my SCSI devices (like a tape drive) don't work;
             why?
    2.7.6        I try to run 'ps' or 'w' and get ': cannot get namelist'
             from the TinyBSD kernel. What did I do wrong?
    2.7.7        I get a 'Floating point constant out of range' when I
             try to compile package 'n'. What is broke?
    2.7.8        I want to use the Adaptec 1542C SCSI controller. What
             are the problems/tricks you need to know to get it
             working?
    2.7.9        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.8          Other common problems that are attributed to the
             installation process but are caused other places.
    2.8.1        Why don't the man pages for "magic" and "file" work?
    2.8.2        Why is apropos broke?
    2.8.3        I want to use more than 16 Megabytes of memory. Will any
             of the BSD based systems support it?
    2.8.4        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?
    3.0          System Internals
    3.1          Kernel
    3.1.1        How do I build a kernel?
    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 don't have the source distribution -- how can I
             rebuild the kernel?
    3.1.4        Now that I have a kernel, how do I install it?
    3.1.5        After installing the patchkit and recompiling the kernel
             with the option "WD8013", I am no longer able to reboot
             the machine. A cold boot (power on) runs fine, but after
             a reboot no boot drive is found by the BIOS. Besides
             having a 16-bit WD/SMC Ethernet card installed the
             machines try to boot using either a Adaptec 1742 or 1542
             SCSI board to boot from.
    3.1.6        My system is complaining about stray interrupt 7. Is my
             machine going to explode or anything?
    3.1.7        I keep getting "wd0c: extra interrupt". What does it
             mean?
    3.1.8        I found a bug in the kernel. How do I report it?
    3.1.9        Can someone please give a reasonably clear set of
             instructions as to how to get a "current" version of
             NetBSD running?
    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        Can I patch the current running OS image?
    3.2.6        Can I have more than one config file? Should I rename it
             to something else? Any other hints?
    3.2.7        What is the meaning of the trap codes I get in panic
             messages? Sometimes this message appears in the form
             "trap type nn".
    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.9        Where can I learn more about all this?
    3.2.10       Does anyone have a system building script that takes
             things like building a new config and multiple config
             files into account?
    3.3          X11/XFree86/XS3
    3.3.1        What options should I define to get the X extensions
             included?
    3.3.2        Where can I get the FAQ for 'X'?
    3.3.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          Compiler and Library routines
    3.4.1        Which C compiler is shipped with my 386BSD derived
             system?
    3.4.2        Where is libcompat.a?
    3.5          You promised to talk about timezones below. Are you
             going to?
    3.5.1        How do you change the timezone on NetBSD (FreeBSD
             also?)?
    3.5.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.6          Optional Op-codes for NetBSD, FreeBSD, and other
             systems.
    4.0          Introduction
    4.1          Common Kernel-related problems
    4.1.1        Where are the commands "rpcinfo" and "rpcgen"?
    4.1.2        Where can I get a working "netstat"?
    4.1.3        How can I fix NFS to work with my NE2000 board?
    4.1.4        How can I get "ps" and "w" to work?
    4.1.5        Where are re_comp and re_exec?
    4.1.6        What about the termio, termios, and termcap stuff?
    4.1.6.1      Where are stty() and gtty()?
    4.1.6.2      Sometimes I have trouble with my system resetting the
             terminal to seven bit mode. Isn't 386BSD eight bit
             clean?
    4.1.7        The system hangs with the HD light on after intense disk
             usage. The system hangs when trying to fsck -p both of
             my IDE hard drives at boot-up.
    4.1.8        How do you implement quotas on Net/2 derived BSD
             systems?
    4.2          Available kernel add-ons
    4.2.1        The Patch-Kit
    4.2.2        Shared Libraries
    4.2.3        Sound Blaster Drivers
    4.2.4        Bus Mouse Drivers
    4.2.5        PPP Support
    4.2.6        re_comp and re_exec library functions
    4.2.7        Intel i82586 Ethernet Controller driver
    4.2.8        PC Speaker driver for Nethack
    4.3          Other program building type problems.
    4.3.1        Greetings from Mars. 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.4          Where is the 'adduser' program?
    5.0          Introduction
    5.1          Available Kernel Replacements
    5.1.1        keycap/codrv
    5.1.2        pcvt
    5.1.3        syscons
    5.1.4        Fast Symbolic Links
    5.1.5        npx fixes
    5.1.6        CGD's COM drivers
    5.1.7        The original 386bsd 0.1 wd.c driver doesn't work.
             [386bsd 0.1 only]
    5.1.8        Interruptless LPT Driver Kit [386bsd 0.1 only]
    5.1.9        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
    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.11       Where are all the answers to the above and related
             questions written down? Neither on the net nor in the
             4.3BSD manuals nor Administration text which I have
             could I find this stuff covered!
    5.4.12       What else should I know? For example, it seems that a
             new tape must stretched. How is this done?
    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.5          Network
    5.5.1        How can I get my system to work as a network router?
    5.5.2        I recently has a problem where I got a message that said
             "panic: kmem_malloc: mb_map too small". What is the
             solution to this problem?
    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 386bsd and MS-DOS.
             Why?
    6.2.3        I can use either MS-DOS or 386BSD on my hard drive, but
             shutdown -todos doesn't seem to work.
    6.2.4        Is there any hope of ever running MS-DOS applications
             under any of the free BSD systems?
    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        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.3          TCP/IP
    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          Terminals
    7.6          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.7          Can network attached assets be used by/from NetBSD?
    8.0          What hardware is 386BSD known to run on and support!
    8.1          Video cards
    8.2          Mice and Trackballs
    8.3          Serial Cards
    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.2        Now that I have FreeBSD 1.0 installed, how do I set up
             the serial ports for bi-directional use?
    8.3.3        What is the difference between baud and bits per second?

    8.3.4        How do I get a serial console to work?
    8.4          Disk Controller Problems
    8.4.1        IDE controller problems
    8.4.2        SCSI controller problems
    8.5          SCSI Controllers
    8.6          Network Cards
    8.7          Printers
    8.8          TAPE Drives
    8.9          QIC-40/80 tape drives
    8.10         CD-ROMs
    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.2          How did you get emacs to compile?
    9.2          Has anyone tried to get Postgres to work?


0.1    Introduction

    The 386BSD 0.1 operating system was originally a derivative of
    the generally available parts of the Berkeley Net/2 release.
    The definitive "man without whom we would have nothing" in
    this effort has been William Jolitz.  For more information,
    download the code.

    386BSD is fully redistributable and is intended as a research OS.
    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 June of '92.  There was an 'unofficial'
    patchkit which was available from many anonymous FTP sources
    which makes 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.  In
    addition, many common Unix packages have been ported with
    varying degrees of difficulty.

    386BSD is available completely free of charge.  It is also
    available on CD-ROM and many other methods, most of which end up
    charging for 'media and handling costs'.  It is available by
    Anonymous FTP and through FTP-Mail.  Recently, a new CD-ROM
    version of 386BSD has been announced in Dr. Dobb's Journal.  It
    may be the long awaited 386BSD 1.0, or simply a revenue
    enhancement version of 386BSD 0.1 (or 0.2).

    386BSD came in three distinct pieces, each of which was
    exclusive of the other two.  These distributions were called the
    'bindist', 'srcdist', and 'etcdist'.  The bindist could be unloaded
    from its native form (on about 10 diskettes) and loaded onto a
    42Meg hard drive partition.  It is a fully functional system,
    including gcc 1.39, all executables for normal Unix style
    operation, and many other things.  The etc distribution included
    MANY additional programs (all with source) which extended the
    functionality of 386BSD.  The srcdist was the source code for
    386bsd, along with all of the header files not included in the
    bindist.  All of the distributions and compilation files would
    fit onto 180Meg of hard drive (barely).

    In addition to the original 386BSD, two newer versions of the
    system are available, under new names.  NetBSD is the older (or
    newer depending on whom you choose to believe) and FreeBSD is the
    other.  Both systems have evolved into programs that are superior
    to the progenitor and both have sizable (if a little rabid)
    followings.  Most of the statements made in this FAQ will apply
    to all three, 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 (you should be able
    to tell by context) of any of the three members of the PC BSD
    family.

    There have been many attempts to polarize the FreeBSD and NetBSD
    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 and
    FreeBSD.

    It should be noted that when the *BSD family started out, they
    used a source called the "Berkeley Net Release/2" tape as their
    genesis.  While this has provided a stable starting point, it
    also built a possible bomb into the system.  Due to an ongoing
    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.  This is the
    pertinent excerpt from a letter from someone (whose name I have
    lost) indicating what is and is not releasable.

    Q:  What's all this about `binary-only files'?  Will BSDI
    continue to ship source code?
    A:  For Version 1.1 only, BSDI will ship the following kernel
    files in binary format:

    kern/init_main.c    kern/subr_rmap.c    ufs/ufs_bmap.c
    kern/kern_clock.c    kern/sys_generic.c    ufs/ufs_disksubr.c
    kern/kern_exit.c    kern/sys_process.c    ufs/ufs_inode.c
    kern/kern_physio.c    kern/tty.c        ufs/ufs_vnops.c
    kern/kern_sig.c        kern/tty_subr.c
    kern/kern_synch.c    kern/vfs_syscalls.c

    Our (Berkeley's) 4.4Lite-based release will again include the
    entire source tree (with the exception of a tiny number of
    device drivers whose interfaces are kept confidential at the
    request of their authors.

    I have it from a reasonably reliable source that these files
    either have been completely rewritten in a 'clean room'
    development effort or were replaced with code from other
    sources (such as CMU, or GNU).  The encumbered sources for the
    user land portion of the system have long since been replaced.



0.2    About this FAQ.

    This FAQ consists of 10 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.  "Supported" Hardware List
        Section 9.  "Supported" Software List

    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.2a    What are the differences between *BSD and (your favorite operating
    system name here)?
0.2b    Which is better, (your favorite operating system name here) or
    *BSD?
0.2c    Is 386bsd better than (your favorite operating system name here)?

    I decided to put this in section 0, primarily because it by far
    the most asked and least useful question in comp.os.386bsd.*.

    You will often see this question veiled as a request for a brief
    description of the differences between 386bsd and (YFOS).  This
    type of request, while seeming to be a reasonable one, is usually
    looked upon as either an attempt by some folks for the net to do
    their homework, or as an attempt to start yet another flame-war.

    What is the answer to this question, then?

    No.  It is not.

    Nor is it any worse.

    It is DIFFERENT.  There are alternative Operating Systems
    available, both free and commercial.  386bsd, NetBSD, FreeBSD,
    and Linux are examples of "free" Unix style Operating Systems.

    If you ask any of these questions, you are wasting a LOT of
    bandwidth and making a real name for yourself.  Don't bother.
    It nearly always ends up in name calling and 'mine is bigger
    (or littler) than yours...' arguments.  I have included an
    excerpt below:

    >>>>>>>>>>>>>>>>>>>>>>>>>> Is not!
    >>>>>>>>>>>>>>>>>>>>>>>>> Is so!
    >>>>>>>>>>>>>>>>>>>>>>>> Is not!
    >>>>>>>>>>>>>>>>>>>>>>> Is so!
    >>>>>>>>>>>>>>>>>>>>>> Is not!
    >>>>>>>>>>>>>>>>>>>>> Is so!
    >>>>>>>>>>>>>>>>>>>> Is not!
    >>>>>>>>>>>>>>>>>>> Is so!
    >>>>>>>>>>>>>>>>>> Is not!
    >>>>>>>>>>>>>>>>> Is so!
    >>>>>>>>>>>>>>>> Is not!
    >>>>>>>>>>>>>>> Is so!
    >>>>>>>>>>>>>> Is not!
    >>>>>>>>>>>>> Is so!
    >>>>>>>>>>>> Is not!
    >>>>>>>>>>> Is so!
    >>>>>>>>>> Is not!
    >>>>>>>>> Is so!
    >>>>>>>> Is not!
    >>>>>>> Is so!

    [the rest of this scintillating debate is deleted...]

    Here are a brief list of differences between 386bsd and other
    systems:

    1.  *bsd will not run DOS applications natively.  There is
    currently a DOS emulator in work.  It is called pcemu, and it
    provides 8086 emulation for DOS programs.  It only works in text
    mode.  There is also work on a Windows program loader execution
    version.  The project is called 'WINE' and is the free version
    of the 'WABI' project.  More on that to follow.

    2.  386bsd is not binary compatible with anything but the other
    free BSD systems (NetBSD, FreeBSD, and their kith).  There are
    rumors and rumblings from time to time that one or more of the
    *Nix variants may be binary compatible with NetBSD or FreeBSD.
    The more the merrier.  Be warned; if the package you are trying
    to run is not specifically compiled and linked for your version
    of {Free,Net}BSD, then you may well be completely on your own.
    Recent advances have provided some success in getting iBCS2
    compatibility working, allowing certain SCO and AT&T Unix
    programs to work.  See the newsgroups for more current
    information.

     3.  FreeBSD, which originally started life as 386bsd 0.1 with
    the patchkit applied, has since evolved into an entirely
    seperate BSD lineage in its own right and incorporates many
    important innovations.  In addition to extensive, high quality
    work that has been done on the FreeBSD kernel, a great deal of
    effort and time has been invested in improving the overall
    level of quality in such areas as the installation and maintenance
    scripts, third-party applications packaging, and many of the
    various utilities and development tools in BSD.  The emphasis
    seems to be on better packaging and improved operation, and
    with special emphasis being placed on positioning FreeBSD as an
    'Intel-specific' BSD variant.  Much care taken specifically to
    support the various and sundry peripherals and hardware one finds
    on the Intel PC world.  FreeBSD is now based completely on the
    fully unencumbered BSD 4.4 Lite and is still intended primarily
    for the Intel platforms.

     4.  NetBSD, on the other hand, is intended as a multiplatform
     'replacement' for Net2.  It has built-in support for so many
     different platforms that I simply can't begin to list them.
     With the exception of the multiplatform support that is built
     into NetBSD, the two system are very similar and seem to
     parallel one another very closely.  Since the NetBSD folks seem
     to be the self proclaimed 'bearers of the standard' for multi-
     platform BSD support, they are also proceeding with switching
     over to the 4.4 Lite tape.

    5.  Where BSD and POSIX differ, 386BSD conforms by default to
    BSD; Linux to POSIX.  Furthermore, while both run mostly GNU
    utilities, Linux tends toward the SysV flavor (e.g. init)
    where 386BSD sticks with the BSD style.  However, sources for
    different flavors of utilities are available for both, and
    both support compiler options which allow more BSD or more
    POSIX semantics.

    Clifford Stoll talks about the 'West Coast/East Coast' feeling
    of BSD/SysV in his book "The Cuckoo's Egg".  In keeping with
    that, BSD feels like BSD/West Coast, Linux feels like SysV/East
    Coast (actually, Finland is what it says on the passport, but
    stay with me for a minute).   If you don't believe me, just
    look at the primary U.S. archive sites.   Linux is available
    from MIT, BSD is available from Berkeley.  Can't get much more
    'Coast' than that. :-)

    Actually, NetBSD and FreeBSD are feeling more and more POSIX all
    the time.  Recent releases of both products have implemented many
    more POSIX compliant utilities, features, and low-level hooks into
    the operating system.  A great deal of effort has gone into
    supporting and improving the POSIX standards compliance
    throughout all of the systems.

    5.  Linux, NetBSD, FreeBSD, and 386bsd share two vitally important
    facets.  All are free and all include source.  They are all
    excellent, and all fill a niche that the others would gladly
    leave available.  Also, don't forget one of the most important
    things; get what your friends have.  Then they can help you.

    6.  Finally, remember that this FAQ and the comp.os.386bsd.*
    groups are intended as places for 386bsd users and developers
    to meet and discuss topics which are germain to the further
    development of 386bsd.  For more information about Linux, you
    can read the comp.os.linux.* newsgroups.  If you are a 'rabid'
    Linux user, stay on the Linux groups.  Most of us don't care how
    much better Linux is than *BSD.


0.2.1    So what ARE the differences between the *BSD family and Linux?

    Here it is, in its 'right for today' glory.  As of 1 July,
    1994, these statements were more or less accurate.  Against my
    better judgement, I am going to include this, primarily because
    it is a very even handed approach to describing two very
    different systems.  For those of you that find it, I hope that
    it answers some of your questions.  It was written by:

        Thomas Heiling Pharmacist & Doctorate at
        Pharmazeutisches Institut Uni Wuerzburg - Germany
        Email [e-mail] (HP-UX)
                    [e-mail] (Linux)
           or [e-mail] ( VAX )

    I have read this group now for some time and saw this thread
    Linux-BSD coming often. Some answers to this question were good,
    but the FAQ was not updated.

    It is IMHO *not* very helpful to flame a newbie, that he/she
    should read the FAQ, where there is no information, nor it is
    helpful to shout to him "Hey man read the previos posts - I
    *hate* this thread!"

    What is missing here is an overview and a comparison of the free
    available Unixsystems. And this info should be in the FAQ !  I
    will start here such a comparison.

    Q:  For whom should this be ?

    A:  For a (hopefully) new Unix-user, who wants to install one of
    the free Unixes.  He should be able to read this document, look
    at his hardware, define his needs for a Unix-systems and then he
    should be able to choose a system which meets his needs.

    Q:  Who am I and why should I be able to write such a doc ?

    A:  Good Question ! My name is Thomas Heiling, I am working at
    the University of Wuerzburg in Germany as a doctorate.  My job
    is to program an Ultraviolett/Vis-spectrum comparison program.
    Furthermore I am the person, who maintains the Internet
    connections and computers of our Department.  I have running
    Linux and NetBSD 0.9, the main Server is a 486/33 + 16 MB which
    runs Linux. A 486/66 is for numerical work.  Then there are
    some clients mostly 386 with either 4 MB or 8 MB.  One 386 with
    NetBSD, but this is just for testing.

    So I would say I can speak for Linux, a little bit for NetBSD
    and I have no idea for FreeBSD beside the Installation Guide.
    (I have no access to the BSD386 1.0 CD, which was announced some
    time ago).

    * PLEASE PLEASE PLEASE *

    It would be very helpful, if someone of the Core-Team of NetBSD
    and/or FreeBSD have a look at this and fill the white spaces,
    which I left.  And if the FAQ-maintainer reads this, it would be
    nice, if he thinks this info should be in the FAQ.

    Hardware requirements :


    Linux:

    CPU: Anything that runs 386 protected mode programs (all models
        of 386s and 486s should work; 286s don't work, and never will).

    Architecture: ISA or EISA bus. MCA (mostly true blue PS/2's)
        does not work. Local busses (VLB and PCI) work.

        RAM: Theoretically up to 1 GB. This has not been tested. Some
        people (including Linus) have noted that adding ram has slowed
        down their machine extremely without adding more cache at the
        same time, so if you add memory and find your machine slower,
        try adding more cache.

        Data storage: Generic AT drives (IDE, 16 bit HD controllers with
        MFM or RLL) are supported, as are SCSI hard disks and CD-ROMs,
        with a supported SCSI adaptor. Generic XT controllers (8 bit
        controllers with MFM or RLL) are now also supported. Supported
        SCSI adaptors: Adaptec 1542, 1522, and 1740 in extended (not
        1542 compatible) mode, Seagate ST-01 and ST-02, Future Domain
        TMC-88x series (or any board based on the TMC950 chip) and
        TMC1660/1680, Ultrastor 14F, 24F and 34F, and Western Digital
        wd7000. SCSI and QIC-02 tapes are also supported. Support for
        QIC-80 tapes is now in ALPHA testing. Several CD-ROM devices are
        also supported, including Matsushita/Panasonic, Mitsumi, Sony,
        Soundblaster, Toshiba, and others. For exact models, check the
        hardware compatability HOWTO.

        Video: VGA, EGA, CGA, or Hercules (and compatibles) work in text
        mode. For graphics and X, there is support for (at least) normal
        VGA, some super-VGA cards (most of the cards based on ET3000,
        ET4000, Paradise, and some Trident chipsets), S3 (except for
        Diamond Stealth cards, because the manufacturer won't tell how
        to program it), 8514/A, ATI MACH8, ATI MACH32, and hercules.
        (Linux uses the Xfree86 X server, so that determines what cards
        are supported.)

        Networking: Western Digital 80x3, ne1000, ne2000, 3com503,
        3com509, Allied Telliesis AT1500 (said to be some of the
        fastest, as well as quite cheap), d-link pocket adaptors, SLIP,
        CSLIP, PLIP (Parallel Link IP), and more I have forgotten at the
        moment.

        Other hardware: SoundBlaster, ProAudio Spectrum 16, Gravis
        Ultrasound, AST Fourport cards (with 4 serial ports), several
        models of Boca serial boards, the Usenet Serial Card II, several
        flavours of bus mice (Microsoft, Logitech, PS/2).

    *BSD:

        Architecture: ISA or EISA bus. MCA (mostly true blue PS/2's)
        does not work. Local busses (VLB and PCI) are also supported.

    Standard hard disk controllers:
    MFM ESDI IDE RLL

    SCSI hard disk controllers:
    Adaptec 154x *, Adaptec 174x, Buslogic 545S, Bustek 742(EISA)
    DTC 3290 in 1542 emulation mode *, Ultrastor 14f and 34f, and
    the 24f experimentally.  The Soundblaster SCSI code is also
    being tested and should work eventually.



    Display Adaptors : MDA,CGA,VGA,HGC for textmode.
    For X the same as Linux.

    Serial Communications: 8250,16450,16550A,
    4-port multi-serial cards require a kernel rebuild.

    Ethernet controllers:
    SMC/WD 8003, 8013 and equivalents ( including SMC Elite )
    Novell NE1000,NE2000,NE2100
    3com 3c503
    ISOLAN ISOlink

    Tape Drives:
    QIC-02 format tape drives
    QIC-36 format tape drives
    QIC-80 format tape drives (in FreeBSD)
    most SCSI tape/DAT drives on a supported SCSI controller

    CD-ROM drives:
    Mitsumi CDROM with Mitsumi Controller
    Most SCSI CD-ROM drives on a supported SCSI controller


        Other hardware: SoundBlaster, ProAudio Spectrum 16, Gravis
        Ultrasound, AST Fourport cards (with 4 serial ports), several
        models of Boca serial boards, the Usenet Serial Card II, several
        flavours of bus mice (Microsoft, Logitech, PS/2). Same as Linux,
    although some options may require a kernel rebuild.

    Harddisk Storage requirements :
    FreeBSD:
    Base System     16 MB
    Full binary distribution            46 MB
    Full source "                     72 MB
    Kernel Source                    7 MB
    Swap                        8 MB

    They say, that the minimum is Base + Binary + Swap, and that
    this minimum is 80 MB.  For a complete system with binary and
    source you need at least 210 MB.  This does NOT include X or
    LaTeX.


Linux:
    This is difficult, because there are different distributions
    to choose from. Every distribution has a special goal.
    I will show two popular distributions :

    - Slackware and the MCC-Interim Distribution.
        Slackware is intended for a full fledge system, which has
        everything you want. You need about 150 MB for this.
    - MCC-Interim is intended for small systems. The main idea is
        to give a ASCII-environment for programming courses.  For a
        full MCC install you need about 47 MB + 8 MB Swap, you can
        strip this down to 23 MB + 8 MB Swap, if you don't want
        emacs, no kernel source and no extras.







    Some other features:

    virtual terminals/consoles:
    All of the -current versions of *BSD have virtualy consoles
    available.  Linux has virtual consoles as well.

    shared libraries:
    NetBSD, FreeBSD, and Linux have it. I recall a thread some time
    ago, which was something like "Linux shared Libs are no
    good - A pain for the developer."  For the user this should be
    meaningless.  NetBSD and FreeBSD shared library implementations
    are both very easy to use both from the developer and user
    point of view.

    Networking:
    *BSD networking is more mature, but with Linux 1.0 it's getting
    closer.

    One Feature of Linux is the ability to make a filesystem on top
    of a DOS-FAT, so you don't  need to repartition your Disk. This
    Filesystem is of course not so fast as a native Filesystem, but
    for trial it should be O.K.

    Conclusion:
    It depends on you hardware and what you want to do with your
    system.  If your hardware is supported and if you have the
    resources and if you are on the net, I would vote for *BSD. If
    you just want some *iX experience and have low ressources,
    choose Linux.



    Here are some pro's and con's for both :

    *BSD:
    + Full Source Code of all commands in a source tree, no need
      to look all over the Internet for the source of a command.
    + There is only one distribution, which is valid for some time.
    + Networking is better.
    + The system is standard BSD.
    - You need extra packages for XFree and for TeX.  They are not
    hard to find, and install into a standard location in the
    directory tree, but they are not included in the base
    distribution.

    Linux:
    + Uses fewer resources
    + Has more support for devices
    - Every distribution is a little bit different
    - Development is too fast without net access

    I include here some info from other posts, which should help
    the new user to show the differences:

    [e-mail] wrote:
    : NetBSD is the OS I use.  It is a BSD derived Operating System
    : that has a very stable operating envelope.  The networking code
    : has been stolen by commercial OS and network vendors the world
    : over.  NetBSD has the advantage of being meant for a wide
    : range of hardware platforms.  It is currently available for
    : something like 10 different CPUs, and has been laid out such
    : that new architectures can be added relatively painlessly.

    These arechitetures include several Sun Systems, many
    Motorolas, including the Amiga and Mac, and several other older
    mini- and microcomputer systems.

    :
    : FreeBSD is pretty much the same (go ahead a quibble over
    : details, I don't care anymore).  The biggest difference is that
    : NetBSD is a horizontal system (across platforms) and FreeBSD is
    : a vertical system (intended to stay on the Intel family).  Both
    : are based on code from 386BSD, although neither really resembles
    : it any more.
    :
    : Linux was developed by Linus Torvalds and has the advantage of
    : being available in source code form first.  Other than that, I
    : have heard that it is a good OS platform for standalone Unix
    : workstations.  It had a lot of things that made its users rabid
    : before the *BSD folks did, but the purists insist that *BSD is
    : (choose two:  cleaner, safer, taller, wider, better, quieter,
    : louder, greener).  I even heard a rumor that Linus had sold the
    : source code license to Novell so that they could distribute an
    : 'X' terminal package for use in their networks.

    From: [e-mail] (Charles Hedrick)

    There are four major differences:

    1) the 386BSD family started with BSD, and Linux started with
    POSIX.  NetBSD/FreeBSD/386BSD have been adding POSIX and System
    V compatibility, and Linux has been adding Berkeley and System
    V compatibility.  So there's a good deal of overlap.  But ...BSD
    is still a better choice if you want to program in a Berkeley
    environment and Linux if you want a POSIX environment.

    That's for the kernel and libc -- the utilities and other stuff
    users see tends to be fairly similar.  In both cases the
    programs are what I call "typical University Unix".  The main
    difference is that the base Unix utilities tend to be Berkeley
    for ...BSD and Gnu for Linux.  Gnu is fairly
    Berkeley-compatible, but its priority is POSIX, so it tends to
    look slightly closer to System V, with massive Berkeley
    extension.  There are several sets of administrative utilities,
    but it's more likely that init, getty, etc., are going to be
    System V style for Linux and BSD for ...BSD.

    Again, these things aren't as significant as they might be
    because ...BSD is also concerned about POSIX compatibility and
    Gnu is concerned about BSD compatibility.  So both sets of
    software are approaching a similar sort of goal from opposite
    directions.  You could probably use the systems for quite a
    while without noticing much difference.  (I'd like to emphasize
    that there's no similarity in overall feel between Linux and
    typical brain-dead PC System V ports.)

    The ...BSD FAQ characterizes the difference as one of East
    Coast vs. West Coast.  There's a lot to be said for that
    summary.  There's more difference in Unix culture between New
    Jersey and California than between New Jersey and Finland.

    2) The nature of the development communities and distribution
    mechanisms are different.  ...BSD has two or three different
    developer communities that take code from each other, but
    appear to hate each other's guts.  (Actually, even ...BSD and
    Linux take code from each other.)  Thus there are several
    different ...BSD's, each of which has an official distribution.
    There's just one Linux kernel, and from a practical point of
    view just one set of major utilities, but there's no official
    distribution.  So several different groups put together
    distributions, with their own choice of kernel and utility
    versions.  This means that it's easier to define what the One
    True Linux is than what the One True BSD is, but harder to get
    it. Once you've decided which BSD is the right one, it's easier
    to find an authoritative distribution of it.  Development of
    Linux tends to be more distributed.  Lots of people are working
    on lots of projects: new drivers for this and that, new
    versions of this utility and that.  If you want to keep up with
    NetBSD, you can sup netBSD-current from one or two places.  If
    you want to keep up with Linux, you end up taking pieces from
    lots of people (though they generally end up on one of two
    archive machines -- tsx-11.mit.edu or sunsite.unc.edu).  If you
    don't want to do this, of course the packaged distributions do
    it for you.

    3) The BSD networking is more mature than the Linux networking.
    This is one area in which I don't think Linux has any
    countervailing advantages, though in my opinion by release 1.0
    Linux networking will be acceptable.

    4) There are specific things in each system that are likely to
    be deciding factors for some people.  I don't know what unique
    things BSD has, because I'm not part of that community, but for
    some people the COFF and ELF compatiblity projects may be big
    selling points.  Both ...BSD and Linux are working towards
    having these executable formats available.  In addition,
    Windows executable emulation may also be important to some
    people.  This is probably more useful, and it's being done
    jointly by developers from both BSD and Linux cooperatively.
    (Neither of these things is finished, by the way.)  It's
    not clear to me whether the existing Linux DOS compatibility is
    a critical advantage.  BSD doesn't have it, but my experience is
    that the Linux DOS emulator is slow enough and creaky enough
    that it's not generally usable.  However it certainly does work
    for many programs, and if one of those programs is critical to
    you, it may be a big deal.  Differences in support of devices
    are not likely to persist for long.  There's a history of
    taking device drivers in both directions, so if there's enough
    interest in a device, and one side implements it, you can bet
    it will show up on the other side.  Linux uses DOS partitions
    (including extended partitions).  BSD creates its own
    partitions inside a single DOS partition.  This is a
    difference, but it's unclear whether it's a critical one.
    Linux and ...BSD can all mount DOS filesystems and Linux can
    mount OS/2 file systems (OS/2 is read-only).

    For a lot of people, the best suggestion is to find out what
    your friends are doing.  If there's a significant user
    community near you of either kind, you're probably best off to
    go with it.  If not, flip a coin (or look at a map and see
    whether you're nearer Berkeley or Finland -- note that in this
    comparison portions of the distance that are over an ocean
    don't count).






0.2.2    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" 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.2.3    Are all of the Berkeley derived systems binary compatible?  If
    not, what are the differences?

    (Ed Note.  This section is probably wrong, even if it was right
    when I looked at it last.  There is a LOT of work going on,
    including SysV ELF support and other cool stuff.)

    NetBSD/386 runs 386BSD, FreeBSD, NetBSD/386 0.8, and most
    BSDI executables.  However, due to upgrading to the latest
    version of the UCB DB library, programs which use said
    library cannot be mixed old and new; e.g. an old `ls' cannot
    read the pwd.db file created with a new `pwd_mkdb', and vice
    versa.

    FreeBSD runs 386BSD, NetBSD/386 0.8, and most BSDi executables.
    You can replace the remainder of the paragraph above here too.

    The FreeBSD and NetBSD shared libraries are different, so
    programs that are intended to be shared in binary form across
    the two platforms need to be compiled as 'static'
    implementations.  This is not actually a guarantee that they
    will work across platforms, but this is the first hurdle that
    needs to be jumped in order to have the programs run.

    Also, due to better (read: properly) enforced address space
    protections, some incorrectly written programs which seemed to
    work under 386BSD or NetBSD/386 0.8 will core dump under
    NetBSD/386 0.9, even when recompiled.

    The default executable format produced by the NetBSD 0.9 `ld' i
    is not downward compatible with FreeBSD or 386BSD.  It is
    essentially the same as BSDI's QMAGIC format and Sun's normal
    format--with no padding between the exec header and the first
    page of text, and with the first page of the address space
    always unmapped when loaded--except that the magic numbers are
    in the conventional `magic + machine id' format, and are in
    network (big-endian) order.


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

    Yup:

    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/1
    http://www.public.iastate.edu:~gendalia/FAQ/FAQ.list.html
    ftp://ftp.iastate.edu:/pub/Netbsd/FAQ


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 [e-mail].
    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?


--
TSgt Dave Burgess           | Dave Burgess
NCOIC, USSTRATCOM/J6844     | *BSD FAQ Maintainer
Offutt AFB, NE              | [e-mail]

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

Section 1. (General Network Information)
General information

    This section of the FAQ is about the electronic support network
    that exists for 386bsd and its off-spring.

1.0    What is 386BSD? (Taken from the original INSTALL.NOTES by the
    Jolitz's, specifically Lynne)

    Welcome to 386BSD Release 0.1, the second edition of the 386BSD
    operating system created by William and Lynne Jolitz.  Like its
    predecessor, 386BSD Release 0.0, Release 0.1 comprises an entire
    and complete UNIX-like operating system for the 80386/80486-based
    AT Personal Computer.

    386BSD Release 0.1 is an enhanced version of the original release
    done by William F. Jolitz, the developer of 386BSD.  386BSD
    Release 0.0 was based on the Networking Software, Release 2 from
    the University of California at Berkeley EECS Department, and
    included much of the 386BSD work done earlier by Bill and
    contributed by us to the University. The latest release, 386BSD
    Release 0.1, contains new work by the developer and many new items
    which have been freely contributed by other software developers
    for incorporation into 386BSD (see the file CONTRIB.LIST).  These
    contributions have increased the functionality and made it more
    robust.  As a courtesy to the developer and the many people who
    have generously contributed these software enhancements, we request
    that users abide by and properly maintain all attributions,
    copyrights, and copylefts contained within this release.

     386BSD is intended to foster new research and development in
     operating systems and networking technology by providing this base
     technology in a broadly accessible manner.  As such, like its
     predecessor, 386BSD Release 0.1 is freely redistributable and
     modifiable.

1.0.1    What are these other Free BSD systems?

    For reasons best left to private E-Mail, there have been two
    different 'product lines' that have been established for
    development of BSD systems.  They are NetBSD and FreeBSD.  Both,
    individually, have virtually deprecated the original 386bsd.
    The "raison d'etre" for each is different and each has a different
    set of goals.  The purpose for FreeBSD is to develop a stable
    working environment for [3-9]86 systems.  The emphasis has been
    on upgrading utility programs and incorporating changes that make
    the system more stable.

    NetBSD, on the other hand, is a development effort whose main
    thrust is on mulitple platform support and staying more current
    with BSD 4.4.  In other words, NetBSD is more 'horizontal' and
    FreeBSD is more 'vertical'.

    Both systems are excellent choices for the casual user or people
    who are interested in studying the internals of an operating
    system.  While the products are nearly commercial quality, they
    are both maintained by volunteers.


1.0.2    I just downloaded all of 386bsd version 0.1 and I can't get
    [some feature] to work?  Do you have any suggestions?

    Yes.  Get either FreeBSD or NetBSD.

    The original 386BSD software was kind of buggy when it was put
    up for anonymous FTP in 1992.  It has been modified significantly
    since then, and now exists in two different forms.  There are people
    who will argue that the original 386BSD was completely unusable,
    but that is generally an overstatement.

    Over 100 patches were applied to the original system, with hundreds
    more waiting in the wings.  It became just too much trouble to
    constantly have to patch the system to get it to work.  This
    'patched' version of 386bsd became FreeBSD.  Around the same
    time, a second group split off from the original 386bsd tree
    and became NetBSD.  For the primary differences, see above.

    Getting one of these two systems will provide you with a more
    complete system, with newer utilities, and many bugs already
    fixed.


1.1    Feature summary

    Among the many features of these systems:

    *    Floppy disk based Installation

    *    Hard drive partitioning for use with MS-DOS partitions

    *    Compressed, multivolume CPIO dump format binary/source/other
         distribution sets on MS-DOS floppies.  The cpio is based
         on the GNU cpio, and is completely free of encumbering USL
         software.

    *    387 support or emulation.

    *    SCSI support.

    *    (SCSI and most Mitsumi) CD-ROM support.

    *    NFS, TCP/IP and full networking.

    *    MS-DOS file system access (in newer *BSD systems).

    *    PPP and SLIP protocol support.

    *    System upgrades through Carnegie Mellon University's 'sup'
         utility.

    *    Shared Library Support (in the newer version of both
         NetBSD and FreeBSD.

    *    Both systems are based exclusively on Berkeley's BSD 4.4
         Lite tape, instead of the encumbered 4.3 Net2 tape.
         Hence, both systems are free of USL code and are freely
         redistributable.


1.2    The future of 386BSD.

    { This section is included for historical purposes only.  Most
    of the information in here is either wildly out of date or just
    plain wrong.  For example, the FreeBSD statements in here imply
    that it is nothing more than 386bsd in a new coat of paint.
    Nothing could be further from the truth.  I decided to include
    it mostly to show how far we have come... dbb }

    Forecasting the future is always a tricky business.  There is work
    underway to implement version 0.2 of 386bsd.  In addition, many
    people are involved in a project to put together a 386bsd version
    (FreeBSD) which will be a complete distribution set including all
    relevant patches and updates to new versions of many of the
    software packages that are currently available.  It is available
    by anonymous FTP from FreeBSD.cdrom.com

    In addition, NetBSD (a direct descendent of 386bsd) is available
    for anonymous FTP from sun-lamp.cs.berkeley.edu.  The purposes of
    these two apparent competitors appear to be at odds, but in
    fact are very similar.  NetBSD has taken a 'stable, production
    quality, free OS' as one of its primary goals, where 386bsd
    pursues the high ideal of the ultimate OS research platform.
    There is considerable cross pollination of the two.  The frequent
    debates on style and concept that appear in comp.os.386bsd.*
    are testimony to that point.  NetBSD and FreeBSD are still both
    very viable operating system alternatives, with differing goals.

    To see the Future of 386bsd as seen by Bill and Lynne Jolitz, I
    suggest you read the INSTALL.NOTES that come with 386bsd.


1.3    386BSD software projects in progress

    The list of software projects in progress is just too volatile
    to go into a static document like the FAQ.  Suffice it to say,
    if there is something you want to do using 386bsd; ask first to
    see what has been done.

    Folks that are interested in software projects for NetBSD
    should contact [e-mail] and
    let that mailing list know the same information.

    Folks interested in software projects for FreeBSD should contact
    the [e-mail] mailing list and talk to
    them.


1.3.1    Contacting software authors

    Whenever you are working on a port of a software package, it is
    always a good idea to contact the original author and offer
    whatever changes you needed to make in order to port the software.
    That way, subsequent releases of the package may include changes
    that allow all users of 386bsd the advantage of reusing your work
    over and over.

    Also, once you have ported a package to *BSD, you might want to
    contact the respective *BSD teams to let them know you've completed
    it and where it may be located.

    For FreeBSD, contact:

        <[e-mail]>

    For NetBSD, contact:

        <[e-mail].>

    If the port was a simple recompile of the source and install, a
    note to one of the newsgroups telling the story could be considered
    appropriate as well.

    In keeping with that, if you find a 'bug' in 386bsd, or NetBSD,
    or FreeBSD, or find a problem that causes you some headaches and
    find a solution, you should contact the author of the particular
    driver/module/program and let them know.  In addition, you could
    also post the problem and/or fix to "comp.os.386bsd.bugs".

    Both NetBSD and FreeBSD have implemented 'bugfiler', so if you
    are connected to the net, you can use that to send out your
    bug.  See the documentation that comes with your system to find
    out more.


1.4    Minimum hardware configuration recommended

    There has been considerable debate about what the REAL minimum
    configuration for 386bsd is.  Some would claim that it is the
    smallest computer that an installation will succeed on.  Others
    claim that it is the smallest usable computer (based on RAM and
    speed constraints) and others would claim that it should be
    based on using 'X'-windows.

    For specific hardware, see Section 8 (still in development).

    The smallest installable platform is an 80386, using an MGA card,
    with at least 2Meg of RAM and a 20 Megabyte hard disk.  While not
    all SCSI cards (especially EISA) are supported, a great many are
    either in the base distribution or through patches.  Thanks to
    the new shared library code in FreeBSD and NetBSD, a 20Meg
    installation should be easier now (in spite of the more advanced
    functionality) than it ever was before.

    A comfortable installation which includes source and binary
    distributions, as well as other utilities will work in about
    100Meg of hard drive.

    'X' requires at least a Hercules MGA; for masochists only, from
    what I understand.

    See section 8 for more details.


1.5    Where to get the source and binaries
1.5.1    Forms available (floppy, FTP, CD-ROM)

    386bsd is available in just about every format known to man, with
    the possible exception of stone tablets and papyrus.


1.5.1.1 Where can I get the distribution on floppy or tape?

    Many people will copy files onto diskettes or tapes if you
    coordinate it with them ahead of time.  In addition, many
    companies offer 386bsd on various types of media for money.
    Austin Code Works and others (usually advertisers in PC
    magazines) offer the base 0.1 "official" distribution for a fee.

    Note that there are virtually no restrictions on distributing
    the 386bsd distributions.  Basically, wherever you can find it,
    you can get it.  This goes for FreeBSD and NetBSD as well.


1.5.1.2 Where can I get the distribution via FTP?

    If you are looking for the original 386bsd version 0.1, the
    files you should look for specifically when using FTP are
    directories called srcdist, bindist, and etcdist.  These
    directories will hold the files for each of the distributions.
    Once you have received the files via FTP, you can either load
    them directly onto your system and then un archive them using
    'extract' or one of the other methods suggested in Section 2 of
    the FAQ, in the section about installing with 'real partitioning'.

    The list of sites that have 386BSD is covered in section 1.8 below.
    This list is produced automatically by using a utility called
    'archie' and is updated for every new version of the FAQ.  If you
    try to access a site from this list and find that they either
    don't have FTP enabled, or don't have 386bsd loaded any more,
    a polite letter to the admin of the system asking them to
    update their 'archie' entries is good manners.


1.5.1.3 Where can I get the distribution on CD ROM?

    Infomagic sells a UNIX CD-ROM that has 386BSD.  Their FAX number
    is 609-683-5502.

    In a new joint venture, DiscNet, Inc., and InfoMagic, Inc. are
    pleased to announce their joint release of the BSDisc.  This
    collaboration should be beneficial to all of our customers, since
    it brings to bear more experience, more support capability, and
    economies of scale in production.

    The BSDisc (Vol 2, Num 1) is scheduled to begin shipping on the
    20th of December, 1994.  Available now for over a year, the BSDisc
    seeks to provide what BSD users and hackers want most on a CD-ROM.

    The current issue includes:

    - NetBSD 1.0
        - distribution sets for 1, sparc, mac68k, and amiga
        - expanded source tree for all architectures
    - FreeBSD 2.0
        - distribution sets for 1
        - expanded source and binary trees for 1
    - XFree86 binaries for both FreeBSD and NetBSD
    - X11R6 (xc as well as contrib)
    - BSD-related news archive
    - various Answers to Frequently asked Question (FAQs)
    - Lots of Freeware/Gnuware sources from the FreeBSD Ports effort
    - FreeBSD pre-built binary packages
    - a small set of pre-built NetBSD binary packages

    The BSDisc is available both for single-issue purchases, or on
    a buying plan.  Single-issue price is $35.00; subscription pricing
    is $19.50 per issue, for a minimum length of 3 issues.  (Those
    prices do not include S/H.)

    For single-issue purchases, contact InfoMagic at:

                                                       [phone]
    InfoMagic, Inc.                           Tel: [phone]
    PO Box 30370                              Fax: [phone]
    Flagstaff, AZ  86003-0370         e-mail: [e-mail]
                                                  [e-mail]

    For information about subscriptions, contact DiscNet at:

    DiscNet, Inc.                                   [phone]
    841 Acker Pkwy
    DeForest, WI  53532     email: [e-mail]
                                        [e-mail]

        European subscriptions, email: [e-mail]

    Profit Press has 386BSD dated 7/21/92 on their "Mega Win OS/2"
    CD-ROM.  This is in the format of BINDIST, ETCDIST, SRCDIST and
    BOOTABLE.

        Profit Press
        2956 N. Campbell Ave
        Tucson, Arizona 85719
        [phone]
        Their order line is 1-800-843-7990

    Look for their advertisements in the back pages of Computer
    Shopper.  The Mega series is $29.00 each or $69.00 for all three
    plus a fourth "Demo Disk".

    In all likelihood, the version 386bsd that is available on CD-ROM
    will be the 0.1 version, without any patches.  Keep this in mind
    when ordering, since the first thing most people want to do is
    bring the system up to the current patch level.  If you do not want
    the original 0.1 version, be sure to ask where the distribution
    came from and which version of *BSD it is.

    For our European users, I have included these notes from Julian
    Stacey ([e-mail]) and Christian Seyb ([e-mail])
    concerning locations and methods for getting 386bsd in Europe on
    both CD-ROM and floppies.

    ----------------------------------------------------------------------
    The following CDROM is available for DM 98,-- (app. $60) and contains
    the following software:

    - Linux SLS V1.03, Kernel 0.99.11 and utilities for Linux
    - 386BSD version 0.1 including patch-kit 0.2.4
    - NetBSD version 0.8
    - Utilities for 386BSD and NetBSD
    - The Berkely Second Networking Distribution
    - GNU software (gcc 2.4.5, emacs 19.17, gmake 3.68, etc)
    - X11R5 up to patch 25 and lots of Contributed Software
    - TeX version 3.14
    - The Internet RFCs up to RFC1493
    - News, mail and mailbox software and many utilities for Unix


    To: CDROM Versand
        Helga Seyb
        Fuchsweg 86
                                              Tel: [phone]
        85598 Baldham                         Fax: [phone]
        Germany                           Bbs/Fax: [phone]

    (Ed. Note:  This appears to be an advertisement, but the price is
    right and appears to be reasonable.  Christian and Helga may have
    the same last name by coincidence :-)  If you want more ordering
    information, please feel free to give Helga a call.)
    -----------------------------------------------------------------------

    In Munich Germany:
    Buy the monthly "c't magazin fuer computer technik" (Price 8.5 DM)
    (~1.7 = $1) & look in back pages, I saw:

    Mail Order:
        JF Lehmanns Buchhandlung, fuer EDV,
        Zuelpicher Str 182, D-50937 Koeln, Germany
        Free catalogue for X, Linux, 386bsd, 1.
        Confusing advert seems to offer X11R5 + GNU + 386BSD
        on CD Rom "InfoMagic Vol2 No2" for Price: 149 DM.
        Tel. [phone] (always busy, claims to be free,
            so don't know if [phone] viable)
        Fax: [phone]
        Shops in Berlin, Koeln, Regensburg, Ulm.

    (Editorial Notes:  DM149 is about $75-$90 US (or a little more)
    and 0130 numbers are Toll Free in Germany only.)

    Mail Order:
        Computer Solutions Software GmbH
        Postfach 1180, D-85561 Grafing (Muenchen), Germany
        Tel [phone]
        Fax [phone]
        23 * 3.5" 1.4M flops @ Price: DM199
        Order No:/Best Nr: 5099
        Shop:
            Columbus Datentechnik,
            Theresienstr 63, D-80333 Muenchen, Germany
            Tel [phone]

    Lynne wrote a short follow-up, letting us know that these
    companies do not send them any money.

    This announcement in from Jordan Hubbard:

    On the morning of 30 December, 1993, and after many many delays,
    the first official release of FreeBSD 1.0 began shipping on CDROM.

    This CD is being sold through Walnut Creek CDROM, our ongoing
    sponsors in the FreeBSD project, and without whom we would have had
    a substantially more difficult (if not impossible) time producing it.


    While I will _always_ encourage obtaining FreeBSD through "free"
    channels (the Internet, friends, suspicious individuals in dark
    alleys), and given that none of us will make any money from CD
    sales, or ever have from FreeBSD in general given that WC's
    sponsorship is confined to the loan of centralized development
    hardware and network access, I still hope that some of you will
    find the CD distribution medium convenient enough to order a
    FreeBSD CD from Walnut Creek, thus indirectly supporting our
    future development work.

    If this marriage between commercial and free software interests
    proves to be mututally beneficial (which still remains to be seen,
    from Walnut Creek's point of view), it is my hope that it may serve
    as a model for similar future endeavors.  It is an unfortunate fact
    that developing free software at this scale costs money, even with
    the developers donating their time and efforts, and financing some
    of it through the sale of convenient distribution media is one of
    the least venal ways I know of going about it.

    This CD contains a full FreeBSD 1.0.2 source & binary release, the
    sources and binaries for XFree86 2.0, and numerous sources from the
    FreeBSD "ports collection".  Where space permitted, sources were
    provided in both "packed" and "unpacked" forms for easy access both
    as an on-line resource and as a source for compressed downloads in BBS
    or release-construction situations.  The CD is fully ISO9660 compatable
    and has been mastered using RockRidge extensions for long filenames on
    systems that support it (like FreeBSD! :-).

    It is, of course, possible to install the system off the CD from
    scratch, given some basic willingness to read a little documentation
    and a few blank floppy disks.  [ Ed Note.  You would be surprised the
    number of people that do not see this paragraph...DBB]

    For the sake of convenience, I append the ordering information
    distilled from FreeBSD's /usr/src/RELNOTES.FreeBSD below.

    Ordering information:

        Walnut Creek CDROM
        4041 Pike Lane, Suite D
        Concord CA  94520
        1-800-786-9907, [phone], [phone] (fax)

    Or via the internet from [e-mail].  A current catalog can
    be obtained via ftp from ftp.cdrom.com:/cdrom/catalog.

    Cost is $39.95.  Shipping (per order, not per disc if ordering
    multiple disks) is $5 in the US, Canada, or Mexico and $10.00
    overseas.  They accept Visa, Mastercard, American Express, and
    ship COD within the United States.  California residents please
    add 8.25% sales tax.

    In addition, John Cargille publishes a CD-ROM which caters
    primarily to the NetBSD crowd.  It is called BSDisc and it is
    also available by mail.  While that may seem like terrific news,
    it is unfortunately all the information I have right now.  Once
    he sees his name in the FAQ, maybe he'll put together some real
    ordering instructions ;-)

    [e-mail] (Roman Yanovsky  [e-mail]) sent in this
    note.  I have editted it down some, but left in the bulk of the
    stuff in case you need more information:

    Subject: Linux Slackware and FreeBSD CD-ROM with X-windows etc.

    Trans-Ameritech presents "The best Linux plus FreeBSD CDROM ever"

    [ Linux stuff deleted ]

    * For hacker's reference an uncompressed FreeBSD source tree is
    provided.

    * On the BSD side there is a full source and binary distribution
    of the "final" FreeBSD 1.0

    * If you have questions or problems Trans-Ameritech provides free
    support via e-mail within 24 hours.

    * We ship the same day as we get the order.

    The new CDROM is available for $30 plus shipping/handling. If you
    are a current customer, it is only $20.  New releases will be
    available every 3 month. Subscription is available.

        Trans-Ameritech Enterprises, Inc.
        2342A Walsh Ave.
        Santa Clara, CA 95051

        Tel. [phone]
        FAX: [phone]

    This information is offered with no warranties, guarantees,
    franchise offers, or recommendations.

1.6    Electronic Information Groups for 386BSD

1.6.1    Usenet newsgroups

    General BSD questions can be posted to comp.1.bsd.  Bear
    in mind, however; that your questions to this group should
    really be about BSD in general, not a specific implementation
    detail of *BSD.

    Listed below are the Usenet newsgroups that were developed to
    support 386bsd and its descendents.  This means that you should
    ask your questions in one of these newsgroups or on one of the
    many mailing lists that are available for specific features of
    said systems.

    comp.os.386bsd.announce (Moderated)
        Announcements relating to the 386bsd operating system.
        Posts should be mailed to "[e-mail]".
        This is also the place that improtant news about the past
        and future of 386bsd, FreeBSD, and NetBSD will be placed.

    comp.os.386bsd.apps
        Applications which run under 386bsd.  Not all sites will
        carry comp.os.386bsd.apps, since it kind of 'showed up'.

    comp.os.386bsd.bugs
        Bugs and fixes for the 386bsd OS and its clients.

    comp.os.386bsd.development
        Working on 386bsd internals.

    comp.os.386bsd.misc
        General aspects of 386bsd not covered by other groups.

    comp.os.386bsd.questions
        General questions about 386bsd.


1.6.2    Newsgroup archives.

    These sites maintain a historical record of the traffic in the Usenet
    Newsgroups indicated.  There are others, but I haven't gotten their
    names yet.

Host Name            IP address     Location        Newsgroups archived
-------------------- -------------- --------------  ----------------
minnie.cs.adfa.oz.au 131.236.20.70  Australia       comp.1.bsd
src.doc.ic.ac.uk     146.169.2.1    London, UK      comp.os.386bsd.*


1.6.3    386bsd Derived mailing lists.

    There are at least two mailing lists for 386bsd.  Both are for
    discussions of the patchkit and patches.  Last I heard, neither
    of them is particularly active any more.  They are:

    [e-mail]:
        This list is primarily for discussion of the patchkit and other
        patch procedure discussions.
    [e-mail]:
        This list is for patch submissions.

    NOTE: The patchkit is discussed in detail in Section 2 of the FAQ.
    Also, the patchkit has been effectively deprecated.  Sending to
    these lists may or may not get you the kind of info you are looking
    for.

    In addition to the pure 386bsd lists mentioned above, there are
    mailing lists available for FreeBSD and NetBSD.  Information about
    the NetBSD lists and how to use majordomo (the list handler) is
    available by mailing to [e-mail].

    There are three mailing lists for FreeBSD and they are:

    FreeBSD-hackers: for hackers
    FreeBSD-questions: misc questions
    FreeBSD-bugs: bug reports

    Send to [e-mail] to be added
    to the hackers list, and *-questions-request@freefall... to be
    added to the questions list.


1.6.4    Other electronic resources.

    There are many bulletin boards throughout the world that have
    386bsd software and information available.   Also, there are
    CompuServe and other on-line services that have 386bsd
    discussions.  It is even rumored that Bill and Lynne have been
    active on Compuserve talking about 386BSD Version 1.0 (or 0.2,
    or whatever it is going to be).


1.6.5    System Updates.

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


    Instructions for installing NetBSD sources and releases using SUP
    -----------------------------------------------------------------
                    1.3 1993/11/3

    SUP is a network installation package written by CMU used to
    distribute software. For more details on SUP refer to the man
    pages.

    Sup works by reading a configuration file (supfile) and using
    this information to determine what "collections" of files will
    be loaded from the collection repository.  Here is an example
    of a supfile to load the NetBSD current release.

    [ Notes: lines have been broken for readability; do NOT use '\'
    in supfiles and the information here is an EXAMPLE.  This ain't
    a cooking school, folks.  Also, the information in these lines
    has changed for each of the distributions.  Read the
    documentation that comes with your software carefully for the
    lastest information. ]

    src release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp         base=/usr prefix=/usr backup

    ksrc release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp         base=/usr prefix=/usr backup

    security release=current host=sun-lamp.cs.berkeley.edu         hostbase=/b/anon_ftp base=/usr prefix=/usr backup

    gamessrc release=current host=sun-lamp.cs.berkeley.edu         hostbase=/b/anon_ftp base=/usr prefix=/usr backup

    regress release=current host=sun-lamp.cs.berkeley.edu         hostbase=/b/anon_ftp base=/usr prefix=/usr backup

    #othersrc release=current host=sun-lamp.cs.berkeley.edu         hostbase=/b/anon_ftp base=/usr prefix=/usr backup


    This supfile will load the "current" collections for "src",
    "ksrc", "security", "gamessrc", and "regress" in the /usr
    directory on the local machine.  The "othersrc" collection will
    not be loaded because it is commented out.

    The supfile line is made up of keywords that describe the
    collection's location on the sup server and where and how it
    will be loaded on the local host.

        release - the release of the collection to load.
            host    - the 'host' where the SUP repository resides.
            NetBSD uses sun-lamp.cs.berkeley.edu .
            hostbase- the pathname on the host to the base of the
                collection.  The hostbase for NetBSD is "/b/anon_ftp".
        base    - where you want to install it locally.
        prefix    - used to locate the "sup" directory to write sup's
            info about updates. Usually the same as base.

    This supfile can also set some options. The "old" option tells sup
    to check all files for changes, not just those that are newer than
    the last sup update. Normally sup will overwrite local files with the
    changed file from the repository. If the sup collection specifies
    that an existing file should be renamed to a backup, the "backup"
    option in the supfile activates this. The "delete" option tells
    sup to delete any files locally that are no longer in the
    collection - be careful with this one.  The "keep" option will
    cause sup to NOT update files that have been changes locally.
    The "compress" option will use gzip to compress the files before
    transfer and gunzip them on the receiving end. This option can be
    used to cut down on the number of transmitted bytes.

    You may want to set 'base' and 'prefix' to something other than /usr
    if you want to preserve your existing src tree.

    The sup repository on sun-lamp.cs.berkeley.edu currently offers these
    collections.

        src, ksrc, security
            The sources for NetBSD

        othersrc
            The current sources for contributed parts of
            NetBSD.  This contains the sources for sup.

        regress
            The current sources for the NetBSD regression test
            suite.

    If you only want the kernel sources for a specific port there are
    some sub packages that you can use instead of the "ksrc" one. If
    you are using the sub packages, be sure to also sup the
    "ksrc-common" package.

            ksrc-common
                    Kernel sources common to all ports.

            ksrc-1, ksrc-sparc, ksrc-hp300, ksrc-amiga, ksrc-mac,
            ksrc-pc532, ksrc-pmax, ksrc-sun3
                    Kernel sources for a particular port.


    The security package is not to be sup'ed by sites outside of the
    U. S., read the "README.export-control" file for details.

    Each collection can have multiple releases (as specified by the
    "release" keyword).

    IMPORTANT!!
    Be aware that the current release is simply a snapshot of the
    daily state of NetBSD development and is not guaranteed to
    build (or even work) - use at your own risk !

    Stable releases of NetBSD are available via SUP.  Instructions
    are included with the release announcement.

    Before running sup, be sure that your /etc/services contains
    these entries.

    supfilesrv      871/tcp         # for SUP
    supfiledbg      1127/tcp

    To try sup without really updating anything use the '-f' flag.
    The '-v' flag means verbose and can be used to see what sup is
    doing.

        sup -fv supfile

    The sup binary, sup man page and sample supfiles can be ftp'ed
    from sun-lamp.cs.berkeley.edu:~ftp/pub/sup .  Comments should be
    directed to "[e-mail]".

    A mailing list exists for users of the NetBSD "current"
    release.  To join, mail to '[e-mail]'
    with a mail body of "info".  The reply will describe the mailing
    lists for NetBSD.  The you will want to subscribe to the
    "current-users" mailing list.  We will use this list to announce
    any special changes made to the "current" tree.


1.7    Documentation available

    This entire section pertains as much to NetBSD and FreeBSD as
    it does to 386BSD.  Simply 'sed 's/386bsd/Your System/g' below.

    There are two types of documentation for 386bsd.  First is the
    set that covers the operation and theory used in BSD-Unix.
    These sources are often excellent for background and understanding
    of the current implementation of 386bsd.  Second is the set of
    manuals written specifically for 386bsd.  Most of these are books
    and magazine articles written by Bill and Lynne Jolitz.


1.7.1    BSD manuals

    The full set of BSD documentation is available via anonymous FTP
    from ocf.berkeley.edu in /pub/Library/Computer/doc4.3.  To print
    this documentation on 386bsd systems, replace the ditroff
    references in the Makefile with 'groff -e -t -msU {SRC} >out.ps'
    to generate PostScript format files.  Use different options to
    make the output conform to other print styles.

    The etc distribution also comes with a documentation directory
    /usr/share/doc which has nearly 3Meg of documentation about *BSD.

    In addition, on-line manuals are available in the binary
    distribution set.  It contains specific information on the use
    of UNIX utilities and commands.  Type "man man" for information
    on the online manual.


1.7.2    BSD books

    There is an excellent set of works recommended by Bill and Lynne
    in the original 386bsd INSTALL.NOTES.  In addition, several other
    books have been recommended by Andrew Moore and others.

    For learning how to work in the Unix environment, the standard text
    is "The Unix Programming Environment,"  by Kernighan and Pike.

    For Unix Administration, the best is "Unix System Administration
    Handbook," by Nemeth, Snyder and Seebass.

    For systems level programming (i.e., systems calls), I recommend
    "Advanced Unix Programming," by Marc Rochkind.  Unfortunately it is
    out-dated and oriented towards System V.

    A new book "Advanced Programming in the Unix Environment," by W.
    Richard Stevens is very    up-to-date, and an excellent reference,
    especially for dealing with POSIX standards issues.

    For network programming, "Unix Network Programming," by W. Richard
    Stevens is highly regarded.

    The 4.3BSD Unix Manuals contain loads of invaluable tutorials and
    historical papers in addition to hard copies of on-line documentation.
    The six volume set is available from Usenix for $60.00 (email:
    [e-mail])

    The 4.4 BSD Unic Manuals are the authoritative source for
    information about the 4.4 BSD release, and by inference the
    NetBSD and FreeBSD systems.  They are available from O'Reilly
    and Associates (the Nutshell series people).  In addition the
    the six volume set, there is a CD included (at a price) of the
    entire 4.4 release.  Combine this with the NetBSD 1.0 or FreeBSD
    2.0 systems, and you should have a commercial quality operating
    system available in no time.

    I could go on, but let me mention just two more - if you have a full
    386BSD installation, you may want to learn the bash shell (in
    /usr/othersrc/public).  This is an extension of the Bourne shell (sh)
    with features from both the C shell (Csh) and the Korn shell (Ksh).
    The Korn shell is described in "The Kornshell," by Korn (of course).

    Second, I recommend you look at "The AWK Programming Language," by
    Aho, Weinberger and Kernighan.  This is a very nice prototyping
    language - powerful and easy to use.

    Another excellent reference book for 386bsd is "The Design and
    Implementation of the 4.3BSD UNIX Operating system" by  Samuel J.
    Leffler, Marshall Kirk McKusick, Michael J. Karels, John S.
    Quarterman, 1989, Addison-Wesley, ISBN 0-201-06196-1.  While this
    book is out of date in many sections, it is purported to be an
    excellent source of historical information, if nothing else.
    Chris Demetriou recommends the sections on the treatment of
    file systems, caching and the networking layer.  The sections in
    this books which do not apply to 386bsd include the VM section,
    bootstrapping, and autoconfig.

    Here is a list from Hellmuth Michaelis (duplicative as it may seem
    to have all of these lists) for more information on *BSD:

    UNIX AND UNIX DEVICE DRIVERS
    ----------------------------

    Bell Telephone Laboratories, Inc. "UNIX Programmer's Manual, Seventh
        Edition, Volume 2". Revised and Expanded Version.
        Holt, Rinehart and Winston 1983


    George Pajari, "Writing Unix Device Drivers"
        Addison Wesley 1992


    Janet I. Egan and Thomas J. Teixeira, "Writing a UNIX Device Driver"
        John Wiley & Sons 1988


    Janet I. Egan and Thomas J. Teixeira, "Writing a UNIX Device Driver"
        Second Edition. John Wiley & Sons 1992


    Leffler, McKusick, Karels, Quarterman, "The Design and Implementation
        of the 4.3BSD UNIX Operating System"
        Addison Wesley 1988, corrected Reprint 1989


    Leffler, McKusick, "The Design and Implementation of the 4.3BSD UNIX
        Operating System, Answer Book"
        Addison Wesley 1991


    Maurice J. Bach, "The Design of the UNIX Operating System"
        Prentice-Hall 1986


    Sun Microsystems Inc., "Writing Device Drivers"
        Part No. 800-3851-10, Revision A of 27 March 1990


    Hewlett-Packard Company, "HP-UX Driver Development Guide",
        Part No. 98577-90013, First Edition 07/91


    W. Richard Stevens, "Advanced Programming in the UNIX Environment",
        Addison Wesley 1992


    Phillip M. Adams, Clovis L. Tondo, "Writing Unix Device Drivers in C",
        Prentice Hall 1993


    Peter Kettle, Steve Statler, "Writing Device Drivers for SCO UNIX,
        A Practical Approach", Addison Wesley 1993

    In addition, there are many other books which, for one reason or
    another, have not made it into this brief list.  Rest assured that
    this is not intended to be an exhaustive list by any means.


1.7.3    The Jolitz Book

    Bill and Lynne Jolitz are writing a book about 386bsd.  It will
    be announced once it is ready.  A tentative date of late 1992
    was once offered, but since it is now 1994 and no book has
    been announced, we can assume that it will be later than the
    original estimate.


1.7.4    Dr. Dobbs' journal

    For users who wish to understand the internals of the BNR/2 BSD
    family of Operating Systems originally developed and/or ported by
    William F. Jolitz from 1989 to the present, the most immediate
    and available reference is the feature series entitled
    "Porting UNIX to the 386: A Practical Approach", appearing in Dr.
    Dobbs' Journal, USA (January 1991 to July 1992) and UNIX and iX
    Magazines, Germany (June 1991 to present). For inquiries on the
    article series (including reprints),  contact the magazines for
    information.

    "Porting UNIX to the 386: A Practical Approach" (feature series)
    by Jolitz and Jolitz

     1/91: DDJ        "Designing a Software Specification"
     2/91: DDJ        "Three Initial PC Utilities"
     3/91: DDJ        "The Standalone System"
     4/91: DDJ        "Copyright, Copyleft, and Competitive Advantage"
     4/91: DDJ        "Language Tools Cross-Support"
     5/91: DDJ        "The Initial Root Filesystem"
     6/91: DDJ        "Research and the Commercial Sector: Where Does
                BSD Fit In?"
     7/91: DDJ        "A Stripped-Down Kernel"
     8/91: DDJ        "The Basic Kernel"
     9/91: DDJ        "Multiprogramming and Multiprocessing, Part I"
    10/91: DDJ        "Multiprogramming and Multiprocessing, Part II"
    11/91: DDJ        "Device Autoconfiguration"
     2/92: DDJ        "UNIX Device Drivers, Part I"
     3/92: DDJ        "UNIX Device Drivers, Part II"
     4/92: DDJ        "UNIX Device Drivers, Part III"
     5/92: DDJ        "Missing Pieces, Part I"
     6/92: DDJ        "Missing Pieces, Part II"
     7/92: DDJ        "The Final Step: Running Light with 386BSD"

    You can contact M&T Books (DDJ) for reprints if you can't get them from
    your technical library:

    1-800-356-2002 (inside CA)
    1-800-444-4881 (better In NA Backorder number)
    1-415-358-9500 (international)

     6/91: UNIX Magazin    "Portierung von BSD-UNIX auf den 80386. Heimlich
                Liebe."
     7/91: UNIX Magazin    "Steighilfe."
     8/91: UNIX Magazin    "Systemverwaltung durch Tabellen"
     9/91: UNIX Magazin    "Sicher bewegen auf fremdem Terrain"
    10/91: UNIX Magazin    "Damit die Fehlersuche nicht zum Hurdenspringen
                wird"
    11/91: UNIX Magazin    "Alles in eine Schublade"
    12/91: UNIX Magazin    "Feuer und Wasser"
     1/92: UNIX Magazin    "Rekursives Speicher-Mapping"
     2/92: UNIX Magazin    "Tanz auf dem Eis"
     3/92: UNIX Magazin    "Aus Hanschen wird Hans"
     4/92: UNIX Magazin    "Das Geheimnis des Multiprogramming"
     5/92: UNIX Magazin    "Zeitmanagement scheibenweise"
     6/92: UNIX Magazin    "Magie des Kernels"
     7/92: UNIX Magazin    "Erkenne Dich Selbst"
     9/92: UNIX Magazin    "Niemand is eine Insel"
    10/92: UNIX Magazin    "Treiberlatein"
    12/92: UNIX Magazin    "Einlandung erforderlich"
     1/93: iX Magazin    "Wir unterbrechen das Programm"
     2/93: iX Magazin    "Liste gut, alles gut"
     3/93: iX Magazin    "Blick ins Allerheiligste"
     4/93: iX Magazin    "Von Bl"ocken, Ringen und Zeichen"

    NOTE: The series in UNIX Magazin was moved to IX Magazin in 1/93.
    The article in the April issue was the last one in the series.

    In addition, other major articles which discuss 386BSD in detail:

     8/92: UNIX Magazin "Interview mit Bill Jolitz. Das passiert mit
         386BSD" by Jurgen Fey
     8/92: DDJ "Very High-Speed Networking" by W.F. Jolitz
    12/92: DDJ "Inside the ISO-9660 Filesystem Format" by Jolitz and
        Jolitz

    Reprints of the first 19 parts on the UNIX Magazin series are available
    from:

    iX Redaktion
    Stichwort: 386BSD-Serie
    Verlag Heinz Heise GmbH & Co KG
    Helstorfer Str. 7
    D-30625 Hannover, Germany

    Some of the parts are without code listings due to the unclear
    status of the BSD releases stemming from the Net/2 release.  Dr.
    Dobbs is reported out of back issues of the articles listed above.
    You best bet may be to try your local public or school library.

1.7.5    Documentation that comes with most of the distributions.

    In the standard set for both NetBSD and FreeBSD there is a directory
    called '/usr/share/doc'.  Here is a 'du' listing.

        128    /usr/share/doc/ps1/06.sysman
        98    /usr/share/doc/ps1/07.ipctut
        116    /usr/share/doc/ps1/08.ipc
        16    /usr/share/doc/ps1/13.rcs
        37    /usr/share/doc/ps1/14.sccs
        420    /usr/share/doc/ps1
        123    /usr/share/doc/smm/02.config
        14    /usr/share/doc/smm/04.quotas
        78    /usr/share/doc/smm/05.fsck
        42    /usr/share/doc/smm/06.lpd
        92    /usr/share/doc/smm/07.sendmailop
        14    /usr/share/doc/smm/08.timedop
        99    /usr/share/doc/smm/10.newsop
        83    /usr/share/doc/smm/11.named
        77    /usr/share/doc/smm/14.fastfs
        128    /usr/share/doc/smm/15.net
        41    /usr/share/doc/smm/16.sendmail
        21    /usr/share/doc/smm/20.termdesc
        17    /usr/share/doc/smm/22.timed
        851    /usr/share/doc/smm
        144    /usr/share/doc/usd/04.csh
        97    /usr/share/doc/usd/07.Mail
        66    /usr/share/doc/usd/09.newsread
        68    /usr/share/doc/usd/10.etiq
        67    /usr/share/doc/usd/14.edit
        107    /usr/share/doc/usd/15.vi
        61    /usr/share/doc/usd/16.ex
        13    /usr/share/doc/usd/21.msdiffs
        45    /usr/share/doc/usd/22.memacros
        43    /usr/share/doc/usd/23.meref
        26    /usr/share/doc/usd/33.rogue
        25    /usr/share/doc/usd/34.trek
        798    /usr/share/doc/usd
        2077    /usr/share/doc

    For those of you that don't read 'du -k' listings, this means that
    there is 'around' 2 MEGABYTES of documentation in the 'doc'
    directory.  In addition, there are a few man pages.

        2312    /usr/share/man/cat1
        397    /usr/share/man/cat2
        1    /usr/share/man/cat2a
        855    /usr/share/man/cat3
        1    /usr/share/man/cat3f
        607    /usr/share/man/cat4
        368    /usr/share/man/cat5
        166    /usr/share/man/cat6
        169    /usr/share/man/cat7
        749    /usr/share/man/cat8

    Something on the order of another 4 Megabytes of manual pages.
    That's what, about 6 MILLION CHARACTERS of documentation.

    I have received mail from several sources saying that my
    approximation of the amount of system documentation is way too
    low (by a factor of at least 50%).  Given the fact that even by
    my meager estimation there is already more information here
    than most people can be bothered to read, whether there is 6
    Meg or 60 Meg seems like overkill.

    Now, does anyone REALLY want to whine about there being no
    documentation included with the system?


1.7.6    Other FAQ's on the net that are relevant

    There is now a FAQ set up specifically for FreeBSD.  In addition
    to answering the many specific questions that folks have about
    FreeBSD, it is also a good source for information on NetBSD and
    whatever the 386BSD {0.2,1.0,95} project is going to look like.
    In spite of all of the shouting and chest beating that you hear
    from time to time, the systems are still very close.

    There are many FAQs that can be used in conjunction with 386bsd.
    These include the FAQs for all of the GNU software, the different
    shells that are available, the programming languages that are
    available, and many more.  In addition, many programs have their
    own FAQ which should be referenced whenever that package is being
    added.  Good examples of the latter are the FAQs for elm, C-News,
    and innd.

    The observant reader will notice that there are very few 'X'
    questions in this FAQ.  The XFree86 FAQ is posted regularly to
    comp.os.386bsd.*.  There is no good reason to include any 'X'
    questions in this FAQ, with the exception of the most basic
    'Where can I get the 'X' FAQ'.

    Most FAQs are available by anonymous FTP from rtfm.mit.edu and
    via Usenet News in news.answers and/or comp.answers.  This FAQ
    is no exception (I hope).


1.8    FTP sites for 386BSD

    A standard tool on Internet connected hosts for finding files is
    'archie'.  Searching the archie archive for either "386BSD"  or
    "386bsd" yields the following list.   For UUCP sites, FTP-Mail
    is available from gatekeeper.dec.com.  The list below was created
    with an 'archie -l' on 26 Feb 1995 searching for FreeBSD.

    For those folks that have access to telnet, but not FTP, you can use
    archie by using telnet and connecting to 132.206.2.3.  Log in as
    'archie' and use the 'prog' command to find programs of interest.
    The list below is included primarily for those folks that have only
    uucp, and will need to get their software though UUCP and other
    channels.


1.8.1    FTP Site List

    This list is automatically generated every time the FAQ is
    produced.  Please do not request that your host be added to
    this list.  If your host is represented in an 'archie' list,
    it will be reflected here.  Several other sites are included
    in Section 1.8.4 below.

    Host                    Directory


    The code may soon also to be available, or perhaps is already
    available, from both CompuServe and BIX.

1.8.2    Official distribution sites

    According to Lynne Jolitz, there is no such thing as an 'official'
    386bsd site.  The closest we had was 'agate.berkeley.edu' which is
    now closed.  Because of the USL/UCB agreement, 386bsd is no
    longer freely redistributable, since it was based on Net/2 and
    Net/2 was encumbered.

    FreeBSD's 'home' is FreeBSD.cdrom.com (the home disk of Walnut
    Creek).  The portions of FreeBSD (versions less than 2.0) that
    were encumbered are distributed with the tolerance of
    AT&T/USL/Novell/whoever owns the source for SysV this week.  All
    FreeBSD versions (with version number >= 2.0) are based solely
    on the freely redistributable BSD 4.4 sources.

    NetBSD's 'home' is now ftp.NetBSD.Org.  All versions of
    NetBSD since 0.9 have replaced the kernel code from the 4.3
    distribution with the source from the 4.4 distribution.  The
    only code still in NetBSD from the 4.3 distribution is some user
    program code that was uncontested in the USL/UCB agreement.


1.8.3    Reference sites

    For a brief period, ref.tfs.com was available for use as a
    reference system.  This system was used as the test-bed for
    many programs that were ported to 386bsd by many authors.
    Unfortunately, ref.tfs.com has been disabled as a reference
    system. The site is now a update by mail (CTM) system and is
    providing a mail only service for developers who do not have
    access to anything more than electronic mail.  For more
    information, contact [e-mail] for the standard
    CTM package.

    There is a site in Germany that is acting as a reference site
    for FreeBSD.  The name is "g386bsd.first.gmd.de", also known as
    "bsd386.first.gmd.de". Sorry, no anonymous ftp yet. But there is
    a "guest" login with the password "guest".

    But the most important reason why I had installed the machine on
    the network was for all these people who don't have enough space
    to compile their own kernel or their own packages.   They can do
    it on this machine.  ATS ( [e-mail] or [e-mail] )


1.8.4    Unofficial archive sites that have neat stuff!

    There are many sites that have things which have either been ported
    to 386bsd or are available to the world.  Use archie to find these
    sites, or read comp.os.386bsd.* for more information.

    Listed here because they don't have access to 'archie' yet...
    g386bsd.first.gmd.de -or- bsd386.first.gmd.de:
        Sources for 386bsd0.1 and the later patchkits.
        Source for NetBSD0.8 and the newer snapshots.

        Xfree is installed binary as version 1.3.

    Ported software are:
        tcsh6.03.00
        emacs19-15
        gcc-2.4.5
        top3-1
        perl4.0.36
        elvis1.7
        bison-1.21
        rn and nn.

     In addition, ftp.cs.tu-berlin.de has a lot of neat
     software and Wolfram Schneider ([e-mail]) has
     'ported' the FAQ into LaTeX.  It is available in
     pub/386BSD/FAQ/tex in both PostScript and DVI formats.


1.8.5     X for 386BSD 0.1 Ported Software List

    This is a list of non-core X window system application that
    have been ported to 386BSD 0.1.  The ftp server and directory
    name are listed above and each file or directory name is
    followed by a short description.  Feel free to send corrections,
    additions or suggestions to [e-mail].

    nova.cc.purdue.edu:/pub/386bsd/submissions

    Xdtm-2.5.386bsd        X desk top manager
    idraw-bin.tar.Z        C++ GUI class library + WYSIWYG document &
                graphics editors.
    img1.3.386bsd.tar.Z    see above
    mpeg_play.Z        animated raster image viewer
    small_X11r5.tZ        a minimal subset of the core distribution
    vogl.tar.Z        a library that emulatates Silicon Graphics
                GL calls
    xview3            sun's GUI development tool kit

sunvis.rtpnc.epa.gov:/pub/386bsd/incoming:

    Dirt.tar.Z        GUI development tool kit
    XBSD8514-0.1.Z        8514 X server port
    XS3-0.3-exp.Z        S3 X server port
    acm.tar.Z        aerial combat mission/flight simulator
    chess-vort-movie.tar.Z    ?
    epoch.Z            enhanced emacs for X
    jpeg.tar.Z        jpeg viewer
    libXaw3d.a.Z        3D widget library
    mpeg-1.2.tar.Z        animated raster image viewer
    ups-2.45.bin.tar.Z    C source level debugger with slick GUI
    vort-movie.tar.Z    ?
    xantfarm.tar.Z        screen saver with ants?
    xbench.tar.Z        X server performance measurement tool
    xpipeman.tar.Z        game: connect pipes to keep a liquid within
    xxgdb.tar.Z        GUI for GNU source level debugger

1.8.6    Motif for the *BSD family. (Infomercial to follow)

    While I don't normally include commercials in the FAQ, I will
    this time.  Motif is an interesting product that will help the
    development of the free Unices.  It can also serve as a
    benchmark for other commercial organizations to consider
    supporting us by producing versions of their products that will work
    on these systems.

    Sequoia International, Inc. (305-783-4915/305-783-4935 (FAX))
    sells a complete Motif 1.2.3 Runtime and Development package
    for FreeBSD, NetBSD, BSD/386, Linux, and Coherent.  It is
    available for $149.95 and includes the following:
       * The Motif Window Manager (mwm)
       * Shared Library (libXm)  [operating system dependent]
       * Static Libraries (libXm, libMrm, libUil)
       * Header and Include Files
       * Complete On-Line Manual Pages
       * Source code to OSF/Motif Demo programs
       * Complete OSF/Motif Users Guide

    Send mail to [e-mail] or contact them at the address below:

    Sequoia International, Inc.
    600 West Hillsboro Blvd, Suite 300
    Deerfield Beach, FL 33441
    Phone: [phone] / FAX: [phone] / Email: [e-mail]


--
TSgt Dave Burgess           | Dave Burgess
NCOIC, USSTRATCOM/J6844     | *BSD FAQ Maintainer
Offutt AFB, NE              | [e-mail]

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

Section 2.    (Common installation questions)


2.0    Install process

    The 386bsd system is distributed in many ways.  One of the most
    common is via DOS diskettes, (either 3 1/2 or 5 1/4, both high
    density) with the actual distribution being a 'CPIO archive'
    broken into 240K pieces.  This allows the distribution to fit
    onto a minimum number of floppies.

    Once the files are on floppies, thoughts usually turn to
    questions about how to install the boot image on a floppy.  The
    rawrite program (for DOS) is used to write the bootable images
    (dist.fs and fixit.fs) onto floppies.  The same image can used
    for 3 1/2 and 5 1/4 high density diskettes.  Low density
    diskettes are not supported in this version of 386bsd.

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

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

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

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

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

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

    Keep trying, these same files have been used by literally
    thousands of people to install 386bsd.

    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:

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

    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.

    You did back your system up, right?


2.0.1    Boot disks  (versions and media formats)

    There is currently one official 386bsd 0.1 boot disk, referred
    to as the "Tiny" boot disk.

    Because of the nature of the agreement between USL and
    Berkeley, it is rapidly becoming impossible to get 386bsd 0.1
    diskettes.  The archive at agate.berkeley.edu has been
    eliminated completely.  The NetBSD archive that was there has
    also been eliminated.

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


2.0.1.1    Where does extract go when I reboot?

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

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

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


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

    There are lots of possibilities.  We will start with the oldest
    (386bsd 0.1) problems.

    This is usually referred to as the Compaq boot problem.  The
    easiest solution is to get a patched boot disk.

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

    The FreeBSD install process is said to be better than the NetBSD
    program for some machines.  Could be.  They are all available for
    free from the net.  Try it.


2.0.1.3a    The floppy booted, but now the hard disk won't boot?
2.0.1.3b    I am trying to reinstall.  I run install and it loops
          asking me if I want to use the whole disk?

    The most likely culprit is your hard disk controller.  It is
    probably doing some type of disk translation for you.  If this
    is the case (assume it is) then you will need to find out the
    real disk controller geometry, and rewrite your disk label.
    See section 2.6.2, but before doing that get the program
    pfdisk.exe.  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:


        -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.
            ( not sure if this is presently working)

    I have noticed that there is a fourth one.  I'll write it up
    later.


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.0.2    Fix-it boot disk

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

    For NetBSD and FreeBSD, you will probably have to build your own
    Fixit disk.  You can mount the original file system floppy and
    beat it to death if you want.  Put programs on it that you will
    need to build a new system.  As I think of them, I will put them
    in.

2.1    Binary distribution

    The binary distribution 386bsd 0.1 consists of virtually all of
    the programs that a typical *nix system would be expected to have.
    The list includes mail, UUCP, GCC version 1.39, and others.

    Known problems with the binary distribution include the following:

    1.  Mtools as shipped in the bindist does not always work.  The
    ones on the install disk seem to work fine.

    2.  The install script built into the binary distribution does
    not correctly install all of the files and symbolic links that it
    should.  For example,  some of the symbolic links to the
    /usr/include directory are botched up.

    3.  'tip', the modem control program, does not always work right
    out of the box.

    4.  Any program that relies on a valid symbol table in the kernel
    (e.g. ps) will not work because the kernel is stripped so that it
    will fit onto the bootable disk.

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

    FreeBSD and NetBSD have solved these problems.  This information
    is included primarily for those few people that get sucked into
    using an old version of 386bsd for a class or something.


2.1.1    I want to install by NFS but I am having all kinds of problems.

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

    # mount -o resvport server:/fs /mnt_point

    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:

      -P server:/fs

    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    Source distribution

    The source distribution 386bsd 0.1 contains all of the source code
    for every program in the bindist.  Known problems (which are fixed
    in the patchkit) include the following:

    1.  There is an error message during install about install.src01
    not being found.  It is not an error, there isn't an install.src01.
    Think of it as Bill and Lynne's idea of a practical joke.

    2.  There are several symbolic links that are not made correctly.
    In addition, there are several files that should have been deleted
    (to ensure clean 'make's) before the files were packed.  This is
    fixed by the patchkit, as of 0.2.3.

    3.  The /usr/src tree does not compile cleanly.  This is fixed by
    the patchkit, as of 0.2.3, or by NetBSD or FreeBSD.


2.3    Additional software distribution

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

    The most common problem with the etc distribution is the error
    "too many files open".  Followed closely by "install.etc01 not
    found".  The latter is a annoyance (see above) but the former can
    be easily overcome in a couple of ways.

    The "too many files open" is a result of the "cat" command leaving
    files open after it has read a file.   Dwight E. Cass (his Email
    address is [e-mail]) has provided us with this
    anecdotal work around for his own experiences:

    --------------------------------------------------------------------
    So - back to installation.  This time, when I get to the etc01
    partition, I am a bit more awake, so I run it from Csh (with the
    open file limit at 256).  Works pretty well - but complains at the
    end that it could not do the final configuration because it could
    not find the configuration file - I checked the MANIFEST and the
    file is not there, so I finally decided to ignore the message (but
    it was bothersome!)  Once etc01 was done - source was easy ... and
    I am now up and running, and quite impressed!!!
    --------------------------------------------------------------------

    Another method is to use a loop construct in the Bourne shell.  For
    example:

    for i in (etc01.*)
    do
      cat $i
    done | compress -d | cpio -idalmu

    -or-

    for i in (etc01.*)
    do
      zcat $i
    done | cpio -idalmu

    will also solve the problem handily.  This solution solves the problem
    by running cat multiple times, with one file each.  Since cat now only
    has one file, there are no limits on the number of files that can be
    used for the distribution set.

2.4    Patch-kit

    The patchkit has been completely deprecated.  FreeBSD and NetBSD
    are both mature programs that will serve the average user extremely
    well.  The patchkit may still be available, but it is only required
    if you are installing the original 386BSD 0.1 version.

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

    [e-mail], which is primarily for discussion of
    up-coming patches and patchkit philosophy.

    [e-mail], which is dedicated to submitting new,
    untested patches.

    The current (and final) version of the patchkit is 0.2.4, which
    has absolutely no relationship with the new version of 386bsd.
    It is available by anonymous FTP from several sites throughout
    the net.


2.5    Configuration

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


    A less frequently asked question is "Where can I get info on how
    to configure a kernel?"  The answer to this question has been
    provided by Richard Murphey (Email address [e-mail]).

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

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

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

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

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

    This tutorial is provided by by "<[e-mail]>" and
    provides an  excellent overview of the hard disk partitioning
    procedure from start to finish.

        "Disk Partitioning for the Compleat Idiot"

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

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

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

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

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

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

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

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

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

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

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

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

    d: Must refer to the whole disk, from cylinder 0 to the last
    one...

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

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

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

    Some math:
    Looking at the comments at the end and the size and offset columns,
    size is a function of (last - first + 1) * sectors per cylinder:
    a: 399 - 0 + 1 = 400 * 496 = 198400
    b: 965 - 902 + 1 = 64 * 496 = 31744
    c: & d: (Since I have no DOS partition, whatsoever)
          965 - 0 = 1 = 966 * 496 = 479136
    e: 901 - 400 = 502 * 496 = 248992

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

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

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

    Note from TSgt Dave:

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

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

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

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

    Note from TSgt Dave:

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

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

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

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

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

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

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

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

    One last note from TSgt Dave:

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

    Comnonly used definitions:

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

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

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

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


    Cgd posted a description of how to manually install 386bsd and
    create 'real' BSD partitions.  It is excerpted below:

    --------------------------------------------------------------------
    HOW TO GET 386bsd 0.1 INSTALLED WITH "REAL" PARTITIONING:

    (remember, if things don't work, they might be in places that aren't
    normally looked in... things should work as below, but you might
    have to use explicit paths occasionally... the 'better' stuff --
    mount, umount, cp, etc... is in /usr/distbin on the fixit floppy...
    even mknod is there, if the devices you need aren't on the fixit
    floppy...)

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

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

    congratulations!  you now have a working system!

    you can repeat step 21 for the srcdist and etcdist files, as well,
    if you wish...


2.5.2    Common Disk Label Problems.
2.5.2.1    Swap space.

    Nate Williams provides a short tutorial on swap space in 386bsd,
    excerpted below:

    To be able to use additional swap partitions, you need to specify
    them in the config (/sys/i386/conf/WHATEVER) file.

    Ex:

    config          "386bsd"        root on sd0 swap on sd0 and sd1

    Allows swap on sd0 and sd1

    config          "386bsd"        root on wd0 swap on wd0 and sd0

    This would allow swap on both wd0 and sd0 OR whichever (both/either)
    of the two had a valid disklabel.  Note, you can really screw
    yourself up with this, if you should happen to not want to swap to
    this partition, and it happens to be the first one found...

    The problem of not being able to swap was from the config file not
    having wd1 in it.

    controller      wd0     at isa? port "IO_WD1" bio irq 14 vector wdintr
    disk            wd0     at wd0 drive 0
    disk            wd0     at wd0 drive 1
                    ^^^
    This should have been wd1, and that's why it didn't get added by
    default.  I may be wrong, but I have swapped to two different
    partitions w/out any problems since patchkit 0.1, and there aren't
    any patches to swap386bsd.c

    Once the install is complete, swapping will not be enabled on the
    second drive.  The following steps can be used to make sure that it
    is enabled correctly.

    If there is a 'b' partition in your root disk 386bsd partition, it
    will be used automatically (MAKE SURE B is not the start of the
    disk, and MAKE SURE b doesn't contain any data you wish to keep).
    If b starts at disk offset 0, it will promptly wipe out your boot
    sectors and other important disk stuff.  (This appears to be fixed
    in the current NetBSD sources)

    If you want an additional partition, put an entry similar to this
    in /etc/fstab:

    /dev/sd1b    none            swap        sw

    I'm swapping on sd0b and sd1b, and 'swapon' is run on this partition
    on boot up.

    Swapping to a file is still not implemented.  Rumor has it 0.2 will
    have such things.  If someone wanted to add it, the vnops_* files
    would have to be radically modified to get it to work correctly.


2.5.2.2    Increasing the 386bsd partition size.

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


2.5.2.3    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
          1    6    0    69 DOSbi # ..
          2    165  70    98 unkno
        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.5.3    How do I set up the system so that I can boot from more than one
    operating system/file-loader without using floppies?

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

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

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

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

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

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

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

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

    After you have the necessary tools handy:

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

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

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

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

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

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


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

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

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

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

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

    It worked perfectly for me.

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

    Julian Elischer ([e-mail]) adds:

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

loadstart:

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


    and change it to:


loadstart:

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

    And in yet another interation, Luke Mewburn ([e-mail])
    decided to hack that a bit further in his NetBSD 0.9 (as_shipped i.e.,
    non-current) to set the drive to the unit which the boot blocks
    loaded off.

    So, instead of:
        part = unit = 0;
    do:
        part = 0;
        unit = (drive & 0x7F);

    (the FAQ suggests `part = 0; unit = 1;' )

        This way, whatever drive the bb's 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 centre the last day getting dos to boot on one drive
    and netbsd on another).


2.5.4    How do I disklabel my second hard drive?

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

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

    Mark Weaver ([e-mail]) provides us with an illuminating
    answer to this perplexing problem.

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

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

    For instance, the following line works for me:

      disklabel -w -r sd0 <drive-type>

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

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

    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:

        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.

    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.5.5    386bsd/NetBSD/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 ([e-mail]):

    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.5.6    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 ([e-mail]) 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 execpt 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.5.7    What are the options for the bootup prompt?

    The options are supposed to be as follows:

    -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)
              (not sure if this is presently working)


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

    127.0.0.1        localhost    localhost.my.domain

    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:

        ifconfig lo0 localhost
        route add {hostname} localhost

    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:

        hosts
        bind

    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.6    Common installation problems.

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

2.6.1    Swap space not identified correctly.

    There are several levels of problems associated with swap space.
    The first is that the swap space on a second disk will not get
    used if it is not in your /etc/fstab file.  Your /etc/fstab should
    have the swap space identified.  The following is a representative
    fstab:

    /dev/wd0a        /        ufs  rw 1 1
    /dev/wd1b        swap        swap sw 0 0

    Another common question is that the install program installs the
    swap partition in the 'b' partition, but does not mark it correctly
    as a swap partition.  The swapping software will use the swap
    partition regardless of what it is called, but it should still be
    identified in the disklabel as the swap partition.  Use 'disklabel'
    to change the partition type from 'unused' to 'swap'.

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


2.6.2    Endless reboot cycles.

    Endless reboot cycles are the single most vexing aspect of 386bsd.
    Part of the problem is that the 0.1 distribution boot routines
    were never checked against many types of computers and have bugs.
    Most of the bugs are fixed in the patchkit, but that doesn't do
    the average novice user any good.

    In general, this will show up as a "bad disk label" error, and
    can result in in not booting from the hard drive "most of the time".
    You may be able to partially (or even completely) work around this
    problem by making your machine run at a lower clock rate.

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

    The correct solution is to use a patched "dist.fs" or "fixit.fs"
    boot disk.  Since these are no longer available, using an
    unpatched 386BSD 0.1 is a not a possibility any longer if you
    have this problem.  You will have to upgrade to either FreeBSD
    or NetBSD.

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

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


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

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

    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.7.1    The boot disk works all right on one computer but not another.

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

    - Misconfigured hardware.  The iomem, IRQ, and other board
    settings must match the ones listed in the INSTALL.NOTES.
    Unfortunately, the INSTALL.NOTES are on the disk that will
    not boot.  You can grab them via FTP from 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.  The Ultrastore 24F
    (when not running in ISA emulation mode) is a good example of this.
    There are also some network cards that are not directly supported
    in 386bsd.  If you get into a real bind, you can post a question
    to comp.os.386bsd.questions, and one of the many experienced 386bsd
    gurus that reads that group will probably try to help you.

    - 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.7.2    Really strange errors in the various *BSD flavors.

2.7.2.1    I am using the original 386bsd 0.1 with no patches installed
    and I get flashing multicolored characters and  a "ptdi 81061"
    prompt error?

    Since 386BSD 0.1 is no longer available, you will have to
    upgrade to either FreeBSD or NetBSD, which both deal with this
    problem directly.


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


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

    The description of this problem is that one of the cards in your
    system (most likely the VGA card) is either generating interrupts
    or is causing the IRQ 2 to be actively disabled.  Older VGA card
    uses 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 ([e-mail]) 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-bipartite driver, you would
    want to catch the retrace interrupt to get rid of "sparklies" or to
    implement a driver for a very high resolution monitor for X.  If
    this happens, given a choice between alcohol and solder, I vote for
    alcohol.

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

    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:

        Internal    External    Function
        IRQ0        n/a        Refresh/Timer
        IRQ1        n/a        Keyboard
        IRQ2        n/a        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

        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.
    There are very few drivers for *BSD that support an
    interruptless mode that it almost doesn't pay to even include
    this.


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

    That is because the original 386bsd 0.1 SCSI drivers didn't
    recognize any devices past the first two (ID 0 and ID 1).  Also,
    there was a bug in the distribution floppy regarding the devices
    at ID 6.  The 'dev' files in 386bsd 0.1 for that id need to be
    remade.  Use MAKEDEV to do that.

    The disks and tapes will be recognized and configured when they
    are first accessed.

    A new and improved SCSI driver has been written by Julian Elischer
    and is available from many sources.  It includes support for many
    new types of SCSI controllers and many devices that are thereby
    attached.  This driver is included in the patchkit.

    In addition, many of these types of devices are supported in
    FreeBSD and NetBSD.  If one of the devices you are interested
    in using is not supported in 386BSD, you might try one of these
    newer systems.

    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.

    Who says computers are logical?


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

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


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

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

    NetBSD-0.9, and presumably FreeBSD, contain a repaired printf()
    function, which corrects this problem.  The easiest solution for
    this (and MANY other) problems is to upgrade.  In addition, these
    systems also include gcc-2.3.3 (or newer) as the default compiler.

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

          touch protoize.o
          touch unprotoize.o

    after the line:

          touch stamp-proto

    After this "make bootstrap" will run to completion.

    gas apparently has bugs too.  It should produce +Infinity.  I
    think it is OK internally but it may be trusting the library
    too much.  gcc can easily be changed to avoid printf for output,
    but input is harder.

     One of the problems is that various pieces of code rely on the
     value of DBL_MAX.  A kludge to fix it is to change the line
     below:

    #define DBL_MAX         1.7976931348623157E+308

    One value that works is

     #define DBL_MAX         1.7976931348623147E+308
                                            ^ was 5

    This is a kludge, but it does mostly work.


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

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

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

    atof("1.7976931348623157e+308") returns

         0x7fefffffffffffff

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

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


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

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

    Matthias Urlichs ([e-mail]) has provided this
    description of the types of things that can cause problems for the
    controller and devices attached to it.

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

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

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

    So...

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

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

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

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

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

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

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


2.7.9    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 kernal
    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 simlar 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.8    Other common problems that are attributed to the installation
    process but are caused other places.

2.8.1    Why don't the man pages for "magic" and "file" work?

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


2.8.2    Why is apropos broke?

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

    excerpt from the Makefile.

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

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

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


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

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

    As people started using VESA and EISA busses, however, attempts
    were made to push the envelope even further.  Memory limits have
    expanded seemingly without limit.  Since the EISA bus (for example)
    has 32 address lines, it is capable of supporting more memory than
    the ISA bus with its 24 address lines.  While the 386 and 486 are
    capable of addresses up to 4 Gigabytes (considerably more than the
    ISA bus allows) the ISA bus is still the primary limitation.

    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:

        hostname /netbsd: sd0: not queued
        hostname /netbsd: aha0: DMA beyond end of ISA
        hostname /netbsd: sd0: not queuedaha0: DMA beyond end of ISA

    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 ([e-mail]) has provided this
    explanation of the distinction:

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

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

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

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

    The only way to get full EISA, 32MB-of-memory-and-everything, mode
    is to use an EISA controller in full EISA mode (for Adaptec 1742,
    this is "enhanced" mode, for DTC 3290 it's "DTC" mode, 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.8.4    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 ([e-mail]) 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.


--
TSgt Dave Burgess           | Dave Burgess
NCOIC, USSTRATCOM/J6844     | *BSD FAQ Maintainer
Offutt AFB, NE              | [e-mail]

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

Section 3.    (Kernel Building and Maintenance)

3.0    System Internals

    One of the interesting aspects of *BSD is the fact that it comes
    with the complete source.  This allows you to make changes to the
    system, recompile, and test out your new ideas.  This section of
    the FAQ describes many of the different aspects of this endeavor
    and common problems and pitfalls that are encountered.  Kevin Lahey
    provided the substantial portion of this section.  You can contact
    him via E-Mail at ([e-mail]) or contact Dave Burgess
    ([e-mail]).

3.1    Kernel

3.1.1    How do I build a kernel?

    The kernel can be compiled in a variety of ways to support different
    devices and configurations.  Compilation is controlled by a config
    file that specifies the characteristics of the kernel.  A set of
    different config files is located in /sys/i386/conf or
    /sys/arch/i386/conf.  The configuration file names are in upper case.

    To build a particular kernel (in this example, we use the GENERICISA
    configuration file in NetBSD or FreeBSD):

    % cd /sys/i386/conf
    % config GENERICISA
    % cd /sys/compile/GENERICISA
    % make depend
    % make

    If you are using 386bsd 0.1, you'll need patch 1 from the patchkit
    to get the compilation to work, because the version file isn't
    correctly included in the Makefile.

    In NetBSD, since there are multiple architectures supported, there
    is an architecture line in the middle of the path to these files.
    See the build.kernel script in section 3.8 for more information.


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.

    You're going to have to recompile the kernel after you modify the
    config file.  See section 3.2 below for more information about the
    config file in general.


3.1.3    I don't have the source distribution -- how can I rebuild the
    kernel?

    There are reference sites available, as well as the 'good
    net-neighbor' policy, whereby you could make arrangements
    with a net neighbor to use a large local machine as a Network
    File System (NFS), or allow you to compile a new kernel on
    their machine and transfer it to yours.  You can also ask for
    help from comp.os.386bsd.questions if you get stuck and cannot
    make any headway.


3.1.4    Now that I have a kernel, how do I install it?

    Your kernel is called /386bsd or /netbsd.  Copy the new kernel
    from /sys/compile/GENERICISA/386bsd to /, assuming that it is
    in that directory.  This is relatively straightforward; there
    are a couple of things to remember, though.  First, if you
    really screw up the new kernel, you want to have something to
    fall back on, so be sure to save /386bsd to /386bsd.old before
    copying in a new kernel.  Second, if you just copy the new
    kernel over the currently running kernel, funny things can
    happen.  Be sure to move aside the currently running kernel
    before copying over the new one.

    There are folks that have reported that overwriting their
    current kernel has never caused them any real problems.  On the
    other hand, if the old kernel was working and the new one
    doesn't, and you have made changes that require that old
    kernel, it should be available to the system, and saving it
    to /386bsd.alt or /386bsd.old are reasonable things to do.

    If you are really paranoid, you can mount a new fixit floppy
    and replace its kernel with the one you just built, and then
    boot from the fixit floppy to make sure everything will work.
    This is a pretty good idea if you are making radical changes or
    if you are unsure about your changes.


3.1.5    After installing the patchkit and recompiling the kernel with the
    option "WD8013", I am no longer able to reboot the machine.  A
    cold boot (power on) runs fine, but after a reboot no boot drive
    is found by the BIOS.  Besides having a 16-bit WD/SMC Ethernet
    card installed the machines try to boot using either a Adaptec
    1742 or 1542 SCSI board to boot from.

    This answer was provided by Hellmuth Michaelis ([e-mail])
    and by Rodney Grimes (rgrimes@acacia).

    Remove "option WD8013" from the config files and recompile and
    reinstall the kernel.

    The reason that option WD8013 often causes this reboot problem is
    this:

    There is a requirement that all memory within a 128k bank in the
    0xA0000 to 0xFFFFF region be either 16-bit or 8-bit.  On a cold
    boot, the WD8013 boards are reset to 8-bit mode, the POST
    (Power On Self Test) passes without error.  386bsd comes up, the
    if_we.c driver places the WD8013 in 16-bit mode.  Now on a soft boot
    when the BIOS runs some quick POST tests it finds a problem in the
    0xA000 to 0xF000 region.  You probably get a "beep-beep" when this
    happens.  It means you have a memory size conflict.
    The machine has been mis-configured.

    This is a little known fact about 16-bit vs 8-bit option cards.
    It has caused more than one person to go crazy tracking down
    what they swear is a bug in the program.  It is not, it is a
    flaw in the design of the ISA bus.  The signal MEMCS16- must be
    returned the same for every 128k block of memory:

         A0000-BFFFF    Must all be either 8-bit or 16-bit.
         B0000-CFFFF    Must all be either 8-bit or 16-bit.
         D0000-FFFFF    Must all be either 8-bit or 16-bit.

    In your particular configuration (WD8013 @ cc000) I suspect that
    you have another board in the B0000-CFFFFF region that is 8-bit,
    i.e.  your Adaptec has an 8-bit BIOS on it!

    Try moving the board to the 0xD0000 region and see if it works
    there, you may still have a problem as many modern system BIOSes
    are now 8-bit.  If your system BIOS is 8-bit, try shadowing the
    system BIOS region at 0xF0000 to 0xFFFFF, this effectively turns
    it into a 16-bit BIOS.

    Do not attempt to shadow the WD8013, it will cause you many
    headaches.  In fact, it sometimes helps to turn on BIOS shadowing.
    Some BIOSes allow to copy ROM contents to unused RAM pages for
    selected 16KB-regions. While it is generally a good idea to turn
    BIOS shadowing off, I have also observed that sometimes it helps to
    turn shadowing of true ROM regions on.


3.1.6    My system is complaining about stray interrupt 7.  Is my machine
    going to explode or anything?

    No.  They are caused by lots of things.  They are, as far as
    anyone that should be expected to know about this stuff, harmless.
    There are ramifications on them being there, but for MOST users
    they do not pose a real threat to your operations.  For those of
    you that are doing REALLY interrupt intensive stuff, you may want
    to grab a technical reference and figure out why the 8259 is not
    getting reset correctly.

    In spite of the number of times this has come up (and people have
    even referenced this section) there are still at least two
    questions on the net about this.  A memorable one was a guy who
    was just vehement that the stray int 7 was what was keeping his
    system from booting.  In fact, he went so far as to say that this
    document was practically worthless because I didn't tell him how
    to fix it.  Of course, once he configured his hard drive controller
    so that it was on the right interrupt, his booting problem went
    away.  I have said it before and I will say it again.  For MOST
    users they do not pose a real threat to your operations.
    I have heard of three people (out of at least 2000) that have
    actually have problems so bad that they couldn't proceed.  They
    bought new computers, and the problem went away.

    These stray interrupts are caused by something in the PC.
    I have yet to see a convincing explanation of precisely what,
    but they are definitely caused by something.  There are four
    ways to deal with this problem.

    1)  Ignore them.  They are spurious and do not effect the
    operation of your computer.

    2)  Implement the lpt driver.  This way, the driver traps
    (the lpt driver expects IRQ 7) and then quietly discards them.
    That is why when folks implement the lpt driver the 'problem'
    goes away.  The computer is taught how to ignore them.

    3)  Do what the original 386bsd code did.  Comment out the
    diagnostic and associated code that tries to deal with them so
    you don't see the error message.

    4)  Buy a new computer that doesn't cause this problem.   It is a
    known hardware problem with the 8259 being reset incorrectly in
    hardware.

    Kalevi Suominen ([e-mail]) offers this technical
    explanation of the 'stray interrupt 7' phenomenom.

    In the section of the Intel Peripheral Handbook dealing with
    the 8259A there is a description of the 6-step interrupt
    sequence for an 80x86 system (and 7-step for an MCS-80/85),
    and then the following paragraph:

    "If no interrupt request is present at step 4 of either sequence
    (i.e., the request was too short in duration) the 8259A will
    issue an interrupt level 7. Both the vectoring bytes and the CAS
    lines will look like an interrupt level 7 was requested."

    This explains how some transient disturbances or improperly
    functioning adapter cards could trigger a stray interrupt 7
    in a system operating in the *level* interrupt mode (such as
    a PS/2 with MCA): An interrupt request will disappear as soon
    as the interrupt line goes inactive.

    That such interrupts may also occur in a system operating in
    the *edge* triggered mode (such as an ordinary PC/AT with ISA)
    is a little harder to see. Yet it is possible - even without
    malfunctioning hardware - because masking an interrupt request
    will hide its presence from the 8259A as well:


        1. The interrupt flag (IF) of the 80x86 is reset either
        directly (e.g., by a "cli" instruction) or because an
        interrupt handler is entered. In the latter case the
        corresponding in-service (IS) bit of the 8259A is set
        (effectively blocking interrupts of lower priority).

        2. The 8259A receives an unmasked interrupt request (IRQn),
        and, in case an interrupt is being served and has higher
        priority than IRQn, the IS bit of the 8259A is reset by
        an end of interrupt (EOI) command. (These steps may occur
        in either order.) If IRQn has higher priority (e.g. IRQ0),
        no EOI is necessary.

        3. The 8259A activates the interrupt (INT) line to the 80x86
           (which will ignore it - for the moment).

        4. The interrupt mask (IM) bit of the 8259A for IRQn is set.
        (A little late, though. The sequence has already started.)

        5. The interrupt flag (IF) of the 80x86 is set (either
        directly, or as a consequence of e.g. an "iret" instruction).

        6. The 80x86 will now acknowledge the INT request by activating
           the INTA line of the 8259A.

        7. The 8259A will not see the masked IRQn and will continue
           by issuing a spurious interrupt of level 7 instead.


    The original interrupt request (IRQn) will not be lost, however.
    It is preserved by the associated edge sense latch of the 8259A,
    and will be acted on after the IM bit has been reset again.

    The net result is that a single interrupt request will be
    delivered *twice* to the 80x86: first as a stray interrupt 7
    and later as the proper interrupt. In particular, it is perfectly
    safe to ignore the stray interrupt (other than sending an EOI).
    It is just the ghost of an aborted interrupt sequence: the system
    was not prepared for it yet.


3.1.7    I keep getting "wd0c: extra interrupt".  What does it mean?

    It means that the drive was already processing a command
    (active) when it recieved an interrupt from the system telling
    it to see if it had anything to do.  This is mostly harmless
    but could indicate that the drive/controller is having problems
    if the message appears often.


3.1.8    I found a bug in the kernel.  How do I report it?

    Both NetBSD and FreeBSD include a facility called 'bugfiler'.
    While the instructions are included in both system, there is
    still some apparent confusion about when to use (and when to
    NOT use) bugfiler.

    Jordan K. Hubbard ([e-mail])  provides us with this
    short article for FreeBSD.

    To send bug reports, you want to use the sendbug(1) command.
    The entire package for sending and filing these bugs is known
    as "the bugfiler", which is where the confusion stepped in,
    but sendbug is definately the command you want to use.

    Second, it doesn't take a "net connection" to use sendbug,
    since all it does is package up your "bug report form" and mail
    it to us; no direct internet connectivity is required, just mail.

    So if you can send internet mail you can use sendbug, or you can
    also send mail to the `[e-mail]' address
    (do NOT send it to FreeBSD.cdrom.com since it will BOUNCE, this
    is not the place to send bugs to, just to ftp stuff from!).

    NetBSD has a similar facility, but has a different program and
    host for bug reports.  The program for NetBSD is called send-pr
    and is slightly different in several respects.  It is
    recommended that NetBSD users see the man page on send-pr
    before filing bug reports.


3.1.9    Can someone please give a reasonably clear set of instructions
    as to how to get a "current" version of NetBSD running?

    Marc Wandschneider <[e-mail]> provided this
    description of what he did to upgrade to the (then) current
    version of NetBSD:

    1. Delete the old source tree, saving what I wanted to (a bunch
    of files moved around, and just unpacking the new one over the
    old will cause some problems)

    2. Unpacked the new source tree.

    3. ran the following sequence of commands:

        cd /usr/src/share/mk; make install
        cd /usr/src/include; make && make install
           setenv LDSTATIC -static
           setenv NOPIC
        cd /usr/src/lib/libc; make && make install
        cd /usr/src/gnu/lib/libmalloc; make && make install
           cd /usr/src/gnu/usr.bin/gas; make && make install
           cd /usr/src/gnu/usr.bin/ld; make && make install
        # You'll probably get some barfage from the above because
        # ld.so won't build yet.  Ignore it and install ld anyway.
           cd /usr/src/gnu/usr.bin/gcc; make && make install
           unsetenv NOPIC LDSTATIC
           cd /usr/src/lib ; make && make install
           cd /usr/src/gnu/lib ; make && make install
        cd /usr/src/gnu/usr.bin/ld; make && make install
           cd /usr/src; make && make install

    At some point during the installation, your system will be
    fixed enough that many of these steps will no longer be required.
    For example, the new 'make' defines the variables OBJDIR and
    MACHINE_ARCH for you, so you will not need those  once you get to
    that point.  Until then, the following procedure may suit your
    needs better.

        #! /bin/csh

        unsetenv NOPIC LDSTATIC
        setenv MACHINE_ARCH i386
        # Pick one of these three setenv lines.
        #  setenv MAKE "make clean "
        #  setenv MAKE "make obj "
            setenv MAKE
        cd /usr/src/share/mk
           make install
        cd /usr/src/include
           $MAKE
           make && make install
        setenv LDSTATIC -static
        setenv NOPIC
        cd /usr/src/usr.bin/make
           $MAKE
           make && make install

        cd /usr/src/usr.bin/rpcgen
           $MAKE
           make && make install

        cd /usr/src/lib/libc
           $MAKE
           make && make install

        cd /usr/src/gnu/lib/libmalloc
           $MAKE
           make && make install

        cd /usr/src/gnu/usr.bin/gas
           $MAKE
           make && make install

        cd /usr/src/gnu/usr.bin/ld
           $MAKE
           make && make install

        cd /usr/src/gnu/usr.bin/gcc2
           $MAKE
           make && make install

        #
        unsetenv NOPIC LDSTATIC

        cd /usr/src/lib
           $MAKE
           make && make install

        cd /usr/src/gnu/lib
           $MAKE
           make && make install

        cd /usr/src/gnu/usr.bin/ld
           $MAKE
           make && make install

        cd /usr/src
           make && make install


    NOTE: At some point, you might very well come across an
    unresolved external __DYNAMIC in crt0.o.  If this happens, edit
    the makefile for crt0.o (lib/csu/i386) and remove the -DDYNAMIC
    flag) make && make install.  Then put the flag back in the
    makefile (but don't rebuild it until the natural order of things
    dicates that it happen)

    And Theo Deraadt provides this guidance when you get an error
    like "init_main.o: Undefined symbol _pdevinit referenced from
    text segment."

    You need to
        (1) install new config
        (2) make clean
        (3) re-config your kernel
    then this goes away


3.2    What exactly is this config file, anyway?  What are all of these
    cryptic notations?

    I've annotated the distributed 386bsd GENERICISA file;  my comments
    are delineated by the '--' symbols.

    THIS IS NOT A COOK-BOOK.  YOU WILL NEED TO DO THE RESEARCH (LIKE
    LOOKING AT THE 20 OTHER CONFIG FILES) TO SEE WHAT IS CURRENT AND
    WHAT YOU WILL NEED IN YOUR CONFIG FILE.

    #
    # GENERICISA -- Generic ISA machine -- distribution floppy
    #
--  BSD can be compiled for different hardware platforms, so it is important to
--  define the hardware types.  386bsd can only be built for 386 or
--  compatible machines, so this is sort of superfluous, but maintains
--  compatibility with standard BSD config files.
    machine        "i386"
    cpu        "i386"
--  The ident describes the machine for which this kernel is to be built.
--  It is usually the system name -- "ROKKAKU", "REF", or whatever.
--  This can be used for conditional compilation, so that kernel changes
--  can be compiled in only for one machine.
    ident        GENERICISA
--  This should indicate the timezone of the system relative the
--  Greenwich.   8 is PST;  4 is EST.  A fuller explanation is provided
--  below.
    timezone    8 dst 7
--  maxusers isn't strictly checked;  it is just used to size several
--  system data parameters.
    maxusers    10
--  The options control the conditional compilation of features into the
--  kernel.  The options can be listed all on a line separated by commas.
--  They are #define'ed when the kernel is compiled, so that #ifdef's
--  will work.  An option can be given a value by appending an equals sign
--  and a value (enclosed in double quotes) to the option name.

--  Hopefully the names are at least somewhat self-explanatory.  To
--  discover what everything does, you'd have to go through the kernel
--  looking for all of the appropriate #ifdef's.

--  [Perhaps somebody else could list the *exact* meanings of these
--  options and some of the other possible options?]
    options        INET,ISOFS,NFS
    options        "COMPAT_43"
    options        "TCP_COMPAT_42"

--  The config line controls the location of the root, swap, and dump
--  devices.  Anything not specified is defaulted.  This is where you add
--  support for multiple swap devices.  Just list 'em, separated by 'and'.
--  The config line below identifies the root drive as wd0 and the
--  swap drives as wd0 and as0.  See the section on swap devices in FAQ_02
--  for additional information.
    config        "386bsd"    root on wd0 swap on wd0 and as0
--  A 'controller' is a device or bus controller.  'isa' is obviously for
--  the ISA bus.  'wd0' is for regular disk controllers,  'fd0' is for the
--  floppies, and 'as0' is for SCSI disk controllers.
    controller    isa0
--  The fields work as follows:

--  a.  What do you call this device?
--  b.  What controller is this on?  As you can see, the disk controller
--  talks to the ISA bus, and the disks talk to the disk controller.
--  c.  Where are the registers for the controller mapped into memory?
--  This is #defined in /sys/i386/isa/isa.h.
--  d.  What IRQ is this device set up for?
--  e.  What routine should be called on an interrupt from the device?

--             a          b           c             d           e
--            vvv        vvv       vvvvvvv          vv        vvvvvv
    controller    wd0    at isa? port "IO_WD1" bio irq 14 vector wdintr
--  You need a 'disk' entry for every disk on the controller.  In the
--  config file originally shipped with 386bsd, both hard disks were
--  incorrectly identified as wd0.  Be sure to change the second occurrence
--  to wd1, as I have done in below.
    disk        wd0    at wd0 drive 0
    disk        wd1    at wd0 drive 1

    controller    fd0    at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
    disk        fd0    at fd0 drive 0
    disk        fd1    at fd0 drive 1

--  The 'drq' specifies the channel used for bus-mastering DMA.
    controller    as0    at isa? port 0x330 bio irq 11 drq 5 vector asintr
    disk        as0    at as0 drive 0
    disk        as1    at as0 drive 1

--  Define other physical devices.  pc0 is the keyboard, npx0 drives the
--  math coprocessor, and com* controls the com ports.
    device        pc0    at isa? port "IO_KBD" tty irq 1 vector pcrint
    device        npx0    at isa? port "IO_NPX" irq 13 vector npxintr
    device        com1    at isa? port "IO_COM1" tty irq 4 vector comintr
    device        com2    at isa? port "IO_COM2" tty irq 3 vector comintr

--  Ethernet drivers of various sorts and the particular configuration
--  information they require.  For most installations, only one of these
--  devices would normally be defined.
    device we0 at isa? port 0x280 net irq 2 iomem 0xd0000 iosiz 8192 vector weintr
    device ne0 at isa? port 0x300 net irq 2 vector neintr
    device ec0 at isa? port 0x250 net irq 2 iomem 0xd8000 iosiz 8192 vector ecintr
    device is0 at isa? port 0x280 net irq 10 drq 7 vector isintr

--  Tape driver
    device        wt0    at isa? port 0x300 bio irq 5 drq 1 vector wtintr

--  The TCP/IP loop-back device, ethernet interface, slip interface, log
--  device, and pseudo-terminals.
    pseudo-device    loop
    pseudo-device    ether
    pseudo-device    sl    2
    pseudo-device    log
    pseudo-device    pty    4

--  Devices required by VM.
    pseudo-device    swappager
    pseudo-device    vnodepager
    pseudo-device    devpager

    Normally, there is an annotated configuration file called ALL which
    gives a list of all of the options for the configuration file.

    The configuration file that was used to create the list above
    was for a 386BSD system.  Many things have changed in the
    config files for NetBSD and FreeBSD.  As an example, the
    psuedo-devices swappager, vnodepager, and devpager are now full
    fledged devices.  Like it said up at the top, use the config
    files that come with your system as a basis for your own
    experiments in kernel building.

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?

    Because it takes up space.  The kernel is wired into memory, so
    every byte it uses comes out of the pool of memory for everything
    else.  It can't page out sections that aren't in use.  If your
    kernel is larger than 640K, then it can't be loaded.  You'll need
    to use Julian Elischer's bootblocks to put it in high memory, which
    seem to be fairly complex.  Installing them (once they are
    compiled) is as easy as using disklabel.

    Newer versions of the *BSD kith provide the capability to build
    a kernel that is larger than 640K.  Complete instructions are
    provided in the appropriate systems.


3.2.2    What should I remove from the kernel?

    What do you need?  If you only have an SCSI controller, you don't
    need the wd0 device;  if you have another kind of disk controller,
    you don't need as0.  Unless you actually HAVE more than one Ethernet
    controller, you should comment out all but one of them.  If you don't
    have an ethernet controller, you don't need any of the controllers or
    NFS compiled in.   Without a CD-ROM, ISOFS is kind of pointless.  Just
    look at what you have and think about what you really need.


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?

    Increase the count of pseudo-terminals --

    pseudo-device    pty    12  # or whatever

    Every pseudo terminal should have a /dev/pty* entry.  If you have 12
    pseudo terminals, you should also have at least 12 pty devices in the
    /dev directory.  The MAKEDEV script in /dev will create as many pseudo-
    terminals as you tell it to.


3.2.4    How do I get ddb, the kernel debugger, compiled into the kernel
    and running?

    If you are using older versions of the 386BSD family, you will
    need to add a line in your config file that looks like this:

    device-pseudo    ddb

    If you are using a more recent version (the division is pretty
    unclear about when the switch was made) and do not have any
    device-pseudo entries, you will need to add the line:

    options     DDB

    to your config file.

    Build the kernel, then run dbsym on it:

    % dbsym ./386bsd

    Install it and go for it.  Ctl-Alt-Esc drops you into the debugger.

    Note: DDB as shipped originally is a memory hog, and it is very
    difficult to get a kernel small enough with enough fun things in it
    to debug in 640K

    On the NetBSD-sparc system, the L1-A is used by the the DDB
    routines to drop you into the debugger.


3.2.5    Can I patch the current running OS image?

    In general, I think, the answer is no.  The prevailing philosophy
    seems to be that one should use sysctl for such things, but that
    requires that one has already compiled in the ability to change
    the specific variable in question.  (I discovered this when I
    wanted to patch tickadj at runtime; I added it to kernfs, and
    when I offered the patches (which are quite small) I was told
    sysctl was the `correct' way.  What's incorrect about /kern was
    never quite explained; the closest anyone came was to invoke
    internationalization concerns.  Of course, using /kern also
    requires having compiled in support for tweaking the variable
    you want to change.)

    Besides, unless you've patched securelevel, I don't think there
    is any good way to twiddle variables in the running kernel.
    /dev/{,k}mem are, I believe, read-only once init sets securelevel
    to 1.
                Der Mouse
                ([e-mail])


3.2.6    Can I have more than one config file?  Should I rename it to something
    else?  Any other hints?

    You can create as many (or as few) config files as you desire.  The
    system, once the patchkit is applied, will have between 10 and 15,
    each of which implements certain functions or features.  In addition,
    the normal place for the patchkit to make changes to the config files
    is in the GENERICISA file.  Since this file should remain unchanged
    and available, it is always a good idea to copy this file to a
    meaningful name and modify that file.  In other words, change every
    reference in 3.1.1 from GENERICISA to HAL (or whatever you call your
    system).

    One final note.  Every /sys/compile directory takes up 800K or so;
    you might want to watch to see how big these all get.



3.2.7    What is the meaning of the trap codes I get in panic messages?
    Sometimes this message appears in the form "trap type nn".

    That message means that the system received an unexpected (and
    unwanted) trap that probably indicates some form of kernel bug.
    These traps, are usually received from the kernel, in which case
    the trap.h definitions should be used.

    The number (which appears in place of "nn" above) is *NOT* the
    i386 or i386 trap type, it is a BSD-defined trap type number.

    The definitions of the various trap types can be found in
    /usr/include/machine/trap.h.

    two of the more common ones are:
          9    T_PROTFLT    protection fault
                (The kernel tried executing code
                which was not noted as "executable".
                This happens if the kernel jumps to
                a bogus location.)
         12    T_PAGEFLT    page fault
                (The kernel tried to access a bogus
                area of memory.  This can happen if
                an invalid pointer is dereferenced.)


    This is a list of i386 trap codes (just to confuse the issue).

Trap    0    Divide Error
        The DIV or IDIV instruction is executed with a zero denominator
        or the quotient is too large for the destination operand.


Trap    1    Debug Exceptions
        Used in conjunction with DR6 and DR7, The following flags
        need to be tested to determine what caused the trap:
        BS=1                Single-step trap
        B0=1 AND (GE0=1 or LE0=1)    Breakpoint, DR0, LEN0, R/W0
        B1=1 AND (GE1=1 or LE1=1)    Breakpoint, DR1, LEN1, R/W1
        B2=1 AND (GE2=1 or LE2=1)    Breakpoint, DR2, LEN2, R/W2
        B3=1 AND (GE3=1 or LE3=1)    Breakpoint, DR3, LEN3, R/W3
        BD=1                Debug registers not available,
                        in use by ICE-386
        BT=1                Task Switch


Trap    2    NMI Interrupt
        On PC/AT systems, the NMI input to the CPU is usually
        connected to the main memory parity circuit.  By the time the
        error signal is generated, the data may have already been
        used in an instruction, so it isn't possible to reliably
        recover.

        And some not-so-common causes (from various sources):

          PS50+ : I/O channel check, system watch-dog timer
          time-out interrupt, DMA timer time-out interrupt

          parity errors on any 8-bit or 16-bit board pulling the
          IOCHCK* line low

          first generation of auto-switching EGA cards used NMI to trap port
          access for CGA emulation (e.g., ATI's EGA Wonder)

          Zeos Notebook low battery (perhaps other battery-based
          computers)


Trap    3    Breakpoint
        The result of executing an INT 3 instruction.  MS-DOS and
        Windows and some other non-386 systems use this for debugging.
        Code specific to the 386 and later processors should use
        the debugging features tied to Trap 1.


Trap    4    INT0 Detected Overflow
        Occurs if an INT0 instruction is executed and the overflow
        flag (OF) is currently set.


Trap    5    BOUND Range Exceeded
        Occurs if the BOUND instruction is executed and the array
        index points beyond the area of memory containing the array
        being tested.


Trap    6    Invalid Opcode
        The value read at CS:IP is not a valid opcode.


Trap    7    Coprocessor Not Available
        This occurs if the processor fetches an instruction that is
        for the coprocessor and no coprocessor is present.


Trap    8    Double Exception (Fault)
        An exception occurred while trying to execute the handler
        for a prior exception.  Example, an application causes a
        General Protection Fault (13) and the area of memory where
        the GPF handler should be is flagged not-present (paged-out?).
        The double-fault handler is invoked in these conditions.
        If a fault occurs while trying to run the double-fault handler,
        a triple-fault occurs and the CPU resets.

        The rules for deciding if a double-fault should occur or
        if the two faults can be handled serially are discussed in
        more detail in the Intel song book.


Trap    9    Coprocessor Segment Overrun
        A page or segment violation occurred while transferring
        the middle part of a coprocessor operand to the NPX.


Trap    10    Invalid Task State Segment
        During a task switch, the new TSS was invalid.  Here is
        a table of conditions that Invalidate the TSS:
        TSS id + EXT    The limit in the TSS descriptor is < 103
        LTD id + EXT    Invalid LDT selector or LDT not present
        SS id + EXT    Stack segment selector is outside table limit
        SS id + EXT    Stack segment is not a writable segment
        SS id + EXT    Stack segment DPL does not match new CPL
        SS id + EXT    Stack segment selector RPL <> CPL
        CS id + EXT     Code segment is outside table limit
        CS id + EXT    Code segment selector does not refer to
                    code segment
        CS id + EXT    DPL of non-conforming code segment <> new CPL
        CS id + EXT    CPL of conforming code segment > new CPL
        DS/ES/FS/GS id + EXT    DS, ES, FS or GS segment selector is
                    outside table limits
        DS/ES/FS/FS id + EXT    DS, ES, FS, or GS is not readable
                    segment


Trap    11    Segment Not Present
        Occurs when the "present" bit of a descriptor is zero.
        This can occur while loading any of these segment registers
        CS, DS, ES, FS, or GS.  Loading SS causes a Stack fault.
        Also occurs when attempting to use a gate descriptor that is
        marked "not present", and if attempting to load the LDT with
        an LLDT instruction.  Note that loading the LDT during a
        task switch causes an "invalid TSS" trap.


Trap    12    Stack Fault
        A limit violation relating to an address referenced off
        the SS register.  Includes POP, PUSH, ENTER and LEAVE
        opcodes, as well as references such as MOV AX,[BP+8]
        (which has an implied SS:).
        Also causes by loading SS with a descriptor that is marked
        "not present".


Trap    13    General Protection Fault (GPF)
        Americas Favorite, in the Windows 3.0 world, it is known as
        the UAE error.  The instruction tried to access data out of
        the bounds designated by the descriptors.  The access that
        failed can be a read, write or instruction fetch.  There are
        15 classifications of GPFs:
        1.  Exceeding segment limit when using CS, DE, ES, FS or GS.
        2.  Exceeding segment limit when referencing a descriptor
            table.
        3.  Transferring control to a segment that is not executable.
        4.  Writing into a read-only data segment or into a code
            segment.
        5.  Reading from an execute-only segment.
        6.  Loading the SS register with a read-only descriptor
            (unless the selector comes from the TSS during a task
            switch, in which case a TSS exception occurs.)
        7.  Loading SS, DS, ES, FS or GS with the descriptor of a
            system segment.
        8.  Loading, DS, ES, FS or GS with the descriptor of an
            executable segment that is not also readable.
        9.  Loading SS with the descriptor of an executable segment.
        10. Accessing memory via, DS, ES, FS or GS when the segment
            register contains a null selector.
        11. Switching to a busy task.
        12. Violating privilege rules.
        13. Loading CR0 with a PG=1 and PE=0.
        14. Interrupt or exception via trap or interrupt gate from
            V86 mode to privilege level other than zero.
        15. Exceeding the instruction limit of 15 bytes (this can
            only occur if redundant prefixes are placed before an
            instruction).
        To determine which condition caused the trap, you need
        the instruction, the contents of all associated registers,
        particularly the segment registers involved, then the various
        LDT, GDT and page control tables.  Lots of common coding
        errors cause the GPFs.  Even a stack imbalance will usually
        show up as a GPF.   Even MOV AX,7 MOV ES,AX or
        MOV AX,5 PUSH AX POP DS will get a GPF error.  You can't
        use a segment register for "temporary storage" of any
        old value the way you could on the 8086.  The values loaded
        into the segment registers are checked in protected mode.


Trap    14    Page Fault
        The page directory or page table entry needed for the address
        translation has a zero in the present bit, or the current
        procedure does not have sufficient privilege to access the
        indicated page.

Trap    15    (reserved)


Trap    16    Coprocessor Error
        The coprocessor asserted the ERROR# input pin on the 386
        (internal on the 486)


Trap    17    Alignment Check (486 and later)
        If enabled, this trap will occur if a data fetch does not
        occur on a word boundary.  I don't know of any software that
        activates this feature yet.  I have seen SCO UNIX get this
        error on early Cyrix processors, even though SCO had not
        enabled the feature.


Trap    18-32    (reserved)

[answered by     Frank Durda IV <[e-mail]>    and
        jim mullens [e-mail]  -or- [e-mail]]

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

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?

    If you are using Csh, you can simply unlimit your processes in
    your system level /etc/csh.cshrc file or your personal .cshrc
    file.  You can also modify your kernel so that the
    amount of memory available is less limiting.  J"org Wunsch
    ([e-mail]) provides us with this brief description:

    From a recent posting i just made, regarding the problem how much
    virtual memory one could get.

    | On the other hand, i've also changed the definitions you
    | mentioned. But i didn't like to modify the header files, and
    | actually, modifying the values is as easy as:
    |
    | options        "DFLDSIZ='(16 * 1024 * 1024)'"
    | options        "MAXDSIZ='(64 * 1024 * 1024)'"
    |
    | Include the above lines into your kernel's config file, reconfig
    | and rebuild it.
    |

    This is just a hint for those people poking around with compiling
    large source files. Especially, due to some gcc problems with large
    static arrays, compiling X applications with huge bitmaps would
    cause virtual memory trouble. Increasing the limits (o'course, as
    long as the h/w resources suffice) could help there.

    The default definitions for the above parameters are found in
    /usr/include/machine/vmparam.h.


3.2.9    Where can I learn more about all this?

    We've skipped over a lot of details here;  the straight dope comes from
    "Building Berkeley UNIX Kernels with Config", by Samuel J. Leffler and
    Michael J. Karels.


3.2.10    Does anyone have a system building script that takes things like
    building a new config and multiple config files into account?

    This is the program that I use to rebuild my kernel.  See the note
    in the file about my 'test' program.  You may elect to build a
    new config every time, or not, depending on your requirements.


    #! /bin/sh
    #
    #  Script to rebuild the kernel.
    #
    if [ `whoami` != 'root' ] ; then
      echo 'You must be root to successfully proceed from this point'
      exit 1
    fi

    #
    #  Set up the environment
    #

    if [ X$MACHINE_ARCH = "X" ] ; then
      MACHINE_ARCH=i386
    fi

    if [ -f /netbsd ] ; then
      ARCHDIR='/arch'
    fi

    #
    # Rebuild Config
    #
    # I am using a modified test(1) that allows for file date comparisons.
    # You can either get my patches (if they aren't already included),
    # modify test() yourself, or get the GNU ShellUtils test(1) program.
    #

    if [ /usr/src/usr.sbin/config -ot /usr/sbin/config ] ; then
      echo "Config Up To Date"
    else
     cd /usr/src/usr.sbin/config
     make clean
     make depend
     make
     make install
    fi

    cd /sys
    make
    make install

    #
    # Modify the local Configuration File
    #
    echo `tput clr`
    cd /sys$ARCHDIR/i386/conf

    if [ "X$CONFIG_NAME" = "X" ]; then
      CONFIG_NAME=GENERIC
    fi

    if [ "X$1" = "X" ]; then
      echo "Configuration Files available:"
      ls [A-Z]*
      echo " "
      echo -n "Enter the name of the config file to use: "
      read CONFIG_NAME
      echo
    else
      CONFIG_NAME=$1
    fi

    if [ ! -f $CONFIG_NAME ]; then
      cp GENERIC $CONFIG_NAME
    fi

    echo "Modifying $CONFIG_NAME config file"
    echo -n "Press return to continue (q to quit) "
    read ans

    ans=`echo $ans | cut -c1 | tr 'QqYy' 'qqqq'`

    if [ "X$ans" = "Xq" ] ; then
      exit 0
    fi

    vi $CONFIG_NAME

    #config.new $CONFIG_NAME
    config $CONFIG_NAME

    COMPILE_DIR=/sys$ARCHDIR/i386/compile/$CONFIG_NAME

    cd $COMPILE_DIR
    make depend
    make

    if [ $? -ge 1 ] ; then
      echo "Errors encountered"
    else
      if [ -f netbsd ] ; then
        PROGNAME=netbsd
      else
        if [ -f freebsd ] ; then
          PROGNAME=freebsd
        else
          PROGNAME=386bsd
        fi
      fi
      echo `tput clr`
      echo ""
      echo "  Manual Installation is recommended.  The following files should be"
      echo "copied/linked/moved to the root directory.  The following steps are"
      echo "suggested:"
      echo ""
      echo "    mv /$PROGNAME /$PROGNAME.old"
      echo "    mv $COMPILE_DIR/$PROGNAME /$PROGNAME"
      echo "    reboot"
      echo ""
      echo "Remember that the new kernel changes will not take place until you "
      echo "re-boot the system."
    fi


3.3    X11/XFree86/XS3
3.3.1    What options should I define to get the X extensions included?

    Once you have applied the patch kit, the only thing left to do is to
    modify the config file to include the following line:

    options    XSERVER, UCONSOLE

    recompile the kernel and the kernel should support X.

3.3.2    Where can I get the FAQ for 'X'?

    Steve Kotsopoulos' general 'X on Intel-based Unix' FAQ
    available by anonymous ftp from export.lcs.mit.edu in
    /contrib/Intel-Unix-X-faq.


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

        You need to run xdm with the -nodaemon flag.  The reason is
        xdm normally detaches from the keyboard.  This allows other
        processes (like getty) to return to reading from the keyboard.
        A race condition results, where some keystrokes are sent to
        xdm and others are sent to other processes.  Using the
        -nodaemon flag causes xdm to stay attached to the keyboard
        so no other process can use it.  This answer comes from Michael
        C. Newell ([e-mail])

    This bit of trivia is also covered in detail in the X FAQ and
    the README that accompanies XFree86.


3.4    Compiler and Library routines

    There are several questions that could probably be included
    here.  See also Section 4 for some of the more common 'missing
    modules' that also happen to be library routines.


3.4.1    Which C compiler is shipped with my 386BSD derived system?

    The standard compiler released with 386bsd 0.1 is GCC 1.38.  This
    version is considered by many people to be the most stable of
    the GCC versions.  All other Net/2 derived BSD systems have both
    1.38 and 2.4+ available.  NetBSD 0.9, for example, is completely
    compilable using GCC 2.4.5, which is included as the default
    compiler.  FreeBSD also ships with the same compiler.

3.4.2    Where is libcompat.a?

    The library libcompat.a is (working from memory here) completely
    deprecated in 386bsd.  The only exceptions might be the re_comp
    and re_exec routines, which are discussed in detail in section 4.
    In addition, things will be added to libcompat.a as they are
    deprecated in the newer versions of NetBSD and FreeBSD.  The
    getreuid() and setreuid() stuff may be heading that way (if they
    aren't there already.

    The easiest way around not having a libcompat.a is to simply link
    it to a small library, since virtually every other function that
    is expected in libcompat.a is already include libc.a.


3.5    You promised to talk about timezones below.  Are you going to?

    >I've seen lots of stuff about timezone's being a bit dodgy,
    >especially with most European timezones changing over to DST on
    >the 27th March.  I must say that that was NOT the case for me -
    >pumpy (the author's system) is running off the
    >/usr/share/zoneinfo/GB-Eire timezone file, (symbolically) linked
    >to /etc/localtime, the CMOS clock is running off GMT, and the
    >kernel is compiled with "timezone 0".

    I use /usr/share/zoneinfo/MET as /etc/localtime and have the
    kernel configured as

        timezone        -1 dst 4

    (My wife is running DOS on this machine for doom sometimes ;-)

    I set this strange dst value after diging in some old ultrix(?)
    man pages.  There were several dst-changing-method listed and 4
    was the code for the central europe one.

    This gave me an idea... I use an Ultrix box every day, so why not...

    Now, I don't know how closely this applies to NetBSD since
    Ultrix is based on a much older version of BSD, and this isn't
    for the kernel config, but for an envar of timezone values, but
    it's at least somewhat enlightening on possible meanings for
    these things.  Could someone in the know shed light on how
    accurately this models the timezone stuff in the kernel config?
    When I did "man timezone" this is what I got (portion of this
    quoted from the DEC MIPS Ultrix 4.3a timezone(3) manpage,
    slightly hacked by me (Michael L. VanLoon ([e-mail]))


         STD offset [DST [offset][,start[/time],end[/time]]]

         the components of the string have the following meaning:

    STD and DST    Three or more characters that are the
            designation for the standard (STD) or
            summer (DST) time zone. Only STD is required;
            if DST is missing, then summer time does not apply
            in this locale. Upper- and lowercase letters are
            explicitly allowed.  Any characters except a
            leading colon (:), digits, comma (,), minus (-),
            plus (+), and ASCII NUL are allowed.

         offset        Indicates the value to be added to the local
            time to arrive at Coordinated Universal Time. The
            offset has the form:

            hh[:mm[:ss]]

            The minutes (mm) and seconds (ss) are optional.
            The hour (hh) is required and may be a single
            digit.    The offset following STD is required. If
            no offset follows DST, summer time is assumed to
            be one hour ahead of standard time.  One or more
            digits may be used; the value is always
            interpreted as a decimal number.  The hour must
            be between 0 and 24, and the minutes (and
            seconds) - if present - between zero and 59. If
            preceded by a "-", the time zone is east of the
            Prime Meridian; otherwise it is west (which may
            be indicated by an optional preceding "+").

     start and end    Indicates when to change to and back from summer
                 time. Start describes the date when the change
            from standard to summer time occurs and end
            describes the date when the change back
            happens.  The format of start and end must be
            one of the following:

            Jn    The Julian day n (1 < n < 365). Leap
                days are not counted.  That is, in all
                years, including leap years, February
                28 is day 59 and March 1 is day 60.  It
                is impossible to explicitly refer to
                the occasional February 29.

            n    The zero-based Julian day (0 < n <
                365).  Leap days are counted, and it is
                possible to refer to February 29.

            Mm.n.d    The nth d day of month m (1 < n < 5,
                0 < d < 6, 1 < m < 12).  When n is 5 it
                refers to the last d day of month m.
                Day 0 is Sunday.

                 time    The time field describes the time when,
                in current time, the change to or from
                summer time occurs. Time has the same
                format as offset except that no leading
                sign (a minus (-) or a plus (+) sign)
                is allowed. The default, if time is not
                given, is 02:00:00.

    As an example of the previous format, if the TZ environment
    variable had the value EST5EDT4,M4.1.0,M10.5.0 it would    describe
    the rule, which went into effect in 1987, for the Eastern time
    zone in the USA.  Specifically, EST would be the designation for
    standard time, which is 5 hours behind GMT.  EDT would be the
    designation for DST, which is 4 hours behind GMT.  DST starts
    on the first Sunday in April and ends on the last Sunday in
    October.  In both cases, since the time was not specified, the
    change to and from DST would occur at the default time of 2:00 AM.

    The timezone call remains for compatibility reasons only; it is
    impossible to reliably map timezone's arguments (zone, a
    `minutes west of GMT' value and DST, a `daylight saving time in
    effect' flag) to a time zone abbreviation.


3.5.1    How do you change the timezone on NetBSD (FreeBSD also?)?

    Relink /etc/localtime.  This will correct the difference from
    GMT (or its trendy equivelant) to your local timezone.  In
    addition, the kernel needs to be modified to take the clock
    time in your CMOS into account.  Since most folks that run DOS
    prefer to have their clocks set to local time, the timezone
    hack was introduced to allow the kernel to adjust the CMOS
    clock time to GMT.  Once GMT has been computed, the
    /etc/localtime file can be referenced to determine the
    corrected local time.

    All generic kernels are built using the offset from California
    (why is anyone's guess:-) so just about everyone's clock will
    be off by their timezone offset from Berkeley.

    Also, it may pay to actually copy the correct timezone file
    rather than link it.  That way, you clock will be correct even
    in single users mode (when the /usr partition is not even
    mounted.  The disadvantage of this is that anytime the timezone
    file gets updated, you will need to make certain that the file
    is copied into the /etc directory.


3.5.2    The translation between seconds-since-the-epoch and date
    differs by about 18 seconds between BSD and other Unixes when
    running ntp; why?

    See ntp FAQ. Apparently, the time correction takes leap seconds
    into account twice.  The timezone files in our system take the
    leap seconds into account in the kernel, and nntp takes the
    same 18 leap seconds into account when syncing the time.
    Because of that, the time will appear to be off by eighteen
    seconds.  (Henning Schulzrinne)


3.6    Optional Op-codes for NetBSD, FreeBSD, and other systems.


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

    If you have gotten this far, you deserve some humor.

--
TSgt Dave Burgess           | Dave Burgess
NCOIC, USSTRATCOM/J6844     | *BSD FAQ Maintainer
Offutt AFB, NE              | [e-mail]

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

Section 4.    (System Additions)

  Thanks go to Marc Wandschneider ([e-mail]) for putting this
  section of the FAQ together..

  Important note:  Most of these 'kernel patches' are to the original
  386bsd 0.1.  The really useful ones have been added to the kernel
  of both NetBSD and FreeBSD.

4.0    Introduction

    If you have written some addition to the kernel or some other
    part of the system, or know of one that feel should be mentioned,
    send mail to Dave Burgess ([e-mail]) with all
    the relevant information, and it will be added for the next
    release.

4.1    Common Kernel-related problems

4.1.1    Where are the commands "rpcinfo" and "rpcgen"?

    Chris Flatters ([e-mail]) informs us in the following
    posting excerpt where we can find them:

    --------------------------------------------------------------------
    The sources for the Sun OS 4.0 RPC are on titan.rice.edu (I don't
    have the inet number handy) in directory sun-sources.  You will have
    to pick up all the shell archives and unpack them to get at rpcgen.
    --------------------------------------------------------------------

    These sources are also included in NetBSD and FreeBSD as part of the
    normal installation.

4.1.2    Where can I get a working "netstat"?

    When netstat was released, it came out as a binary patch and
    source patch in the patchkit for 386bsd 0.1.  The program has
    been included in both NetBSD and FreeBSD.


4.1.3    How can I fix NFS to work with my NE2000 board?

    Ken Raeburn ([e-mail]) has both identified the
    problem (in 386bsd 0.1) 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
    anyways) were not a problem.

    After playing with etherfind and kernel printfs, I've come to this
    conclusion: Fragmented 8K UDP packets from the NFS server are not
    reaching the UDP layer in 386bsd.  The Sun is sending them (according
    to another Sun spying on the network), but the UDP input routine is
    never called.  I don't know if the bug here is on the 386bsd or Sun
    side, and won't have time to look into it in the next couple of days.

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

    (It does nothing about TCP being slow, though.)
    Ken
    --------------------------------------------------------------------

    Hopefully, the real solution (a UDP fix) will be forthcoming so
    that the slow TCP problem is fixed as well.

    See also:  Section 2.6.3.3c "I am getting lousy performance
           out of my network card.  What are some of the other
           possibilities?"

    Recent work in FreeBSD and NetBSD may have deprecated this problem.
    There is a new network card driver called the ed0 driver.  This
    replaces the original NE1000/NE2000 drivers, as well as replacing
    the we0 driver.  By combining the two, a more flexible driver has
    been developed and most of these types of problems have been fixed.
    Once again, upgrading to FreeBSD or NetBSD seems to be the answer.


4.1.4    How can I get "ps" and "w" to work?

    The patch-kit contains a fix for /src/lib/libutil/kvm.c, which,
    last we heard, was due to the work of Jim Paradis
    ([e-mail]).  New versions of the kernel should
    have this problem fixed.

    In order for users to be able to use certain flags with ps and
    the w/uptime commands, the kernel must have permissions 755.

    Also, in order to save space on the distribution, the 386bsd 0.1
    kernel is 'stripped' of all its labels.  Programs that rely on
    those labels will not work.  There are several in this category,
    including ps, w, and uptime.  Either ftp an un-stripped kernel,
    or recompile.

    Also, when the internal structure of the kernel changes (as
    with the changes to NetBSD and FreeBSD that change fundamental
    parts of the kernel) a new ps, w, and uptime must usually be
    recompiled.  If you are having trouble with your ps and have
    recently upgraded/rebuilt your kernel, you will probably have
    to rebuild ps etal.


4.1.5    Where are re_comp and re_exec?

    These two functions are currently not in libc.a.  However, there
    are two related functions that seem to work exactly the same in
    all cases we've heard of---These are regcomp() and regexec().

    Thus, a pretty ugly fix for the problem would be to always compile
    as follows:

    $(CC) -Dre_comp=regcomp -Dre_exec=regexec ....

    There is a slightly nicer fix available for this, listed in 4.2

4.1.6    What about the termio, termios, and termcap stuff?

4.1.6.1    Where are stty() and gtty()?

    These functions were missing from libc.a in the original 386bsd 0.1.
    To fix, add the following #defines to your program:

    #define stty(f, m)    ioctl((f), TIOCSETP, (m))
    #define gtty(f, m)    ioctl((f), TIOCGETP, (m))

    A more elegant solution is to apply the patchkit.  These routines
    are included in there.

4.1.6.2    Sometimes I have trouble with my system resetting the terminal
    to seven bit mode.  Isn't 386BSD eight bit clean?

    The answer is "sort of".  The problem seems to come from the
    fact that the <sgtty.h> interface is not guaranteed to be eight
    bit clean.  The <termios.h> interface is better, and should be
    eight bit clean in all cases.  If you find an application that
    uses the <sgtty.h> interface, you should either contact the
    author and try and get them to use the termios interface or port
    the code yourself.


4.1.7    The system hangs with the HD light on after intense disk usage.
    The system hangs when trying to fsck -p both of my IDE hard drives
    at boot-up.

    Brett Lymn ([e-mail])  Provides us with a
    description of the problem and the steps that he had to take
    to fix it:

        It seems that, on some disk subsystems, the controller and the
    hard disk get out of synchronization when they are being used
    intensively.  The result of this is that the disk completes a
    command but the controller still believes the disk not to have
    completed the command, so the controller status register
    indicates the disk is busy when it is not really.  The standard
    wd drivers are too trusting of the hardware and expect it to do
    the right thing all the time.  There are a few while loops in
    the wd drivers that loop on a status change from the disk
    controller, however; if the problem I have described takes place
    then the wd driver will be stuck looping waiting for the disk to
    not be busy - which never happens, so you lock the machine because
    this is a kernel level wait.  To fix this problem I put a timeout
    into the while loops so that after a specified time the wd driver
    will give up waiting for the drive to become ready, reset the
    controller and retry the command.  In my experience the retry
    always succeeds.

    Ed.Note:  The retry doesn't ALWAYS work, but it IS better than
    just waiting for the drive to wake back up (which it never does).

    It has been recently noted that, from time to time, a SCSI disk
    subsystem will behave exactly the same way.  It is usually because
    of bad/out-of-tolerance cables.  It is not a common problem, but it
    is one that you, the reader, may need to take into account when
    you are trouble-shooting your drives.

    Dan Yergeau ([e-mail]) provides us with more
    insight into this problem.  The README accompanying the original
    sources used as a base for the NetBSD driver indicates that

    > There's also another problem still bothering me: There's some
    sort of timing/reentrancy error still lurking in here, that was
    there in the original 0.1 wd driver as well.  The symptom is that,
    on *some* controllers, doing the initial wdopen() (which will
    then call the readdisklabel() function) for two or more disks at
    the same time (so that wdopen() gets called again while it's
    already being executed), the controller gets hung.  I'm still
    looking for this, meanwhile I specify in my config file that I
    have swap on all disks.  This causes the kernel to wdopen() the
    drives nicely in order -- and once it's been done for each disk,
    the problem will, of course, not occur.  Without the "swap on ...
    and ... and ..." stuff, my wd1, wd2 and wd3 would be opened
    simultaneously by "fsck -p" forks, which would nicely hang up
    everything...  I note a "sleep(10)" in fsck, but it obviously
    doesn't do that.

    So, changing the appropriate config line to

    config        "386bsd"    root on wd0 swap on wd0 and wd1
                                                            ^^^^^^^
    may get around the problem.  I don't run NetBSD, but I do use a
    variation of the barsoom/NetBSD driver.  This works for me.
    Please let the NetBSD people know if it works for you.


#include <std.disclaimer>

    [Ed. again] Other methods for fixing this problem include doing a
    dd if=/dev/wd1d of=/dev/null count=1 before the initial 'fsck -p'.
    This method is considered brute force.  It works by making sure
    that the drive is properly initialized before the disklabel is
    read in the fsck.

    Another method involves using the '-l1' (little L) flag to make sure
    that the fsck doesn't try to open both unopened hard drives at the
    same time.  This method is a little better (from a purely brute
    viewpoint) but does caused your startup to run longer, since the
    purpose of this option is to have each of your fsck passes run
    one after another.


4.1.8    How do you implement quotas on Net/2 derived BSD systems?

    From: [e-mail] (Mark Tinguely)

     maybe you did not complete the setup, here is a step-by-step
     instructions to get them to work:

    1)  make a kernel with "options QUOTA" installed

    2)  edit /etc/fstab and include the kinds of quotas you want,
        below I used "userquota", you could also add "groupquota".

    /dev/wd0h        /usr        ufs    rw,userquota 1 2

    3)  for each filesystem that is in /etc/fstab that uses quota,
        create the file "quota.user" (and "quota.group if appropriate).
        Above I have user quotas in the /usr filesystem, so I would:

        # touch /usr/quota.user

    4)  scan filesystem for files ownership (and/or group ownership).

        # quotacheck -a

    5)  now you can add individual quota limits, if you want to add
        the same quotas to the many people, then make a template and
        replicate the template.  If they change for each user, then
        edit seperately.

        # edquota tinguely

     (an editor is kicked up and says something like:

    Quotas for user tinguely:
      /usr: blocks in use: 11876, limits (soft = 0, hard = 0)
            inodes in use: 891, limits (soft = 0, hard = 0)

     a limit of 0 means "unlimited".  Change these to the appropriate
     number of blocks.  A soft limit generates a warning, and can be
     exceed for period of time (7 days?), after which time a soft limit
     is treated like a hard limit.  A hard limit denies new writes.

     to replicate a template (for this example let us assume "tinguely"
     is the template):

        # edquota -p tinguely user1 user2 user3 ... userN

    6)  turn quotas on (usually done in the /etc/rc file, but turn it
        on manually so you do not have to reboot right now:

        # quotaon

    that should take care of setting up quotas.  You can look at the
    status of use of files with repquota, the -a option lists all
    filesystems with quotas.


4.2    Available kernel add-ons


4.2.1    The Patch-Kit

    Perhaps the most famous of all additions to the kernel, the Patch-Kit,
    coordinated by Rodney Grimes ([e-mail]) contained
    numerous bug fixes, Julian's SCSI drivers, as well as fixes
    for other parts of the system.

    It is highly recommended that all users with space for the source code
    apply the patch-kits as many things that seem broken in 0.1 suddenly
    start working with the patch-kits.

    Of course, there is no such thing as a patch kit for NetBSD or FreeBSD.
    The update method for these systems is different, and covered in the
    section about the System Update Protocol (sup) updates.


4.2.2    Shared Libraries

    A basic and experimental implementation of shared libraries exists
    for 386bsd.  According to the author (Dr. Joerg Lohse,
    [e-mail]), features are as follows:

    -No kernel extension is necessary
    -Shared libraries use the approach used in SysV.

    Others are also working on different implementations of shared
    libraries.

    Bill and Lynne have adopted a shared-library implementation based
    on Dr. Lohse's original work.  It will be included in Version 0.2
    of 386bsd.

    For NetBSD and FreeBSD users, two seperate and different shared
    library systems have been developed.  This feature is included in
    the '-current' tree of both systems, and will be included in the
    next major release of eiter or both.

    The shared libs have, in general, been very well behaved.  The
    closest thing to a FAQ that has been introduced is the
    following:


    I installed FreeBSD-1.1-BETA a few weeks ago but can't get
    dynamically linked programs to run for some reason.  Every time
    I try to run a dynamically linked program, I get a message that
    says "No ld.so"...

    The answer is:

    # chmod 755 /usr/* /usr/share/misc


4.2.3    Sound Blaster Drivers

    A driver for the Sound Blaster card has been written by Steve
    Haehnichen ([e-mail]) for BSD.  Steve Gerakines has
    provided us with the information necessary to get this driver
    working under 386bsd.

    Most features of the SB family of cards are supported save some
    stereo portions of the SBPro cards.

    NetBSD and FreeBSD have also adapted soundblaster drivers.  They
    are included in either the -current tree or in the most recent
    release (depending on when you read this).

    For a fact, the following sound cards are supported in FreeBSD:

        1    Yamaha FM Synth
        2    Soundblaster/Soundblaster Pro DSP
        3    PAS PCM and Midi
        4    Gravis UltraSound
        5    MPU-401

    In the release notes I have, there is some doubt as to the
    operational status of the MPU-401 sound card driver.  If you have
    one of these cards and want to try the driver out, you should
    contact Jordan Hubbard ([e-mail]) when you are
    finished installing it and let him know how it is working.

    The docs for the FreeBSD driver are in
    /usr/src/sys/i386/doc/sound.doc.


4.2.4    Bus Mouse Drivers

    Fred Cawthorne ([e-mail]) wrote a busmouse
    driver for 386bsd.  He recently wrote a short letter with this
    update:

    This is taken from the INDEX in the Freebsd.cdrom.com mice
    directory:

    "We currently have four bus mouse drivers for 386bsd available by
    anonymous ftp on XFree-86.cdrom.com in pub/XFree86/mice:

    ms-busmouse.tar.z

        Sandi Donno's <[e-mail].> port of
        Erik Forsberg's Microsoft bus mouse driver to 386bsd.

    logitech-busmouse-0.2.shar.z

        Fred Cawthorne's <[e-mail]> second version
        of a logitech Bus Mouse driver.

    busmouse.tar.z:

        Eugene Stark's port of Rick Macklem's driver to the
        Microsoft bus mouse.  Rick's driver supports the
        Logitech and ATI Inport Bus mice with 386bsd.  It's also
        available by e-mail to [e-mail] and by anon.
        ftp on cs.sunysb.edu in pub/386BSD/busmouse.tar.Z.

    psm.tar.z:

        Johan Solhed <[e-mail]> ported the
        Linux PS/2 mouse driver to 386BSD.  It includes a PS/2
        to Microsoft protocol converter in the driver so XFree86
        understands the mouse events.

    In addition we have busmouse.v3.z which is Erik Forsberg's original
    post of his device driver for BSDI/386 and Microsoft (and
    compatible) bus mice using the Microsoft InPort chip as well as a
    device driver for Logitech bus mice. "

    Most of these busmouse drivers are now included in the current
    releases of NetBSD and FreeBSD.  There is some question about
    how well they work (especially the psm driver), but they are
    all there.

    Additional information about configuring the psm device is
    included below to help make the psm driver work reliably.

    Add the following entries to your config file:

    options        ALLOW_CONFLICT_IOADDR
    device         psm0    at isa? port "IO_KBD" tty irq 12 vector psmintr

    Duplicate the options and device lines into your own kernel
    configuration file, making sure to obey the proviso given about
    following your pc0/sc0 devices, recompile it, install it, and
    you should be off.  The the LINT configuration file for more
    information.


4.2.5    PPP Support

    PPP support is included in NetBSD and FreeBSD.  With the demise
    of agate's support for 386BSD, there is no way to add ppp
    support to 386BSD.  You must upgrade to wither FreeBSD or
    NetBSD.


4.2.6    re_comp and re_exec library functions

    As mentioned in section 4.1, re_comp and related functions, such
    as re_exec, are currently not in the library libc.a.  Apart from
    using the rather crude fix listed above, there is another option.

    Kim Anderson ([e-mail]) has provided a patch that will add these
    to libc.a.  You can probably obtain this patch from the author, or
    you can ftp it from binkley.cs.mcgill.ca in pub/386bsd.

    These functions are (I think) included in the libcompat.a that
    comes with both NetBSD and FreeBSD.


4.2.7    Intel i82586 Ethernet Controller driver

    Garrett A. Wollman has written a 386bsd 0.1 driver for the
    Intel i83586 Ethernet Controller.  The author's e-mail address
    is listed as [e-mail].


4.2.8    PC Speaker driver for Nethack

    Andrew A. Chernov has ported the Nethack PC Speaker driver to
    386bsd.  It allows the speaker to be controlled by applications.

    Unfortunately, we are not aware of a site that distributes this,
    but this patch has been posted a couple of times to the various
    comp.os.386bsd groups, and the author can be contacted at
    [e-mail]

    The patch that is included in the NetBSD and FreeBSD source trees
    is one written by Soerne Schmitt.  It appears to use the Sun-style
    /dev/audio interface and is different in goals and implementation
    from Andrew Chernov's speaker driver.  The source for this package
    is included in the source trees for both, but is not included in
    the distribution kernels.


4.3    Other program building type problems.

4.3.1    Greetings from Mars.  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?

    This is actually two separate questions, but they are close enough
    to the same that I can answer them here.  The first problem that
    anyone building a 'crypt' aware program needs to remember is that
    the crypt library is a separate library and requires a '-lcrypt'
    to be added at the end of the link line.  The other half of the
    problem is the 'US Non Export' policy for DES encryption.  There
    are several good sources (about one per country) for non-US
    crypt libraries.  IF you are outside the US and need one, look
    around on some of the NetBSD/FreeBSD/386BSD FTP sites in the
    'local area'.


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.

    There is a 16 character limit, sort of.  The most likely symptom
    for this is that the header for the file _after_ the long file
    name will be mangled.  It turns out that there is a "T" option
    that may not be documented very well that provides the correct
    functionality for long filename support in ar.


4.4    Where is the 'adduser' program?

    Here.

#!/bin/sh
# This is a shell archive.
# remove everything above the "#!/bin/sh" line
# and feed to /bin/sh
# Use -c option to overwrite existing files
#
# Contents:
#    adduser.sh
#
# packed by: <[e-mail]> on Sun Aug 21 10:25:30 EST 1994
#
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f adduser.sh -a x$1 != x-c ; then
  echo shar: Will not over-write existing file \"adduser.sh\"
else
  echo shar: Extracting \"adduser.sh\" \(6443 characters\)
  sed 's/^X//' >adduser.sh << '!EOF'
X:
X#
X# NAME:
X#    adduser.sh - portable add user script
X#
X# SYNOPSIS:
X#
X#    adduser.sh [-G "Group"] [-H "Homes"] [-S "Shell"] [-u "uid"] \\
X#        [-p "encrypted"] [-P "cleartext"] [-l]
X#
X# DESCRIPTION:
X#    Simply adds users and their home directory.  It prompts for a
X#    "username" and "fullname" which become part of the passwd file
X#    entry for the new user.  It adds "username" to "Group"
X#    (creating it if necessary) and uses "uid" or the 'gid' of
X#    "Group" as a starting point for its search for an unused
X#    'uid'.  By default it will prompt for a passwd after adding
X#    each user, but '-p' can be used to set a pre-encrypted password
X#    or '-P' can be used to give a clear text password which the
X#    script will encrypt and then use for each new "username".
X#
X#    Most of the variables used are obvious.  "Homes" is the parent
X#    directory of new users home directories.
X#
X#    The '-l' option causes the script to show the default values
X#    for the variables that it uses.  Most if not all can be set on
X#    a per machine basis by creating a file '.adduserrc' in the
X#    super users home directory or in the directory where
X#    'adduser.sh' is found.  If "Homes"/.adduserrc exists it will
X#    be processed after any others, so can be used to set defaults
X#    on a per project basis.
X#
X# NOTES:
X#    The script handles shadow password files on Solaris 2.3, other
X#    machines may break.  It has been tested on NetBSD, SunOS,
X#    Solaris and HP-UX.
X#
X# AUTHOR:
X#    Simon J. Gerraty <[e-mail]>
X#
X
X# RCSid:
X#    $Id: adduser.sh,v 1.2 1994/05/08 22:54:04 sjg Exp sjg $
X#
X#    @(#) Copyright (c) 1993 Simon J. Gerraty
X#
X#    This file is provided in the hope that it will
X#    be of use.  There is absolutely NO WARRANTY.
X#    Permission to copy, redistribute or otherwise
X#    use this file is hereby granted provided that
X#    the above copyright notice and this notice are
X#    left intact.
X#
X#    Please send copies of changes and bug-fixes to:
X#    [e-mail]
X#
X
XMyname=`basename $0 .sh`
XMydir=`dirname $0`
Xcase $Mydir in
X.)    Mydir=`pwd`;;
Xesac
X
XETC=/etc
X# for testing only
X#ETC=/tmp
X#VIPW="ed $ETC/passwd"
X
X# thinks that the rc file may override.
Xhost=`hostname 2>/dev/null`
XHomes=/home/${host:-`uname -n`}
XShell=/bin/csh
X[ -x /bin/ksh ] && Shell=/bin/ksh
XGroup=users
XPasswd='**'
X
X# look for an rc file
Xfor d in $HOME $Mydir
Xdo
X  [ -s $d/.${Myname}rc ] && { . $d/.${Myname}rc; break; }
Xdone
X
XEXF=/tmp/e$$
XTF=/tmp/u$$
XTF2=/tmp/uu$$
X
Xcase `echo -n .` in
X-n*)    N=;C="\c";;
X*)    N=-n;C=;;
Xesac
X
XOS=`uname -s`
X
Xadd_path () { [ -d $1 ] && eval ${2:-PATH}="\$${2:-PATH}:$1"; }
X
Xget_id()
X{
X  file=$1
X  name=$2
X  min=${3:-1000}
X  max=`expr $min + ${4:-999}`
X  > $EXF
X
X  id=`grep "^$name:" $file | cut -d: -f3`
X  case "$id" in
X  "")
X    # missing, must add it
X    i=$min
X    while [ $i -lt $max ]
X    do
X      n=`cut -d: -f1,3 $file | grep ":$i\$"`
X      case "$n" in
X      "")
X        # an empty slot - use it
X        id=$i
X        break;;
X      esac
X      i=`expr $i + 1`
X  done
X  ;;
X  *)
X    echo $id > $EXF;;
X  esac
X  echo $id
X}
X
Xmkdirs()
X{
X  case $1 in
X  /*)    pp=/;;
X  *)    pp=;;
X  esac
X  for p in `echo $1 | tr / " "`
X  do
X    case "$pp" in
X    "")    pp=$p;;
X    /)    pp=/$p;;
X    *)    pp=$pp/$p;;
X    esac
X    [ -d $pp ] || mkdir $pp || exit 1
X  done
X}
X
X
Xadd_group()
X{
X  echo "adding $1:*:$2: to $ETC/group"
X  echo "$1:*:$2:" >> $ETC/group
X}
X
Xupd_group()
X{
X  [ "$mygroup" ] || mygroup=`grep "^$1:" /etc/group | cut -d: -f4`
X  case ",$mygroup," in
X  ",,")                # empty
X    add=$2;;
X  *,$2,*)            # already there
X    add=;;
X  *)                # missing
X    add=,$2;;
X  esac
X  [ "$add" ] && sed "/^$1:/s/\$/$add/" $ETC/group > $ETC/group.$$ &&
X      mv $ETC/group.$$ $ETC/group
X}
X
Xupd_passwd()
X{
X  EDITOR=ed
X  VISUAL=ed
X  export EDITOR VISUAL
X
X  didit=
X
X  echo "adding $1:$2:$3:$4:$5:$6:$7 to $ETC/passwd"
X  case "$OS" in
X  SunOS)
X    if test -f /etc/shadow; then
X      # we are assuming its Solaris
X      echo "$1:x:$3:$4:$5:$6:$7" > $TF
X      echo "$1:$2:6445::::::" > $TF2
X      didit=yes
X    fi
X    ;;
X  *BSD)      # NetBSD at least
X    echo "$1:$2:$3:$4::0:0:$5:$6:$7" > $TF
X    didit=yes
X    ;;
X  esac
X  # most OS's just want this.
X  test "$didit" || echo "$1:$2:$3:$4:$5:$6:$7" > $TF
X
X  line=`grep -n '^+:' $ETC/passwd | cut -d: -f1`
X  ( sleep 1; echo ${line}-1r $TF; echo w; echo q;
X    if test -f /etc/shadow && test "$OS" = SunOS
X    then
X      # this is a crok...
X      sleep 5
X      echo e
X      sleep 5
X      echo '$r' $TF2
X      echo w
X      echo q
X    fi
X  ) | ${VIPW:-vipw}
X}
X
Xadd_user()
X{
X  group=$1; shift
X
X  eval set -- `echo "'$*'" | sed "s/:/' '/g"`
X
X  gid=`get_id $ETC/group $group $4 256`
X  if [ "$gid" ]; then
X    [ -s $EXF ] || add_group $group $gid
X    uid=`get_id $ETC/passwd $1 $3 1024`
X    if [ "$uid" ]; then
X      [ -s $EXF ] || upd_passwd "$1" "$2" "$uid" "$gid" "$5" "$6" "$7"; upd_group $group $1
X      [ -d $6 ] || { mkdirs $6 && chown $1 $6 && chgrp $group $6 && chmod 2775 $6; }
X    else
X      echo "can't add user $1" >&2; exit 1
X    fi
X  else
X    echo "can't add group $group" >&2; exit 1
X  fi
X}
X
Xrm_user()
X{
X  ( echo /^$1:/d; echo w; echo q ) | ${VIPW:-vipw}
X}
X
X# needs perl
Xencrypt() {
X  for d in /usr/libexec /usr/lib
X  do
X    [ -x $d/makekey ] && { makekey=$d/makekey; break; }
X  done
X  perl -e "print pack('a8a2', '$1', '${2:-$$}')" | ${makekey:-makekey}
X}
X
X# ok, time to get to work...
Xset -- `getopt H:S:G:u:p:P:l $*`
X
Xadd_path /sbin
Xadd_path /usr/sbin
Xadd_path /usr/ucb
Xadd_path /usr/etc
X
Xfor i in $*
Xdo
X  case "$i" in
X  --)    shift; break;;
X  -H)    Homes=$2; shift 2;
X    # pick up group defaults...
X    test -s $Homes/.${Myname}rc && . $Homes/.${Myname}rc
X        ;;
X  -S)    Shell=$2; shift 2;;
X  -G)    Group=$2; shift 2;;
X  -u)    uid=$2; shift 2;;
X  -p)    Passwd="$2"; shift 2;;
X  -P)    Passwd=`encrypt $2`; shift 2;;
X  -l)    list=yes;;
X  esac
Xdone
X
Xgid=`get_id $ETC/group $Group 100 1000`
X[ "$uid" ] || uid=$gid
X
Xcase "$Passwd" in
X""|none)    Passwd=;;
Xnologin)    Passwd='*';;
Xesac
X
Xif [ "$list" = yes ]; then
X  echo "Defaults:"
X  for v in Group Homes Shell
X  do
X    eval echo "\    $v=\$$v"
X  done
X  [ "x$Passwd" = "x*" ] && echo "    Passwd=prompt" || echo "    Passwd=$Passwd"
X  [ "$uid" ] && echo "    Initial uid=$uid"
X  echo
Xfi
Xecho Enter username and fullname - spaces in fullname are ok, no quotes needed.
Xecho An empty line terminates input.
Xecho
X
Xecho $N "username fullname: $C"
Xwhile read uname fname
Xdo
X  [ "$uname" ] || exit 0
X  add_user $Group "$uname:$Passwd:$uid:$gid:$fname:$Homes/$uname:$Shell"
X  [ "x$Passwd" = "x**" ] && passwd $uname
X  echo $N "username fullname: $C"
Xdone
!EOF
  if test 6443 -ne `wc -c < adduser.sh`; then
    echo shar: \"adduser.sh\" unpacked with wrong size!
  fi
  chmod +x adduser.sh
fi
exit 0

--
TSgt Dave Burgess           | Dave Burgess
NCOIC, USSTRATCOM/J6844     | *BSD FAQ Maintainer
Offutt AFB, NE              | [e-mail]

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

Section 5.    (Kernel Replacements)

5.0    Introduction

    This section is supposed to document the unusual or optional
    kernel add-ons that are available from various places.  As
    they are included in the mainstream of the various Berkeley
    Net Release systems, they will slowly come out of here.

    If you know of any replacement parts for the kernel, please
    send Dave Burgess ([e-mail]) a message
    detailing the package (possibly include a README), where it
    can be found, and what version of the OS (ie. NetBSD,
    386bsd 0.1 + pk 0.2, FreeBSD) it was designed to run under.


5.1    Available Kernel Replacements


5.1.1    keycap/codrv

    These server as replacements for the generic pccons driver
    that comes (by default) with 386bsd 0.1.

    Holger Veit (author of these) writes:

    "The same type of driver, but keycap has the version number 0.1.1
    and codrv has the version number 0.1.2.  The latter is much
    improved and downward compatible.  Codrv was developed to provide
    a universal way of mapping national keyboard layouts during
    runtime (ie, not by patching the kernel tables) and providing
    better X11 support.  Codrv uses a superset of the pc3 terminal
    emulation, and a termcap-like database for keymaps (therefore
    "keycap").  X11 is supported by two dedicated console raw devices
    /dev/kbd and /dev/vga, which avoids all the existing problems
    pccons has with X11.  The latest version has virtual consoles.
    Codrv will become part of patchkit 0.2.4"



5.1.2    pcvt

    A superset of pccons, this driver supports virtual consoles,
    and some form of database oriented keyboard mappings.  It was
    also designed to emulate a vt220 terminal as best as possible.

    (This section originally identified Joerg Wuensch as the
    author. Hellmuth Michealis is the author of pcvt.  Joerg was the
    author of the original post.  This update is from Hellmuth
    himself.  Apologies from the FAQ staff...)

    The last release of pcvt is version 3.00 and was done on March
    1st 1994 to the newsgroup comp.sources.misc, Volume 41, Issue
    140-152 (part 1-13).  Future releases and upgrades will be done
    as patches or new releases to that newsgroup.

    pcvt was recently put into the kernel sourcetree of
    NetBSD-current (pre 1.0) into /sys/arch/i386/isa/pcvt.

    pcvt is also available in the FreeBSD contributed tree at
    location /usr/ports/util/pcvt.

    The pcvt package consists of:

    - the driver itself
    - complete documentation for installation and operation
    - termcap/terminfo, pcvt.el, rc.local, /etc/ttys, xmodmap examples
    - cursor, utility to set the cursor size and shape
    - fed, a curses-based EGA/VGA character set editor
    - fontedit, utility to edit the VT220 downloadable character set
    - ispcvt, utility to display the drivers compile time configuration
    - kcon, utility to setup national keyboard layouts and remap keys
    - keycap, keyboard mapping database library similar to termcap
    - loadfont, utility to load up to 4/8 fonts into an EGA/VGA board
    - mcon, utility to control/configure a keyboard based mouse emulator
    - scon, utility to runtime configure the video part of pcvt
    - userkeys, utility to set the VT220 user programmable function keys
    - vttest, VT100 compatibility torture test program
    - demo, color- characterset- and attribute demos
    and more ....

    See the README-file for the latest release (3.00) of pcvt for
    lots more information and a complete list of the contributors
    to this project.


5.1.3    syscons

    Another superset of pccons that was designed to emulate SCO as
    well as possible.  Many of the ioctls from SysV have been
    implemented.  XFree86 2.0 no longer requires special patches
    to be run with kernels using this console driver.


5.1.4    Fast Symbolic Links

    The following is taken from the README for the fast sym-links
    patch:

    "This cruddy but complete hack answers one of the objections to
     symlinks: that they are slow, and cost an entire frag.  Symlinks
     of less than length 60 are stored in the inode itself.  Symlinks
     longer than this are still in the inode.  To make the illusion
     of normality complete, dump and fsck also need changing.
     Additionally, I made dumpfs verbose to excess."

    Fast Symbolic Links are supported natively in FreeBSD and NetBSD.


5.1.5    npx fixes

    There are problems with the floating point error handling
    routines, and there are fixes available for this problem provided
    by Bruce Evans (of Minix-386 fame)

    Note that most of the code is applicable to floating point hardware
    as opposed to emulation.

    The newest version (and now official) fixes to this are in
    patchkit-0.2.4.

    There are still some nits in the npx emulation code in both FreeBSD
    and NetBSD.  They are being worked on.


5.1.6    CGD's COM drivers

    Chris G. Demetriou (cgd@blah blah blah) has written some COM
    drivers for 386bsd.  These, among other things, support multi-
    port serial packages.

    This driver was the basis for the FreeBSD com subsystem.  NetBSD
    does not use them.  There are patch files around that added
    some of the missing functionality to NetBSD.  Multiport comm
    support (the biggest and best feature of the CGD COM driver) is
    included in both FreeBSD and NetBSD as standard 'compile in'
    features.


5.1.7    The original 386bsd 0.1 wd.c driver doesn't work. [386bsd 0.1
    only]

    If you are still using 386bsd 0.1 and are having trouble with
    the wd driver, Tom Helbekkno took the time to write a
    replacement wd driver specifically to fix the problems
    identified in the months after 0.1 was released.  Much of this
    code was pulled into the patch-kit.

    The 'Barsoom' driver was used as the basis for the original
    NetBSD and FreeBSD drivers, and was the source for much of the
    work that has been done to date on this driver.

    Unfortunately, the 'barsoom' driver is no longer available, and
    E-Mail from Tom indicates that there is very little of the
    original 'barsoom' driver left in either FreeBSD or NetBSD.  If
    you find yourself in this predicament, you REALLY need to
    upgrade to either FreeBSD or NetBSD.


5.1.8    Interruptless LPT Driver Kit [386bsd 0.1 only]

    This driver was designed with faster performance and lower system
    load in mind.  See the INSTALL-NOTES that come with the package
    for more details and installation information.

    This is also included in NetBSD and FreeBSD.  Note that with some
    printers, it may be prefereable to ignore the status port and rely
    on the data port.  If you have tried everything else and the
    interruptless printer driver still does not work for you, you may
    need to play with this.

    It has also been determined that the interruptless driver may be
    (or already has been) removed from the system.  A newer lpt driver
    has been developed that removes many of the overhead problems that
    the original 386bsd lpt driver had.


5.1.9    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://netcom.com:/pub/zmbenhal/ncurses/1.8.5.tgz.


5.2    Floppy Disk problems.

    One of the most common problems in 386BSD involves working with
    new boot sector and/or reformatting a floppy.  Dave Silvia
    provided this section on using floppy disks.


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

    Configuring a parallel printer for 386bsd requires a working
    printer driver to be installed in the kernel.  386bsd 0.1 does
    not include a printer driver in the stock distribution kernel.
    NetBSD and FreeBSD both include this driver in their stock
    manifestations.

    It is possible to connect a serial printer to either.  This brief
    tutorial is provided by Daryl Berryhill
    ([e-mail])

    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 queueing 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 Postscipt (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
    resoultions 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

    How to add a modem to 386BSD:

    The first part that confused me was assuming that /dev/com1 is
    the same as DOS com1, they're not.  /dev/com0 is connected to
    COM1 and (I think) /dev/com1 is connected to COM2.

    The switch settings for my modem were the same as what I had
    under DOS, CTS CD RTS et al were set to follow the actual line
    (i.e. my modem can force them high, which I turn off)

    Ok that's not too bad.

    Now you need to edit the /etc/remote file to include a reference
    to the com port. I have only used NetBSD-0.8, so I'm not sure
    what the default files are like that come with the other rev's
    of 386BSD.

    I added the last line (with com0).
    --------------------------------------------------------
    #    @(#)remote    5.2 (Berkeley) 6/30/90
    #

    ...stuff deleted...

    # UNIX system definitions
    unix1200|1200 Baud dial-out to another UNIX system:\
        :el=^U^C^R^O^D^S^Q:ie=%$:oe=^D:tc=dial1200:
    unix300|300 Baud dial-out to another UNIX system:\
        :el=^U^C^R^O^D^S^Q:ie=%$:oe=^D:tc=dial300:

    ...stuff deleted...

    dial2400|2400 Baud Hayes attributes:\
            :dv=/dev/tty19:br#2400:cu=/dev/tty19:at=hayes:du:
    dial1200|1200 Baud Hayes attributes:\
            :dv=/dev/tty19:br#1200:cu=/dev/tty19:at=hayes:du:

    # Hardwired line
    com1c|com1:dv=/dev/com1:br#9600:
    com1b:dv=/dev/com1:br#2400:

    com0:com0:dv=/dev/com0:br#9600:at=hayes:
    ------------------------------------------------

    Ok, now if you are running as root you can use type 'tip com0'
    and you should then be talking to your modem.  I use kermit to
    transfer files, and it wants to create a lock file in (not sure
    about the exact path) /var/spool/uucp/lock or something along
    those lines.  I made the directory world writeable so I could
    run kermit with my own uid, rather than root.

    Also, you may need to add an entry in /etc/remote for com0.

    Thanks also to [e-mail] for information on how
    to do this.

    New problems have surfaced with the latest releases of NetBSD.
    It seems that the paradigm that the com port used to use was
    'less than complte' and much of the code has been replaced.
    This provides for some interesting new problems.  The first is
    that the Carrier Detect line is no longer ignored, as it was
    before.  This means that programs like kermit and tip/cu either
    have to be told explicitly to ignore the CD line (in kermit,
    for example, you would use the 'set carrier off' in your .kermrc)
    or you need to use the 'stty -f /dev/com? clocal' command before
    you open the port.

    If you have trouble getting the settings to 'stick' it is because
    the ports are now initialized to known settings on the last close
    of the port.  A workaround for this is to use the command:

        sleep 1000 < /dev/com?
        tip ...
         { or }
        kermit ...

    This will keep the port open for about 12 minutes while you do
    whatever it is you need to do.  Once the port is open and your
    connection established, the port will not reset until the final
    close.

    Another symptom of this malady is described below.

    When I 'set line' in kermit, it hangs until I hit my escape
    character (^\).  It *does* set the line (and the rest of my session
    is normal), but it's annoying because I can't put 'set line' in
    my .kermrc.

    The answer is available in the kermit documentation as well as
    here (now).  The following commands are MY .kermrc file:


        set carrier off
        set line /dev/com2
        set speed 38400
        set modem hayes
        set dial speed on
        set dial timeout 60

    The 'set carrier off' tells kermit to ignore the Carrier Detect
    line from the modem, and to proceed as if the command were
    there.  This will (as far as I have ever been able to find
    out) fix the specific problem with not being able to set the
    line.


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.

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.11    Where are all the answers to the above and related questions
    written down?  Neither on the net nor in the 4.3BSD manuals
    nor Administration text which I have could I find this stuff
    covered!

    They are in the FAQ :-)...


5.4.12    What else should I know?  For example, it seems that a new tape
    must stretched.  How is this done?

    Use a blowtorch and a pair of pliers;  or you can use the
    non-destructive method and run the tape through a complete fast
    forward/rewind cycle to get it tight on the spindles.


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
    minicartridge drives are supported natively in FreeBSD and
    experimentatlly in NetBSD.  Some aren't (mine for example, is not).

    If your tape drive is a SCSI based drive, your guess is as good as
    mine.  I don't have one.

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

    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.

    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.


5.5.2    I recently has 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.

--
TSgt Dave Burgess           | Dave Burgess
NCOIC, USSTRATCOM/J6844     | *BSD FAQ Maintainer
Offutt AFB, NE              | [e-mail]

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

    There is a rumor that floppy formatting either is possible or was
    possible at one time.  If you see any software or FTP sites with
    anything about this, please contact [e-mail]
    and I will make sure it gets updated in here.

    There was a set of patches that were developed to allow floppy
    formatting.  They are not currently included in any of the *BSD
    systems.

    I have actually applied the patches for floppy formatting here
    on an older version of NetBSD, and they seem to work just fine.
    The fdformat program could use some work, but seems to work OK.
    According to the author, similar patches are available for
    FreeBSD and the original 386BSD.  The package that I used here
    was posted in comp.os.386bsd.* somewhere.  I think that it is
    available by anonymous FTP from cynjut.infonet.net.  If not,
    E-Mail me at [e-mail] and I will mail you a
    tar file with the stuff that I have available.


6.2    Sharing the Disk with MS-DOS

    There are a myriad of questions about how to share a disk between
    386bsd 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 386bsd?
    2)  I can install using the whole disk, but I can't install when
    I try to share the drive between 386bsd and MS-DOS.  Why?
    3)  I can use either MS-DOS or 386BSD 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 anomoly.  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 parition 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 parition 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 paritions 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 milage may vary.

    Luke Mewburn <[e-mail]> 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
    transferrable to all BNR derived Unices.


            Getting NetBSD 0.8 to coexist with DOS.

            Written 930510 by Luke Mewburn <[e-mail]>


    NetBSD can be made to happily co-exist with DOS if its install
    program knows how to modify the partition table. This assumes
    that you have access to a program which enables you to edit the
    partition table of your hard drive (such as Norton Utilities, or
    pfdisk).

    When you partition your hard drive, you will probably have a large
    partition in which you wish to place NetBSD. This has to have the
    partition ID of 165d (or 0xA5). To change this, you can use the
    'Partition Edit' section of Norton's, or you can use pfdisk.
    This document will go into more detail on how to use pfdisk, as it's
    freely available.

    I'll use my personal drive specifications in the following example.
    It is a 1001 cylinder, 15 trk/cyl, 17 sec/trk, 125MB drive. I
    low-level formatted it, and used fdisk on a MS-DOS 5.0 boot disk to
    create a primary partition '1' of 32MB, and an extended partition '2'
    of 93MB.  I formatted the drive with format c: /s to give myself a
    bootstrap for DOS (much faster than floppies :), but this isn't that
    necessary. Now, the next stage...

    Running pfdisk 0 (to access my first (and only :) HD) came up with
    something like:

    For help, enter: '?'
    pfdisk>

    At the prompt, enter 'l' to list partitions, giving (in my case),
    something like:

    # Partition table on device: 0
    geometry 1000 15 17 (cyls heads sectors)
    #  ID  First(cyl)  Last(cyl)  Name  # start, length (sectors)
    1   4      0        256       DOS16 # 17, 65518
    2   0    257        999       unkno # 65535, 189465
    3   0      0          0       empty # 0, 0
    4   0      0          0       empty # 0, 0
    active: 0 (none)

    (Note that there is 1 cylinder less - the last one is, I think,
    for the IDE controller to use when auto-mapping dud sectors out.)

    Now, we want to change the type of #2 (the prospective NetBSD
    partition) to 165. You can obtain a list of known IDs by selecting
    'I'. Depending on the version of pfdisk you have, 165 may or may not
    be known. This doesn't matter too much either way. To get the NetBSD
    install program to use the 2nd partition, I would enter:

    pfdisk> 2 165 257 999

    Another 'l' to list partitions would show that the entry for
    partition 2 will either look like one of the following (depending
    on whether pfdisk knows about the 386bsd partition type or not):

    2 165    257        999       unkno # 65535, 189465
    or
    2 165    257        999       386BS # 65535, 189465


    You could set the active partition with 'a 2' if you want NetBSD
    to always boot, but I personally recommend that you obtain a copy
    of OS-BS 1.35 or BOOTEASY to save you the hassle of running fdisk
    or pfdisk every time you wish to swap system types.

    To complete everything off, do 'w' to write out the info (once
    you're sure it's correct! :), and 'q' to quit the program.


    Well, I hope that is useful to someone. Comments can be directed
    to the author (Email: <[e-mail]>).


6.2.2    I can install using the whole disk, but I can't install when
    I try to share the drive between 386bsd 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 386bsd, 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 386bsd exclusively,
    job not withstanding.


6.2.3    I can use either MS-DOS or 386BSD on my hard drive,
    but shutdown -todos doesn't seem to work.

    There is a known bug in shutdown that prevents the -todos option
    from working as advertised on all but the smallest DOS partitions.
    Many people have reported some success while using a very small
    (less than 32M) DOS partition as the first partition.

    There is a utility available for 386bsd which operates very much
    like the MS-DOS fdisk partitioning program.  You can use this program
    to mark the DOS partition active from 386bsd.  A similar procedure
    is used (fdisk in DOS) to mark the 386bsd partition as the active
    boot partition.  Boot managers are also an excellent investment for
    those individuals that need to boot both DOS and 386BSD.


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

    [e-mail]

    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.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 386bsd.  One way is to modify mtools so that it recognizes your
    DOS partition.  This solution is provided by Jim Paradis
    ([e-mail]):

    --------------------------------------------------------------------
    To build a /usr/othersrc/public/mtools.2.0.5/devices.c file that
    lets you access the DOS partition, you need to know the byte offset
    of the DOS partition from the start of the hard disk.  You would then
    add an entry to the devices[] array as follows:

    {'C', "/dev/wd0d", <byte-offset>L, 16, 0, (int (*) ()) 0, 0, 0, 0},

    So, f'rinstance, if your DOS partition starts at the beginning of
    the disk, you'd have:

    {'C', "/dev/wd0d", 0L, 16, 0, (int (*) ()) 0, 0, 0, 0},

    On the other hand, if your DOS partition starts 32MB into the disk,
    you'd say something like:

    {'C', "/dev/wd0d", (32768L * 1024L), 16, 0, (int (*) ()) 0, 0, 0, 0},

    --------------------------------------------------------------------
    Of course, this is both the hard and VERY non-portable way of
    solving this problem.  An easier way would be to add PCFS or
    MSDOSFS to your *BSD system.  Both the PC File system and PC
    Network File System (PC-NFS) code has been ported to 386bsd/
    NetBSD/FreeBSD.  These are available from several sources,
    including the patchkit and in the -current trees.

    The instructions for using PCFS with 386BSD are provided by Scott
    Miles <[e-mail]>.

        What would probably be easier would be to add a partition to
        the disklabel for your DOS drive and then just mount it with
        PCFS.  I don't know if it's in the FAQ now, I haven't read it
        for a while, but this is what I did:

        1) run 'fdisk' and write down the DOS partition info for
        the start and size that it gives you.

        2) disklabel -e -r /dev/<raw device>
              - Add 1 to the '# partitions:', and then add another line
              for the DOS partition .  Mine went in after e: as

       f:   130977     63   unused      0     0     # (Cyl.    0*- 129*)

    (Ed.Note:  The unused should be something else, although I really
        couldn't tell you what. MSDOS is a recognized partition
        type name; maybe that should be used.  Also, make sure that
        your c: and d: partitions do not overlap this area.  h: might
        be a better partition letter to use; that way the MSDOS
        partition is graphically separate from the rest of the BSD
        partitions.  DO NOT USE a:, b:, c:, or d: for your DOS
        partition.  These are RESERVED for your BSD system and any
        attempt to use these for anything but what BSD uses them for
        will result in a completely hosed, totally dead, absolutely
        screwed up file system.  You have been warned! )

        3) Add a line to /etc/fstab if you want it mounted
        automatically.
             Mine is:
             /dev/wd0f   /dos      pcfs  rw   1       2

           Otherwise, just mount -t pcfs /dev/<part> /<dir>

    Mount has other options that may improve performance or increase
    security for your system.  See 'man mount' for more information
    about mounting your system read-only and other advanced features.

    In addition to this, Jordan Hubbard has provided us with the
    following description for mounting the DOS partition specifically
    from FreeBSD:

        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 insted 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 seriuosly
    doubt that you will be able to read the compressed DOS file system
    anytime in the forseeable 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 ([e-mail]) 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.

    After playing with etherfind and kernel printfs, I've come to this
    conclusion: Fragmented 8K UDP packets from the NFS server are not
    reaching the UDP layer in 386bsd.  The Sun is sending them (according
    to another Sun spying on the network), but the UDP input routine is
    never called.  I don't know if the bug here is on the 386bsd or Sun
    side, and won't have time to look into it in the next couple of days.

    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.
    Charles Hannum reports that he has no trouble using the default 8K
    packet size.  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.  This is part of secure NFS, and is not
    supported in 386BSD.


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 ([e-mail]) 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 386BSD machine.
    Simply remove some entries and the NFS mounts will succeed.

    The problem is also explained in the Clarkson Driver documentation.
    On 386bsd, the maximum number of groups that can be associated with
    a particular user is specified in the source (in a #DEFINE).  In
    386bsd, this number is set to 8.  So, you actually have two routes
    you can take to correct this problem.  The first is outlined by
    Hellmuth, above, and the second is to edit and recompile the NSF
    software to allow more groups.


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 dicotomy 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 ([e-mail]), the original author of
    the ed0 driver, provides us with some insight into the inner
    workings of the ed0 driver.

       It always surpises 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 occassionally 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 386BSD'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    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    1    /* 1.44MB diskette */
        /dev/fd0b    2    /* 1.2 MB AT-diskettes */
        /dev/fd0c    3    /* 360kB in 1.2MB drive */
        /dev/fd0d    4    /* 360kB PC diskettes */
        /dev/fd0e    5    /* 3.5" 720kB diskette */
        /dev/fd0f    6    /* 720kB in 1.2MB drive */
        /dev/fd0g    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.
--
TSgt Dave Burgess           | Dave Burgess
NCOIC, USSTRATCOM/J6844     | *BSD FAQ Maintainer
Offutt AFB, NE              | [e-mail]

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

Section 7.    (System Communication and Network Information)

7.0    Communications

    386bsd and its kith support a wide range of communications methods.

7.1    SLIP/CSLIP

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

    Brian <[e-mail]> 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 eachothers 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 (eg. 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 mine:-

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

    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
    irrelevent 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:e
    ol2
    2=ff:erase=0:intr=3:kill=0:lnext=16:quit=1c:reprint=12:start=11:status=ff:st
    op=
    =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
    should be available in the next major release (0.9+) of NetBSD and
    in the current release of FreeBSD and NetBSD both.

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


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.


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 behaviour 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 equivelent 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 seperate
    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 infomation.


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    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.6    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 adresses, 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
     alaises 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.7    Can network attached assets be used by/from NetBSD?

    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.

    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 and FreeBSD.  Works good for me.

--
TSgt Dave Burgess           | Dave Burgess
NCOIC, USSTRATCOM/J6844     | *BSD FAQ Maintainer
Offutt AFB, NE              | [e-mail]

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

ection 8.    ("Supported" Hardware List)

Disclaimer: This list is NOT a commercial oriented effort.  It is not an
        attempt to promote brands of computer machinery; it merely
        reports "happy" customers.  The validity of information supplied
        is based solely on the validity of the statements made by the
        contributors.  If more information is needed on a particular
        product please contact the contributor directly via e-mail.


8.0    What hardware is 386BSD known to run on and support!

    The problem with this section of the FAQ is that software is
    the only reason that every PC card on the planet does not work.

    EISA cards are not directly supported; when and if EISA
    is directly supported, they will give a significant performance
    advantage to EISA bus machines.  As it happens, user who desire
    more than 16Meg of memory must use either VESA or EISA systems.
    Even with an EISA system, many users will not be able to use the
    address space above 16Meg unless their system uses only EISA
    cards for those devices that need access to DMA.  The limitations
    are covered in another section of the FAQ.

    Many EISA cards operate in an ISA emulation mode.  Notably, the
    Ultrastore 24F SCSI controller operates in an IDE emulation mode
    that allows the card to be used in the current system without
    modification.  Most EISA cards that operate in ISA mode will
    work with 386BSD, NetBSD, or FreeBSD.

    Like EISA, MCA is unsupported currently; unlike EISA, it can't
    work until it is supported, as it doesn't fall back to ISA
    operation.  If you want to work on this problem, I'm sure that
    many people will appreciate it; you will probably need an ISA or
    EISA machine to do the work, however.

    On top of all of that, NetBSD (being the 'horizontal' entry in
    the *BSD family) supports the following CPUs:

        amiga
        hp300
        1
        pc532
        sparc

    There are more systems being added to this 'tested and stable'
    list of computers for which *BSD systems exist.


8.1    Video cards

Card:
Manufacturer:
Price:
Bus:
Comments:

Card:    MGA
Manufacturer:    ?
Price:        $10
Bus:        ISA 8/16
Comments:    Good if you want only text mode in one window, virtually
        unusable in X.

Card:        TVGA
Manufacturer:    Trident
Price:        $30 - $70
Bus:        ISA
Comments:    Good for multiscreen consoles (pcvt, syscons), but sloooow
        for 'X'.  Some cards with this chipset have a bug preventing
        them from being used with XFree86.

Card:        ET3000
Manufacturer:    Tseng Labs/Taiwan
Price:        $40 - $90
Bus:        ISA 8/16
Comments:    Good for text and 'X'.  A bit slow.

Card:        ET4000
Manufacturer:    Tseng Labs/Taiwan
Price:        $45 - $110
Bus:        ISA 8/16, VLB, EISA
Comments:    Good for text and 'X'.  The fastest 'dumb' (unaccelerated)
        card.  Avoid Diamond cards, because of their proprietary
        clock programming.  Diamond is unsupported under XFree.

Card:        ET4000/32
Manufacturer:    Tseng Labs/Taiwan, Hercules
Price:        $65 - $130
Bus:        ISA 16, VLB, EISA
Comments:    Good for text and 'X'.  Some of the early cards have a
        hardware bug and don't work well with XFree86.  Avoid
        Diamond cards, because of their proprietary clock programming.
        They are unsupported in XFree86.

Card:        S3/801, S3/805
Manufacturer:    ?
Price:        $100 - $200
Bus:        ISA 16, VLB, EISA
Comments:    Good for 'X' and text.  Popular accelerated video cards.
        Available with 1 to 2 MB of RAM, VRAM, or DRAM.  If you
        want hhigh resolution, get one that uses VRAM.

Card:        S3/928
Manufacturer:    Miro, ELSA
Price:        $250 - $500
Bus:        ISA 16, VLB, EISA
Comments:    Good for text and 'X'.  Popular accelerated video card.
        Available with 1 to 4 MB or VRAM or DRAM.  For highest
        resolutions, get VRAM.  Supports resolutions up to
        1280x1024@60-70Hz.  It is twice as fast as the the S3/80x.
        It is about as fast as a Sparc II with GX adapters.  Support
        for 'low-end' VGA cards is typically poor.  Resolutions of
        less then 800x600 should be avoided.


8.2    Mice and Trackballs

    Mice are not supported, per se, in the Operating System.  They
    do make the GUI for 'X' a great deal less challenging.  The
    following mice are supported in 'X' and are therefore supported
    by the free BSD systems:

        Microsoft mouse
        Mouse Systems mouse
        Logitech serial mouse
        PS/2 bus mouse requires a special driver that is included
            in the current source trees.
        PS/2 compatible trackballs are also supported, but
            there have been problems with the trackball causing
            the keyboard to lock up.  See the psm driver
            information for help on getting this driver to work
            correctly with your system.


8.3    Serial Cards

    As a general rule, you should avoid a serial card that either
    does not use a 16550 UART, or does not have a chip that you
    can swap out to install one.  The 16550 will prevent many silo
    overflows that can occur with high speed modems.  Other than
    that, virtually all serial cards are supported.


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?

    From: "Martin Husemann" <[e-mail]>
    All AST 8 port Cards I have seen simply were two AST-4-port on
    one board. You would configure them like this:

     master    ast0    at isa? port 0x1a0 tty irq 5 vector astintr
     master    ast1    at isa? port 0x2a0 tty irq 7 vector astintr

    With that said, the discussion about these cards continues with
    how to make older versions of *BSD react correctly to your AST
    4 or 8 port cards.

    The AST/4 and its clone multiport cards can run on 386BSD using
    patchkit 0.2.4 and later, NetBSD, and FreeBSD.  The only
    problems seem to be that the code in older versions of
    sioprobe() and sioattach() in sio.c needs to be hacked to get
    it to properly detect the ports and then recognize the type
    of UARTs installed (16550As).  The code segment that is causing
    the problem is included below:

    The test in the sio.c driver (in the sioattach() routine) that
    is causing it to *think* it is a 8250 is:



    scr = inb(iobase + com_scr);
    outb(iobase + com_scr, 0xa5);
    scr1 = inb(iobase + com_scr);
    outb(iobase + com_scr, 0x5a);
    scr2 = inb(iobase + com_scr);
    outb(iobase + com_scr, scr);
    if (scr1 != 0xa5 || scr2 != 0x5a)   <--- this is it!
        printf(" <8250>");


    This test seems to be depending upon the absence of the com_scr
    register in the 8250 (iobase+7).  Unfortunately, the AST 4-port
    card uses this last register of the last UART for interrupt status
    (for the 4 UARTs), hence the last port of the 4 fails the test.
    The easiest fix is to simply delete this test in your copy of
    sio.c (If you *know* that you have no 8250s).

    The Bocaboard (BB1008) fails the same way on *all* 8 of its
    ports (the +7 address register is replicated for each port
    according to the documentation).

    There are also some problems with another test in the if
    statement:

    if (   inb(iobase + com_cfcr) != CFCR_8BITS
        || inb(iobase + com_ier) != IER_ETXRDY
        || inb(iobase + com_mcr) != MCR_IENABLE
        || !isa_irq_pending(dev)              <--- this one fails!
        || (inb(iobase + com_iir) & IIR_IMASK) != IIR_TXRDY
        || isa_irq_pending(dev)
        || (inb(iobase + com_iir) & IIR_IMASK) != IIR_NOPEND)
        result = 0;

    in the sioprobe() routine for a couple of the ports on the
    4-port card.  Again, the fix is simply to remove that particular
    test and everything seems to be okay.  These are admittedly
    pretty ugly hacks, but when you're in a pinch to the system back
    up...

    What you need in the config file is:

    sio0    -> COM1
    sio1    -> COM2

    (both should be recognized and work just fine)

    sio2    @ 0x1a0    irq 9 flags 0x0501
    sio3    @ 0x1a8    irq 9 flags 0x0501
    sio4    @ 0x1b0 irq 9 flags 0x0501
    sio5    @ 0x1b8 irq 9 flags 0x0501

    Other folks have reported that their configuration looks very
    similar to this, though they are using irq 5 for the 4-port card.

    (above paraphrased from Bob Willcox, et al)

    Another configuration for this is when two AST Four Port cards
    are actually used in a system.  The configuration for that looks
    like this:


    #device  sio0    at isa? port "IO_COM1" tty irq 4 vector siointr
    #device  sio2    at isa? port "IO_COM3" tty irq 5 vector siointr

    device   sio1    at isa? port 0x2a0 tty flags 0x0481
    device   sio2    at isa? port 0x2a8 tty flags 0x0481
    device   sio3    at isa? port 0x2b0 tty flags 0x0481
    device   sio4    at isa? port 0x2b8 tty irq 5 flags 0x0481
                vector siointr

    device   sio5    at isa? port 0x1a0 tty flags 0x0881
    device   sio6    at isa? port 0x1a8 tty flags 0x0881
    device   sio7    at isa? port 0x1b0 tty flags 0x0881
    device   sio8    at isa? port 0x1b8 tty irq 4 flags 0x0881
                vector siointr



    This is one of the areas where FreeBSD and NetBSD have
    diverged.  The actual semantics of the multiport boards have
    changed since this section was originally written (the flags
    are either no longer needed or are different in current NetBSD
    implementations, for example).


8.3.2    Now that I have FreeBSD 1.0 installed, how do I set up the
    serial ports for bi-directional use?

    Thanks to Lyn Kennedy ([e-mail]) for the advice about
    the cua devices and their minor numbers.  He worked out much of this
    without docs.

    In order to get the comm ports working, I decided to run the sio
    driver (heard it is faster and more capable than com).  In order to
    get it set up, this is what I did.

    1. I have four com ports assigned to the addresses and interrupt
    lines that are standard for DOS COM1, COM2, COM3, and COM4.  I
    have the following lines in the file used to specify the config
    for the kernel build:

    device        sio0    at isa? port "IO_COM1" tty irq 4 vector siointr
    device        sio1    at isa? port "IO_COM2" tty irq 3 vector siointr
    device        sio2    at isa? port "IO_COM3" tty irq 5 vector siointr
    device        sio3    at isa? port "IO_COM4" tty irq 9 vector siointr

    I also enabled the use of com ports for either call in or call out
    by selecting the bi-directional option.  The following line in the
    config file causes the proper code to be compiled in the driver.

    options       "COM_BIDIR"    #Bidirectional support in sys/isa/sio.c

    2. After building the kernel, I made sure the devices were
    represented in /dev.  MAKEDEV should be used to create the
    tty0[0-3] special devices.  It will result in entries such as
    the following:

       0 crw-------    1 root     wheel     28,   0 Nov  8 06:28 tty00
       0 crw-------    1 root     wheel     28,   1 Nov  8 10:09 tty01
       0 crw-------    1 root     wheel     28,   2 Nov  7 01:13 tty02
       0 crw-------    1 root     wheel     28,   3 Nov  8 03:02 tty03

    Then mknod and chown should be used to create the following four
    entries:

       0 crw-rw-r--    1 uucp     dialer    28, 128 Nov  8 03:45 cua00
       0 crw-rw-r--    1 uucp     dialer    28, 129 Nov  7 18:34 cua01
       0 crw-rw-r--    1 uucp     dialer    28, 130 Nov  7 17:29 cua02
       0 crw-rw-r--    1 uucp     dialer    28, 131 Nov  8 03:15 cua03

    The tty0[0-3] entries are used to receive calls on (with the
    bidirectional code, this is signalled because the most significant
    bit in the minor number is 0).  The cua0[0-3] entries represent the
    same ports as the corresponding tty ports, but with the most
    significant bit of the minor number turned on.  This indicates to
    the driver that this port is a call out port.

    The reason for the ownership being set to uucp:dialer is because
    I have all programs that use dialers (uucico, kermit, tip, etc.)
    set to operate as set-uid with uucp as owner.  Also all of these
    programs are set up as being in group dialer with group dialer
    membership being required to execute them.

    3.  One further step needs to be done to allow proper use of the
    ports.  In rc.local, the last few lines include the following:

        comcontrol /dev/tty00 bidir
        comcontrol /dev/tty01 bidir
        comcontrol /dev/tty02 bidir
        comcontrol /dev/tty03 bidir

    4. Now I set up getty to use the incoming ports with the following
    entries in /etc/ttys:

        tty00    "/usr/libexec/getty std.19200"    unknown    on secure
        tty01    "/usr/libexec/getty std.4800"    unknown    on secure
        tty02    "/usr/libexec/getty std.4800"    unknown    on secure
        tty03    "/usr/libexec/getty std.19200"    unknown    on secure

    5. I set up the port file for uucp, the remote file for tip, and
    the .kermrc file for kermit to refer to the cua0[0-3] devices for
    call out targets.

    6. Note that I have modems on cua/tty 00 and 03.  My modems are set
    up to adjust the baud rate of the call (in or out) by negotiating
    with the other modem in the call.  However the modems always retain
    the same speed (19,200 Kb) for the rs-232 port.  In order to make
    the modems use the proper speed, I have to send them an AT sequence
    at the desired speed.  They will then retain that setting for
    incoming calls.  So, to do this, I include the following at the
    end of my rc.local script:

        /usr/local/bin/initcua00
        /usr/local/bin/initcua03

    and in /usr/local/bin, I have the two scripts like (this is the one
    for initcua00):

    #!/usr/local/bin/kermit
    set modem hayes
    set line /dev/cua00
    set speed 19200 dial XXXXXXX    <----------- it's own number to get busy
    quit


8.3.3    What is the difference between baud and bits per second?

    It's important to remember that we're transmitting symbols. Does
    this apply to digital transmissions ? Yes. A digital message is
    simply an ordered sequence of symbols from a discreet source. This
    source has an alphabet 'M' of 2 or more symbols, and produces
    the symbols at some rate 'r'.

    If we allocate a finite amount time alloted to a symbol, and call
    that time 'D', we can for once and ever define what baud is. Having
    'D', our "signalling rate" is:

        r = 1/D                       (1)

    measured in _symbols_per_second_ or baud. For binary transmissions,
    we have a bit duration Tb, and our "bit rate" is:

        rb = 1/Tb                     (2)

    measured in _bits_per_second_, (bps, or b/s).

    Now we note that in the special binary (M=2) case, each bit is
    a symbol and thus D=Tb, and by (1) and (2) we have:

        r (baud) = rb (bps)           (3)

    or in English, for *binary* transmissions, we have "the signalling
    rate, measured in baud, is the same as the bit rate, which is
    measured in bps."  For all other transmissions, the signalling
    rate (baud) is not equal to the bit rate (bps).

    Regards,

    -Ade "never wants to see this again" Barkah


8.3.4    How do I get a serial console to work?

    This answer provided by Simon Ritter ([e-mail])

    I've seen a couple of posts requesting this info, so here it
    is. Maybe this should be added to the FAQ's.

    Edit the file /etc/conf/pack.d/sysmsg/space.c.  At the bottom
    of this you will find the following lines:

    extern int kdputchar(), kdgetchar();
    extern int asyputchar(), asygetchar();
    extern int asyputchar2(), asygetchar2();

    struct conssw conssw =
    {
            kdputchar,
            0,
        kdgetchar
    };

    Change all occurences of kdputchar and kdgetchar to asycputchar
    and asycgetchar.  Rebuild your kernel and reboot, connecting a
    terminal to the first serial port.  Behold, all messages on the
    serial port.

    (Ed Note...  I don't even know if this exists in NetBSD or
    FreeBSD, but what the heck, it's an answer :-)...  Either way,
    the method for this is pretty much the same, and will require
    some mucking about on the kernel.)


8.4    Disk Controller Problems

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


8.4.1    IDE controller problems

    The code in the original 386BSD had some serious problems
    dealing with the wd controller.  In addition, changes to the
    controller code which have made improvements in other areas of
    the driver have made the wd driver (in 386BSD with the
    patchkit) even less trustworthy.  The wd driver in NetBSD 0.9
    is better but still has to deal with occasional hard drive bus
    hangs.  The wd driver in the -current code is much more
    reliable.  The FreeBSD code is also greatly improved, and
    likewise does not suffer from these bus hangs.

8.4.2    SCSI controller problems

    Every once on a great while, someone will post a problem with a
    SCSI controller.  Almost all of these are attributed to either
    a) bad cables (or out of spec cables), b) bad termination, or
    c) incorrect irq/drq setup.  Here is an excerpt of a message
    that provides some insight into one man's problems with the
    Adaptec controller, and one with the BusLogic 445.


    From: [e-mail] (Robert Withrow)

    Problem: When the bus hangs, all devices have their access
    lights off, the AHA his its light on.

    If anyone cares:

    Being in a hurry, I made several changes and the problem went
    away. Normally, I would change one thing at a time, but, like I
    said, I was in a hurry.  Below, I list the changes I made:

      1) I replaced the AHA with an older one I keep as a spare.

      2) I *inserted* the the ``synchronous negotiation'' jumper in
      the aha.

      3) I removed the terminator power jumper from two of the hard
      drives.

      4) I removed and reinserted all of connectors into all of the
      drives.

    If I had to guess, I bet #2 was the thing that fixed the
    problem. Perhaps this should be a FAQ answer? (Assuming this is
    a requirement)...

    The system has compiled X11 three times as well as done all
    sorts of other things including all of the drives (cdrom, disk,
    and tape) for three days now without a single hang.

     Robert Withrow, Tel: [phone], Fax: [phone]
      R.W. Withrow Associates, 319 Lynnway, Lynn MA 01901 USA
     Net: [e-mail]

    [e-mail] (Willem Jan Withagen) writes:

    =>  =>  The BT kernel requires the controller to be configured
    =>  =>  for IRQ 12.  That is a strange default.  The default for
    =>  =>  the BT445S is 11, the same as for the 1542.  You probably
    =>  =>  just need to reconfigure the controller.
    =>
    =>  So I redid the switches and the BT kernel recognises it on
    =>  int 12.  Either with or without EISA DMA (switch 2-10)
    =>
    =>  it no longer generates the strayintr 7.
    =>  But it still doesn't boot after the message
    =>      'changing root device to fd0d'
    =>
    =>  So what's going on here. Is there anyway to find out more?
    =>  Or should I go to one of the FreeBSD lists and discuss it there?

    I was browsing thru the hardware manual of the BT 445S and there
    it was on the next page :-( I was just misguided by the nice
    switches on the card edge.

    To set the interrupts not only the dip-switches need to be changed.
    More important is the actual and physical connection of intr 12 to
    the ISA bus connector.

    After taking the board out, and really connecting intr 12, the
    system booted the BT kernel without a glitch.  I'm now compiling a
    new kernel with all our options set as we'd like them to be.

    The current config:
        16 Mb
        BT 445S with intr 12 and switch 2-10 in default state,
        giving dma on channel 5.

    Things I'm going to test:
        toggling the 2-10 switch
        adding 16 MB more.


8.5    SCSI Controllers

    The list of "supported" hard drive controllers is very short.
    Basically, it is any hard drive controller that emulates a
    standard IDE/ESDI/MFM controller and a few SCSI controllers.
    The short list is included below:

    These boot with the kcaha floppy:
        Adaptec 1522        ISA    SCSI    Experimental
        AIC-6260 based        ISA    SCSI
        AIC-6360 based        ISA    SCSI
        Adaptec 1540[ABC]    ISA    SCSI    No Floppy
        Adaptec 1542[ABC]    ISA    SCSI
        Adaptec 174x        EISA    SCSI
        Adaptec 294x        ????    SCSI    Not supported
        Ultrastore 14F        ISA    SCSI
        Ultrastore 24F        EISA    SCSI
        Ultrastore 34F        VLB    SCSI
        Buslogic BT542        ISA    SCSI
        Buslogic BT545        ISA    SCSI    (Old ones only)
        Buslogic BT946C        PCI    SCSI
        NCR 53C810 based    PCI    SCSI

    These boot with the kcbt floppy:
        Buslogic BT742A        EISA    SCSI
        Buslogic BT747A        EISA    SCSI    (modified 742 driver)
        Buslogic BT445S        VLB    SCSI

    Note that the Ultrastore 24F is supported with an experimental
    driver or in IDE emulation mode only.  Any controller that
    purports to be a clone of one of the cards listed above will
    usually work as well.

    The Adaptex 294x cards are a particular problem.  They are based
    on the AIC7770 chipset, for which there is an experimental
    driver.  In addition, several people have reported very limited
    success getting the Linux driver top work.  This is a continuing
    project that is being undertaken without the support of Adaptec.

    The 'based' cards above are special in that many controllers use
    these controller chips as the basis for their implementation.
    The AIC-6260 is the chip set in the Adaptec 1522 series
    controllers, and the AIC-6360 is the chipset used in the
    Soundblaster SCSI controller.  There are several PCI controllers
    that are using the NCR chipset.

    In addition, there is a special note for Buslogic card users.

    The card should be configured to use ioaddr 0x330 and IRQ 12.
    There are two places the IRQ needs to be set.  The first is a
    bank of dip switches, and te next is a jumper.  See your hard
    drive controller documentation for the exact settings.

    Once you've got the controller on the right settings.  As it
    says in the README.INSTALL file, after all:

    BT742 SCSI Cntlr.       0x330   12               [kcopy-bt-floppy]

    So I can only conclude that you've probably not configured the
    card for EISA DMA!  From the /usr/src/KNOWNBUGS file:

    /sys/1/isa/bt742a.c
            The Bt445S and Bt747 controllers can cause problems when
        ISA DMA is selected as an option.  With the EISA controller
        the remedy is easy - simply turn it off using your EISA
        configuration utility.  With the Bt445S, which is a VLB
        card, you must switch the undocumented "SW10" on "SB2" to
        the off position.  Also note that certain revisions of the
        Buslogic board (Revision C or earlier, firmware revision
        <3.37) will cause DATA CORRUPTION with systems containing
        more than 16MB of memory.  If you find this to be the case,
        temporarily remove your extra memory and contact Buslogic
        for an upgrade!

    The BT946C PCI card works flawlessly.  The only thing that needs
    to be done to it is to ensure that the the two jumpers that
    control how and if to autoconfig are removed.  This allows the
    system to autoconfigure everything in the card.  The best thing
    to do is simply set the card to use the "Autoconfig to default"
    option.


8.6    Network Cards

    Common misconception number 1: Why does BSD still support such
    a small selection of network cards?

    Depends on what you mean by `small'.  Here is the 'short list'.

    3c501                   isa     if_el           ([e-mail])
    3c503            isa    if_el        (mycroft)
    3C507            isa    if_el        (mycroft)
    3c509              isa    if_ep   bnc/aui/utp.      (tdr)
    3c579            eisa    if_ep          (tdr)
    WD 8390-based cards     isa    if_ed          (mycroft)
    SMC 8390-based cards     isa    if_ed          (mycroft)
    NE1000, NE2000        isa    if_ed          (mycroft)
    NE2100/BICC Isolan/DEPCA isa    if_le          (mycroft)
    AT&T StarLAN (82586-based cards)          (mycroft)

    These are all in NetBSD, and FreeBSD (by inference)

       Common question number 2: I have a 3Com 3c509 - is it supported?

    The 3C509 works well under NetBSD-current, and has been clocked
    at full ethernet speed.  To use the UTP connection, you will need
    to specify the link0 and link1 options in the ifconfig command.

        -link0  disable AUI/UTP. enable BNC.
        link0   disable BNC. enable AUI.
        link1   if the card has a UTP connector, and link0 is
            set too, then you get the UTP port.


8.7    Printers

    In the original 386bsd system, there were problem with the
    interrupt driven parallel printer driver.  These problems were
    solved by the use of a work around called the interruptless
    printer driver (worked on the theory that once it knew how your
    printer reacted to printing it could configure itself to your
    printer).

    This code has also been deprecated through the use of a new
    printer driver in the {Free,Net}BSD systems that use the same
    source code for either 'interrupt' or 'polled' operation.  The
    closest thing to a 'common' question about printers involves
    questions about CR+LF emulation on some laser printers and some
    questions about some of the filters that 'lpd' talks about, but
    do not seem to be avaiable normally.

    The first is easy.  Set up your printer so that it uses the
    'LF' code as its CR+LF (End of line) character.  If you use
    your machine for operations in more than one OS (like some of
    us that HAVE to use DOS :-( ) then you can include a control
    sequence in the 'ff' control in your /etc/printcap file.

    Here is an example printcap to show you how simple it is:

    lp|ljgpc_deskjet|HP DeskJet Plus:            :lp=/dev/lpt0:mx#0:            :sd=/var/spool/ljgpc_deskjet:lf=/var/log/lpd-errs:            :ff=\033E\033&k2G:fo:sh:tr=\033E:






8.8    TAPE Drives

    Editor's note:

    This tapedrive list is maintained by the original authors.  If you
    have additions, corrections, changes, or deletions, please be sure
    to contact the folks listed in the next paragraph.

SCSI news:

[e-mail] writes:
>FreeBSD 1.1 had a rewritten SCSI system.
>
>In fact the method of using the tape modes was almost completely
>rewritten.
>
>If you are a user of tapes, and have had experience with the new method
>(using a control device), please let me know what you think about the
>new system.  I'm particularly interested in hearing from anyone that has
>used the control device from the rc files to set up the system default
>modes for their device on bootup (that's what it was designed for).
>
>if you have used the tapes in 386BSD or freeBSD-1.0
>and didn't notice that they have changed for 1.1,
>then see the man pages st(4) st(1) scsi(1) scsi(4)

and also...

>as for NetBSD..
>they have integrated the new code into the -current tree
>and it will probably be in the next 'release'


*** Administrivia:

If anyone else aspires to the position of "co-editor of the tape FAQ",
please send me mail.  Until then, I'll use the "Royal We" in the tape
FAQ so I don't have to change all the text.  I'd especially like to hear
from people who are using something other than SCSI tape drives, since I
know almost nothing about non-SCSI tapes, and this is reflected in the
FAQ.

The tape FAQ will be sent out bimonthly, rather than monthly.
 - Andrew Jr.
------------------------------------------------------------------------

These tape drives have been reported as working (or not working)
on 386BSD, NetBSD or FreeBSD, either in articles on USENET or in
response to previous postings.  If you know any more details, want
to point out errors, know another tape drive works (or doesn't),
have any suggestions for additions/changes to the FAQ, or anything
else useful, please send your reports to:

          [e-mail] (Andrew Cornwall)

PLEASE HELP TO UPDATE THIS LIST BY PROVIDING COMMENTS AND NEW
INFO.  IN RETURN, WE WILL POST UPDATES AND TRY TO MAKE THE LIST
AVAILABLE TO ANYONE INTERESTED.

IMPORTANT DISCLAIMER:
        This list is not guaranteed to be 100% correct.
        We don't know much about tape drives as yet, so
        we are only collating information provided by others.
        By getting feedback on this list, we hope to improve
        it into an FAQ.

EVEN MORE IMPORTANT THANK-YOU:
        Thanks to everyone who's contributed to this list. Without
        your help, it wouldn't exist!

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

Changes to:
    Archive 2525-S
    Wangtek 5150ES
    Wangtek 5525ES

Additions:
    -none-

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Format of each entry is as follows:
Name:           {name of the device; if you're reporting, please be as
                 specific as possible}
Capacity:       {Maximum size of the device}
Approx Cost:    {Roughly what you paid}
Interface:      {How it talks to the machine - SCSI, PC bus, etc}
Controllers:    {What controller you're using - Adaptec 1542B, etc}
Informant:      {Who says it works}
Comments:       {Anything good or bad you feel like saying}

*** Please state in the Comments field which operating system you
*** are using and which version.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

MANUFACTURER CONTACTS:
        Archive is a Maynard company bought by Conner
                Sales:     [phone]
                Technical: [phone]
        [informant: [e-mail] (KARAGEORGIOU ANGELOS)]

        Tandberg
                Technical? [phone]
        [informant: [e-mail] (Ken Raeburn)]

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

COMPATIBLE TAPE DRIVES:


Name:           Archive ???
Capacity:       60MB
Approx Cost:
Interface:      QIC02/24
Controllers:    Archive SC499
Informant:      stark![e-mail] (Gene Stark)
Comments:       I have been using the wt driver with an SC499
                controller for a few months.  I am sort of happy
                with the driver.  It streams the tape under dump
                and restore, as long as there is not much else
                going on in the system.  I haven't been able to
                get much streaming with tar.  I tried using dd
                with large block sizes and caused at least one
                system crash, so I don't do that at the moment.
                The error recovery of the driver is not very good.
                If you try to read at the wrong density, you have
                to execute a successful rewind or control command
                before you can then read at the correct density.


Name:           Archive 2060
Capacity:       60MB
Approx Cost:    US$200
Interface:      SCSI
Controllers:    Adaptec 1542b, Adaptec 1742a
Informant:      [e-mail]
Comments:       no observed problems when used with julian's drivers.
                works fine with 1542b/1742a


Name:           Archive 2150
Capacity:       250Mb
Approx cost:    US$350-500
Interface:      SCSI
Controllers:    Adaptec 1542b, Adaptec 1742a
Informant:      [e-mail] (Eric J. Haug)
                [e-mail] (me 8-))
                [e-mail]
                [e-mail]
Comments:       works well with both the driver in the distribution
                kernel and julians' SCSI drivers.   [ejh]

                nice device!!!, works like a charm, tar w/ original
                scsi-driver plus variable block length patch, under DOS:
                GTAR, ASPIBIN (ASPI-TAR), PCTOOLS 8.0, COREL-SCSI
                works fine with julian's drivers and 1542b/1742a
                    [admerlev/duncan]
                and with Adaptec 1542C + Julian's SCSI drivers [jfieber]

                S version (SCSI?) runs under FreeBSD:[e-mail]
                2150S also known as Viper 150


Name:           Archive 2150L
Capacity:       150 Mb, 120 Mb
Interface:      QIC-02
Controllers:    Archive Viper SC402
Informant:      [e-mail] (Serge Vakulenko)
Comments:       Works well, with new wt driver (by me and Sergey Ryzhkov).
                Supports 150Mb and 120 Mb formats on write and 150Mb, 120Mb
                and 60Mb formats on read.  It's possible to use mt command
                to rewind the tape, seek file forward etc.

                It's not a problem in the SCSI code. It's a firmware
                bug in (at least) the Archive Viper 150. Data can be
                appended only if the drive is ``totally sure'' that
                the tape is at end of recorded medium. This could be
                achieved by issuing a `space to end of recorded
                medium' command.  Unfortunately, the recent version of
                Julian's SCSI driver doesn't support this.  (Future
                versions might do.)

                As a workaround, it's possible to ``mt fsf'' after the
                last tape file, then issue another ``mt fsf'', which
                will result in an IO error (SCSI blank check, `no data
                found' appears on console), that should be ignored.
                At this point, the tape could be written to!
                 - [e-mail]


Name:           Archive 2525-S (Firmware Rev. 25462-007 - seems to be important [nbladt])
Capacity:       QIC-24, QIC-120, QIC-150, QIC-525
Approx Cost:    ca. 1000,- DM (about US$ 500)
Interface:      SCSI-1
Controllers:    Adaptec 1542B, Adaptec 1542C, Adaptec 1742A, Adaptec 1742B
Informant:      [e-mail] (Norbert Bladt)
                [e-mail] (Hellmuth Michaelis)
                [e-mail] (Bruce J. Keeler)
                [e-mail] (Irving Moy)
                [e-mail] (Roger M. Levasseur)
                [e-mail] (Andreas Klemm)
Comments:       In contrary to what my dealer told me, it can read and WRITE
                QIC-150 tapes. Didn't have a chance to try QIC-120, or QIC-60,
                etc. yet.
                I am using 386bsd-0.1 (still with the first patchkit and
                all updates from Julian for his fabulous SCSI-driver kit)
                Sorry, no experience with the original driver because
                that driver doesn't work with the 1742A. [nbladt]

                Worked with Julian's driver out of the box. [hm]

                Since putting in Julian's drivers, with Dave Tweten's mods,
                it seems to work just fine.  [loodvrij]

                The drive docs specify that it can r/w QIC-120, 150, and 525.
                It can read QIC-24 but not write it.  I have read QIC-24
                tapes with it.  This is with FreeBSD 1.0.2 +
                Adaptec-1542C  [rml]

                A few days ago I couldn't install netbsd-09
                because I couldn't read the distribution from
                tape.  That was the reason for me ro try
                FreeBSD-1.0.2 (which worked)
                Model: VIPER 2525 25462  Rev: -007 [andreas]


Name:           Archive 5945C drive
Capacity:       45MB used with wr0b device on a 450ft tape
Approx Cost:    0 (from a scrapped Apollo 3000)
Interface:      QIC-02
Controllers:    Archive SC400S
Informant:      Jens Tingleff, Imperial College, London SW7 2BT,
                [e-mail]
Comments:       The `wt' driver from FreeBSD-1.0R works just fine. The
                only change to the controller hardware was to rejumper
                the I/O address selection (jumper pad going A9 A8 ..
                A3) to locate the controller at 0x300.

                Reads tapes written on a SUN3 shoebox. Tapes written
                to rwt0b device do *not* read on the SUN. Multiple tar
                archjives (using device nrwt0b) works just fine.
                Doesn't quite stream with tar, and I'm not sure what
                the max speed is, I'm seing 2.5 MB/Min write speed
                using `tar -b 512', I have seen 4MB/Min read when
                using `dd'.

                [The TAR program archived as TAR313US.ZIP at
                garbo.uwasa.fi works fine under DOS with this
                hardware, reading tapes written on both FreeBSD and on
                a SUN3 shoebox]

Name:           ARCHIVE Python 25501 4mm DAT
Capacity:       >1 Gb
Approx Cost:    ~US$1100
Interface:      SCSI 2
Controllers:    Adaptec 1542B, 1742
Informant:      [e-mail]
Comments:       It works great so far, but I haven't figured out how
                to turn on the hardware compression.  Rich

Name:           Cipher Model 540
Capacity:       45M/60M (probably/hopefully)
Approx Cost:    Loaned to me in `vintage appearance' (Much dust) - No idea !
Interface:      SCSI 1
Controllers:    Adaptec 1542B
Informant:      Julian Stacey   <[e-mail]>
Comments:       Shows promise, Cant yet call it truly usefull though:
                The Good Bit:
                        I have seen it stream constantly on 386bsd.
                The Bad Bit:
                        I can't use it as a usefull drive because it keeps
                        dropping out with errors.
                        The fault does not lie in the media, & most probably
                        not with external power supply or scsi cable -
                        I'm working on it.


Name:           CIPHER MicroStreamer F880 (1600bpi, 9 track PERTEC interface)
Capacity:       ???
Approx Cost:    $5000 for the drive in 1985
                $1000 for protocol Converter 1992
Interface:      SCSI
Controllers:    Adaptec AHA-1542A to NCR ADP-53 to tape drive
Informant:      [e-mail] (Mike Hoffman)
Comments:       It is FAST, reads tape about the same speed as rewind.
                The SCSI controller runs the 9 track drive thru the
                converter and an Archive 2060S 60mb Cartridge tape
                drive directly.  After putting in the current
                patches and reading the PERTEC Specs it was almost
                "plug and play".  The ADP-53 is a protocol converter
                from/to SCSI/PERTEC, purchased from Laguna Data
                Systems (see Byte Magazine).

                Problems:
                mt does not seem to be of much use.  Forward spacing
                the 9 track tape is an iffy job (skipping the label
                on a labeled tape).  dd now does this (skip=1).

                I always get the error 'cannot prevent/allow'.  This
                is not a big deal (prevent or allow removal of
                tape).

                dd does not handle cr/lf at all well.  Could be all
                the protocol conversions or gnu dd just doesn't do
                it.  All files are read in as one line(no CR Lf
                etc).  The blocking and conversion options have no
                effect on line length.  Conversion from EBCDIC to
                ASCII works fine.  A small program to break up the
                file solves the long line problem.


Name:           Cipher ST-150F
Capacity:       150Mb
Approx cost:    US$300 (incl. interface)
Interface:      QIC-02
Controllers:    Cipher
Informant:      [e-mail] (YOSHIDA Hideki)
Comments:       works well with blocksize <= 4b


Name:           Cipher ST150-S
Capacity:       QIC-24(read only), QIC-120, QIC-150
Approx Cost:    1300,- DM (long ago ..)
Interface:      SCSI (better SCSI-I or CCS)
Controllers:    Adaptec 1542B, 1742
Informant:      Hellmuth Michaelis ([e-mail])
Comments:       This drive responds with empty strings if asked for
                for it's vendors name and model.
                It has a strange format of the mode sense/set command
                blocks.
                By default, it reports a soft error back to the host
                which makes it a bit hard to work with.
                Problems solved with next release of Julian Elischer's
                enhanced SCSI driver (currently beta, July '93).
                [e-mail] reports an upgrade
                which involves a new ROM and cutting some traces.
                The drive responds: CIPHER : Model ST150S2 Rev: 2.0
                ANSI SCSI rev: 01 when asked for it's vendors names
                and model.

Name:           COMTEK Gigatape 1200 4mm external DAT
Capacity:       1.2 Gb
Approx Cost:    US$800
Interface:      SCSI 1
Controllers:    Adaptec 1542B
Informant:      [e-mail] (Rich Murphey)
Comments:       You can remove the COMTEK drive because I gave up on it:
                the vendor offered to upgrade me to a different drive,
                the Archive Python 25501 4mm DAT.

Name:           Conner C250MQT
Capacity:       250 MB compressed, 125 not
Approx Cost:    approx $200
Interface:      Uses floppy disk controller on PC.
Controller:     ?
Informant:      [e-mail] (Tom Weldon)
Comments:       Maybe it works, but i couldnt get it to talk to 386BSD
                with GENERICISA kernel.


Name:           DEC TZ30
Capacity:       96 MB (uses 3M CompacTape cartridges)
Approx cost:
Interface:      SCSI
Controllers:    Adaptec 154xB
Informant:      [e-mail] (David Burren) May 1993
Comments:       Works with Julian's SCSI drivers.  Console reports "cannot
                prevent/allow" but this is not a problem.
                This is the native-SCSI half-height version of DEC's
                TK50Z drive.


Name:           DEC TZ857
Capacity:       18.2 GB (stacker unit with seven 2.6 GB CompacTape
                    III tapes)
Approx cost:    lots
Interface:      SCSI
Controllers:    Adaptec 154xB
Informant:      [e-mail] (David Burren) May 1993
Comments:       Works with Julian's SCSI drivers.  As with the TZ30,
                "cannot prevent/allow" is reported but operation
                continues.
                As 386bsd has no "mt online" yet, cartridge loading is
                done manually, but unloading/advancing is done through
                "mt offline" as under Ultrix.
                I don't really use this drive, but I had access to it
                for a day and tried it out...


Name:           Exabyte 8200 8mm
Capacity:       2.2 GB
Approx cost:
Interface:      SCSI
Controllers:    Adaptec 154xB
Informant:      [e-mail] (David Burren) May 1993
                [e-mail] (Todd Pfaff) Nov 1993
Comments:       Works perfectly with Julian's SCSI drivers.
                I use it all the time for my system dumps and for
                exchanging files with other machines.
                Works  great with FreeBSD-1.0-RELEASE although
                'mt -status' doesn't work properly.



Name:           Hewlett-Packard HP35480A DAT drive
Capacity:       4 GB
Approx Cost:    $1400
Interface:      SCSI
Controllers:    Adaptec 1542B
Informant:      [e-mail]
Comments:       Great drive, flawless performance.  Requires
                variable length tapedrive patches which should be
                in the patchkit, but I haven't checked.  (They were
                submitted around November of '92)



Name:           Sankyo ST525
Capacity:       525 Mbyte
Approx Cost:    6000 SEK (US$850), NZ$1400 (internal, Jan94)
Interface:      SCSI (SCSI-2)
Controllers:    Adaptec 1542B
Informant:      [e-mail] (Jonas Lagerblad)
                [e-mail] (Nick Gridley)
Comments:       everything works allright except for one crash
                The SCSI bus seemed hang after running
                "dump 0uf - /dev/rsd0a | gzip --best |
                    dd of=/dev/rst0 bs=64k"
                for approx 1 hour. If I skip the compression
                everything works perfectly. (I am using Julian's
                SCSI driver) 386BSD-0.1 patchkit 0.2 patches 0-110.  [jonas]

                I have no problems with this drive and FreeBSD
                (GAMMA,EPSILON,1.0) I have a BusTek 542B controller but
                no other SCSI devices (yet..).  Further, I mix 150 &
                525 tapes, and read the occasional 60m.  [nickg]





Name:           Sony SDT-1000 DAT
Capacity:       2 GB  on a 90 meter tape
Approx. Cost:   about $600 now, $3500 when purchased 3 yrs ago
Interface:      SCSI  (SCSI-2 also)
Controllers:    Adaptec 1542B
Informant:      [e-mail]
Comments:       I have used it under 386BSD 0.1 and NetBSD 0.8.
                Under 386BSD, it didn't support all of the ioctl functions,
                but works without a hitch under NetBSD. I use it to do tar
                data backups and restores as well as interchanging data
                with an H-P 9000/755 using the HPUX tar command.


Name:           Tandberg 3600 series
Capacity:
Approx cost:
Interface:
Controllers:
Informant:      [e-mail] (Lars Fredriksen),
                [e-mail] (Ken Raeburn)
Comments:       Tandberg SCSI driver work has been pulled into Julian's
                SCSI driver.
                So far I have not had any problems reading 30/60/150/250 Mb
                tapes, similarly no problems writing 150/250 Mb
                tapes.[fredriks]

                People can get firmware changes from Tandberg for the 3600
                and later drives which will make the drive act much like an
                Archive Viper 150MB drive (including identifying itself as
                such).  This is what Tandberg does for people who want to
                use the drives with Sun workstations.

                With this replacement firmware, I was able to read and write
                tapes just fine with mostly stock NetBSD 0.9 (no
                scsi-related changes) and Linux, with an Adaptec 1542B
                controller.

                Paul Rinaldi at Tandberg's east-coast office told me that
                people wanting to get this done should contact Bob Russell
                their factory at 805-495-8384 and ask for part # 966039,
                firmware revision B07:43.  The cost is about $40.  They
                recommend you send in your drive to get the replacement done
                by the factory, but you can probably get them to send you
                the replacement firmware, if you're into hacking hardware.

> As I understood it, this firmware is intended for later-model tape
> drives than the 3600, but Paul and I tried it, and I've had no
> problems yet.



Name:           Tandberg 3660
Capacity:       250Mb
Approx cost:
Interface:
Controllers:
Informant:      Per Anders Olausson <[e-mail]>
                [e-mail](Thomas Meidinger)
Comments:       DC6250, DC6150 (not tested) and DC600A.
                Reads and writes DC-6120 as well. [pao]


Name:           Tandberg TDC-3800 5.25" SCSI-1 325MB TBU
Capacity:       up to 520Mb (depending on media) uncompressed
Approx cost:    Didn't buy it new.
Interface:      SCSI-1
Controllers:    AHA1542B
Informant:      [e-mail] (VaX#n8)
Comments:       Would not work with base 386bsd-0.1 kernel.
                After applying patch kit, everything worked fine.
                Only tested reads on 250MB, reads and writes on 325MB,
                and reads and writes on 525MB.  Works great.
                Also fine under NetBSD-0.9. Even got "aspitar" from
                wuarchive to read tars from DOS. Don't mix 525 and 325MB
                tapes though, causes heads to wear out fast. Coexists with
                SCSI-2 drives just fine. Wouldn't trade it for anything but a
                SCSI DAT or 8mm.Even then, I would have to think about it.


Name:           Tandberg 3820 5 1/4" HH internal QIC 525 SCSI streamer
Capacity:       up to 520Mb (depending on media) uncompressed
Approx cost:    (I bought mine two years ago--it wasn't cheap :-)
Interface:      SCSI-1/2
Controllers:    AHA1542B, 1742A, DTC3290
Informant:      [e-mail] (Thomas M. Hoberg)
                [e-mail] (Julian Stacey)
                [e-mail] (Thomas Bagli)
Comments:       Works well with both the driver in the distribution kernel
                and julians' SCSI drivers. Reads all QIC media (tested
                QIC 40/60/120/150/525) Writes QIC 120/150/250/320/525
                (120/150/525 tested) Includes a 256k buffer. 2 rw
                speeds: 83k/s for QIC<320, 200k/sec for 320+
                Occasionally the file system can't keep up at
                200k/sec on backups (small files), somewhat more often
                on restores. The drive can directly seek to any block
                on the tape, so in theory at least with the
                appropriate device drive you could mount a file system
                on it (you better keep fragmentation low :-) As you
                can guess, I am EXTREMELY happy with it.
                [tmh]

                The Good Bit:
                It streams constantly without error (~40mins for 525M
                write @ 60K blocking).  Tape drive shares bus with 3
                SCSI-2 Seagate drives also OK with a SCSI-1 Micropolis 1684-7.
                The Bad Bit:
                We (several us of using these TDC3820s on different hardware)
                have undergone an eerom + eprom autodensity upgrade to allow
                150M writes (previously could only read 150M tapes +r&w 525M);
                this known as Revision 04908, Done 92 08 28.
                There is some kind of block size problem that prevents
                us reliably exchanging 525M tapes, 150M seems OK,
                problem is tape hardware oriented I believe,
                not 386BSD specific.
                Problem pre-existed the 150M write capability upgrade.
                A friend with same 386bsd + TDC3820 + 1542A can't read my tapes,
                neither can a PCS (M68000 based) computer with a TDC3820
                [stacey]

                We paid DM1000 (~$625) in early 1991.  This was a very
                special price, and I estimate that the actual cost would be
                (very) approximately 50% more (~$950).
                I've used it with an Adaptec 1742A, a DTC3290 (caching 1542B
                emulation), and a Mylex ?376? (caching, but only under DOS)
                SCSI controllers.  It doesn't just stream, it screams.  I've
                never seen a streamer that just streams without a pause,
                rewind or such.  This one does (not to say that the Tandberg
                is the sole reason for this).
                [tomb]


Name:           WangDAT 3200
Capacity:       2Gb (up to 8Gb w/compression) on a 90 meter tape
Approx cost:    US$1200-$1300 approx
Interface:      SCSI
Controllers:
Informant:      [e-mail] (J.T. Conklin)
                [e-mail]
Comments:       Works great with Julian's SCSI drivers and an Adaptec 1742...
                (I use it to do my dumps, and I've actually checked and made
                sure the restores work...  8-) [cgd]


Name:           Wangtek 5099EK
Capacity:       60M
Approx cost:
Interface:      PC/QIC-36
Controllers:
Informant:      [e-mail] (Robert Schien)
Comments:       The wt.c driver, which is delivered with FreeBSD-EPSILON,
                does not work with my Wangtek 5099EK (60 MB) tape drive.
                This drive has a PC/QIC-36 interface and it worked fine with
                ESIX 5.3.2D (For testing I tried SCO Xenix and ISC 2.2.1 and
                it worked with these OSs, too).  With the driver in
                386bsd-0.1, I could read tapes, but not write.  With the
                "improved" driver, I could neither read nor write (all minor
                devices tried). The solution was a driver from someone in
                Sweden (his name is Mikael Hybsch (sp?)), which worked for
                me already with 386bsd-0.1.



Name:           Wangtek 5099EN
Capacity:
Approx cost:
Interface:
Controllers:
Informant:      Original 386bsd.FAQ
Comments:


Name:           Wangtek 5099SC24, this is a QIC drive (same mechanical drive
                as 5099EN24) with a QIC24 to SCSI board by wangtek full height
Capacity:       60Mb w/DC600A, 100Mb w/DC6250
Approx cost:    Used as is drives US$25.00/each, refurbs ~US$100.00
Interface:      SCSI
Controllers:    Adaptec 1542B
Informant:      [e-mail]
Comments:       works well with both the driver in the distribution
                kernel and julians' SCSI drivers.  Very old full height
                driver readily availiable in the surplus market.  I know
                where there are 50 or so of these for $25.00/each as is,
                they are pulls from old workstations.


Name:           Wangtek 5150EQ
Capacity:       250MB (QIC-150)
Approx cost:    400 UK pounds including software for DOS
Interface:      QIC-02
Controllers:    Wangtek QIC-02 included
Informant:      [e-mail] (K J Dryllerakis)
Comments:       Works with stock driver. Very very slow but reliable. Funny,
                it only seems to work if you use /dev/wt0 instead of /dev/rwt0.
                New driver in beta version by [e-mail] (Mikael Hybsch).



Name:           Wangtek 5150ES
Capacity:       250Mb
Approx cost:    $500 in Germany
Interface:      SCSI-1
Controllers:    Adaptec 1542B, Adaptec 1542CF
Informant:      [e-mail] (Stefan Behrens)
                [e-mail] (Don)
Comments:       [With original 0.1 SCSI ...] it streams constantly
                and works without any errors.  Works with original
                as.c driver and with newer drivers from Julian
                [eg in patchkit 0.2.4].  [berry]

                Does not work with the 1742a and 386bsd!!!!!
                SCSI driver compatibility problems.  [duncan, ~Jun'93]
                NOTE: with the latest patchkit Stefan Behrens [berry]
                has reported that Julian's SCSI now works with it.
                No update yet on 1742A behaviour.

                works without any problems on any version of FreeBSD
                with the Adaptec 1542B and the 1542CF (the CF requires
                an up to date version of the SCSI driver). Used to work
                on 386bsd with newer drivers from Julian. I've also used
                the drive with Linux, Solaris2.1/x86 and DOS (Adaptecs
                ASPI and GNU tar) with success. [berry]


Name:           Wangtek 5525ES
Capacity:       525M
Approx cost:    US$600, CDN$1000
Interface:      Adaptec 1542B, Adaptec 1742
Controllers:    SCSI-1
Informant:      [e-mail] (Brian Yasaki)
                [e-mail] (Andrew Cornwall)
                Jeffrey Lang <[e-mail]>
Comments:       Writes QIC120, 150, 250, 525. Reads QIC24 as well
                (untested). Works with the distribution kernel.
                [e-mail] reports problems with the "REV1"
                drive.

                In theory a jumper on JP2 will select SCSI-2 instead
                of SCSI-1, but I stuck a jumper there and still boot
                up as SCSI-1 on NetBSD 0.9 [andrew]


Name:           Wangtek 6200-HS
Capacity:       2GB
Approx cost:    $600 (refurbished)
Interface:      SCSI (SCSI II if controller supports)
Controllers:    Adaptec 154x, 1742, ...
Informant:      [e-mail] (Brian Smith)
Comments:       Averages 150 KBytes/sec throughput uncompressed, tested
                with FreeBSD 1.02 and Adaptec 1542B.


Name:           Wangtek QT60 (aka Tecmar QT60)
Capacity:       60M
Approx cost:
Interface:      QIC 02
Informant:      [e-mail] (Tim Combs)
Comments:       It works although does not stream under 386BSD 0.1

END OF COMPATIBLE TAPE DRIVE LIST

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-





8.9    QIC-40/80 tape drives

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

    I have been playing with Steve's patches for FreeBSD to get
    them hooked into NetBSD for the past year.  The best I
    have ever been able to get is a kernel that doesn't recognize
    any of my floppy drives.


8.10    CD-ROMs

    The Sony Multispin drives work well for Charles Hannum using NetBSD
    and an SCSI controller.

    The Sony CDU 561 works well, as do the Toshiba 401 and 4101.  The
    4101 is a double speed SCSI-2 device and allows 'grabbing' of
    music tracks.

    Many folks have announced that they had problems with Mitsumi
    CD-ROM drives.  It seems that there are nearly as many releases
    of the firmware as there were drives sold.  Many of the firmware
    versions were incompatible with each other.  A generic Mitsumi
    driver will be a hard act to accomplish, if it is possible at all.

    There are Mitsumi CD-ROM drivers for NetBSD and FreeBSD.  They are
    available in the -current source tree of each, and should be
    available in the next general release of both systems.  If your
    CD-ROM is not recognized by the kernel, and uses a Mitsumi
    controller, you will need to make changes to the mcd.c source
    file to change the behaviour of the first getreply() function.
    Instead of exitting immediately, the check for whether the
    getreply was successful should be commented out and assumed to
    be correct.  While this is a brute force method (it may find a
    CD-ROM that isn't even there) it will help many Mitsumi
    controllers probe correctly.  The brute force method is
    included below:

    The answer is to replace the probe code which was broken with
    an old version.  The old version will detect mcd0 even if it
    isn't there :-) Doesn't matter!  Warren Toomey ([e-mail])

    int mcd_probe(struct isa_device *dev)
    {
            int port = dev->id_iobase;
            int unit = dev->id_unit;
            int st;

            mcd_data[unit].flags = MCDPROBING;

    #ifdef NOTDEF

            mcd_data[unit].config = irqs[dev->id_irq]
                       ;
    #else
            mcd_data[unit].config = 0;
    #endif


            outb(port+mcd_reset, MCD_CMDRESET);
            mcd_delay(300000);


            st = mcd_getstat(unit,1);
            mcd_data[unit].flags = 0;

            return (st<0) ? 0 : 4;
    }


--
TSgt Dave Burgess           | Dave Burgess
NCOIC, USSTRATCOM/J6844     | *BSD FAQ Maintainer
Offutt AFB, NE              | [e-mail]

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

Section 9    ("Supported" Software List).

#9.1    Software known to run under 386BSD
#9.2    List whether patches are needed
#9.3    List version/release of program
#9.4    List who is supporting it if anyone
#9.5    List where you can get it

9.0    What GNU software has been tested and is working with Net/2 derived
    BSD systems for the 386?

    Just about all of it.


9.1    Has anyone ever gotten news to work?


    news running on 386bsd.  Here is a quick summary of the major
    places to stumble:

    1)  get bash, gmake, gcc 2.X, cnews, trn (or your favorite reader).

    2)  Make uucp work. (Read the info files that come with the
        original distribution for the whole scoop on configuration
        files.)

    Ed Note:  This step is not needed if you are imeplementing SLIP or
    are directly connected to a network.

    3)  Edit all the scripts which come with cnews and replace every
    occurence of /bin/sh with /usr/local/bin/bash (or wherever you put
    it).

    4)  Build cnews using bash, gmake and gcc 2.x

    5)  Install cnews in the directories you want it.  Some hand-hacking
    of the intall scripts is required (Too long ago to remember the
    details).

    6)  Change the permissions on all the scripts from execute only to
    read-execute for group and other.  (On 386bsd, if you can't read
    a script, you can't execute it).

    7)  Set up uucp to accept news

    8)  Post an article and steal it out of the uucp queue before it
    gets sent.  Feed it to your rnews (as user uucp) instead and make
    sure that it does not bomb out with permission denied or some such.

    9)  Have fun!

    Implementing innd is even easier.  The configure script that comes
    with the system has been modified to work more correctly with
    Net/2 derived BSD systems.  There are rumors of  problems with
    'lint', but these are easiest to find if you just run the configure
    script and let the system find the errors.  This patch file gives
    an example of the types of changes that need to be made.

    Ed Note:  This patch is reversed.  The first block in each
    section is the way your Makefile should look.

*** /usr/src/local/innd-1.4-dist/Makefile    Mon Jun 14 11:01:35 1993
--- /usr/src/local/innd-1.4-dist/Makefile.orig    Mon Jun 14 10:54:25 1993
***************
*** 35,46 ****
      $(SHELL) ./makedirs.sh

  ##  Other generic targets.
! depend tags ctags profiled:
      @$(MAKE) $(FLAGS) WHAT_TO_MAKE=$@ common

  clean:
      @$(MAKE) $(FLAGS) WHAT_TO_MAKE=$@ common
!     rm -f libinn.a libinn_p.a FILELIST

  ##  Common target.
  common:
--- 35,46 ----
      $(SHELL) ./makedirs.sh

  ##  Other generic targets.
! lint depend tags ctags profiled:
      @$(MAKE) $(FLAGS) WHAT_TO_MAKE=$@ common

  clean:
      @$(MAKE) $(FLAGS) WHAT_TO_MAKE=$@ common
!     rm -f libinn.a libinn_p.a llib-linn.ln FILELIST

  ##  Common target.
  common:
***************
*** 87,96 ****
      -cd syslog; $(CC) -o syslogd syslogd.c ; cd ..
      @echo "Install syslogd and syslog.conf as appropriate"

! ##  Configure, compile.
  world:        Install.ms
      cd config ; $(MAKE) $(FLAGS) subst quiet ; cd ..
      cd lib ; $(MAKE) $(FLAGS) install ; cd ..

  ##  Make a distribution.
  shar:
--- 87,99 ----
      -cd syslog; $(CC) -o syslogd syslogd.c ; cd ..
      @echo "Install syslogd and syslog.conf as appropriate"

! ##  Configure, compile, and lint.
  world:        Install.ms
      cd config ; $(MAKE) $(FLAGS) subst quiet ; cd ..
+     cd lib ; $(MAKE) $(FLAGS) lint ; cd ..
+     cat lib/lint
      cd lib ; $(MAKE) $(FLAGS) install ; cd ..
+     $(MAKE) $(FLAGS) lint

  ##  Make a distribution.
  shar:

  Simple as that :-)


9.2    How did you get emacs to compile?

    The problem is in the dump-emacs function.  It writes the image
    header and then the text section of the image overwrites the
    header.  This leaves you with a bad image.  If you try to load it
    into gdb, it will tell you that it is not an executable.

    What to do?

    Look back at your configuration command:

    >% configure i386-intel-386bsd --with-x=no

    The 386bsd qualifier means that the compiles will include the file
    src/s/386bsd.h.  If you go into this file and add the lines:

    #define A_TEXT_OFFSET(x)  (sizeof (struct exec))
    #define A_TEXT_SEEK(hdr) (N_TXTOFF(hdr) + A_TEXT_OFFSET(hdr))

    This tells the subroutines in src/unexec.c about the 32 byte image
    header, so that they will set up the header appropriately and not step
    on it while writing the emacs executable.

    The second problem is that emacs tries use its own crt0.o file.
    Kill that line in the Makefile and you should be able to compile
    for either static or shared library operations.

9.2    Has anyone tried to get Postgres to work?

    Jim Bachesta and his crew have gotten Postgres 4.2 working in
    the i386 version of NetBSD 1.0.  The netbsd source tree is
    available from:

    ftp://charon.amdahl.com:pub/agc/postgres-4.2-src-netbsd-v2.tar.gz

    The regular postgres distribution is available from:

    ftp://s2k-ftp.cs.berkeley.edu:pub/postgres

    Get the standard distribution and then overlay the NetBSD source
    distribution over it for a complete system.

--
TSgt Dave Burgess           | Dave Burgess
NCOIC, USSTRATCOM/J6844     | *BSD FAQ Maintainer
Offutt AFB, NE              | [e-mail]