In the beginning, there was Research Unix. Bell Labs, in a moment of utter abandon said "Let us produce progeny of Unix. yea verily, that we might garner a market share with this white elephant." In order to beget as many pretenders to the Unix throne as possible, they removed most of the copyright notices and released huge gobbets of code to Universities throughout the United States. From that humble decision came the very spark of what has arguably become the most successful, completely free Unix-style operating system you can make money on.

There were several version of BSD roaming around, but they all had one thing in common. You HAD to have a source code license to the original Unix source to get a working version going. The bulk of the code was written at Berkeley, much of it by long-haired computer geeks, complete with bad complexions and pocket protectors. Many Master's Degrees were built on what was to follow.

Then, suddenly, someone realized the amount of source code from the original Unix distribution was pretty much down to zilch. They decided that making the distribution available to the whole world (not just the select Unix license holders) seemed like a pretty 'groovy' (to use the vernacular) idea. From that came the Net distribution.

William and Lynne Jolitz, with their standard flair and panache, decided to write the pieces that needed to be written. From that decision came 386BSD Version 0.0. Generally considered to be unusable, it was nonetheless a major coup, in that one no longer needed the dreaded 'source license' to produce working operating system images. Version 0.1 (generally considered to be the progenitor of all of the subsequent PC BSD systems) was released on Bastille Day, 1992.

386BSD 0.1 eventually came to be. Linux, the other entrant in the Free Unix-style OS family, had been running for about a year by then. Many people, wanting to stick with code that they already knew and which was in use in the commercial sector, decided to start using (and fixing) the 386BSD 0.1 code. As such, many contributions to the system are provided through interaction by people who communicate via many means. Many new and innovative features have been added to 386BSD since it's original release in July of '92. There was an 'unofficial' patchkit which was available from many anonymous FTP sources which made 386BSD more stable and usable. Many problems associated with the use of 386BSD Version 0.1 were solved through the application of patches from the patchkit. Now, more or less overcome by events, the original 386BSD, with its relationship to the AT&T/Berkeley out-of-court settlement, has become a rare piece of code to find. With some of the code considered 'suspect', it was removed from FTP sites world-wide.

To replace the original 386BSD, three newer versions of the system are available, under new names. NetBSD is the oldest, FreeBSD followed shortly thereafter. Both systems have evolved into programs that are superior to their progenitor and both have sizable (if a little rabid) followings. The third entry in the group is a fairly recent entrant, called OpenBSD.

Most of the statements made in this FAQ will apply to all three of the replacement systems, although I will try to differentiate one from another whenever the difference matters. Any place that says 386bsd either means the original 386bsd 0.1 or any of the members of the PC BSD family.

There have been many attempts to polarize the *BSD development groups in the past. One of the reasons that I am still maintaining the FAQ is that it simply is a good source for historical information, as well as a reasonable source for information that is specific to the implementations of NetBSD, FreeBSD, and OpenBSD.

It should be remembered that when the *BSD family started out, Bill and Lynne used a source called the "Berkeley Net Release/2" tape as their foundation. While this provided a stable starting point, it also built a possible bomb into the system. Due to a legal battle (which has now been resolved) the following files are identified as 'encumbered' in the BNR/2 source tree. These kernel files are identified as the 'binary only' files in the BSDI distribution, and either have been or must be replaced before we can have a truly free OS family. These files are the primary reason you won't find the original 386BSD Version 0.1 available for FTP anymore.

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

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

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

This FAQ consists of several parts:

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

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

From time to time, a thread in both the comp.os.386bsd.misc and comp.os.linux.misc groups flares up regarding which operating system is "better", FreeBSD or Linux. This generally provokes controversy from users on both sides, with one group claiming that their OS is "better" for some reason and the other group claiming that the first group doesn't know what the heck it's talking about.

Both arguments are a waste of time.

