There are currently three active/semi-active branches in the FreeBSD
To make a release you need to do three things: First, you need to
be running a kernel with the Second, you have to have the whole CVS repository at hand.
- To get this you can use Then run Finally, you need a chunk of empty space to build into. Let's
say it's in /some/big/filesystem, and from the example
above you've got the CVS repository in /home/ncvs:
An entire release will be built in
/some/big/filesystem/release and you will have a full FTP-type
installation in /some/big/filesystem/release/R/ftp when you're
done. If you want to build your SNAP along some other branch than
-current, you can also add
The entire process of creating installation disks and source and
binary archives is automated by various targets in
/usr/src/release/Makefile. The information there should
be enough to get you started. However, it should be said that this
involves doing a ``make world'' and will therefore take up a lot of
time and disk space.
Yes, this is the general idea; as its name might suggest,
``make world'' rebuilds every system binary from scratch, so you can be
certain of having a clean and consistent environment at the end (which
is why it takes so long).
If the environment variable ${DESTDIR}.
Some random combination of shared libraries modifications and
program rebuilds can cause this to fail in ``
The Adaptec 1542 SCSI host adapters allow the user to configure
their bus access speed in software. Previous versions of the
1542 driver tried to determine the fastest usable speed and set
the adapter to that. We found that this breaks some users'
systems, so you now have to define the ``
Yes, you can do this
+ by using the Newer BSD based systems have a ``Here is an example from /usr/src/Makefile.
Please take a look at And thanks for the thought!
By: In a nutshell, there a few I/O ports that all of the PnP boards
respond to when the host asks if anyone is out there. So when
the PnP probe routine starts, he asks if there are any PnP boards
present, and all the PnP boards respond with their model # to
a I/O read of the same port, so the probe routine gets a wired-OR
``yes'' to that question. At least one bit will be on in that
reply. Then the probe code is able to cause boards with board
model IDs (assigned by Microsoft/Intel) lower than X to go
``off-line''. It then looks to see if any boards are still
responding to the query. If the answer was ``The IDs are two 32-bit fields (hence 2ˆ64) + 8 bit checksum.
The first 32 bits are a vendor identifier. They never come out
and say it, but it appears to be assumed that different types of
boards from the same vendor could have different 32-bit vendor
ids. The idea of needing 32 bits just for unique manufacturers
is a bit excessive.
The lower 32 bits are a serial #, ethernet address, something
that makes this one board unique. The vendor must never produce
a second board that has the same lower 32 bits unless the upper
32 bits are also different. So you can have multiple boards of
the same type in the machine and the full 64 bits will still be
unique.
The 32 bit groups can never be all zero. This allows the
wired-OR to show non-zero bits during the initial binary search.
Once the system has identified all the board IDs present, it will
reactivate each board, one at a time (via the same I/O ports),
and find out what resources the given board needs, what interrupt
choices are available, etc. A scan is made over all the boards
to collect this information.
This info is then combined with info from any ECU files on the
hard disk or wired into the MLB BIOS. The ECU and BIOS PnP
support for hardware on the MLB is usually synthetic, and the
peripherals don't really do genuine PnP. However by examining
the BIOS info plus the ECU info, the probe routines can cause the
devices that are PnP to avoid those devices the probe code cannot
relocate.
Then the PnP devices are visited once more and given their I/O,
DMA, IRQ and Memory-map address assignments. The devices will
then appear at those locations and remain there until the next
reboot, although there is nothing that says you can't move them
around whenever you want.
There is a lot of oversimplification above, but you should get
the general idea.
Microsoft took over some of the primary printer status ports to
do PnP, on the logic that no boards decoded those addresses for
the opposing I/O cycles. I found a genuine IBM printer board
that did decode writes of the status port during the early PnP
proposal review period, but MS said ``tough''. So they do a
write to the printer status port for setting addresses, plus that
use that address +
Several groups of people have expressed interest in working on
multi-architecture ports for FreeBSD and the FreeBSD/AXP (ALPHA)
port is one such effort which has been quite successful, now
available in 3.0 SNAPshot release form at This depends on whether or not you plan on making the driver
publicly available. If you do, then please send us a copy of the
driver source code, plus the appropriate modifications to
files.i386, a sample configuration file entry, and the
appropriate
In answer to the question of alternative layout policies for
directories, the scheme that is currently in use is unchanged
from what I wrote in 1983. I wrote that policy for the original
fast filesystem, and never revisited it. It works well at keeping
cylinder groups from filling up. As several of you have noted,
it works poorly for find. Most filesystems are created from
archives that were created by a depth first search (aka ftw).
These directories end up being striped across the cylinder groups
thus creating a worst possible senario for future depth first
searches. If one knew the total number of directories to be
created, the solution would be to create (total / fs_ncg) per
cylinder group before moving on. Obviously, one would have to
create some heuristic to guess at this number. Even using a
small fixed number like say 10 would make an order of magnitude
improvement. To differentiate restores from normal operation
(when the current algorithm is probably more sensible), you
could use the clustering of up to 10 if they were all done
within a ten second window. Anyway, my conclusion is that this
is an area ripe for experimentation. Kirk McKusick, September 1998
[This section was extracted from a mail written by
[<ben@rosengart.com> posted the following panic
message]
[When] you see a message like this, it's not enough to just
reproduce it and send it in. The instruction pointer value that
I highlighted up there is important; unfortunately, it's also
configuration dependent. In other words, the value varies
depending on the exact kernel image that you're using. If you're
using a GENERIC kernel image from one of the snapshots, then
it's possible for somebody else to track down the offending
function, but if you're running a custom kernel then only
What you should do is this:
I see people constantly show panic messages like this but
rarely do I see someone take the time to match up the
instruction pointer with a function in the kernel symbol table.
The best way to track down the cause of a panic is by
capturing a crash dump, then using
In any case, the method I normally use is this:
[Note: Now that FreeBSD 3.x kernels are Elf by default,
you should use
Note that YOU DO To make sure you capture a crash dump, you need edit
/etc/rc.conf and set /etc/rc.conf, the /var/crash.
NOTE: FreeBSD crash dumps are usually the same size as the
physical RAM size of your machine. That is, if you have 64MB of
RAM, you will get a 64MB crash dump. Therefore you must make sure
there's enough space in /var/crash to hold the dump.
Alternatively, you run Once you have recovered the crash dump, you can get a stack
trace with
Note that there may be several screens worth of information;
ideally you should use Now, if you're really insane and have a second computer, you
can also configure [Bill adds: "I forgot to mention one thing: if you have
DDB enabled and the kernel drops into the debugger, you can
force a panic (and a crash dump) just by typing 'panic' at the
ddb prompt. It may stop in the debugger again during the panic
phase. If it does, type 'continue' and it will finish the crash
dump." -ed]
The ELF toolchain does not, by default, make the symbols
defined in an executable visible to the dynamic linker.
Consequently dlsym() searches on handles obtained
from calls to dlopen(NULL, flags) will fail to find
such symbols.
If you want to search, using dlsym(), for symbols
present in the main executable of a process, you need to link
the executable using the -export-dynamic option to the
By default, the kernel address space is 256 MB on FreeBSD 3.x
and 1 GB on FreeBSD 4.x. If you run a network-intensive server
(e.g. a large FTP or HTTP server), you might find that 256 MB is
not enough.
So how do you increase the address space? There are two aspects
to this. First, you need to tell the kernel to reserve a larger
portion of the address space for itself. Second, since the
kernel is loaded at the top of the address space, you need to
lower the load address so it doesn't bump its head against the
ceiling.
The first goal is achieved by increasing the value of
src/sys/i386/include/pmap.h. Here's what
it looks like for a 1 GB address space:
To find the correct value of
To achieve the second goal, you need to compute the correct load
address: simply subtract the address space size (in bytes) from
0x100100000; the result is 0xc0100000 for a 1 GB address space.
Set src/sys/i386/conf/Makefile.i386
to that value; then set the location counter in the beginning of
the section listing to the same value, as follows:
Then reconfig and rebuild your kernel. You will probably have
problems with /usr/include/vm/.
NOTE: the size of the kernel address space must be a multiple of
four megabytes.
[
FreeBSD supports EIDE and SCSI drives (with a compatible
controller; see the next section), and all drives using the
original "Western Digital" interface (MFM, RLL, ESDI, and
of course IDE). A few ESDI controllers that use proprietary
interfaces may not work: stick to WD1002/3/6/7 interfaces
and clones.
See the complete list in the
- Any SCSI drive connected to a supported controller is supported.
The following proprietary CD-ROM interfaces are also supported:
All non-SCSI cards are known to be extremely slow compared to
SCSI drives, and some ATAPI CDROMs may not work.
As of 2.2 the FreeBSD CDROM from Walnut Creek supports booting
directly from the CD.
FreeBSD supports the SCSI ZIP drive out of the box, of course. The
ZIP drive can only be set to run at SCSI target IDs 5 or 6, but if
your SCSI host adapter's BIOS supports it you can even boot from
it. I don't know which host adapters let you boot from targets
other than 0 or 1... look at your docs (and let me know if it works
out for you).
ATAPI (IDE) Zip drives are supported in FreeBSD 2.2.6 and
later releases.
FreeBSD 3.0-STABLE contains support for the parallel Zip
However, you will need to build a new kernel with
support for ppbus (Parallel Port Bus) in order to use the Zip. See
the LINT configuration file for examples.
Also check out ,
and .
Apart from the IDE version of the EZ drive, these are all SCSI
devices, so the should all look like SCSI disks to FreeBSD, and
the IDE EZ should look like an IDE drive.
FreeBSD only appears to use more swap than Linux. In actual fact, it does not. The main difference between FreeBSD and Linux in this regard is that FreeBSD will proactively move entirely idle, unused pages of main memory into swap in order to make more main memory available for active use. Linux tends to only move pages to swap as a last resort. The perceived heavier use of swap is balanced by the more efficient use of main memory.
Note that while FreeBSD is proactive in this regard, it does not
arbitrarily decide to swap pages when the system is truely idle. Thus
you will not find your system all paged out when you get up in the
morning after leaving it idle overnight.
To understand why FreeBSD uses the a.out format, you must
first know a little about the 3 currently "dominant" executable
formats for UNIX:
The oldest and `classic' unix object format. It uses a
short and compact header with a magic number at the beginning
that's often used to characterize the format (see
The SVR3 object format. The header now comprises a section
table, so you can have more than just .text, .data, and .bss
sections. The successor to FreeBSD tries to work around this problem somewhat by
providing a utility for branding a known for more information.
FreeBSD comes from the "classic" camp and has traditionally used
the Back in the dim, dark past, there was simple hardware. This
simple hardware supported a simple, small system. a.out was
completely adequate for the job of representing binaries on this
simple system (a PDP-11). As people ported unix from this
simple system, they retained the a.out format because it was
sufficient for the early ports of unix to architectures like the
Motorola 68k, VAXen, etc.
Then some bright hardware engineer decided that if he could
force software to do some sleazy tricks, then he'd be able to
shave a few gates off the design and allow his CPU core to run
faster. While it was made to work with this new kind of
hardware (known these days as RISC), In addition, program sizes were getting huge and disks (and
physical memory) were still relatively small so the concept of a
shared library was born. The VM system also became more
sophisticated. While each one of these advancements was done
using the However, as time passed, the build tools that FreeBSD derived
their build tools from (the assembler and loader especially)
evolved in two parallel trees. The FreeBSD tree added shared
libraries and fixed some bugs. The GNU folks that originally
write these programs rewrote them and added simpler support for
building cross compilers, plugging in different formats at will,
etc. Since many people wanted to build cross compilers
targeting FreeBSD, they were out of luck since the older sources
that FreeBSD had for as and ld weren't up to the task. The new
gnu tools chain (binutils) does support cross compiling,
You have to use either `` and
With the trailing slash, You'd think it'd be easy enough to change If you're absolutely confident in your ability to find and fix
these sorts of problems for yourself when and if they pop up, you
can increase the login name length in earlier releases by editing
/usr/include/utmp.h and changing UT_NAMESIZE accordingly. You must
also update MAXLOGNAME in /usr/include/sys/param.h to match
the UT_NAMESIZE change. Finally, if you build from sources, don't
forget that /usr/include is updated each time! Change the appropriate
files in /usr/src/.. instead. Yes, starting with version 3.0 you can using BSDI's if you're interested in
joining this ongoing effort!
For pre-3.0 systems, there is a neat utility called
SUP is not bandwidth friendly, and has been retired. The current
recommended method to keep your sources up to date is
- Q. Has anyone done any temperature testing while running FreeBSD?
I know Linux runs cooler than dos, but have never seen a mention of
FreeBSD. It seems to run really hot.
A. No, but we have done numerous taste tests on blindfolded
volunteers who have also had 250 micrograms of LSD-25
administered beforehand. 35% of the volunteers said that FreeBSD
tasted sort of orange, whereas Linux tasted like purple haze.
Neither group mentioned any particular variances in temperature
that I can remember. We eventually had to throw the results of
this survey out entirely anyway when we found that too many
volunteers were wandering out of the room during the tests, thus
skewing the results. I think most of the volunteers are at Apple
now, working on their new ``scratch and sniff'' GUI. It's a
funny old business we're in!
Seriously, both FreeBSD and Linux use the ``
Q. Is there anything "odd" that FreeBSD does when compiling the
kernel which would cause the memory to make a scratchy sound? When
compiling (and for a brief moment after recognizing the floppy drive
upon startup, as well), a strange scratchy sound emanates from what
appears to be the memory banks.
A. Yes! You'll see frequent references to ``daemons'' in the BSD
documentation, and what most people don't know is that this
refers to genuine, non-corporeal entities that now possess your
computer. The scratchy sound coming from your memory is actually
high-pitched whispering exchanged among the daemons as they best
decide how to deal with various system administration tasks.
If the noise gets to you, a good ``fdisk /mbr'' from DOS
will get rid of them, but don't be surprised if they react
adversely and try to stop you. In fact, if at any point during
the exercise you hear the satanic voice of Bill Gates coming from
the built-in speaker, take off running and don't ever look back!
Freed from the counterbalancing influence of the BSD daemons, the
twin demons of DOS and Windows are often able to re-assert total
control over your machine to the eternal damnation of your soul.
Given a choice, I think I'd prefer to get used to the scratchy
noises, myself!
MFC is an acronym for 'Merged From -CURRENT.' It's used in the CVS
logs to denote when a change was migrated from the CURRENT to the STABLE
branches.
It stands for something in a secret language that only
members can know. It doesn't translate literally but its ok to
tell you that BSD's translation is something between, 'Formula-1
Racing Team', 'Penguins are tasty snacks', and 'We have a better
sense of humor than Linux.' :-)
Seriously, BSD is an acronym for 'Berkeley Software
Distribution', which is the name the Berkeley CSRG (Computer
Systems Research Group) chose for their Unix distribution way
back when.
Welcome to the FreeBSD 2.X FAQ!
As is usual with Usenet FAQs, this document aims to cover the most
frequently asked questions concerning the FreeBSD operating system
(and of course answer them!). Although originally intended to reduce
bandwidth and avoid the same old questions being asked over and over
again, FAQs have become recognized as valuable information resources.
Every effort has been made to make this FAQ as informative as
possible; if you have any suggestions as to how it may be improved,
please feel free to mail them to the Briefly, FreeBSD 2.X is a UN*X-like operating system based on
U.C. Berkeley's 4.4BSD-lite release for the i386 platform. It is
also based indirectly on William Jolitz's port of U.C. Berkeley's
Net/2 to the i386, known as 386BSD, though very little of the 386BSD
code remains. A fuller description of what FreeBSD is and how
it can work for you may be found on the FreeBSD is used by companies, Internet Service Providers, researchers,
computer professionals, students and home users all over the world
in their work, education and recreation. See some of them in the
For more detailed information on FreeBSD, please see the
The goals of the FreeBSD Project are to provide software that may
be used for any purpose and without strings attached. Many of us
have a significant investment in the code (and project) and would
certainly not mind a little financial compensation now and then,
but we're definitely not prepared to insist on it. We believe
that our first and foremost "mission" is to provide code to any
and all comers, and for whatever purpose, so that the code gets
the widest possible use and provides the widest possible benefit.
This is, we believe, one of the most fundamental goals of Free
Software and one that we enthusiastically support.
That code in our source tree which falls under the GNU Public License
(GPL) or GNU Library Public License (GLPL) comes with slightly more
strings attached, though at least on the side of enforced
access rather than the usual opposite. Due to the additional
complexities that can evolve in the commercial use of GPL software,
we do, however, endeavor to replace such software with submissions
under the more relaxed BSD copyright whenever possible.
For those of our readers whose first language is not English, it
may be worth pointing out that the word ``free'' is being used in two
ways here, one meaning ``at no cost'', the other meaning ``you can do
whatever you like''. Apart from one or two things you
Version If you are not familiar with the operating system or are not
capable of identifying the difference between a real problem and
a temporary problem, you should not use FreeBSD-current. This
branch sometimes evolves quite quickly and can be un-buildable
for a number of days at a time. People that use FreeBSD-current
are expected to be able to analyze any problems and only report them
if they are deemed to be mistakes rather than ``glitches''. Questions
such as ``make world produces some error about groups'' on the
-current mailing list are sometimes treated with contempt.
Every now and again, a No claims are made that any snapshot can be considered
``production quality'' for any purpose. For stability
and tested mettle, you will have to stick to full releases.
Snapshot releases are directly available from Back when FreeBSD 2.0.5 was released, we decided to branch FreeBSD
development into two parts. One branch was named The -current branch is slowly progressing towards 4.0 and beyond,
the previous 2.2-stable branch having just retired with the release
of 2.2.8. 3.0-stable has now replaced it, the next release coming
up with 3.1 in early 1999. 4.0-current is now the "current branch",
with the first 4.0 releases appearing in Q1 2000.
As a general principle, the FreeBSD core team only release a new
version of FreeBSD when they believe that there are sufficient new
features and/or bug fixes to justify one, and are satisfied that the
changes made have settled down sufficiently to avoid compromising the
stability of the release. Many users regard this caution as one of
the best things about FreeBSD, although it can be a little
frustrating when waiting for all the latest goodies to become
available...
Releases are made about every 4 months on average.
For people needing (or wanting) a little more excitement, there are
SNAPs released more frequently, particularly during the month or so
leading up to a release.
FreeBSD 3.x currently runs on the The key decisions concerning the FreeBSD project, such as the
overall direction of the project and who is allowed to add code to
- the source tree, are made by a However, most non-trivial changes are discussed in advance in the
, and there are no restrictions
on who may take part in the discussion.
Every significant release of FreeBSD is available via anonymous ftp
from the FreeBSD is also available via CDROM, from the following place(s):
Walnut Creek CDROM In Australia, you may find it at:
Advanced Multimedia Distributors You can find full information in the You can find full information in the Yes, most major IRC networks host a FreeBSD chat
channel:
Each of these channels are distinct and are not connected to
each other. Their chat styles also differ, so you may need to try
each to find one suited to your chat style. As with *all* types
of IRC traffic, if you're easily offended or can't deal with lots
of young people (and more than a few older ones) doing the verbal
equivalent of jello wrestling, don't even bother with it.
There is a FreeBSD Documentation Project which you may contact (or
even better, join) on the doc mailing list:
A FreeBSD ``handbook'' is available, and can be found as:
The definitive printed guide on FreeBSD is ``The Complete FreeBSD'',
written by Greg Lehey and published by Walnut Creek CDROM Books. Now
in its second edition, the book contains 1,750 pages of install &
system administration guidance, program setup help, and manual pages.
The book (and current FreeBSD release) can be ordered from
However, as FreeBSD 2.2.X is based upon Berkeley 4.4BSD-Lite2, most
of the 4.4BSD manuals are applicable to FreeBSD 2.2.X. O'Reilly
and Associates publishes these manuals:
A description of these can be found via WWW as:
For a more in-depth look at the 4.4BSD kernel organization,
you can't go wrong with:
McKusick, Marshall Kirk, Keith Bostic, Michael J Karels,
and John Quarterman. The Design and Implementation of the 4.4BSD Operating
System. Reading, Mass. : Addison-Wesley, 1996. A good book on system administration is:
Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein, The Problem Report database of all open user change requests
may be queried (or submitted to) by using our web-based PR
The up-to-date FAQ is available from the FreeBSD Web Server or any
mirror as PostScript and plain text (7 bit ASCII and 8-bit Latin1).
As PostScript (about 370KB):
As ASCII text (about 220KB):
As ISO 8859-1 text (about 220KB):
The up-to-date Handbook is available from the FreeBSD Web Server or any
mirror as PostScript and plain text (7 bit ASCII and 8-bit Latin1).
As PostScript (about 1.7MB):
As ASCII text (about 1080KB):
As ISO 8859-1 text (about 1080KB):
True, the ASCII and Latin1 versions of the FAQ and Handbook aren't
strictly plaintext; they contain underlines and overprints that
assume the output is going directly to a dot matrix printer. If you
need to reformat them to be human-readable, run the file through col:
Certainly! There are multiple ways to mirror the Web pages.
Well, we can't pay, but we might arrange a free CD or T-shirt and a
Contributor's Handbook entry if you submit a translation of the
documentation.
The following newsgroups contain pertinent discussion for FreeBSD
users:
Web resources:
The FreeBSD handbook also has a fairly complete