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.
FreeBSD supports the following SCSI controllers:
Any SCSI drive connected to a supported controller is supported.
The following proprietry 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).
There is no built in support for the parallel ZIP drive, and if you
haven't bought your ZIP drive already I recommend you get the SCSI
one... the price is the same, and the performance is much better,
and you're unlikely to ever be able to boot from the parallel port.
If you already have a parallel ZIP, there is a port of the Linux
driver available at
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.
The easiest way is to simply specify that you want to run X during the installation process.
Then read and follow the documentation on the You may also wish to investigate the Xaccel server, which is
available at a very reasonable price. See the section on
for more details.
If you are using syscons (the default console driver), you can
configure FreeBSD to support a mouse pointer on each virtual
screen. In order to avoid conflicting with X, syscons supports
a virtual device called ``/dev/sysmouse''. All mouse events
received from the real mouse device are written to the sysmouse
device, using the MouseSystems protocol. If you wish to use your
mouse on one or more virtual consoles, Some people prefer to use ``/dev/mouse'' under X. To
make this work, ``/dev/mouse'' should be linked to
Try turning off the Num Lock key.
If your Num Lock key is on by default at boot-time, you may add
the following line in the ``
# Let the server do the NumLock processing. This should only be
# required when using pre-R6 clients
ServerNumLock
Virtual consoles, put simply, enable you to have several
simultaneous sessions on the same machine without doing anything
complicated like setting up a network or running X.
When the system starts, it will display a login prompt on
the monitor after displaying all the boot messages. You can
then type in your login name and password and start working (or
playing!) on the first virtual console.
At some point, you will probably wish to start another
session, perhaps to look at documentation for a program
you are running or to read your mail while waiting for an
FTP transfer to finish. Just do Alt-F2 (hold down the Alt
key and press the F2 key), and you will find a login prompt
waiting for you on the second ``virtual console''! When you
want to go back to the original session, do Alt-F1.
The default FreeBSD installation has three virtual consoles
enabled, and Alt-F1, Alt-F2, and Alt-F3 will switch between
these virtual consoles.
To enable more of them, edit Use as many or as few as you want. The more virtual terminals
you have, the more resources that are used; this can be important
if you have 8MB RAM or less. You may also want to change the
`` to:
If your keyboard has only ten function keys, you would end up with:
(You could also just delete these lines.)
Once you have edited Next, the easiest (and cleanest) way to activate the virtual
consoles is to reboot. However, if you really don't want to
reboot, you can just shut down the X Window system and execute (as
kill -HUP 1
It's imperative that you completely shut down X Window if it is
running, before running this command. If you don't, your system
will probably appear to hang/lock up after executing the kill
command.
If the console is currently displaying X Window, you can use
Ctrl-Alt-F1, etc. to switch to a virtual console. Note, however,
that once you've switched away from X Window to a virtual
terminal, you may use only the Alt- function key to switch to another
virtual terminal or back to X Window. You do not need to also press the
Ctrl key. If you use the control key to switch back to X on some
older releases, you can find your text console stuck in ``control-lock''
mode. Tap the control key to wake it up again.
Starting If you start This is because of the way console permissions are set by default.
On a multi-user system, one doesn't necessarily want just any user
to be able to write on the system console. For users who are logging
directly onto a machine with a VTY, the
In a nutshell, make sure an uncommented line of the form
is in Your mouse and the mouse driver have somewhat become out of
- synchronization. Switching away from X to a virtual terminal
- and getting back to X again may make them re-synchronized.
- If the problem occurs often, you may add the following option
- in your kernel configuration file and recompile it.
+ Your mouse and the mouse driver may have somewhat become out of
+ synchronization.
+
+ In versions 2.2.5 and earlier, switching away from X to a
+ virtual terminal and getting back to X again may make them
+ re-synchronized. If the problem occurs often, you may add the
+ following option in your kernel configuration file and recompile it.
See the section on
if you've no experience with building kernels.
With this option, there should be less chance of synchronization
problem between the mouse and the driver. If, however, you
still see the problem, click any mouse button while holding
the mouse still to re-synchronize the mouse and the driver.
Note that unfortunately this option may not work with all the
systems and voids the ``tap'' feature of the ALPS GlidePoint
device attached to the PS/2 mouse port.
+ In versions 2.2.6 and later, synchronization check is done
+ in a slightly better way and is standard in the PS/2 mouse driver.
+ It should even work with GlidePoint. (As the check code has become
+ a standard feature, PSM_CHECKSYNC option is not available in these
+ versions.) However, in rare case the driver may erroneously report
+ synchronization problem and you may see the kernel message:
+
+ If this happens, disable the synchronization check code by
+ setting the driver flags for the PS/2 mouse driver to 0x100.
+ Enter UserConfig by giving the ``-c'' option
+ at the boot prompt:
+
+ There have been some reports that certain model of PS/2 mouse
+ from MouseSystems works only if it is put into the ``high resolution''
+ mode. Otherwise, the mouse cursor may jump to the upper-left
+ corner of the screen every so often.
+
+ Unfortunately there is no workaround for versions 2.0.X and
+ 2.1.X. In versions 2.2 through 2.2.5, apply the following patch
+ to /sys/i386/isa/psm.c and rebuild the kernel. See the
+ section on
+ if you've no experience with building kernels.
+
+ In versions 2.2.6 or later, specify the flags 0x04 to the PS/2
+ mouse driver to put the mouse into the high resolution mode.
+ Enter UserConfig by giving the ``-c'' option
+ at the boot prompt:
+
+ See the previous section for another possible cause of mouse
+ problems.
+