Rather than trying to win a rather questionable debate on relative (and constantly changing) technical merits, we should be asking ourselves what both groups are REALLY about and what they represent. This is naturally going to be a matter of personal opinion, but I believe even the most seriously at-odds members would agree that both operating systems represent a unique and long-awaited opportunity: The ability to run a fully featured operating system on popular, easily affordable hardware and for which all source code is freely available. Those who have been in computing for awhile will remember when the term `operating system' referred almost exclusively to something provided solely by the hardware vendor, with very little in the way of alternative options. It was never EVER given out with source code, and true "wizard" status could only be achieved by exerting mind-numbing amounts of effort and patience in digging through forbidden bits of binary data. By comparison, the situation today seems almost too good to be true! Certainly, the feeling of achievement that came from finally ferreting out some esoteric bit of information from a 4MB printed system dump was high, but I don't think that anyone would argue that it was hardly the most optimal way of truly getting to know your operating system! :-)

So now, within a very short space of time, we're almost spoiled for choice in having machines several times more powerful than the first multi-user VAX machines and available for under $2000, and we've got not one but SEVERAL perfectly reasonable free operating systems to chose from. We are in a comparative paradise, and what are some of us doing? *Complaining* about it! I suppose too much is never enough, eh? :-)

So, my essential point is simply this: For the first time ever we have what previous computing generations could only dream about; powerful computers at a reasonable prices and a wonderful selection of things to run on them. Be happy, read the source code you're so privileged to now have available (*believe* me! What I wouldn't have given, even 5 years ago!) and spend your energy in making constructive use of it, not in arguing with the guys on the other side of the fence!

Additionally, it should be said that none of the FreeBSD team has anything but the highest degree of respect for Linus Torvalds and his "team" of dedicated volunteers (and we occasionaly exchange gripe mail about the huge volume of messages each of us gets as a direct result of being insane enough to volunteer to do something like this :-). Our common commitment to the Intel platform also gives us more common ground (and interests) than one might think and, if anything, it's a pity that we do not endeavor to share more code and effort - ideologically, at least, I'd say we share pretty similar goals.

As to which is "best", I have only one standard reply: Try them both, see for yourself, think for yourself. Both groups have given you something for free, at considerable personal effort, and the least you can do is give them the benefit of exerting enough effort to try what they're offering out before passing judgment (or worse, blindly accepting someone else's!).

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

Jordan Hubbard

Yup:

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

I'm not sure. While reasearching the great 'Linux vs. everyone else sucks' debate, I received this in E-Mail. The author's identity has been removed to protect him from the mail-bombs. For the humor impaired, stop reading now!

Many people ask the question "Which is better? FreeBSD, NetBSD, OpenBSD, or Linux?" Up until now, not many people are willing to answer thoroughly and give reasons. I, being a brave soul, am. This mini-FAQ lists the most significant differences between Linux, NetBSD, and FreeBSD in a fair and evenhanded manner. Permission is given to redistribute this mini-FAQ freely, with attribution. If anyone wants to take the burden of posting it periodically on the appropriate newsgroups, be my guest.

This is based on a message I wrote some months ago. I've tried to update it substantially to reflect the changing nature of x86 OS's.

A) NetBSD is the best of the three because of it's superb error handling capabilities (this is the "Net" referred to in the name). With NetBSD, it's almost impossible to make a mistake, either in installation, or operation, because the system will "catch" you as you "fall". NetBSD works on a wide range of processors, including the Intel 386, 486, and 586, the Sun, Sparc, SGI, MIPS, Macintosh, Motorola 6809, Krupf, ADC Kentrox, Whirlpool, Amana, Zilog Z80, Timex-Sinclair, and the Braun. Currently, the NetBSD team is devoting all of their energies towards finishing the all-important IBM RT port.

Linux is the successor to an operating system called "Minix". Linux was developed by Linus Pauling, a Finnish communist. Linux tries to uphold traditional Marxist values in several ways; firstly by using GNU tools from the FSF foundation wherever possible. The Linux kernel is developed by committee, and the operating system reflects this: rather than having one "init" process which fathers all others, a group of co-resident processes with equal powers are created simultaneously. "Kill" commands are treated as formal protests. Linux networking has come a long way since it's implementation, and there is no truth whatsoever to the rumor that sudden losses of IP connectivity are in any way related to future plans to limit users to 1.5 hours of SLIP or PPP unless they send in the registration fee.

FreeBSD was a radical offshoot of the Linux project; you could consider it to be of the Trotskyite school. FreeBSD supports an extremely wide range of PC hardware, as long as it was obtained at less than cost. FreeBSD is used by Amnesty International and many other human rights organizations. FreeBSD supports every peripheral available for the IBM PC except the ones you have. The FreeBSD team was actually responsible for porting "Doom" to Linux, in a successful effort to slow down constructive work by distracting the central committee with frivolous games. FreeBSD has the nicest installation of any of the x86 unices -- you install the boot disks, which then initialize the modem and call Jordan "Perky" Hubbard, who then comes to your house with the rest of the disks and completes the installation. The FreeBSD CD-ROM plays various Nick Cave and Tom Waits songs Jordan is known to be fond of.

386bsd was written by Bill Jolitz in a fit of pique. It was based entirely on Sun's widely-respected "Solaris" operating system, as revenge against Sun's Bill Joy, who rudely chose a name with the same initials as Jolitz. A new version of 386bsd will be released very soon. Unfortunately, it will only run on 386es, and thus is unsuitable for anyone with a 486 or Pentium. 486bsd should be released "sometime in 2138," according to industry insider James Monroe, Sr.

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

1) The Free and Net BSD teams split up in the year 1632. The cause of the split is uncertain, but it seems to have something to do with someone named "Janice." They still get together for drinks occasionally, and remember old times. Every so often, after tying on a few too many, they end up waking up next to each other and feel ashamed over their night of pleasure. The kids still blame themselves.

2) The Linux kernel has actually not changed at all since January, '94? Linus just increments "version.c" once every 48 hours and unleashes the "change" on an unsuspecting Internet, bringing FTP servers to their knees. A book, "The Design and Implementation of the Linux Operating System," by Gary Marshall James T. Kirk McUsenet, was rejected by Addison-Wesley on the grounds that they didn't feel the public was prepared to purchase a book written on looseleaf paper with diagrams in crayon.

3) All three systems claim to be "POSIX" compliant. However, the POSIX people have denied knowing anything about it. Scuttlebutt in the industry is that POSIX will soon be outdated, and will be replaced by GNOPIX, a FSF standard which implements the TOPS-20 operating system in Scheme.

General information

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

Yes. Get FreeBSD, OpenBSD, or NetBSD.

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

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

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.

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

The BSDisc is scheduled to ship every six months or so. The current (November 1995) disk is a two CD set with the following:

- NetBSD 1.1 - distribution sets for x86, sparc, mac68k, and amiga
- expanded source tree for all architectures
- FreeBSD 2.1.5 - distribution sets for x86
- expanded source and binary trees for x86
- XFree86 binaries for both FreeBSD and NetBSD - X11R6 (xc as well as contrib) - BSD-related news archive - various Answers to Frequently asked Question (FAQs)

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

For single-issue purchases, contact InfoMagic at:

There are two types of documentation for *BSD. First is the set that covers the operation and theory used in BSD-Unix.

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.

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

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

FreeBSD's 'home' is FreeBSD.cdrom.com (the home disk of Walnut Creek). The portions of FreeBSD (versions less than 2.0) that were encumbered are distributed with the tolerance of AT&T/USL/Novell/SCO/whoever owns the source for SysV this week. All FreeBSD versions (with version number >= 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.

OpenBSD's 'home' is ftp.openbsd.org. It was based on NetBSD Version 1.0, so it is (by definition) clean. There are (at least) two things which differentiate OpenBSD from NetBSD. One big difference here is that nearly anyone can write changes to the kernel code in the -current line and make their updates available. Another is OpenBSD is hosted in Canada, and therefore has no export restrictions on any of it's code (specifically the encryption code for DES).

Once the files are on floppies, thoughts usually turn to questions about how to install the boot image on a floppy. The rawrite program (for DOS) is used to write the bootable images (dist.fs and fixit.fs) onto floppies. The same image can used for 3 1/2 and 5 1/4 high density diskettes. NetBSD uses the .fs file extension for its floppy images. FreeBSD uses the .flp extension.

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

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

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

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

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

- One or two of the files are no good. Try getting them again. As a precaution, rename the bad files on your hard drive to names like foo.1 and bob.23. Copy the files again from floppy. If they are still bad, rename the file, and the one immediately before the first bad file (bin01.23 if bin01.24 is bad) and copy them again. If they are still bad, download those files again from the distribution site (including the one before and after the bad one) and try again.

The reason for renaming the files is that sometimes, especially with drive that do not auto-magically record bad sectors, you could copy a distribution file onto a bad spot on the disk. If this happens, you want to isolate the bad spot. The easiest way to do that is just leave the bad file on it.

For those of you that have received your system on a CD-ROM, you will need to find at least three things. One is this file. Since you are reading it, I assume that you got it already. :-) If you can't read this file (you got it from the newsgroup, for example) there is one thing that you need to know so you don't look like a complete idiot on the net.

There is no such thing as a Unix CD-ROM. They are all in something called the ISO CD-ROM format. You can read them as the D: drive in DOS, or mount them on your Sun or SVR4 system or whatever.

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

You get the idea, right? Look for the MS-DOS program "RAWRITE.EXE". It should be right near the file system (.fs) files. Another clue for the truly lost will be that the file system files will all be 1.2 Meg big. These files will fit onto either a 1.2Meg 5.25 inch diskette, or a 1.44Meg 2.5 inch diskette. Use rawrite to write the fs files to diskettes and boot from the diskettes.

The FreeBSD system uses a system 'pretty much' the same as this, except that the filesystem files are 1.2 Meg files and they all have a '.flp' extension. Other than that, the instructions apply.

You did back your system up, right?

For those of you trying to build installation floppies, you will need to verify the media type on the 'dd' and 'disklabel' commands in the Makefile. The default is to build to 1.2 Meg disks (being the smallest in terms of room). Change the 12100 and floppy5 entries to 14410 and floppy3 (respectivly).

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

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

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

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

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

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

2.0.1.2b : I am trying to reinstall. I run install and it loops asking me if I want to use the whole disk?

The most likely culprit is your hard disk controller. If you have an IDE or EIDE controller, it is probably doing some type of disk translation for you. If this is the case (assume it is) then you will need to find out the real disk controller geometry, and rewrite your disk label. See section 2.6.2, but before doing that get the program pfdisk.exe. This program will tell you what the controller geometry is (right before it reboots your computer). Make the disklabel agree with this program and your system should boot. You may have to reinstall, but at least your disklabel will be right. Note that this is a nearly required step for all NetBSD and FreeBSD installs. You need to know what the disk geometry is before the BIOS messes with it. If you start having these kinds of installation problems, I can virtually assure you that it is because your controller geometry and your disklabel geometry are different.

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

But on the other hand, maybe not...

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

The most amazing thing about the boot process in *BSD is the boot up alternatives that are available. There is little that a person can NOT do from the boot prompt. The boot diskette or disk can be selected (fd(1,a) for fd1a (my B: drive is DOS)) can be the source of my kernel. In addition, the name of the kernel can be chosen (this allows you to boot with a test kernel or reboot an older kernel if the new one gets hosed). Finally, there are three choices for options that may or may not work, depending on the age and proclivities of your boot blocks. These options are documented in 2.5.9 below.

In single-user (system booted with -s or an error in one of the processes started by /etc/rc) the root filesystem mounts as read-only by default. This was intended so that some range of problems would not be made worse by writes to the disk.

The 'dos' partitions mount as read-only in that there are reservations as to how well some of the FreeBSD tools work with the pcfs. The same kind of reservations exist with NetBSD and the '-t msdosfs' option. These options (-r for read-only, -w for read-write) can be set in /etc/fstab.

The status of both can be changed with 'mount -wu /{mount.dir}' (where {mount-dir} is the name of the directory that the offending partition is mounted) to read-write. Particularly for the dos filesystem, the man page for mount should be read in detail and the 'noexec' option examined.

Note that mounting the file systems using the '-a' option will mount all of the file systems that are normally mounted with their usual read-write bits set normally. Using this option makes your root partition writable, and also mounts the rest of the partitions in your /etc/fstab that are normally mounted during boot-up.

2.1.1 : I want to install by NFS but I am having all kinds of problems connecting to the Sun server where the files are.

There is an unusual problem when installing over NFS. This solution may have been corrected in the documentation that comes with FreeBSD and NetBSD, but if not, here it is.

The most common problem seems to be that FreeBSD (and by inference NetBSD and all the other 4.4 based systems) do not send out NFS requests over privileged ports. Sun's NFS implementation (and others, once again by inference) expect precisely the opposite. These systems will quietly fail if you try to NFS to them.

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

SunOS is particularly insidious at this point. The mount succeeds, but then everything else after that fails. This means that your FreeBSD or NetBSD system will return an EACCESS error whenever you try to grab a file from the NFS filesystem. The solution (tested in FreeBSD) is to include the 'resvport' flag like this:

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:

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.

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.

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.

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

There have been many good articles in both the mailing lists and the newsgroups about disk labeling and partitioning. I have included a few of them here. NOTE: This information has not really changed since 386BSD 0.1. Some of the specifics may be out of date (the use of the d: partition, for example) but the steps and information are still pertinent.

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

If you have compiled in the VNODEPAGER option in your config file, you can use vnode files for swap space. The precise details are exaplined in the man pages, but the easiest way to start is to include the following line in your /etc/fstab:

/dev/vnd0b swap swap sw

Defining the file for the vnode is fairly straightforward:

vnconfig -c /tmp/swapfile /dev/vnd0b

and actually making it swap is as simple as

swapon /dev/vnd0b

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

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

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.

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

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.

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

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

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

For instance, the following line works for me:

disklabel -w -r sd0 <drive-type>

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

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

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

A report about someone with an Austin Tower (486DX/50), AMI BIOS, Caviar 2250 IDE, Adaptec 1542CF, and Toshiba SCSI disk (1.2GB) posted this set of instructions:

The BIOS is configured to boot from the IDE drive as type 47 (user defined). The IDE drive currently has NetBSD 1.0 BETA on it.

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

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

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

The options are supposed to be as follows:

A related question concerns the options on the 'reboot' program. These flags are as follows:

As with so many other things in the systems, each of these may (or may not) work for FreeBSD or NetBSD. Your Mileage May Vary.

One other note about 'reboot'. There are some motherboards which do not reboot reliably. Instead of rebooting, they simply hang. While this isn't a definitive answer, some folks have noticed that have the BIOS relocate option set seems to help them, especially with Micronics motherboards. If you are having problems with your system not resetting after a reboot, try changing the setting on the BIOS relocation option.

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

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

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:

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:

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.

When the system is starting, the nameserver hasn't started yet. If you are using any names that must be resolved, the system will attempt to get the names from the nameserver, When that fails (three timeouts at one minute apiece) the name will be resolved from the /etc/hosts file (if the name is available).

There are essentially two ways to solve the immediate problem. The first is to reduce the number of entries you have in your /etc/hosts file to the absolute minimum you need for booting and change the order for host resolution from 'bind file' to 'file bind'. If you specify a name in any of your start up files and the name server isn't available, you will still have the hang, but this is only a small annoyance.

The second (and generally more effective) way to deal with the problem is to use only numeric addresses in your /etc/* files. This way, the resolver is never called upon to figure out the addresses and your boot-up will always 'just work'. This is sometimes more time intensive to set up, since all of the names in the files need to be removed and replaced with numbers. "C'est la vie".

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

- Use "netmask 0xffffff00" (or whatever is appropriate) for the first IP address, and "netmask 0xffffffff" for all aliases that happen to be in the same (sub)net as the primary one. The reason this is right (no matter how odd it may seem) is you have multiple interfaces referring to the same network. You *have* to chose one of the various interface addresses as the "gateway" for outgoing packets into this network, you cannot have them going out through a dozen of addresses simultaneously. The netmask 0xffffffff prevents the kernel from considering this IP address as a valid gateway (since it's not pointing to any network at all).

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

Where the xx.xx.xx.xx are the host address for the alias and the yy.yy.yy.yy.yy.yy is the interface MAC address (if appropriate).

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

PPP includes a link-level checksum. Watch the packet counts in the netstat -I ppp? output over time. Check carefully to see whether the PPP driver is recording input errors (frames whose CRC failed.) Frames with bad checksums are counted in Ierr field. A non-zero count indicates _something_, possibly overruns, is in fact garbling your PPP traffic. If the packets are being discarded due to errors at the PPP level, they'll never even get as far as IP.

Also, use netstat (or an SNMP daemon and monitor, if you prefer) to watch the rate of change of bad packets at the IP and TCP level. I run "netstat -p ip" "netstat -p tcp". One has to manually compute the rate of change; netstat's -i option means something different to, say, vmstat's. (Adding periodic sampling and rate-of-change to netstat would be a Cool Project.)

At the IP level, the relevant statistics are

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

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

It could be that a TCP ack got munged or dropped by your PPP link; or possibly somewhere else in the Internet. That's not abnormal on busy links.

What OS is your FTP peer running? Is it a pre-2.0.0 Linux or an older version of a commercial Unix? If so, have you tried turning off rfc1323 on your NetBSD machine??

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

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

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

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

then

etc.

That syntax won't work on ports which use 'old config,' but I believe an appropriate description of how to do it on them has already been posted.

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

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

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.

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

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

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

- Misconfigured hardware. The iomem, IRQ, and other board settings must match the ones listed in the INSTALL.NOTES. Unfortunately, the INSTALL.NOTES are on the disk that will not boot. You can grab them via FTP from many archive sites. This installation file may have many names. Look for something kind of obvious (like 'install.notes' or 'readme' or 'configuration guide') and you should find it. Finally, there have been many reports (particularly with the BusLogic SCSI cards (specifically reported was the BT445C VLB host adapter) where the system seems to boot up, but starts getting 'stray interrupt c' messages. This is usually caused by people having there SCSI card set up on some IRQ other than the one that the kernel expects. The factory default for this card seems to be IRQ 12, but the kernel wants the card at IRQ 11. Setting the card (using the configuration program supplied) changes the setting so that it matches the kernel and the card then works.

- Unsupported hardware. There are several SCSI controllers on the market that are not fully supported by 386bsd. This is due in large part to the way these controllers work. Instead of using a standard interface and command set for the controllers, most manufacturers make up their own controller interface language, which is then translated into SCSI commands which are interpreted by the drives.

- One or more of the devices in the /dev directory on the intended root partition was either not created correctly or was not created at all. Run the program MAKEDEV in the /dev/ directory to ensure that all of the correct devices are built.

Increase NKPDE in /sys/i386/include/pmap.h. The largest it should be 31; see question 3.2.8.1 for other useful values. Be sure to keep the changes around as a patch file, since this is one of the files that will get overwritten during a source code update. Note that in the versions of NetBSD newer than 1.2.1, this value is computed, so you won't need to change it.

2.4.3b : I have some card on IRQ2 and it doesn't work; why?

2.4.3c : I am getting lousy performance out of my network card. What are some of the other possibilities?

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

One solution would be to plan on not using your Ethernet card (or any other card you want on IRQ 2) until you have rebuilt the kernel so that it expects it at an interrupt other than IRQ 2 or 9, re-jumper or reconfigure the card to match the IRQ you have selected, and enable it.

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

On the XT, there was one interrupt controller, an Intel 8259, which handled 8 interrupts numbered IRQ0 through IRQ7. IRQs 2 through 7 were accessible via bus lines IRQ2 through IRQ7.

The AT had two interrupt controllers. Due to the design of the 8259, one has to be the master and the rest (up to 8) must be slaves. Each slave controller output its interrupt request to and input on the master controller. In the case of the AT, the master controller handles IRQ0 through IRQ7. The slave handles IRQ8 through IRQ15. The interrupt request from the slave to the master goes through IRQ2, which is termed the cascase input. IRQ2 was chosen to allow future compatabilty with the old XT hardware; it was the first IRQ that was 'available'.

This means. of course, that the bus line for IRQ2 could no longer be used for external interrupts. Instead, the bus line that WAS IRQ2 in the XT became IRQ9 on the AT. This whole issue is confused further by the fact that some vendors refer to this external interrupt as IRQ2, while others refer to it as IRQ9. In either case, if you are talking about an external interrupt, it means the same thing.

BTW, IRQ8 is used for the Real Time Clock, and does not have an external interrupt. Here is a map, in case anyone still needs it:

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.

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.

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.

A common cause for this is when all of the right devices aren't created on the root partition. Since you say you can boot off of a floppy, do so and check to make sure everything in /dev exists. You might consider running "MAKEDEV all" to be sure everything is created.

(Ed.Note: I find that whenever I create a new kernel, it isn't a 'bad' idea to run a precautionary MAKEDEV to make sure that the devices are created correctly. Since I only build a new kernel about once a month, it isn't a very costly insurance policy.)

Also, there are known problems with IRQ configurations and the PCI bus. The system hanging right after the changing root device message usually indicates a misconfigured IRQ for the controller. The initial probes by most (all?) drivers are done in polled mode, only when mounting the disk for real does the kernel begin to do interrupt driven I/O and DMA.

Is this system a PCI system? Is the SCSI controller a PCI board? If so, make sure the IRQ configured in the PCI BIOS matches the IRQ configured for the card.

Also, with PCI, forgetting to enable the slot for "master" in the BIOS setup or motherboard jumpers or putting a bus mastering card in a slave only slot will give similar symptoms. The system may not have problems under DOS because some SCSI BIOS or device drivers don't actually use the DMA or bus mastering features of the card... {sigh}, they run in PIO mode under DOS.

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:

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.

2.6.1 : How do I get the system to not display the machine name, but display our company name?

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

The inetd program has a 40 start per minute limit for all programs started out of inetd.conf. You need to add a 'max starts' option on the end of your 'wait' or 'nowait' option. For example, try 'nowait.100' if you expect the program to start 90 times a minute.

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

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.

Remember, when structures in the kernel change, there are some programs (ps, top, etc.) that will cease to work correctly. You will need to recompile these programs as well as the new kernel. You need to do the following to make sure that your programs get updated as well as the kernel:

cd /usr/src/include make install cd /usr/src/lib/libkvm make clean && make && make install cd /usr/src/bin/ps make clean && make && make install cd /usr/src/...

3.1.1.2 : How do I port NetBSD to another platform?

We still use the old style K&R definitions easier, because bringing up a new port on a foreign machine with a brain-damaged compiler can be impossible, or at least very difficult, if you don't do it this way. Remember, NetBSD is multi-platform, and tries to make it as easy as possible to port. Which means building pieces of the system with someone else's compiler.

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.

Step 1 is to build a profiled kernel:

cd /sys/arch/<X>/conf
config -p CONFIG.FILE.OF.YOUR.CHOICE
cd /sys/arch/<X>/compile/CONFIG.FILE.OF.YOUR.CHOICE
make depend
make
<install the kernel and reboot>

Step 2 is to start the profiling process:

log in
su to root
kgmon -r -h
kgmon -b

Step 3 is to run the application in question

Step 4 is to stop the profile:

kgmon -h
kgmon -p (this produces the gmon.out file, which is the
profiles kernel information)

Step 5 is to analyze the output:

gprof /{kernel name} gmon.out > profile

which produces a hierarchical call graph as well as flat profile. The flat profile is easiest to use for beginners, although both are good information sources for kernel code performance.

Your kernel is called /kernel or /netbsd. Copy the new kernel from /sys/compile/GENERICISA/(whatever) to /, assuming that it is in that directory. If you really screw up the new kernel, you want to have something to fall back on, so be sure to save /kernel to /kernel.old before copying in a new kernel.

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.

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

Not exactly. This simply means that the First in first out buffer is getting too full. I markedly reduced the incidence of silo overflows on my system by editing dev/isa/com.c to change the FIFO threshold from 8 to 4 characters. This way, the buffer gets more attention and reduces the chance of overflowing the buffer.

Another possibility is caused when you are using internet over a telephone line via SLIP or PPP. You might have an unbuffered UART on your serial port, like the 8250 or the 16450. With the introduction of the IBM PS/2 systems the first 16550 UART's were shipped to provide a 16 byte buffer. But unfortunately the buffering of the original 16550 did not work. The problem was solved with the improved 16550A UART. If you run MSD (under MSDOS!), an application that comes with MS-Windows, you can determine the UART type of your serial ports (by choosing COMS). The UART type is also showed when your UNIX boots up.

To solve the `silo overflow' problem you can by a Multi/IO card with a `real' 16550A, or a card with an extra serial port, like the HAYES ESP card. The Hayes card has a DOSSETUP utility to configure its port address and IRQ. The port address can be chosen between 180H and 380H, the IRQ address 3, 4, 5 or 9. Normally COM1 (tty00) and COM2 (tty01) claim IRQ 3 and 4. So you can choose (for example) IRQ 9 for the Hayes ESP card. Then you have to add the appropriate lines in your kernel configuration:

