The FreeBSD site has much excellent documentation. The user coming to FreeBSD from Linux might also find many of the man pages far clearer than their Linux equivalents. In addition to the online handbook, there are various faqs, forums and mailing lists. Sometimes, one checks all these sources, and still finds that they missed an obvious place to check. So, if you get told to RTFM, don't feel too badly, sometimes one simply doesn't know where to look.

Some things seem to be hard to find. One of those things that everyone knows, except for those who know it, is how to turn off malloc debugging. /usr/src/UPDATING specifically mentions that the user who finds 6.x (or 7.x as CURRENT is now 7.0-CURRENT) slow might want to turn off various options in the kernel, which are listed, and turn off malloc debugging. A quick google gives the answer, but at any rate, just do (from anywhere on the system)

ln -s aj /etc/malloc.conf

This will turn off malloc debugging. As I write this, I feel as if I should send in a PR as it would save a bit of noise on the mailing lists, but at any rate, now it's mentioned here.

In CURRENT as of early 2006, some heavy malloc debugging is turned on by default. If one does

MALLOC_OPTIONS=P ls

they will see that redzone, for example, is 16. (If it was turned off, this would read 0.)

I am not a programmer, and the malloc manpage was a bit over my head, but from the CURRENT mailing list, the way to turn this off is to add

CFLAGS+=-DNO_MALLOC_EXTRAS

to /etc/make.conf

Then, one can rebuild or reinstall libc. From further googling (in honesty, I'm way out of my depth here, and take no responsibility if this trashes a reader's system) it seems the safest way to do this is to just rebuild world. Otherwise, libc may be out of sync with other parts of the system.

Again, I'm out of my depth with this. All I can say is that is what I did, and afterwards, MALLOC_OPTIONS=P ls showed redzone at 0.

Linux users might find this section helpful. It covers some things that I hear from Linux using friends trying out FreeBSD.

Installation is covered quite well in the handbook. One thing to note is that FreeBSD does require a primary partition.

One common issue (and this is now covered in the FAQ, possibly due to my efforts :) ) is that on boot one might get a bunch of error messages that UDMA mode isn't working, dropping to PIO mode. This one is almost always fixed by replacing 40 pin IDE cable with shielded, 80 pin ATA 100 cable. (Even more expensive computers seem to come with the less expensive 40 pin cable).

I am fortunate enough to live in the US where broadband is now common and cheap. If you are on dialup, some of the things mentioned here might take a great deal of time. Also, none of my boxes are complete antiques--the slowest one that I use is a PIII 500 with 382 megs of RAM.

So, after installation, my first step is update the source. This is covered in the handbook and also in /usr/src/UPDATING. Nowadays, the advised method of updating is to use subversion. There are a few articles on it around, such as this one at mebsd.com that give examples of how to get stable, release, and so on. One important thing to note is that if you have a /usr/src directory, remove or rename it before running subversion for the first time.

The first time will take awhile. When it's done you can start your buildworld while reading the rest of this article. Afterwards, as explained on wblock's page, you can keep it up to date with

svn up /usr/src

On a very new machine, with a 3 gig processor and a gig of RAM, buildworld took about a half hour--on my P500 with 382 megs of RAM it takes about two hours.

Before doing buildworld, first look at /usr/src/UPDATING, which will point out important changes. Often, there will be some sort of major change and the mailing lists and forums are suddenly full of people asking the same question.

So, you've checked UPDATING and you see nothing drastic. There are a few things you still might wish to do first. For example, if you plan to be using CUPS as your printing program add the following to /etc/make.conf before starting buildworld

NO_LPR=true

There is a script in /usr/src/sys/conf called newversion.sh. If for some reason, you're not sure which cvsup file you used, you can always do

egrep "^REVISION|^BRANCH" /usr/src/sys/conf/newvers.sh

It should say something like

REVISION="6.0"
BRANCH="RC1"

Silly as it sounds, people have been known to have a supfile for 5.x and 6.x, use the wrong supfile, and forget which one they used while the machine is in the process of downloading.

Now it's time to do the first buildworld.

