NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 6 of 10)

NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 6 of 10)

Post by Dale Bat » Fri, 14 Jun 1996 04:00:00

'Dave Burgess wrote:

> Posted-By: auto-faq
> 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 ( a message
>         detailing the package (possibly include a README), where it
>         can be found, and what version of the OS (ie. NetBSD or
>         FreeBSD) it was designed to run under.

> 5.1     Available Kernel Replacements

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

> 5.2     Floppy Disk problems.

> 5.2.1   How do I get a bootable floppy?

>         Several ways, ranging from brain-dead-but-works to simplest.
>         Classification into categories is left to the reader (is there
>         really a difference between 'brain-dead' and 'simple'?:')

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

>                 rm -rf .

>            you now have a bootable floppy!;^}

>         2) Take your existing dist.fs or fixit.fs boot disk and
>            diskcopy it on a DOS machine.  Mount and rm as in 1)
>            above.  Again, you have a bootable floppy!;^}

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

>                 disklabel -w -r fd0a floppy5

>            where 'floppy5' is a 'name' for an entry in the /etc/disktab
>            file.  You'll get a couple of ioctl errors because writing a
>            label to a floppy isn't supported (yet?), but the boot blocks
>            have indeed been written.

>         4) Write the boot blocks to the floppy:

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

>            or, more simply:

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

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

>         newfs /dev/rfd0a floppy5

>         If you have a floppy that was originally bootable, but the boot
>         blocks were somehow damaged, you can use method 3) or 4) to
>         restore boot-ability (do _NOT_ run newfs).  You _could_, through
>         the convolutions of copying a floppy whose boot blocks are damaged
>         to a temporary location and then re-copying to a bootable floppy,
>         use method 1) or 2) (if you really want to!;^})

>         5)  If the disk is already newfs'ed and is otherwise ready to use,
>         disklabel will write the boot blocks on the disk.  Read the man page
>         for disklabel.

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

>         As you all know, when you are working with a floppy, it is usually
>         more important that the floppy have a lot of room, rather than a
>         lot of other 'stuff'.  Here is the magic incantation that will
>         maximize the amount of free space on the disk.

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

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

> 5.3     Character Device Driver info

>         These devices are also often referred to as character devices.

> 5.3.1   Printers

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

>         It is possible to connect a serial printer to either.  This brief
>         tutorial is provided by Daryl Berryhill
>         (

>         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
>         isn't anything 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 use an output
>         filter instead of the rm/rp approach (more efficent), you can get
>         away with something like:

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

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

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

> 5.3.2   Terminals/Keyboards

>         Terminals are relatively simple to add.  It involves making sure the
>         /etc/ttys file identifies the com port (com0, com00, or tty00
>         depending on your configuration) as an active port and a getty is
>         running.  The man page for ttys and getty help explain this.

>         Many people report that there are sometimes problems running some
>         programs on a remote terminal.  There are some known bugs in the
>         terminal handler where the parity and bits per character are
>         concerned.  They are being worked on.

> 5.3.3   Modems/FAX Modems

> How do I add a modem to *BSD:

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

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

> Adding a modem to NetBSD.

> Adding a modem to FreeBSD.

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

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

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

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

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

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

>         I use the non modem control device; however, it's nonstandard
>         hardware and I've modified the driver to always return sighup
>         on lost carrier to solve some sticky problems with non modem
>         control devices never getting SIGHUP's.

>         Basically, I just did as the directions said to do. I ran
>         'faxaddmodem' script to configure the type of modem. I did
>         have to simplify some lines in the script (the ones executed
>         in a subshell) since I think my version of bash doesn't handle
>         subshells correctly.

>         RTFM and you should be OK unless your modem is braindead and
>         stupid, not too unlikely tho given the current state of Fax
>         modems... B^(.

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

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

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

> 5.4     Tape Drives

>         This section should help out for those of you that have either
>         never used tape drives before, or only have experience with them
>         as non-Unix devices.

> 5.4.1   Does the tape need to be formatted?

>         It depends, but I think usually not.  And when it is necessary,
>         I don't know how it would be done.  One thing is for certain,
>         though, first....  NEVER use the block devices..  erase them and
>         forget you ever saw them.  All operations on tape should be to
>         the character device (rst0).

> 5.4.2   If I execute the command 'st -f /dev/st0 status', I get:
>                 Archive/Tandberg? tape drive, residual=0, blocksize=512
>                 Density: high = 16 (0x10), medium = 15 (0xf), low = 5 (0x5)
>                 ds=0
>                 er=0

>         so to write to tape at high-density (QIC-150), presumably I want
>         to use a device with minor number +4 (in st.c, density is computed as
>         minor >> 2 & 0x03, where low density == 3 and high == 1):

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

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

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

> 5.4.3   When is erst0 used?

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

>         There is actually a method to this whole thing:

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

> 5.4.4   How is density (bpi) computed?  I am using 3M DC 6250 cassettes
>         which have a 250MB capacity on the Viper 150.  But computing the
>         bits/inch based on 250MB/tape-length (1020 ft.), I get a density
>         of 171335 bpi, which is nowhere near the 10000 bpi associated
>         with QIC-150 in the st(1) man page.  Why the discrepancy?

>         These cartridge tapes are written in narrow tracks which
>         alternately begin at opposite ends of the tape.  Track 0 starts
>         at the beginning of the tape, and Track 1 starts at the other
>         end, etc.

>         So, how many times does the tape go backwards and forwards?  If
>         there are 17 tracks, your density is 170000 bpi if it is 10000
>         bpi per track.  The more tracks, the lower the bpi/track.

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

>         QIC 150 and below should stick to 512 byte blocks a write of
>         1024 bytes from the program will be written as 2 512 byte blocks
>         with no speed penalty.  dd will think it's writing a 1024 byte
>         block but on tape it's 2 x 512.

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

> 5.4.6   From the 4.3BSD mtio(4) man page, it sounds like data is typically
>         (traditionally?) stored on tape in eof-terminated sequences of
>         1K records.

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

> What about a "record"?

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

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

> 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

> 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.
>         Remember, once you build the new kernel, you will need to
>         install it in the root directory and reboot.

>         Once you have the forwarding option set, you will need to make
>         certain that you have not included the '-q' option to routed.
>         This should be in the routed_flags keyword in /etc/netstart.  If
>         you are using multiple internal LANs, you may also want to
>         invest in gated instead.

>         For those folks that are not using routed, you will need to make
>         certain that you have a static route to your network provider
>         established.

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

>                 trceroute -s YOUR_ETHERNET_ADDRESS

>         Check to see where your packets are hanging up.  It might be
>         that someone upstream from you has something broken instead of
>         simply assuming it is your fault.

> 5.5.2   I recently 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.

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

>         One of the things that "just work" are ZIP drives.  The -current
>         code for both FreeBSD and NetBSD handle ZIP drives very cleanly.
>         One of the unusual things about ZIP drives is that most people
>         don't know (and the man page is deliberately vague about) is
>         once a pers