options COM_HAYESP

device com0 at isa? port "IO_COM1" irq 4 device com1 at isa? port "IO_COM2" irq 3 # com2: Hayes ESP serial port device com2 at isa? port "IO_COM3" irq 9

For more information on com ports in general, try this URL:

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.

The config file is the list of all of the optional (and settings for the mandatory) parts of the kernel. If the system is made up of static object files which don't change, then all you should ever need to do is modify the config file, reconfigure the kernel objects, and relink. Since both NetBSD and FreeBSD are distributed with source, these files are recompiled and a kernel is constructed. Some of these have been deprecated, and may not be in use for a particular version of the system (i.e. ISO9660 and CD9660 are the same, CD9660 being the newer version).

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.

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

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.

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

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.

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

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.

If you need to know more about the sysctl command, try "sysctl -a | more" to get a list of the parameters that can be modified while the system is running.

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.

The EXTMEM_SIZE and NKPDE entries need to be specified for in your system config file. I'm not completely clear on the concept, but it goes something like this:

The value of EXTMEM_SIZE needs to be set to the number of bytes in the extended memory range for your system. Since this excludes the ISA hole and a 4K region claimed by the BIOS, the value for the machine above would be ((128 * 1024 * 1024) - (384 + 4) * 1024) which equals 133820416 You also need to set NKPDE to something larger than the default of 12. The best advise seems to be setting it to the maximum (31) for everything over 64M of real memory.

Both of these can be set in the source (which is the ugly way), or you can use the "options" keyword in a custom config file. Look in the "/usr/src/sys/arch/{arch}/conf" directory for the GENERIC config file, and copy it to a config file name of your choosing. Near the top, there will be several 'options' listed. Somewhere in there (placement is not critical) add the lines:

options EXTMEM=133820416 # assuming 128M of mem options NKPDE=31 # more than 64M of mem

Set BUFPAGES to the number of 4K buffers you want to allocate. For 16Meg, you would use "options BUFPAGES=4096".

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.3.1 : Has the method for system call changed in NetBSD?

Q. Is there something special with the order I need to update binaries and libraries in? If I drop in the new libc, everything gives me a bus error. Both shared and static do this.

A. On the port-i386 list, Charles Hannum discussed changing the system call mechanism (doing it via an INT instead of a call gate). Looking at src/lib/libc/arch/i386/sys/syscall.S, it looks like this change is in. Your binaries are (if you are using an old kernel) probably crashing at each system call now.

So.. first compiling a new kernel with COMPAT_10 in it should make your newly linked binaries work, I guess (have not recompiled since the update myself yet). Also don't forget that you need to use config.new now.

So, the answer is Yes, the mechanism for system calls has changed, but the old method (using a call gate) is still available by specifying COMPAT_10 in your configuration file.

Your best method _by far_ would to to pull down a snapshot (assuming one exists for your arch) & install all except the etc tarfile, then diff the etc tarfile contents with your setup to check for any updates you should make.

If you really want to do it the hard way, here is your map.

# Remember to make yourself a new config (not config.old) kernel # config file. # # This means any old config file you may have had from # V1.1 needs to have the mainbus changes made. See GENERICADP and look # for the isa0,eisa0,pci0 at root add the mainbus0 stuff and attached # your buses to it. For updates to V1.2, you will need to make # certain the COMPAT_* options are correct. # # Make sure you have COMPAT_11 as part of your kernel config # options. # # This assumes that the -current source is in /usr/src