(NOTE--if this is NOT the first buildworld that you're doing on the box, take a quick look at this section which covers things to be done in future buildworlds, such as cleaning out /usr/obj and the like.)

Here is the entire sequence, assuming that you're going to customize your kernel.

cd /usr/src
make buildworld
make buildkernel KERNCONF=MYKERN
make installkernel KERNCONF=MYKERN
reboot

Reboot into single user mode (covered in more detail below.) Then

fsck -p
mount -u /
mount -a
cd /usr/src
adjkerntz -i
mergemaster -p
make installworld
mergemaster -Ui
exit

All of this is covered in more detail below, but above is for the impatient. :)

If you use a custom kernel, the next step can often tell you if you have to reconfigure it or not after cvsuping source. So, after the first time I compile a custom kernel I do the following.

cd /usr/src/sys/i386/conf
cp GENERIC GENERIC.bak

Now, next time I cvsup source I can do

and see if anything's changed. If nothing has, I can leave my custom kernel alone. (Note that the first time you cvsup the source on a fresh install, that isn't necessary.)

While buildworld is going on, you can configure your custom kernel. If you don't know what you're doing, you might want to stick with GENERIC for now. The handbook has an excellent section, however, on configuring your kernel. If you choose to do so

A couple of notes for people used to 4.x or 5.2. LINT is no longer included by default, being replaced by NOTES. If you prefer LINT

This will create the LINT file.

Note that in addition to /usr/src/sys/i386/conf/NOTES there is is also a /usr/src/sys/conf/NOTES which covers the drivers that work on all architectures, for example the snd_xxx drivers.

Sound is handled a bit differently now. Rather than device pcm it's

device          sound

There are also various sound cards that can be built into the kernel or loaded as modules with kldload. Look at /boot/defaults/loader.conf for a list. The AC97 codec type is often snd_ich and the Yamaha type that is popular on some old Dell Dimensions is ds1. In the kernel, the ds1 has to be doublequoted, i.e

device          "snd_ds1"

Other cards don't have to be quoted, and in fact some won't work if they are. One can check LINT for the syntax. If there is a digit or digits in the name, such as snd_ds1 or snd_via8233 the quotes are necessary. If there are none, such as snd_ich or snd_cmi they shouldn't be quoted.

Note that sound and the various cards can be loaded as modules--again, look at /boot/defaults/loader.conf to see what is there. Apparently the old device pcm included most generic drivers while device sound doesn't. However, snd_driver, which can be loaded as a module by adding it to your loader.conf does include most drivers.

I accidentally learned that one can leave sound out of both kernel and loader.conf and if you have the module in loader.conf, it will automagically load the sound module. In other words, if I don't have device sound in my kernel, and don't have sound_load="YES" in loader.conf, but do have the module for the card such as snd_via8233_load="YES" in loader.conf, doing kldstat shows that the sound module is loaded.

However, if you decide to compile the sound card into your kernel, then you will also need the device sound line mentioned above. If you leave that out, and try to compile in your card's driver, you'll get an unresolved reference error while compiling the kernel.

Those who know better than I point out that after loading snd_driver, you should type

cat /dev/sndstat

which should show which driver you need. (Then, reboot and load just that driver, see if sound works, and if it does add it to /boot/loader.conf)