(cd /usr/src/usr.sbin/config ; make && make install && make cleandir)

# if you don't do this, config of your kernel config file will # fail with errors in files.i386

(cd /usr/src/gnu/usr.bin/gas ; make && make install && make cleandir)

# if you don't do this, you won't be able to build locore.s, with # errors about cpuid instruction not found

(cd /sys/arch/i386/conf ; config BCC13) (cd /sys/arch/i386/compile/BCC13 ; make depend && make)

# copy new kernel to /, and boot off it

(cd /usr/src/share/mk ; make install)

# if you don't do this, you'll get errors building gcc, when it # doesn't know how to make the manual pages (don't know how to # make gcc.0) # # Rebuild yacc first or the yacc from v1.1 dies on Error Code 1 when # it hits %expect 34 in /usr/src/gnu/gcc/common/c-parse.y. The # new yacc included with V1.1B handles it, build and install it # before it gets used in the gcc building. # # *** # (cd /usr/src/usr.bin/yacc; make && make install && make cleandir) # # The build now uses a new tsort option (-q) when it gets to the # point of 'building standard cc1 library'. At this point if using # the tsort that comes with V1.1 it dies on a Error 1 and no # obvious explanation. Going to the common sub-directory under # gcc (ie. /usr/src/gnu/usr.bin/gcc/common) # and typing 'make' will reveal the full error. # (cd /usr/src/usr.bin/tsort; make && make install && make cleandir) # # cd /usr/src/gnu/usr.bin/gcc make # # Build will die here on libgcc # (cd cc; make install) (cd cc1; make install) (cd cc1obj; make install) (cd cc1plus; make install) (cd cpp; make install) (cd g++; make install) (cd libgcc; make; make install) (cd libobjc; make; make install) (cd /usr/src/gnu/usr.bin/gcc ; make && make install && make cleandir) # # Bernd Wiserner says that the ld.so that will be built next will # work only with libc.so.12.0, not with libc.so.12.3 # His instructions to make a working ld.so follow: # Do NOT run ldconfig while doing the folowing 5 lines ... # (cd /usr/src/include ; make && make includes) # cp -p /usr/libexec/ld.so /usr/libexec/ld.so.good (cd /usr/src/gnu/usr.bin/ld ; make && make install && make cleandir) cp -p /usr/libexec/ld.so.good /usr/libexec/ld.so # # Then build ld.so again ... (cd /usr/src/gnu/usr.bin/ld ; make && make install && make cleandir) # Thanks, Bernd...

# And now the libraries (cd /usr/src/lib ; make && make install && make cleandir)

(cd /usr/src/bin/sh ; make && make install && make cleandir)

# and now back to the beginning and make the world # (cd /usr/src/bin ; make && make install && make cleandir) (cd /usr/src/sbin ; make && make install && make cleandir)

mkdir /usr/share/doc/usd/13.viref # otherwise "make install" in /usr/src/usr.bin will fail because # the destination directory doesn't exist - from Tom Thai

# if you're using the obj directory hierarchy, use the # initscan.c from the obj directory, otherwise use the initscan.c # that was created here.

cd /usr/src/usr.bin/lex if test -d /usr/src/usr.bin/lex/obj ; then cp initscan.c obj/scan.c else cp initscan.c scan.c fi

# if you don't, then lex won't be built

(cd /usr/src/usr.bin ; make && make install && make cleandir) (cd /usr/src/usr.sbin ; make && make install && make cleandir) (cd /usr/src/libexec ; make && make install && make cleandir) (cd /usr/src/gnu ; make && make install && make cleandir) (cd /usr/src/share ; make && make install && make cleandir)

mkdir /usr/share/doc/usd/30.rogue /usr/share/doc/usd/31.trek # otherwise "make install" in /usr/src/games might fail # if the dirs weren't already there

(cd /usr/src/games ; make && make install && make cleandir)

There is one in the /usr/src directory. Unfortunately, it seldom gets sent down unless you are using sup to get -current. If you need it for NetBSD, you can FTP to ftp.netbsd.org and get it from the src archive.

Sure. Check out the cross-compiling howto for MacBSD for an example. All of the NetBSD ports should be capable of doing 'pretty much' the same thing.

You can find Colin Wood's MacBSD cross compilation howto at the following URL:

Probably not. When the system starts, the kernel malloc pool is not backed by real memory. As these pages are allocated, real memory is assigned to them, increasing your memory usage. As these pages are released, they are returned to the malloc pool, but the memory is never returned to the system. Eventually, your malloc area will reach a point of statis, where new pages are not needed from real memory; the releases to the malloc area should cover the new pages needed.

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

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

The best way to debug problems with starting 'X' is to redirect the output of the 'startx' program to a file:

% startx >& startx.log # csh % startx 2>&1 > startx.log # sh

With the output from this, the problems should be fairly easy to identify and (hopefully) fix.

OK, first off, make sure you're using the latest version of xlock. If you've pulled it out of the /ports/ distribution then you've got version 1.14. This is woefully ancient, so get the latest, which at the time of writing is 2.7 (just do an archie search for 'xlockmore-2.7' to find it).

Get this, compile it up and *make sure it's setuid root*. So, after you've copied it into /usr/X11R6/bin or wherever, do the following:

# chown root.wheel ./xlock # chmod 4755 ./xlock

After that, it should work fine. The problem is that without being setuid root xlock cannot read the real system passwords. If you look in /etc/passwd you'll see that the passwords are all '*'d out, because FreeBSD and NetBSD use shadow passwords.

That's what worked for me. A couple of other suggestions were raised last time this problem cropped up:

o If you're using a pre-compiled xlock then it might have been linked against the USA encryption libraries. If you're outside the States then the encryption libraries are different, and a US xlock will not be able to read the passwords. The fix is to get the sources and recompile.

o If you've compiled it from source, made it setuid root, and it still doesn't work, someone suggested changing the size of the constant PASSLENGTH in xlock.c from '20' to '40'. I haven't had to do this, and in v2.7 it's '64' anyway, so it shouldn't be a problem.

For NetBSD: Assuming you are trying to simulate a SVR4 system, you want to create the '/emul/svr4' directory. You will also want to ensure the "COMPAT_SVR4" option is in your kernel config file. This option will change in 1.3-current and later, so be sure to check out the config files included with those versions to ensure you have the right options.

Note that there are known problems when trying to run a staically linked Linux ELF executable and you have SVR4 emulation built into your kernel. THe problem is the order in which ELF executables are processed through the kernel tables. The SVR4 emulation gets processed first, thus causing the LInux ELF executable to be improperly processed. This may cause certain Linux static ELF executables to fail under the *BSD systems. The way to fix this is to remove SVR4 emulation from the kernel or switch to a real SVR4 executable.

Also note that newer versions of NetBSD do not make a distinction between Linux ELF executables and SVR4 ELF executables. The only difference (from the 1.3 kernel's viewpoint) is whether they are 32 or 64 bit ELF executables.

With this accomplished, you will need to copy several files into the emulation directoy. A live example might be best at this point. Most of this information is include in the 'compat_linux(8)' manpage.

First, set up the '/emul/linux' directory. Within this directory (and virtually all of the emulation directories) you will need the following:

etc/ (the emulated /etc directory)
lib/ (the emulated /lib directory)
usr/ (the emulated /usr directory)

From there, the simplest way to populate these directories is to use a program like 'cpio' or 'tar' to build an archive. Having a linux machine available will greatly simplify this. Copy (basically everything from the Linux (or whatever) /etc and /lib directories.

Any executables that you need from the Linux system should then be copied into an appropriate place in the usr/ directory. For example, when creating the Linux Doom system on NetBSD, you need to have the following files (which should all come from the Linux Doom distribution).

usr/X11R6/lib libX11.so.6.0

usr/bin: as86
ld86

usr/games/doom README.linuxx
doom1.wad
linuxxdoom
sndserver.old

With Doom specifically, you may need to set 'DOOMWAD' (or whatever it is) to usr/games/doom for it to work correctly.

In addition to the 'X' version, the native version should also work (with recent versions of NetBSD (1.1+)

It is generally accepted that NetBSD's emulation of the other systems is pretty close *except for* sound. The audio drivers in NetBSD are not a robust (yet) as they probably should be. Don't be surprised if sound emulation works badly, if at all, for any of the other operating systems emulation works for.

The good news is that work under way (early 1997) in the -current version of NetBSD (pre 1.3) should fix most of this. The sound subsystem has been modified so that machine independent components are seperated from the machine dependent stuff, and each of the machine dependent parts is getting a facelist. Ultimately, the NetBSD sounds system should be 100% compatible with the one from FreeBSD (that was the design goal) and probably Linux as well.

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

For a full discussion of this problem, check out the 'options(4)' manpage. It describes the DST and TIMEZONE options in detail.

In newer kernels, the problems are far less dramatic than they used to be (see below):

The problems with timezones and real-time clocks is that most 386 hardware is just stupid. It doesn't recognize DST, even when told to. It can't use network system time during DST because it makes all the PC clocks off by an hour.

For machines that dual boot DOS and *BSD, one of the simplest solutions involves using a program called 'clock372' from Simtelnet (the exact site is not available). After you install it, you add a couple of lines to your DOS CONFIG.SYS and set the hardware clock to DST. From there, you build a kernel with DST and TIMEZONE set to 0 and your whole system "just works".

In older kernels the following works:

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

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.

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)

I'll append the scripts I use, but be warned, they may bite you if you are careless...

The main reason I use cvs import is to handle updates from the ``vendor''. The best way I've found is to import _exactly_ what was shipped. This means unconfigured, and I put config.h, etc, in .cvsignore. If I have to modify configure.in then obviously I commit them :-)

#!/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:

# README.import

# import.sh

# prune.sh

#

MNEMONIC INSTRUCTION

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

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.

See section 5 for more Terminfo/Termlib information, as well as a discussion of the new curses library that is available.

All of these directories should be owned by bin, group bin, mode 1777. This turns on the sticky bit, so that the only people who can remove a file from these directories are the owner and root.

Several strides have been made in the past to reduce the amount of 'cruft' that gets into the default kernel. One way is to make the kernel so hard to use that practically no one but a person with precisely the 'right' hardware would be able to use the system

Another way is to implement something called 'LKM's or "Loadable Kernel Modules". These are run-time extensions to the system that allow the distribution kernel to not include things that people might want, but not nxbeed until they get the system up and running. While the security concerns of LKMs are valid, their implementation is such a win that the research to implement them is well worth it.

It was really _very_ simple to make these, so this is nothing spectacular. Just something to keep from having to recompile just to add msdosfs support to a machine. ;)

To try this:

This is actually two separate questions, but they are close enough to the same that I can answer them here. The first problem that anyone building a 'crypt' aware program needs to remember is that the crypt library is a separate library and requires a '-lcrypt' to be added at the end of the link line. The other half of the problem is the 'US Non Export' policy for DES encryption. There are several good sources (about one per country) for non-US crypt libraries. IF you are outside the US and need one, look around on some of the NetBSD/FreeBSD/OpenBSD FTP sites in the 'local area'. By the way. I don't have any good URLs for Mars, so you might be out of luck.

OpenBSD doesn't appear to have this problem, since it is a "Canadian" product rather than an American one. Thanks to this, there is no restriction on exporting (or importing) the crypt library, so it is no longer needed. With version 2.1 of OpenBSD, the crypt library doesn't even exist; it is included in the standard library for the system.

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.

Remove the sys_errlist reference in the source you're compiling. You can either delete it (there are advantages to just deleting it) or you can wrap a "#ifdef __NetBSD__/#endif" (obviously only if you are running NetBSD, FreeBSD and OpenBSD have a similar mechanism) pair around it. There are religious issues regarding the use of sys_errlist that involve either system security (most declaration allow the error list to be written to) or system internals (there's already a well-defined library call that performs the sys_errlist lookup). An anonymous example is included below:

Most stupid packages such as GCC expects extern (char*)sys_errlist[] whereas 4.4Lite based systems have more secure extern const (char*) const sys_errlist[] declaration. Just kick that "cccp.c" in the butt and modify the suspicious line. Hard to believe GCC still doesn't do that. You're going to have to do lots of this modification as you encounter more of such programs.

4.4.1 : Where can I get good books about NetBSD or FreeBSD?

With the release of the System Administrators Tool for Analyzing Networks (SATAN), network security has suddenly become a serious issue. There are a few things you can do.

-- Get, read, and understand the CERT advisories -- Get SATAN and run it against your own system or network. Fix whatever it finds as holes -- Get courtney, a program that was written to recognize a SATAN attack pattern and notify you whenever someone tries to probe your system -- Log all failed login attempts (see below)

Failed logins are logged (without the attempted login name) at LOG_NOTICE priority. Failed logins are logged _with_ the attempted login name at LOG_NOTICE priority, and with the LOG_AUTHPRIV facility.

If you set up some lines in syslog.conf like:

# The authpriv log file should be restricted access; # these messages shouldn't go to terminals or publically-readable files. authpriv.* /var/log/secure

Make absolutely sure, though, that it's really what you want: logging actual supplied logins is often a great way to offer cleartext passwords to an adversary...

Which is why you have authpriv.* /var/log/secure ...,authpriv.none,... /var/log/messages

So none of the authpriv messages (those that actually display the failed login) goto /var/log/messages, but they do go to /var/log/secure (which you have with 600 perms.) Bear in mind that this still does not prevent someone that has hacked into your system with root privs from reading them. See 4.4.2 for more information.

Considering that the error comes froom the ioctl (rather than the open) I'm tempted to say it comes from either the vn_open() or subsequent VOP_*() operations on the components. If you compile your kernel with `options CCDDEBUG' and set the ccddebug variable (near the top of ccd.c or with the ddb) to 0x03, you should be able to see where it fails. If you could send me that information, that would be most helpful.

Might be the same problem I had; it turns out that the partitions that you build your concatenated disk device from must not be marked "unused" in their native disks' labels. This "device not configured" is the way ccdconfig informs you of this condition... :-)

Actually, I guess this indicates a need for a special "ccd component" type entry for disklabel? Or should the partition simply be marked as a "raw" partition, sharing this type with database log partitions etc?

4.4.5.2 : I can't log in as 'su'. What does that message mean when I log in as root.

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

Yes. Here are a couple:

(1) Nemeth, Snyder, and Seebass, "Unix System Administration i Handbook"

(2) Horspool, "The Berkeley Unix Environment"

There are three ways, listed here from most difficult to least difficult:

1) Use 'vi' to edit the /etc/master.passwd. Once you have changed the entry you want modified, run the program "pwd_mkdb -p /etc/master.passwd". This will rebuild the password database and update your /etc/passwd file. Cd to the /var/yp directory and run a "make" to update your 'NIS' database (important only if you are using NIS).

2) Use the 'vipw' program and make your change. This automatically rebuilds the password database and the /etc/passwd file. You still need to update the 'NIS' database on your own.

3) Use 'chpass', 'chfn', or 'chsh' programs to update the appropriate entry in the password database. These have the advantage of update the NIS stuff automatically.

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

There are several ways to achieve 'amd nirvana'. Each of these elements below is an important consideration for getting amd to work correctly.

The "-" means use these as defaults, so you need an entry without a "-". Also, I think one "-..." overrides the previous one completely.

As a start, you can use the following in your amd.project file:

usr/local opts:=rw;type:=nfs;rhost:=hostname;rfs:=/usr/local

Then run "amd /usr/local /your/map/name -type:=direct".

One word of warning, however. In NetBSD 1.0, I couldn't get direct mount points to work for some reason. I don't know if this has been fixed or not.

If you are using a NetBSD 1.0 (or earlier) system, make /usr/local a real symbolic link into an automount filesystem.

Another instance of the amd.project file might look like this: /defaults type:=nfs;opts:=rw,soft,intr,grpid local \ host==hostname;type:=link;fs=/usr/local ||\
host!=hostname;rhost:=hostname;rfs:=/usr/local

You amd.master file might look like this: /project amd.project

Here's another example which auto-mounts /usr/src from another machine:

grizu% ls -lad /usr/src lrwxr-xr-x 1 root wheel 29 Dec 30 15:33 \ (split by ed.) /usr/src -> /tmp_mnt/mounts/src10/usr/src

grizu% cat /etc/amd/master /net /etc/amd/net /tmp_mnt/mounts /etc/amd/src

grizu% cat /etc/amd/net /defaults type:=host;fs:=${autodir}/${rhost};rhost:=${key} * opts:=ro,soft,intr

grizu% cat /etc/amd/src /defaults type:=host;fs:=${autodir}/${rhost}; src10 opts:=rw,soft,intr;rhost:=rfhu1001

grizu% grep ^amd /etc/netstart amd=YES amd_dir=/tmp_mnt # AMD's mount directory amd_master=/etc/amd/master # AMD 'master' map

grizu% ls -la /tmp_mnt total 9 drwxr-xr-x 5 root wheel 512 Jan 3 12:09 . drwxr-xr-x 26 root wheel 1024 Jan 3 12:09 .. dr-xr-xr-x 3 root wheel 512 Nov 20 19:29 ftp.uni-regensburg.de dr-xr-xr-x 2 root wheel 512 Jan 4 10:43 mounts dr-xr-xr-x 4 root wheel 512 Dec 11 08:18 rfhu1001

grizu% ls -la /tmp_mnt/mounts total 3 dr-xr-xr-x 2 root wheel 512 Jan 4 10:43 . drwxr-xr-x 5 root wheel 512 Jan 3 12:09 ..

I guess that's all. rfhu1001 is the NFS server, grizu the client.

From the README file in the BIND distribution:

Versions of NSLOOKUP up through BIND 4.8.3's used IQUERY to ask the local server for information about the server's own name. I assume that this was done in a "what the heck, nothing uses these, how can we contrive a need?" sort of spirit. I removed this code as of BIND 4.9's NSLOOKUP and had it use the standard gethostbyaddr() mechanisms (which depend on normal queries of PTR data). Disabling INVQ and putting "options fake-iquery" in the boot file will cause IQUERY to be answered bogusly but in a way that old nslookup programs won't trip on. INVQ is disabled by default in conf/options.h.

So, your options are:

- Add "options fake-iquery" to named.boot and restart the server

- Replace your old, broken nslookup with the one in the 4.9.3 BIND distribution.

-- Enable INVQ in conf/options.h, then rebuild and re-install named. This latter option isn't guaranteed to work. If
you point an old version of nslookup at a server, and the
server either is not authoritative for a zone containing
the A RR matching the address you are sending the query to,
or if this A RR is not in it's cache, then nslookup will
still fail even if the server has the INVQ option turned on.

4.6.1 : Where can I FTP the 'adduser' program?

There is one you can FTP (see the URL below). You will need to be able to use 'vipw' to make it work, but that shouldn't be a big problem for most people.

There is a Perl script called 'removeuser' which should be available from one of the 'CPAN' sites. As soon as someone has a URL, let me know.

There is also a FreeBSD 2.2 'rmuser' program which does everything the remove program does, plus removes crontab and at command entries.

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.

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.

These devices are also often referred to as character devices.

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

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.

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

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

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

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

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

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

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

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

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)

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.

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

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.

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)

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.

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

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

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

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.

This suggests that 32 512 blocks will be written at a time. This jives with the tape format for some of the lower density cartridges (QIC-40 and 80, for example). The tape is written in blocks of 32 512-byte blocks, with the last three being used for Error Correction Codes.

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

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

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

OK. There are lots of reasons why it may not. The most obvious is that there are no devices associated with the device in the kernel. You can check this through the use of the 'dmesg' command. Look for tape drives.

If your tape drive is connected to your floppy controller, it may or may not be supported. Several manufacturers of QIC-40/QIC-80 mini-cartridge drives are supported natively in FreeBSD and experimentally in NetBSD. Some aren't (mine for example, is not).

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.

Vipers can't do auto-detection. You have to create different devices for different densities. Minor number 8 = 120Mb, 4 = 150Mb and 12 = QIC-24 (60Mb). At least this is the only way it works for me, and since it do I haven't bothered to find out why minor 0 doesn't. If you have a 2525 (525Mb) it uses ST_Q_SENSE_HELP quirk but it might not work.

The cfg0-2 switches is for setting the disconnect size, e.g. the maximum size transfered before disconnect to allow other SCSI devices to access the bus. Jumper in sets bit to 1.

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

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

I assume that the driver is trying to use some SCSI-2 command to set the default density -- but after that, the drive is perfectly happy to do the tedious density check and off it goes. I've read all three densities on the drive. Once the drive is set up and the driver realizes there is no density command, it just brute forces the drive density and off it goes.

Of course, if you get this error, this program doesn't exist. This information comes from ../src/sbin/dump/pathnames.h. The reason we still use /etc/rmt and /dev/rmt8 is because the rdump and rrestore protocol call for those names.

This problem usually won't show up unless the original installation of the system was done before NetBSD 0.9 *AND* the etc.tar.gz distribution was never done. This distribution fixes this problem by creating the symbolic link from where rmt lives to /etc/rmt. The Makefile for rmt should also create this link (I'd check before assuming it does.)

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

The first hurdle to overcome is that the default kernels do not have the GATEWAY option compiled in. Without this, it is very nearly impossible to use the kernel as a router.