One way to figure out your card (for example, I recently got a lowend board and the snd_ich didn't work with its onboard AC97 compatible card) is to do

pciconf -lv

This showed me, among other things

pcm0@pci0:17:5: class=0x040100 card=0xa1011019 chip=0x30591106 rev=0x50 hdr=0x00
    vendor   = 'VIA Technologies Inc'
    device   = 'VT8233/33A/8235/8237 AC97 Enhanced Audio Controller'
    class    = multimedia
    subclass = audio

So, then I looked in /boot/defaults/loader.conf and found

snd_via8233_load="NO"

I changed the NO to a YES in my /boot/loader.conf and sound worked. (FreeBSD forums has an excellent sound howto here Note that for FreeBSD 5.3 you can use the advice that he gives for CURRENT, in other words use sound rather than snd_pcm.

(One thing I once ran into is that the Turtle Beach Aureal requires a port to be installed, /usr/audio/aureal-kmod).

If you have an LCD screen you will also want

options         VESA
options         SC_PIXEL_MODE

(VESA can be loaded as a module, SC_PIXEL_MODE has to be compiled into the kernel).

The reason for the SC_PIXEL mode is that one might want to use the vidcontrol command to make the text fit better on a console screen. Reading man vidcontrol gives more detail, but in a nutshell, on an LCD screen doing

vidcontrol -g 100x37 VESA_800x600

gives a more readable screen, but it only works if you have SC_PIXEL_MODE compiled into your kernel.

Speaking of modules for those unfamiliar with FreeBSD, the way to load modules is usually with the kldload command. To see if a module is available, look at /boot/kernel. If something is in there it can be loaded with kldload. For example, if you were checking for VESA

ls /boot/kernel | grep vesa

You will find vesa.ko. (I think all the modules are lower case, you can always do grep -i to be sure). To load it

kldload vesa

There is also a kldunload command as well as kldstat to see what you have loaded at any given time.

While speaking of /boot, on a fresh install, there is sometimes no /boot/loader.conf but only the /boot/defaults/loader.conf. You can look through it to see if there's anything you want to change. For example, the default is ten seconds between the selection screen and boot, I like to change that to five. Sometimes I've found loader.conf in /boot as an empty file, other times I've had to create it. It is recommended to edit /boot/loader.conf rather than play with /boot/defaults/loader.conf. So, I would add (one can check the defaults for the syntax)

autoboot_delay="5"

to /boot/loader.conf

(The changes I mentioned earlier, adding the line for the sound card were also added to /boot/loader.conf, NOT /boot/defaults/loader.conf)

By now, your buildworld might be finished. So, going back to the kernel.

cd /usr/src
make buildkernel KERNCONF=MYKERN

This takes much less time than building world. If you're using the GENERIC kernel than you can leave out KERNCONF and just type make buildkernel. When this is done

cd /usr/src
make installkernel KERNCONF=MYKERN

When this is done, reboot into single user mode.

reboot

If you've really messed up your kernel and it won't boot then you can always boot the last working kernel. On restart choose escape to loader prompt (number 6) and you'll come to a prompt saying OK. Type

boot /boot/kernel.old

Then you can try to figure out what went wrong, or to get things going, just use GENERIC. To do that, go back to /usr/src and do the make buildkernel and make installkernel again without the KERNCONF part.

However, assuming things went well, reboot into single mode, choosing number 4 at the list of options. It'll do its thing and eventually you'll see something saying hit return for sh. Do so. Then

fsck -p
mount -u /
mount -a
cd /usr/src
adjkerntz -i
mergemaster -p

This will take care of any essential things in /etc. For example, upon upgrading from 5.2 to 5.3 (I think, I forget exactly when the change took place) you had to create a user and group called proxy. If you've messed this up, and it doesn't work (you'll know because when you try to do an installworld you'll get an error message about the missing user proxy) you can sometimes fix it by doing

/usr/src/usr.sbin/mergemaster/mergemaster.sh -p

However, again, we'll assume that things have gone smoothly (snicker) and you have run mergemaster -p without problems. Now

make installworld

Sometimes, people mistype this as make install world. If you do so, it usually dies in the middle, complaining about trouble with Yugoslavian locales--at least that's where it died for me--err, no, not me, a friend of mine, I'm never that careless. Once the installworld is done, once again run mergemaster, without the -p this time. However, to make sure we don't wreck anything, first we're going to back up /etc

cp -Rp /etc /etc.old
cd /usr/src/
mergemaster -Ui

If you make errors here, you can trash various important /etc files, such as /etc/passwd--yes, as the Japanese proverb goes, Saru de mo, ki kara ochiru, even monkeys fall from trees, and gurus as well as novices have done so. This is why we backed up /etc first.

Mergemaster compares various files showing the differences--as it's running through the file, you can page down with the space bar, or hit q for quit. It will then ask if you want to leave the old file, merge the two or install the new one. If you hit m for merge, it will show the old file on the left and the new on the right. If you want the left--for example, /etc/passwd's root entry, you hit l (a lower case L, not the numeral one) for left and if you want right, you hit r. When done it asks if you want to install the merged file.

Some things, such as motd (message of the day) can be installed or deleted with no real effect on your system, others, such as /etc/group or /etc/passwd can seriously trash things if you hit r instead of l. :)

When done, mergemaster will ask if you want to keep or discard the temporary files. On a fresh install of 5.3-Beta7 it's usually pretty quick. If you're upgrading, it may go through many files.

When it's finished, you can then just type

exit

The system will then boot into normal mode.

Booting into single user mode in 7.x-CURRENT

Through 5.x (and 6.x) when booting, one has a menu, giving various numbered options. For example, number 4 is boot into single user mode and 6 is escape to command prompt.

7.x-CURRENT, as of Summer 2005, has reverted back to the old style, without that numbered menu. If you prefer to leave it that way, then, while the machine is booting, you'll see a message to hit enter to boot or any other key for a command prompt. You can use the space bar or any other key you choose.

You'll then see a prompt saying OK, as mentioned above when discussing booting the old kernel. If you wish to boot into single user mode at that point you would type

boot -s

This will boot in single mode.

If you want your beastie prompt and handy numbered menu back, it's easy to do. Add the following two lines to /boot/loader.rc

include /boot/beastie.4th
beastie-start

Then, copy from /usr/src/sys/ into /boot

cp /usr/src/sys/boot/forth/beastie.4th /boot/

Now that we're back in normal mode, and everything is fine, we can begin installing programs we need. First update ports the same way you did with source.

cvsup -g -L 2 -h cvsup.freebsd.org /usr/share/examples/cvsup/ports-supfile

Next, check out the ports version of UPDATING

cd /usr/ports
less UPDATING

It is important to read UPDATING. In mid-November 2004, for example, there were some changes to the index, and if you tried to do portupgrade, you would have a loooooooooooong wait while it rebuilt. UPDATING gave workarounds. This may become permanent--the reference in 5.3 is 20041115. The workaround that I find most convenient is to, after cvsuping ports

cd /usr/ports
make fetchindex
pkgdb -u

Once ports are updated, one of the first programs I add is fastest_cvsup.

cd /usr/ports/sysutils/fastest_cvsup
make install clean

Once it's installed, you can check which cvsup host has the best connection for you with

fastest_cvsup -c us

The -c is for country--as I've mentioned, I live in the US, so I use -c us. Obviously, change that for your country.

From there, one can install other programs that they need. I usually start with sudo. One can often install more than one port at a time, but this can be tricky because if both ports have the same dependency one or both builds might fail. You can also start downloading necessary files while installing other ports. To download all files, including dependencies, you can go into the port's directory, for example /usr/ports/mail/mutt-devel and type

make fetch-recursive

Again, be careful for if you are doing fetch-recursive on two ports that share dependencies, it will fail.

One of the big issues with the upgrading is that from 5.3BETA7 some library versions have changed. It is probably necessary to reinstall any programs that were installed prior to upgrading to BETA7 (assuming it isn't a fresh install). This is usually done with portupgrade. If you haven't installed it yet, do so

cd /usr/ports/sysutils/portupgrade
make install clean

To upgrade all ports and packages

portupgrade -af

READ THE PORTUPGRADE MAN PAGE FIRST!!!. I am giving a fairly quick and dirty guide here, and there are various pitfalls you might face.

One thing you might find, even on a fresh install, is that some programs are still looking for the older libraries. I'm not sure how long this will go on, but as of early October, the FreeBSD native opera port, for example, is built from a binary rather than source, and is looking for older libraries. The quickest fix is

cd /usr/src/lib/compat/compat4x.i386
make depend && make && make install

The next time you cvsup source and build and install world, there are a few other steps. Aside from the comparison of GENERIC and GENERIC.bak mentioned above, you want to clear out /usr/obj

The new and better way to do it is

cd /usr/src
make cleanworld

As of early December, 2004 I haven't seen cleanworld mentioned in the Handbook or in /usr/src/UPDATING. They still refer to the older method which is

cd /usr/obj
chflags -R noschg *
rm -rf *

One nice thing about cleanworld is that it will prevent a mistake like doing rm -rf * in /usr rather than /usr/obj. :)

If you are familiar with particular ports and know that the port requires user intervention (for example, procmail pauses at some point, asking you to hit enter) you can always install a port with

make BATCH=yes install clean

This assumes yes answers or going with defaults--for instance, when installing samba, there are some config options--if you just type make install clean and walk away, when you come back, it's waiting for you to select which options you want. Using the BATCH=yes will accept the defaults.

Some people put BATCH=yes in their /etc/make.conf. You can do that, but what usually happens is that then you install a port where you don't want the defaults, forget that you have that line in make.conf and wind up accidentally going with the default configuration.

lptcontrol -e

(As printing is not one of my favorite things to research and troubleshoot, I haven't looked more deeply into this. It's only happened on one very low end machine, and I suspect the trouble is simply hardware.

Browsers

The native opera port doesn't handle plugins well, if at all. I've never gotten flash, java, or the mplayer plugins working with it.

The native firefox port is good if one also installs the mplayerplug-in port. Then, firefox is useful for various (quicktime, wmv, avi, etc) formats, feeding them to mplayer.

Flash, however, can be problematic. There are workarounds, but even in the cases where I've gotten it working, it will have trouble with things like tvguide.com's listings, freezing completely on the page and having to be killed from a separate terminal window.

Native java (as opposed to Linux java) works but there are several files that have to be fetched by hand. You have to register at Sun's site to get them. One can get the url's from the make file, but I actually find the easiest thing to do is startx, open a full screen xterm and just cut and paste the urls as they appear when the build stops. The reason I use a full screen is because some of the URL's are incredibly long.

If you install the native java jdk14, it will in the course of installation, also install the linux-sun-jdk14 port. If using linux-opera as detailed below, one can stop with linux-sun-jdk14

When you register at Sun's site, keep your user name and password, for you may have to go back there a few times.

If you install java before firefox, it should just work, showing up when you type about:plugins in the address bar. If not, or if you install firefox first create a symlink

ln -s /usr/local/jdk.1.4.2/jre/plugin/i386/ns610/libjavaplugin_oji.so
/usr/X116/lib/browser_plugins/

One last comment about firefox, so that I don't have to look it up each time. I prefer that a link open in a new tab, not a new window. To get that behavior, one has to cd into their home directory's .mozilla/firefox directory. In there you'll see a file with a long random string of letters and/or numbers ending in default. If you cd into that file you'll see a file called prefs.js.

If one closes firefox, then adds the line

user_pref("browser.tabs.showSingleWindowModePrefs", true);

to that file, when you go to firefox's Edit=>Preferences=>Advanced=>Tabbed Browsing you'll see an unchecked check box with the option of forcing links that open new windows to open in a tab or a window.

(You may have more than one default file in the .mozilla/firefox directory--if that's the case, you'll have to figure out which one is being used or just add it to all of 'em. :) ) (As of early January, 2005, native java still doesn't work with native opera, it just crashes it.)

Later I learned that if I simply typed

about:config

in the firefox address bar, it brings up a list of configured options. If I type singlewindow in the filter textbox, it brings me to that preference. It is set, by default, to false. Right click on it, choose toggle from the menu, and it will change to true.

As mentioned, firefox and flash don't always work well together on some flash heavy sites, such as tvguide.com. I really prefer opera, which is less resource intensive anyway, so also install linux-opera which is my usual browser.

With linux-opera, if I've installed the flash plugin and linux-sun-jdk for java, they simply work when I startup opera. Sometimes, you have to go to the Tools, Preferences and click the Advanced tab. There you will see, among other things, Content. Click on that and you'll see an option to Enable Java. If it's not checked off, and you want java, then check it off. You can then doublecheck, by clicking the Java Options button, that the path to java is correct. After clicking that button, there's an option to Validate the path. It should be, on both STABLE and CURRENT

/usr/local/linux-sun-jdk1.4.2/jre/lib/i386

The only other thing you might have to do is make sure that acroread7, if you use it, is installed as a plugin. To do that, after installing acroread7, as root or with root privilege

acroread --install-plugin

This will enable linux-opera to see it. If you type about:plugins in the linux-opera address bar, you should see that flash and acrobat are there. (Java isn't considered a plugin, it's shown if you type about:opera in the address bar.)

USB scanners

pw groupmod operator -m john

Now, I add these two lines to /etc/devfs.conf

own     uscanner0 root:operator
perm    uscanner0 0660

Next, I'll have to restart /etc/devfs.

/etc/rc.d/devfs restart

The user john will now be able to make use of the scanner.

Rather than the md5sum command, to check an md5 sum one just uses

md5

FreeBSD doesn't include wget (although it is available from ports in /usr/ports/ftp/wget). However, it has its own builtin fetch command. With fetch, you do have to specify the http:// prefix. So, where with wget you could pull down this page with

wget home.nyc.rr.com/computertaijutsu/FreeBSD5x.html

with fetch it would have to be

fetch http://home.nyc.rr.com/computertaijutsu/FreeBSD5x.html

The syntax of xorgconfig (or xf86config) is a bit different than Linux. With an MS optical Intellimouse, using a PS/2 connection, in Linux one chooses IMPS/2 protocol and /dev/psaux. In FreeBSD choose the Auto protocol and use /dev/sysmouse if you use the moused daemon in console. If you don't use the moused daemon use /dev/psm0.

While on X, many Linux users know that to get to a console while in X, you hit ctl+alt+F1 and ctl+alt+F7 to get back to X. In FreeBSD it's also F1 but to get back to X it's ctl+alt+F9.

There is now a way to mount reiserfs partitions, but I think it's only available for FreeBSD-6.x and up. You can find the program here. You install it and you then have a module, reiserfs.ko and a mount_reiserfs command.

However, recent installations of 6.x and above should have this built in--you don't need the program, just insert the module.

kldload reiserfs

FreeBSD can mount ext2fs partitions and ext3fs. With ext3fs it doesn't do journelling AFAIK, so you might want to mount those read only, depending upon how important the data is to you.

Once you figure out the slice that holds your Linux partition, you can use the mount_ext2fs command. For example, if I have an extended partition that holds Linux and I want the 2nd partition in there, it might be /dev/ad0s9 or so. I don't do this often enough to have it completely figured out--sometimes, I find myself simply repeating the command till I get the right slice--I can tell because (finally) there will be no error messages.)

mount_ext2fs /dev/ad0s9 /mnt

You may have to load the ext2fs module into the kernel

kldload ext2fs

Linux can mount FreeBSD partitions, but you will need to add a few options in the Linux kernel. I don't think the mounting syntax was covered in the man page last time I looked.

In the Linux kernel, you will need the following options. In File systems => Miscellaneous filesystems choose UFS. Then, in Partition types choose Advanced partition types and from the menu that appears, choose BSD disklabel. (Note that the UFS option is for read only--there is a write, but it is still, as of March 2005, considered dangerous.)

In this case, we will assume that both operating systems are on the same machine, with FreeBSD in /dev/hda1 and Linux in /dev/hda2. Once these options are in the kernel, you can do, while running Linux

dmesg | grep bsd

You'll get back something like

hda1: <bsd:hda5 hda6 hda7 hda8 hda9>

These will refer to /var, /tmp, /usr and the rest. ( /usr is usually the last one.) So, say you know that hda9 is /usr, and you wish to mount it and examine something.

mount -r -t ufs -o ufstype=ufs2 /dev/hda9 /mnt

Doing a ls /mnt will show you the contents of your FreeBSD /usr/ partition.

Ports are usually installed to /usr/local/bin or /usr/X11R6/bin. There is no /opt. Ports that run as daemons usually put a startup script into /usr/local/etc/rc.d. They will have names like samba.sh cups.sh and the like. Some might have names such as cups.sh.sample, and will have to be renamed (if you want them to run at boot) to cups.sh.

Some of these scripts, such as samba.sh, require you to add a line like

samba_enable="YES"

to /etc/rc.conf. Usually, this is given as a message after the package is installed and/or mentioned in the comments section of the script. If you missed the messages, you can see them again by using pkg_info. The easy way is to use the -x flag. For example, if I want to see what the message was when samba was installed

pkg_info -Dx samba

If one doesn't use the -x flag, then you will need the exact name of the installed package.

ls /var/db/pkg | grep samba

I'll get back something like samba-3.0.8,1. Then I type

pkg_info -D samba-3.0.8,1

This will give me any messages. Even if there is no message about adding a line to /etc/rc.conf the /usr/local/etc/rc.d shell script might have one, so it's always a good idea to open the shell script in a text editor and check.

Your own custom scripts can also go here, but a look at man rc.d will tell you that the system expects a .sh suffix. To take a simple example, I mention elsewhere how on particular system, I had to run lptcontrol -e to get my printer to work. I wanted this to run at startup. All I had to do was create a simple script, lptcontrol.sh. (I could have called it anything as long as I had the .sh suffix.) This highly complex, sophisticated script reads

lptcontrol -e

(For testing, I actually had an && at the end of that line and a second line saying echo "starting lptcontrol extended mode") Upon reboot, it worked. To test a script in /usr/local/etc/rc.d one should call it with the complete path and the word start, even if you're in the /usr/local/etc/rc.d directory. In other words, I then typed

/usr/local/etc/rc.d/lptcontrol.sh start

It worked. This was a good indication that it would run successfully on startup, which it did.

Adding a default route and ifconfig have slightly different syntax than their Linux counterparts. One can always run /stand/sysinstall, go to post installation configuration and configure the network interfaces there. The syntax of the commands are (in this case, using tx0 as the interface--to see how the interface is named, one can either run ifconfig or do dmesg | grep -i ether)

ifconfig tx0 192.168.1.100 netmask 255.255.255.0
route add default 192.168.1.1

The following lines would be added to /etc/rc.conf

defaultrouter="192.168.1.1"
ifconfig_tx0="inet 192.168.1.101 netmask 255.255.255.0"

For DHCP /etc/rc.conf would read

ifconfig_tx0="DHCP"

If one makes changes, to put them into effect without a reboot you can either drop to single user mode then go back with

/sbin/shutdown now

Then typing exit once you've gone to single user mode. (To shut the machine off, rather than shutdown -h now it's shutdown -p now.) One can also run the handy command /etc/netstart which will put all network changes made in /etc/rc.conf into effect. Of course, in Unix, there's always more than one way to do things (and someone will think your way is wrong) and if it's just one thing that you want to restart, for instance, sshd you can also do

/etc/rc.d/sshd restart

The user and groupmod commands are a bit different as well. An example was given in above but anyway, one uses the pw command then passes usermod or groupmod arguments, for example, to add user john to the wheel group

pw groupmod wheel -m john

To generate a random password for a user (after having used the adduser script, which gives you the option to do that when first creating the user) once again the pw command is used.

pw usermod john -w random

Rather than the seq command, FreeBSD has a builtin called jot. It resembles seq, though it has differences.

To mount an iso image as if it were a cd one uses the mdconfig command. The man page gives more information, but the procedure would be, assuming you were in the same directory as image.iso

mdconfig -a -t vnode -f image.iso

You'll see

md0

(Assuming that it's the first memory disk--md stands for memory disk. The second one would be, obviously enough, md1). Then, mount the memory disk as a cdrom

mount_cd9660 /dev/md0 /mnt

The device will then be mounted as if it were a CDROM.

mdconfig -d -u 0

0, of course, refers to the unit's number. If it were md1, then you would use mdconfig -d -u 1.

To update the locate database, rather than the updatedb command you use

/usr/libexec/locate.updatedb

This has to be done as root or with root privilege and you receive a security warning when you do it. If you leave your machine on all the time, for example, a server, one of the periodic scripts will run it weekly.

Some Linux users, especially those coming from a distribution with a shell prompt that gives them their current working directory might find FreeBSD's default shells, csh for root and sh for user, a bit confusing. Bash and other shells can be installed from the ports collection, and will be put into /usr/local/bin/. To make more informative shell prompts, please look at my Quick-N-Dirty guide to shell prompts. (It covers bash, zsh and ksh).

Many, if not most, Linux distributions have vim rather than vi as their default editor. (Slackware and Debian, however, use elvis). FreeBSD uses nvi. Vim can be installed from ports, however, if you then type the command vi, you'll still get the nvi editor. You have to either create an alias, in, for example, your .bashrc if you're using bash, or call it by name, that is, type vim, rather than vi.

To create an alias, in your (again using bash an as example, since this section is for Linux users), in your ~/.bashrc file add the line

vi=vim