Once you have the GATEWAY option compiled in, all sorts of things magically start to work. If you haven't got the GATEWAY option enabled, you can also use 'sysctl -w net.inet.ip.forwarding=1' if you are using FreeBSD or NetBSD versions that support that. Remember, once you build the new kernel, you will need to install it in the root directory and reboot.

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

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

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

traceroute -s YOUR_ETHERNET_ADDRESS 129.186.150.150

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

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.

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

ifconfig de1 inet 199.232.137.65 mask 255.255.255.192 alias

Gated is running with this config:

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

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

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

All routing and networking is fine right after I start gated. However, if I leave out the 'interface passive' section, gated shuts down the two routes on de1 after a couple of minutes.

If you're trying to join the Mbone, you need to find someone willing to provide you with a "feed", and that person's router will be at the other end of your tunnel. If you're just trying to set up your own private little multicast domain, then you need to set up other such routers on other subnets and interconnect them with tunnels. If you just want to run a little multicast testbed on a single subnet, you don't need any multicast routers at all! See the Mbone FAQ at:

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

There are a myriad of questions about how to share a disk between *BSD and MS-DOS. They all boils down to one of the <n> following questions:

1) How can I partition my drive for both MS-DOS and *BSD? 2) I can install using the whole disk, but I can't install when I try to share the drive between *BSD and MS-DOS. Why? 3) I can use either MS-DOS or *BSD on my hard drive, but shutdown -todos doesn't seem to work.

NOTE: Before attempting to install *bsd on a computer with an active DOS partition, ALWAYS back up your hard drive. No one on the net, no matter how talented, can help you recover a hosed MS-DOS file system. If you lose all of your data, it is YOUR fault.

During the install phase, you need to have un-allocated space left on your disk drive. This allows the install program to correctly install the *bsd partition in the partition table and DOS to peacefully co-exist with *bsd.

If you do not have any space available on your hard drive, you will not be able to install both. Re-fdisk your hard drive and make sure you have left un-allocated space in the partition table. This WILL wipe out your DOS partition - Permanently.

Even though the partition table procedure above may have worked, there are still no guarantees that your system will boot after the install. This problem most often manifests itself as one of the endless reboot problems. You would normally be able to boot DOS from the hard disk, but not *bsd (once that partition is marked as active).

Once the partition table has been correctly defined with both DOS and *bsd, there can still be problem. One of the most common is that the disk drive works in some sort of translation mode. This is particularly common with drives that physically have more than 1024 cylinders. DOS cannot access a drive with more than 1024 cylinders. Translation mode will have to be turned off, usually by redefining your hard drive in SETUP as one of the user definable types. This change will normally trash your hard drive, or at least render your DOS partition unreadable.

The solution to this problem is to install *bsd at the end of the hard drive. While DOS cannot use cylinders above 1024, *bsd has no such limitations, once it has booted. During the boot-up phase, some of the newer boot blocks will refer to the BIOS for some services. Specifically, the disk is checked for a bad sector map on the last track. Since the BIOS cannot deal with cylinders higher than 1024, your bad sector map will be incorrectly identified as 1023 if the number of cylinders is larger than that. This problem is being worked on, and I hope to change this section with better news later.

NOTE: The only people that this problem will effect are those MFM and ESDI users that have drives with more than 1023 tracks. While drives of this type are not the overwhelming majority, neither are they an anomaly. People are working on it.

As an example, if your hard disk physically has 8 heads, 16 sectors per track, and 2000 cylinders (128M); you MUST use some sort of disk translation in order to use the entire drive. An obvious geometry for this drive (for DOS) would be 16 heads, 16 sectors, and 1000 cylinders. Unfortunately, *bsd operates using the disk drives native geometry as reported during the probe phase of boot up. This will probably be 8/16/2000, and will NOT agree with your translated disk geometry. This causes an endless reboot cycle. If you change the geometry so that the drive agrees with the disklabel, your DOS partition is toast.

The best way to operate in this case would be to (for example) split the disk in half. That leaves 64M for DOS, using a geometry of 8 heads, 16 sectors per track, and the first 1000 cylinders for DOS. The second 1000 cylinders could then safely be used for *bsd. The DOS partition table may even be capable of showing this partition as it actually exists.

ACCESSING MS-DOS PARTITIONS FROM NetBSD-i386

First off, it's important to understand BSD disklabels. The disklabel is a description of the Unix partition layout and other disk parameters stored on-disk, usually somewhere in the first couple of sectors. There is a maximum of 8 partitions, labelled "a" thru "h". Typically partition "a" is assigned to the root partition, partition "b" is configured as a swap area, and partition "c" is defined as the whole disk. You can change these, but it's a good idea to stick with this scheme, as many programs assume that's the way things are going to be.

If you're whole disk is dedicated to Unix, then that's all you need to know. But if you're sharing your disk with DOS, then there are a few magical things happening.

DOS has it's own partitioning scheme. The way NetBSD co-exists with this is to fit all of the Unix partitions into one DOS partition. So partitions a-h all fit inside one DOS partition, which has a partition type of 165 (each MS-DOS partition has a "partition type" associated with it. The BSD partition type is 165). In this setup, partition "c" refers to the entire BSD partition. But in this scheme, partition "d" refers to the ENTIRE disk, MS-DOS partitions and all.

So, if you want to access your MS-DOS partition from NetBSD, first you'll have to create a partition that points to the MS-DOS partition. You'll want to run the command:

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

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

6 partitions: # size offset fstype [fsize bsize cpg] a: 30720 409600 4.2BSD 1024 8192 16 # (Cyl... b: 129024 440320 swap # (Cyl... c: 1617920 409600 unused 0 0 # (Cyl... d: 2029568 0 unused 0 0 # (Cyl... e: 61440 569344 4.2BSD 1024 8192 16 # (Cyl... f: 1396736 630784 4.2BSD 1024 8192 16 # (Cyl...

(or whatever it appropriate for your disk). Note that partition "a" starts on cylinder 200. That's where my BSD partition starts on my disk. Also note that partition "c" starts at 200 as well and goes to the end of the disk. You'll also note that partition "d" goes from sector 0 all the way to the end of the disk.

Add a new line that looks something like:

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

(The comment on the end isn't necessary. Only the partition letter, size, offset, and partition type are needed. You can put unused in instead of MS-DOS if you want).

*NOTE* Be sure to change the line that says "6 partitions" to the new number of partitions that you have!!! Otherwise you'll get an obscure error. In my case I'd change that line to be "7 partitions". If you aren't sure what your MS-DOS partition size and offsets are, you can use the NetBSD fdisk to find them out. Don't forget that there's a maximum of 8 partitions.

Once you do that and you have MSDOSFS configured into your kernel, you can just do something like "mount -t msdos /dev/sd0g /msdos". Or you can put a line like this in your fstab:

/dev/sd0g /msdos msdos rw 0 0

If you want to access a DOS-only HD from NetBSD, here are some instructions posted by Charles Hannum a while back. I haven't tried them myself, but they seem like they would work.

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

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

2) Save a copy of the MBR:

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

3) Use `disklabel' to create a NetBSD label with the DOS partition and whatnot. Answer `y' when it asks you if you want to `overwrite [a] disk with [a] DOS partition table'.

4) Put back the saved copy of the MBR:

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

This works for me. Your mileage may vary.

This is an extension of the question above. The most common reason for this is, once again, disk translation problems. If the disklabel does not agree with the disk geometry, the install will fail. Other incarnations of this problem are that you can install DOS, then *BSD, and DOS will be hosed, or vice versa.

There are more than a couple of people who will blithely suggest that this is a good thing, and you should install *BSD exclusively, job not withstanding.

There is currently a project in development to port the Windows program environment to Linux and the *BSD systems. Here is an excerpt from the original message announcing the project:

As many of you already know, we are in the process of creating a Windows emulator. This emulator is similar to Sun's Wabi product, but is being developed completely independent of them. Many of you are anxious to hear the latest status of the project. I have created a mailing list for those of you. To join the list, simply send mail to:

One of the most common MS-DOS related questions (with the possible exception of 6.2 above) is how to access the DOS disk partitions from *BSD.

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

2. Second, use 'fdisk' to see where your DOS partition starts. It will be labeled as type DOS. On my system, 'fdisk /dev/sd0d' produces the following:

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

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

NOTE: If you're trying to mount a DOS `EXTENDED' partition, then you need to add the number of sectors per track to this start address you got from fdisk in subsequent calculations, I.E. in the above example (assuming it was an EXTENDED partition rather than the Primary), you'd use `start 64, size 306400'.

[Ed.Note. This example assumes a SCSI disk. For disks with a number of sectors per track which is different than 32, you will probably see the 32s above replaced with your number of sectors per track. IDE, MFM, and ESDI drives are all examples where the number of sectors per track is likely to NOT be 32.]

3. Next, using this information, you craft a new disk entry in your /etc/disktab file that assigns one of your unused "UNIX" partitions to this DOS region. Again, using my system as a default, you see I've created:

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

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

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

Also, there may be a problem with some versions of disklabel not recognizing the MSDOS (or MS-DOS, depending) in the te: entry above. You may need to run a "disklabel -e" to get the partition type to 'stick'.

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

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

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

6. Mount the DOS partition. I do:

mount -t pcfs /dev/sd0e /dos_c

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

7. You're set!

With the exception that the '-t' option is msdos in NetBSD, these instructions seem to work with the same facility for NetBSD. I also received a note a couple of weeks ago (that I promptly deleted because I new that I would remember what it said) that DOS extended partitions are readable if you skip the first 'n' blocks in your computations (where 'n' is your number of sectors per track). This way, you skip over the 'new' part of the DOS file system. That means that instead of the oe:32 above, you would need an oe:48 instead.

Also remember that the compressed file system in DOS 6 will probably be completely Greek to your NetBSD/FreeBSD system. I seriously doubt that you will be able to read the compressed DOS file system anytime in the foreseeable future.

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

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 problem is a standard NFS problem; it simply means that your user number is not one of the ones that can mount this NFS. Normally, you will get this message when you are trying to mount a filesystem from a machine that allows 'root' to mount an NFS, but limits other users.

Another documented problem with "client credentials being too weak" is the dichotomy of SunOS and 4.4 based systems. SunOS, and other commercial systems, do not allow NFS commands to come in on anything but a reserved port. There are several places that need to be addressed if weak credentials are a problem. The first is the mount command. The mount itself may work, but all references to files in the NFS will fail. This is usually the most common symptom of this problem. The solution for this is to either include the '-o resvport' keyword pair on the mount command, or the -P option. In addition to the resvport command on the mount, it may become important to include an NFS volume in your fstab. If this is the case, you will need to ensure that the resvport keyword is added on the mount line in the fstab. Finally, if you are using the automounter, you will need to make absolutely certain that you have included the resvport option in your automount maps as the default.

Try turning off rfc1323 support:

sysctl w net.inet.tcp.rfc1323=0

only in newer builds. In older versions you have to edit a kernel config file. RFC1323 is not yet supported by all networks, and can cause TCP performance degradation when tried. This, for example, is a known problem on older Sun and VAX hosted networks, and on many networks which are using Linux as an intermediate host.

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.

With the adoption of BSD 4.4, there is a new way of accessing the floppy disk drive types. The method uses the minor device number to specify different media sizes and densities. These densities are established by a table from the file /usr/src/sys/arch/i386/isa/fd.c in NetBSD (your mileage may vary). The table in FreeBSD's fd.c is likely to be slightly different.

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

/dev/fd0a 0 /* default disk type */ /dev/fd0b 1 /* 1.44MB diskette */ /dev/fd0c 2 /* 1.2 MB AT-diskettes */ /dev/fd0d 3 /* 360KB in 1.2MB drive */ /dev/fd0e 4 /* 360KB PC diskettes */ /dev/fd0f 5 /* 3.5" 720KB diskette */ /dev/fd0g 6 /* 720KB in 1.2MB drive */ /dev/fd0h 7 /* 360KB in 720KB drive */

struct fd_type fd_types[] = { { 18,2,0xff,0xcf,0x1b,0x6c,80,2880,1,FDC_500KBPS,2,"1.44MB" }, { 15,2,0xff,0xdf,0x1b,0x54,80,2400,1,FDC_500KBPS,2,"1.2MB" }, { 9,2,0xff,0xdf,0x23,0x50,40, 720,2,FDC_300KBPS,2,"360KB/AT"}, { 9,2,0xff,0xdf,0x2a,0x50,40, 720,1,FDC_250KBPS,2,"360KB/PC"}, { 9,2,0xff,0xdf,0x2a,0x50,80,1440,1,FDC_250KBPS,2,"720KB" }, { 9,2,0xff,0xdf,0x23,0x50,80,1440,1,FDC_300KBPS,2,"720KB/x" }, { 9,2,0xff,0xdf,0x2a,0x50,40, 720,2,FDC_250KBPS,2,"360KB/x" }, };

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

Implementations of Point to Point Protocol are also available. PPP has been available since the 0.9 release of NetBSD and is in the current releases of FreeBSD, OpenBSD, and NetBSD.

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

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

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

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

And in the chat.my-isp file:

ABORT BUSY ABORT ERROR ABORT 'NO DIALTONE' ABORT 'NO CARRIER' '' ATZ OK ATDT1234567 CONNECT \d TIMEOUT 5 ogin:\s--ogin:\s mylogin ssword: mypasswd prompt:\s /usr/lib/ppp/ppp

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

To kill the connection: root # kill `cat /var/run/ppp0.pid` which has the added advantage of hanging up the phone if the modem is set up appropriately.

The biggest problem that I ever had with this was working out the chat script and that was debugged by adding the following line in /etc/syslog.conf:

# Hand chat debug messages to root local2.debug root

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

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

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

pseudo-device ppp 1

This line adds a device driver to the kernel that does the ppp protocol. Once I had that built in, everything worked the first time.

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

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

2. "Suspend" kermit (i. e. put it in the background). This gets me back to the shell prompt. (You can get kermit back using the "fg" command)

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

That's it. This procedure will get you access to machines by using their IP address numbers. You still have to configure a name server in "resolv.conf" in order to get DNS functionality. My resolv.conf looks like this:

domain umd.edu # Maryland's domain name nameserver 128.8.5.2 # These are the IP addresses of three nameserver 128.8.126.2 # hosts that can act as name servers nameserver 128.8.126.3

The name servers should be as "close" as possible. Whatever machine manages the modem pool your on would be the best but any machine on your local loop will give you good performance.

If your Internet Service Provider uses dynamic addressing, You don't even have to worry about this. It's the point of PPP. It's actually a good thing from a security point of view. Your IP address changes w.r.t. to the rest of the net periodically. By the way, don't forget passwords on all your accounts!! When your on PPP, the rest of the net can see you too, you look like a full Internet host.

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

Here is a sample PPP config.

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

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

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

3) Make sure the modem line (in the '/etc/ttys' file) doesn't have the 'local' or 'softcar' options included. With 'local;, CLOCAL will be set for that line and SIGHUP may or may not be sent, apparently based on the age of the software. The "modem" option in the 'options' file (above) should clear that, but it may or may not ever work. If you have "softcar" in /etc/ttys, then the SIGHUP (in fact, almost all of the signals) will never work because the modem lines are effectively ignored, thereby leaving the modem in whatever mode it is in.

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

ABORT BUSY ABORT 'NO CARRIER' '' atdt5551212

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

This setup uses LCP and IPCP (parts of PPP) to negotiate the dynamic IP addresses. This setup assumes an ISP which uses an annex terminal server. It prompts for "Annex username:" and "Annex password:". You then get to the command line prompt: "annex:", at which point "PPP" starts the PPP session. You will have to edit this to suit. If your ISP uses a system where you are automatically connected to PPP when you log in, your '/etc/ppp/sample.chat' file might look like this:

ABORT BUSY ABORT 'NO CARRIER' '' atdt5551212

rname: {sample} sword: crackme

To implement a 'permanent PPP' dial-up connection, the following has been used (by me specifically!) This works in NetBSD 1.1 or higher, OpenBSD, and perhaps recent versions of FreeBSD:

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

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

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

/dev/tty01 115200 connect "/usr/sbin/chat '' 'atdt1' 'ogin:' 'x' 'sword:' 'x'" crtscts defaultroute lock netmask 255.255.255.0 n.n.n.n:n.n.n.n -ip modem mtu 1500 -detach

You will, of course, have to make some changes if you have multiple ppp connections. The key here is the '-detach' to make the pppd remain connected to the controlling terminal (the modem). The basic idea is if the link drops (i.e. loses carrier), a hangup signal will be sent to pppd, causing it to exit, and init will restart it.

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

There are two possibilities. One is that the Van-Jacobsen compression is messing up one of the computers on the link. Test this by disabling VJ compression on the PPP link (change the options file to use '-vjccomp').

The other possibility is one of the machine in the circuit is not processing handshaking correctly. Check the &k setting (for hardware handshaking) and makre sure it is set correctly. Also check your cables (if appropriate).

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

TCP/IP is an integral part of BSD 4.4 Lite. There are at least five different network card drivers. TCP/IP is fully supported and is available to all users of all derived BSD systems. In fact, many people believe that this area is one of the primary advantages that BSD has over Linux. After all, TCP/IP was invented in BSD.

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.

First thing you need to do is...

vi /etc/remote

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

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

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

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

Make sure that, if you are running newsyslog, you change the owner.group entry in the newsyslog.conf file so that the file ownership is maintained correctly.

Then you should be all set, remember "DOS Com1" = tty00, and "DOS Com2" = tty01. So, if your modem is at 0x2F8/IRQ=3 and you access it as the COM2: port from DOS, you would do..

tip tty01

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

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

lock open: no such file or directory all ports busy

You need to create a directory: /var/spool/lock, owned by uucp. If this file already exists and is owned correctly, make sure that the lock file in the directory is deleted.

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

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

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

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

port mymodem type modem
device /dev/tty01
speed 19200

Now cu knows that the line is connected to a modem it does the right thing regarding setting CLOCAL on the line. You don't even have to have either of local or softcar set in /etc/ttys.

Since cu's behavior seems to be correct, I'm happy now. All I need to really make my day though is to have John or Martin to tell me that cu 1.04 still works for them even though they don't have an /etc/uucp/ports (or equivalent HDB or V2 uucp config) file ... :-)

Try 'stty -f /dev/tty0? clocal'. Change the '?' for whatever character is appropriate for your tty port. Remember, DOS COM1 = /dev/tty00 and DOS COM2 = /dev/tty01...

Some other things that might cause some problems are the entries in the /etc/remotes file. Try 'com?:dv=/dev/tty0?:br#19200:pa=none' and see if that helps. Remember to replace the '?' with '[01234]' as appropriate.

NetBSD-current has implemented the 'ttyflags' program. This will set your com ports according to the options specified in the /dev/ttys files. This is an even better solution than the 'stty ... clocal' fix from above!

FreeBSD sets this up a little bit differently by having separate dial in and dial out devices available. The /dev/cua?? devices all have clocal set by default to allow the system to dial out without having a carrier present. If you are using FreeBSD and don't have any cua devices in the /dev/ directory, you need to run the ./MAKEDEV script. See the man page for more information.

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.

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.

(1) Go into sendmail's source directory tree

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

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

mkdir obj

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

vi yourname.mc

(4) Contents of the yourname.mc file:

#--------------------------------------------------------------- divert(-1) # # This is the prototype for a site with only a uucp connection # to the world, where smarthost and uucp relay are the same ... # Replace "yourname" with your machines nodename without domain # Replace "smarthost" with your uucp neighbours nodename without # domain i.e. here is myname "knobel" and my smarthost is "gomel", # to which I'm connected with uucp via dialup modem.

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

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

OSTYPE(bsd4.4)

FEATURE(nodns)dnl

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

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

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

Put a list of machines into this file to which you have active uucp/mail connection. Generally only the name of your smarthost .... Unknown addresses are routed to your smarthost ....

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

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

make yourname.cf

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

(7) It's up to you to browse through the systems global aliases file ((etc/aliases), where important mail aliases are stored. After editing this file you should invoke the command newaliases to update the corresponding database file

newaliases

(8) Then create/edit the file "/etc/sendmail.cw". This file contains alias names of your system (a list of additional names under that your system might receive e-mail):

yourname yourname.uucp yourname.domain

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

.uucp uucp-uudom:name_of_your_uucp_smarthost

(10) Create the hash table the following way:

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

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

newaliases

(11) BTW: You do not need to create a frozen config file, since sendmail on FreeBSD 1.X and NetBSD aren't compiled with that option turned on.

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

Yes, they can, assuming the machine at the other end of the connections is reasonably cooperative. The specifics are up to the remote machine, but a couple of things that you can start looking for that will help are provided below:

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

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

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

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

Note that not all network clients are created equal. There may be semantic differences between what you EXPECT to happen and what actually happens. Your best bet at that point is to get with the local system manager and talk to him or her about what you should be expecting on the system and what is actually happening. An excellent example is the semantics of file group accounts when a new file is created on an NFS machine. The semantics of the create will be based on the OS on the SERVER, so it will be whatever SysV or Sun thinks is correct, not what we expect from the BSD side.

There is a package available which can also be used by *BSD which will allow your machine to be visible to LanManager or Windows NT clients. The package is called 'SAMBA' and includes information about how to configure the package to work with NetBSD, OpenBSD, and FreeBSD. Works good for me.

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

In FreeBSD, there is a file called Diskless.FAQ in the usr/share/FAQ directory. It describes the procedures for diskless booting of an i386 on FreeBSD.

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

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

It depends. There are several levels of ISDN, all of which seem to be incomaptible. One of the highly regarded packages for adding most ISDN connectivity is the bisdn package available from muc.ditec.de.

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, users who desire more than 16Meg of memory must use either VESA or EISA systems. Even with an EISA system, many users will not be able to use the address space above 16Meg unless their system uses only EISA cards for those devices that need access to DMA. The limitations are covered in another section of the FAQ.

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 about 13 CPUs.

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

-Ade "never wants to see this again" Barkah

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.

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.

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 '{something} based' cards above are special in that many controllers use these controller chips as the basis for their implementation. The AIC-6260 is the chip set in the Adaptec 1522 series controllers, and the AIC-6360 is the chipset used in the Soundblaster SCSI controller. There are several PCI controllers that are using the NCR chipset.

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.

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

First, set up your printer so it uses the 'LF' code as its CR+LF (End of line) character. If you use your machine for operations in more than one OS (like some of us that HAVE to use DOS :-( ) then you can include a control sequence in the 'ff' control in your /etc/printcap file.

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:

For the HP LaserJet III (running PostScript) or the Deskjet 540 printers, the sequence is a little more involved:

First, it looks like you will need to install ghostscript. I have a Desk Jet 540 that I use with the printcap entry and filter included below. You could hack the filter slightly to produce output for your Laser Jet III (try changing "-sDEVICE=djet500" to "-sDEVICE=ljet3").

You'll need perl and gs installed on your system. You also need to ensure that gs has the ljet3 driver installed. You can find out by running "gs -h" and looking to see if the driver is listed.

--- printcap entry --- lp|HP Deskjet 540:\ :lo=/var/spool/lpd/lp-lock:\ :lp=/dev/lpt0:\ :lf=/var/log/lpd-errs:\ :of=/var/spool/ps-filter:\ :sd=/var/spool/lpd:\ :sh:

--- /var/spool/ps-filter --- #!/usr/bin/perl # Filter which detects postscript files and appends cr to lines of text. # $Id: bsd-complete.faq.html,v 1.2 2001/06/10 19:12:42 wcooley Exp $

$cat="/bin/cat"; $gs="/usr/local/bin/gs";

$_ = <STDIN> if (/^%!/) { # Pipe the file as-is to the ghostscript interpreter. # Postscript files have their pages reversed because my # DeskJet 540 stacks them in reverse order if I don't. $old_dir=`pwd`; $tmp_dir = "/tmp/lp-gs.$$"; mkdir($tmp_dir,0700); chdir $tmp_dir; open(PIPE, "|$gs -q -sDEVICE=djet500 -sOutputFile=%03d.lj -") || die "$0: can't run ghostscript: $!";
print PIPE $_; while (<STDIN>) { print PIPE $_;
} close PIPE; @pages=reverse(sort(<*.lj>)); system $cat, @pages; unlink @pages; chdir $old_dir; rmdir $tmp_dir; } elsif (&isprint() && !/\r\n$/) { # Send the text to the printer with trailing lf converted to crlf. s/([^\r])?\n$/\1\r\n/; print; while (<STDIN>) { s/([^\r])?\n$/\1\r\n/;
print;
} } else { print; while (<STDIN>) { print; } } sub isprint { ($c) = split(//,$_); return ($c =~ /[\s\n]/) || (ord($c) >= 32 && ord($c) < 127); }

If you are having trouble with the JetDirect card, this entry should work adequately for you, although printing and querying may not be completely solid:

laser: \
:rm=laser.kew.utl: \ :rp=lp: \
:sd=/usr/spool/lpd/laser: \
:lf=/var/log/lpd-errs: \
:sh: \
:rs: \
:ff=: \
:fo

First step: Add ":mx#0:" to the printer's entry in /etc/printcap.

Once you have "mx#0" in your /etc/printcap entry, make sure you have enough disk space in the "/var" filesystem to handle the job. Also beware that "lpr -s" can fail obscurely if the file you are printing (and the path to it) are not accessible by the user daemon.

8.8.1 : What are the jumper configurations for the Exabyte 8200 DAT tape drive?

Jumpers/switches are on the MX board. I think that the top of the case and the board must be removed to access jumpers/switches. Per a November 1989 8200 Spec there are at least two different MX boards. Level 1, part no 724021-xxx has jumpers. Level 2, part no 724022-xxx has switches.

Level 1 Jumper Configuration:

J1 L-M Bypass Memory Test - 8 Second Startup M-R Run Memory Test - 65 Second Startup

J2 L-M Parity Checking Enabled M-R Parity Checking Disabled

J3 L-M Even Byte Disconnect M-R Odd or Even Byte Disconnect

J4 L-M No Busy Enable M-R Report Busy Status

J5 L-M P6 Cartridge Type - Domestic M-R P1 Cartridge Type - International

J6 L-M Reserved for future use

J7 L-M Normal Operations M-R No Disconnect in Data Phase

J8 L-M Fixed Block Mode on Power Up M-R Variable Block Mode on Power Up

Level 2 Switch Configuration:

SW1 Off Run Memory Test - 65 Second Startup On Bypass Memory Test - 8 Second Startup

SW2 Off Parity Checking Disabled On Parity Checking Enabled

SW3 Off Odd or Even Byte Disconnect On Even Byte Disconnect

SW4 Off Report Busy Status On No Busy Enable

SW5 Off Fixed Block Mode on Power Up On Variable Block Mode on Power Up

SW6 Off Normal Operations On No Disconnect in Data Phase

SW7 Off Reserved for Future Use On

SW8 Off P6 Cartridge Type - Domestic On P1 Cartridge Type - International

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.

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. The current Mitsumi driver seems to work well with all of the Mitsumi controllers (FD-001x and older).

There are native (non-EIDE) Mitsumi CD-ROM drivers for NetBSD and FreeBSD. They are available in the latest release version of each. If your CD-ROM is not recognized by the kernel, and uses a Mitsumi controller, you will need to make changes to the mcd.c source file to change the behavior of the first getreply() function. Instead of exiting immediately, the check for whether the getreply was successful should be commented out and assumed to be correct. While this is a brute force method (it may find a CD-ROM that isn't even there) it will help many Mitsumi controllers probe correctly.

The EIDE ATAPI CD-ROM drive is now supported in the -current versions of FreeBSD and OpenBSD, and is supported experimentally in NetBSD Version 1.2 and higher.

FreeBSD also supports the Matsushita (Panasonic) CD-ROM drives.

The only other commonly available CD-ROM drive that is not supported is the SONY CD-ROM.

There are two ways. If the version of *BSD you have supports the union file system, you can use the following:

mount -t union -o -b /cdrom/ports /usr/ports cd /usr/ports make all install

If you want to use an fstab entry, try this:

/cdrom/ports /usr/src union rw,-b 0 0

If your version of *BSD doesn't support union file systems, you could use something like this:

mount /dev/cd0a /cdrom mkdir /usr/ports cd /usr/ports lndir /cdrom/ports . <wait for dirs to link up>

cd /usr/ports/mail/elm make all install

Just about all of it.

The program '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 implementing SLIP, PPP, or are directly connected to a network.

3) Edit all the scripts which come with cnews and replace every occurrence of /bin/sh with /usr/local/bin/bash (or wherever you put it).

4) Build cnews using bash, gmake and gcc 2.x

5) Install cnews in the directories you want it. Some hand-hacking of the install scripts is required (Too long ago to remember the details).

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. The first is that the LINTLIBSTYLE option in config.data needs to be set to NONE, since NetBSD and FreeBSD don't come with lint. With that changed, the system should work right out of the box.

If you are running with memory mapped files, you will also need to make the following patch:

--- icd.c.orig Tue Feb 7 13:36:50 1995 +++ icd.c Tue Feb 7 14:56:27 1995 @@ -366,7 +366,9 @@ ICDwriteactive() { #if defined(ACT_MMAP) - /* No-op. */ + if (msync(ICDactpointer, 0)) { + syslog(L_ERROR, "msync error on active file: %m"); + }

#else

There has been a lot of discussion of the years about the default options for newfs. If you have "modern" disks and you created your filesystems with 1.0, or with a pre-9412 -current, then you may want to back them up and then re-create them. u Filesystems created with the current defaults should be much faster.

The newfs(8) defaults are equivalent to `-a 8 -d 0 -n 1'.

To make you news server software work better, you should increase the number of inodes available, you should include either '-i 512' or '-i 1024' depending on the normal size of the files in the filesystem. News partitions are often the repository for many files which are very small, averaging less than 1K bytes per file. By doubling the number of inodes (using -i 1024 instead of the default 2048) you make it more likely that you will run out of disk SPACE before you run out of disk INODES.

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:

There are a couple of ways to go about this. The first is just use either the FreeBSD or Linux version and load up the /emul directory.

The second is to load Penguin or Kaffe, both Java replacements.

In my experience, most of the commercial firewall systems started out as BSD systems.

In a dark dim machine room Cool A/C in my hair Warm smell of silicon Rising up through the air Up ahead in the distance I saw a Solarian(tm) light My kernel grew heavy, and my disk grew slim I had to halt(8) for the night The backup spun in the tape drive I heard a terminal bell And I was thinking to myself This could be BSD or USL Then they started a lawsuit And they showed me the way There were salesmen down the corridor I thought I heard them say

Welcome to Berkeley California Such a lovely place Such a lovely place (backgrounded) Such a lovely trace(1) Plenty of jobs at Berkeley California Any time of year Any time of year (backgrounded) You can find one here You can find one here

Their code was definitely twisted But they've got the stock market trends They've got a lot of pretty, pretty lawyers That they call friends How they dance in the courtroom See BSDI sweat Some sue to remember Some sue to forget So I called up Kernighan Please bring me ctime(3) He said We haven't had that tm_year since 1969 And still those functions are calling from far away Wake up Jobs in the middle of the night Just to hear them say

Welcome to Berkeley California Such a lovely Place Such a lovely Place (backgrounded) Such a lovely trace(1) They're livin' it up suing Berkeley California What a nice surprise What a nice surprise (backgrounded) Bring your alibis

Windows NT a dreaming Pink OS on ice And they said We are all just prisoners here Of a marketing device And in the judge's chambers They gathered for the feast They diff(1)'d the source code listings But they can't kill -9 the beast Last thing I remember I was restore(8)'ing | more(1) I had to find the soft link back to the path I was before sleep(3) said the pagedaemon We are programmed to recv(2) You can swap out any time you like But you can never leave(1)

[ substitute whirring of disk and tape drives for guitar solo ]