View Poll Results: So, w=how do you like me so far?

4. You may not vote on this poll
  • You Suck!

    1 25.00%
  • Alright

    2 50.00%
  • Pretty Cool

    0 0%
  • Awesome-LAWLZ

    1 25.00%
Page 1 of 3 123 LastLast
Results 1 to 10 of 23

Thread: Why I put Slackware on my Free BSD box

  1. #1
    Senior Member gore's Avatar
    Join Date
    Oct 2002

    Why I put Slackware on my Free BSD box

    First off, this isn't a slap at Free BSD. God knows I love it. But this is an issue I think should be at least looked at.

    With that in mind, here is what I have to say:

    Free BSD is an OS based on Unix, and is considered a true form of Unix from the boys at Berkeley in Cali. This was from back in the day when Unix was given out cheap to colleges because AT&T couldn't do much with it at the time.

    It has a long history of stability and speed. BSD boxes stay up for years at a time without needing a reboot. However, when a security flaw is found, all hell can break free with what should be an easy task.

    With BeOS you would download a zip file and install.

    On Mac OS.... Well they have patches too.

    On Windows you have Windows update and some hot fixes. Unless of course you have Windows 95, because it hadn't came out yet.

    On RedHat Linux you have up2date to grab fixes and install them,

    On SUSE you have YAST, APT4RPM and SMART. Or you can download the patches yourself and install them.

    On Slackware you have wget and the FTP addy, or you can use Swaret. Or a couple others.

    All of these have something in common:

    Just download the patches, install them and you're done.

    Free BSD on the other hand has quite a few things you need to do from what I understand:

    You download the patch with fetch and then do:

    patch < /usr/src/patch.patch

    Then you have to rebuild THE KERNEL.....

    This example is for Telnet:

    I. Background

    The telnet(1) command is a TELNET protocol client, used primarily to
    establish terminal sessions across a network.

    II. Problem Description

    Buffer overflows were discovered in the env_opt_add() and
    slc_add_reply() functions of the telnet(1) command. TELNET protocol
    commands, options, and data are copied from the network to a
    fixed-sized buffer. In the case of env_opt_add (CAN-2005-0468), the
    buffer is located on the heap. In the case of slc_add_reply
    (CAN-2005-0469), the buffer is global uninitialized data (BSS).

    III. Impact

    These buffer overflows may be triggered when connecting to a malicious
    server, or by an active attacker in the network path between the
    client and server. Specially crafted TELNET command sequences may
    cause the execution of arbitrary code with the privileges of the user
    invoking telnet(1).

    IV. Workaround

    Do not use telnet(1) to connect to untrusted machines or over an
    untrusted network.

    V. Solution

    Perform one of the following:

    1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the
    RELENG_5_3, RELENG_4_11, RELENG_4_10, or RELENG_4_8 security branch
    dated after the correction date.

    OK, so one solution is to get a NEW VERSION of it and install another version of Free BSD. Ok, but ther eis another one.

    2) To patch your present system:

    The following patches have been verified to apply to FreeBSD 4.8, 4.10,
    4.11, and 5.3 systems.

    a) Download the relevant patch from the location below, and verify the
    detached PGP signature using your PGP utility.

    [FreeBSD 4.x]
    # fetch
    # fetch

    [FreeBSD 5.x]
    # fetch
    # fetch
    OK so far so good, just download the patch.

    b) Execute the following commands as root:

    # cd /usr/src
    # patch < /path/to/patch
    OK install the patch, no biggie.

    c) Rebuild the operating system as described in
    DO WHAT???????????????????

    It's TELNET!!!! Windows wouldn't even need a reboot for this would it??????........ OK that's just wrong. Now some may wonder "But all it says it to do that as it says on the web site."... Yes, and for anyone who hasn't READ that, HERE is what you'd need to do next:

    Seems easy right? NO.

    Take a Backup: It cannot be stressed enough how important it is to take a backup of your system before you do this. While rebuilding the world is (as long as you follow these instructions) an easy task to do, there will inevitably be times when you make mistakes, or when mistakes made by others in the source tree render your system unbootable.

    Make sure you have taken a backup. And have a fixit floppy or bootable CD at hand. You will probably never have to use it, but it is better to be safe than sorry!
    Are you kidding?

    And more:

    WARNING, this is VERY long:

    20.4.1 The Canonical Way to Update Your System

    To update your system, you should check /usr/src/UPDATING for any pre-buildworld steps necessary for your version of the sources and then use the following procedure:

    # make buildworld
    # make buildkernel
    # make installkernel
    # reboot

    Note: There are a few rare cases when an extra run of mergemaster -p is needed before the buildworld step. These are described in UPDATING. In general, though, you can safely omit this step if you are not updating across one or more major FreeBSD versions.

    After installkernel finishes successfully, you should boot in single user mode (i.e. using boot -s from the loader prompt). Then run:

    # mergemaster -p
    # make installworld
    # mergemaster
    # reboot

    Read Further Explanations: The sequence described above is only a short resume to help you getting started. You should however read the following sections to clearly understand each step, especially if you want to use a custom kernel configuration.

    20.4.2 Read /usr/src/UPDATING

    Before you do anything else, read /usr/src/UPDATING (or the equivalent file wherever you have a copy of the source code). This file should contain important information about problems you might encounter, or specify the order in which you might have to run certain commands. If UPDATING contradicts something you read here, UPDATING takes precedence.

    Important: Reading UPDATING is not an acceptable substitute for subscribing to the correct mailing list, as described previously. The two requirements are complementary, not exclusive.

    20.4.3 Check /etc/make.conf

    Examine the files /usr/share/examples/etc/make.conf (called /etc/defaults/make.conf in FreeBSD 4.X) and /etc/make.conf. The first contains some default defines - most of which are commented out. To make use of them when you rebuild your system from source, add them to /etc/make.conf. Keep in mind that anything you add to /etc/make.conf is also used every time you run make, so it is a good idea to set them to something sensible for your system.

    A typical user will probably want to copy the CFLAGS and NOPROFILE lines found in /usr/share/examples/etc/make.conf (or in /etc/defaults/make.conf on FreeBSD 4.X) to /etc/make.conf and uncomment them.

    Examine the other definitions (COPTFLAGS, NOPORTDOCS and so on) and decide if they are relevant to you.
    20.4.4 Update the Files in /etc

    The /etc directory contains a large part of your system's configuration information, as well as scripts that are run at system startup. Some of these scripts change from version to version of FreeBSD.

    Some of the configuration files are also used in the day to day running of the system. In particular, /etc/group.

    There have been occasions when the installation part of make installworld has expected certain usernames or groups to exist. When performing an upgrade it is likely that these users or groups did not exist. This caused problems when upgrading. In some cases make buildworld will check to see if these users or groups exist.

    A recent example of this is when the smmsp user was added. Users had the installation process fail for them when mtree(8) was trying to create /var/spool/clientmqueue.

    The solution is to examine /usr/src/etc/group and compare its list of groups with your own. If there are any groups in the new file that are not in your file then copy them over. Similarly, you should rename any groups in /etc/group which have the same GID but a different name to those in /usr/src/etc/group.

    Since 4.6-RELEASE you can run mergemaster(8) in pre-buildworld mode by providing the -p option. This will compare only those files that are essential for the success of buildworld or installworld. If your old version of mergemaster does not support -p, use the new version in the source tree when running for the first time:

    # cd /usr/src/usr.sbin/mergemaster
    # ./ -p

    Tip: If you are feeling particularly paranoid, you can check your system to see which files are owned by the group you are renaming or deleting:

    # find / -group GID -print

    will show all files owned by group GID (which can be either a group name or a numeric group ID).

    20.4.5 Drop to Single User Mode

    You may want to compile the system in single user mode. Apart from the obvious benefit of making things go slightly faster, reinstalling the system will touch a lot of important system files, all the standard system binaries, libraries, include files and so on. Changing these on a running system (particularly if you have active users on the system at the time) is asking for trouble.

    Another method is to compile the system in multi-user mode, and then drop into single user mode for the installation. If you would like to do it this way, simply hold off on the following steps until the build has completed. You can postpone dropping to single user mode until you have to installkernel or installworld.

    As the superuser, you can execute:

    # shutdown now

    from a running system, which will drop it to single user mode.

    Alternatively, reboot the system, and at the boot prompt, enter the -s flag. The system will then boot single user. At the shell prompt you should then run:

    # fsck -p
    # mount -u /
    # mount -a -t ufs
    # swapon -a

    This checks the file systems, remounts / read/write, mounts all the other UFS file systems referenced in /etc/fstab and then turns swapping on.

    Note: If your CMOS clock is set to local time and not to GMT (this is true if the output of the date(1) command does not show the correct time and zone), you may also need to run the following command:

    # adjkerntz -i

    This will make sure that your local time-zone settings get set up correctly -- without this, you may later run into some problems.

    20.4.6 Remove /usr/obj

    As parts of the system are rebuilt they are placed in directories which (by default) go under /usr/obj. The directories shadow those under /usr/src.

    You can speed up the make buildworld process, and possibly save yourself some dependency headaches by removing this directory as well.

    Some files below /usr/obj may have the immutable flag set (see chflags(1) for more information) which must be removed first.

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

    20.4.7 Recompile the Source Saving the Output

    It is a good idea to save the output you get from running make(1) to another file. If something goes wrong you will have a copy of the error message. While this might not help you in diagnosing what has gone wrong, it can help others if you post your problem to one of the FreeBSD mailing lists.

    The easiest way to do this is to use the script(1) command, with a parameter that specifies the name of the file to save all output to. You would do this immediately before rebuilding the world, and then type exit when the process has finished.

    # script /var/tmp/mw.out
    Script started, output file is /var/tmp/mw.out
    # make TARGET
    ... compile, compile, compile ...
    # exit
    Script done, ...

    If you do this, do not save the output in /tmp. This directory may be cleared next time you reboot. A better place to store it is in /var/tmp (as in the previous example) or in root's home directory. Compile the Base System

    You must be in the /usr/src directory:

    # cd /usr/src

    (unless, of course, your source code is elsewhere, in which case change to that directory instead).

    To rebuild the world you use the make(1) command. This command reads instructions from the Makefile, which describes how the programs that comprise FreeBSD should be rebuilt, the order in which they should be built, and so on.

    The general format of the command line you will type is as follows:

    # make -x -DVARIABLE target

    In this example, -x is an option that you would pass to make(1). See the make(1) manual page for an example of the options you can pass.

    -DVARIABLE passes a variable to the Makefile. The behavior of the Makefile is controlled by these variables. These are the same variables as are set in /etc/make.conf, and this provides another way of setting them.

    # make -DNOPROFILE target

    is another way of specifying that profiled libraries should not be built, and corresponds with the

    NOPROFILE= true # Avoid compiling profiled libraries

    line in /etc/make.conf.

    target tells make(1) what you want to do. Each Makefile defines a number of different “targets”, and your choice of target determines what happens.

    Some targets are listed in the Makefile, but are not meant for you to run. Instead, they are used by the build process to break out the steps necessary to rebuild the system into a number of sub-steps.

    Most of the time you will not need to pass any parameters to make(1), and so your command like will look like this:

    # make target

    Beginning with version 2.2.5 of FreeBSD (actually, it was first created on the FreeBSD-CURRENT branch, and then retrofitted to FreeBSD-STABLE midway between 2.2.2 and 2.2.5) the world target has been split in two: buildworld and installworld. Beginning with version 5.3 of FreeBSD the world target will be changed so it will not work at all by default because it is actually dangerous for most users.

    As the names imply, buildworld builds a complete new tree under /usr/obj, and installworld installs this tree on the current machine.

    This is very useful for 2 reasons. First, it allows you to do the build safe in the knowledge that no components of your running system will be affected. The build is “self hosted”. Because of this, you can safely run buildworld on a machine running in multi-user mode with no fear of ill-effects. It is still recommended that you run the installworld part in single user mode, though.

    Secondly, it allows you to use NFS mounts to upgrade multiple machines on your network. If you have three machines, A, B and C that you want to upgrade, run make buildworld and make installworld on A. B and C should then NFS mount /usr/src and /usr/obj from A, and you can then run make installworld to install the results of the build on B and C.

    Although the world target still exists, you are strongly encouraged not to use it.


    # make buildworld

    It is now possible to specify a -j option to make which will cause it to spawn several simultaneous processes. This is most useful on multi-CPU machines. However, since much of the compiling process is IO bound rather than CPU bound it is also useful on single CPU machines.

    On a typical single-CPU machine you would run:

    # make -j4 buildworld

    make(1) will then have up to 4 processes running at any one time. Empirical evidence posted to the mailing lists shows this generally gives the best performance benefit.

    If you have a multi-CPU machine and you are using an SMP configured kernel try values between 6 and 10 and see how they speed things up.

    Be aware that this is still somewhat experimental, and commits to the source tree may occasionally break this feature. If the world fails to compile using this parameter try again without it before you report any problems. Timings

    Many factors influence the build time, but currently a 500 MHz Pentium® III with 128 MB of RAM takes about 2 hours to build the FreeBSD-STABLE tree, with no tricks or shortcuts used during the process. A FreeBSD-CURRENT tree will take somewhat longer.
    20.4.8 Compile and Install a New Kernel

    To take full advantage of your new system you should recompile the kernel. This is practically a necessity, as certain memory structures may have changed, and programs like ps(1) and top(1) will fail to work until the kernel and source code versions are the same.

    The simplest, safest way to do this is to build and install a kernel based on GENERIC. While GENERIC may not have all the necessary devices for your system, it should contain everything necessary to boot your system back to single user mode. This is a good test that the new system works properly. After booting from GENERIC and verifying that your system works you can then build a new kernel based on your normal kernel configuration file.

    On modern versions of FreeBSD it is important to build world before building a new kernel.

    Note: If you want to build a custom kernel, and already have a configuration file, just use KERNCONF=MYKERNEL like this:

    # cd /usr/src
    # make buildkernel KERNCONF=MYKERNEL
    # make installkernel KERNCONF=MYKERNEL

    Note that if you have raised kern.securelevel above 1 and you have set either the noschg or similar flags to your kernel binary, you might find it necessary to drop into single user mode to use installkernel. Otherwise you should be able to run both these commands from multi user mode without problems. See init(8) for details about kern.securelevel and chflags(1) for details about the various file flags.
    20.4.9 Reboot into Single User Mode

    You should reboot into single user mode to test the new kernel works. Do this by following the instructions in Section 20.4.5.
    20.4.10 Install the New System Binaries

    If you were building a version of FreeBSD recent enough to have used make buildworld then you should now use installworld to install the new system binaries.


    # cd /usr/src
    # make installworld

    Note: If you specified variables on the make buildworld command line, you must specify the same variables in the make installworld command line. This does not necessarily hold true for other options; for example, -j must never be used with installworld.

    For example, if you ran:

    # make -DNOPROFILE buildworld

    you must install the results with:

    # make -DNOPROFILE installworld

    otherwise it would try to install profiled libraries that had not been built during the make buildworld phase.

    20.4.11 Update Files Not Updated by make installworld

    Remaking the world will not update certain directories (in particular, /etc, /var and /usr) with new or changed configuration files.

    The simplest way to update these files is to use mergemaster(8), though it is possible to do it manually if you would prefer to do that. Regardless of which way you choose, be sure to make a backup of /etc in case anything goes wrong. mergemaster
    Contributed by Tom Rhodes.

    The mergemaster(8) utility is a Bourne script that will aid you in determining the differences between your configuration files in /etc, and the configuration files in the source tree /usr/src/etc. This is the recommended solution for keeping the system configuration files up to date with those located in the source tree.

    To begin simply type mergemaster at your prompt, and watch it start going. mergemaster will then build a temporary root environment, from / down, and populate it with various system configuration files. Those files are then compared to the ones currently installed in your system. At this point, files that differ will be shown in diff(1) format, with the + sign representing added or modified lines, and - representing lines that will be either removed completely, or replaced with a new line. See the diff(1) manual page for more information about the diff(1) syntax and how file differences are shown.

    mergemaster(8) will then show you each file that displays variances, and at this point you will have the option of either deleting the new file (referred to as the temporary file), installing the temporary file in its unmodified state, merging the temporary file with the currently installed file, or viewing the diff(1) results again.

    Choosing to delete the temporary file will tell mergemaster(8) that we wish to keep our current file unchanged, and to delete the new version. This option is not recommended, unless you see no reason to change the current file. You can get help at any time by typing ? at the mergemaster(8) prompt. If the user chooses to skip a file, it will be presented again after all other files have been dealt with.

    Choosing to install the unmodified temporary file will replace the current file with the new one. For most unmodified files, this is the best option.

    Choosing to merge the file will present you with a text editor, and the contents of both files. You can now merge them by reviewing both files side by side on the screen, and choosing parts from both to create a finished product. When the files are compared side by side, the l key will select the left contents and the r key will select contents from your right. The final output will be a file consisting of both parts, which can then be installed. This option is customarily used for files where settings have been modified by the user.

    Choosing to view the diff(1) results again will show you the file differences just like mergemaster(8) did before prompting you for an option.

    After mergemaster(8) is done with the system files you will be prompted for other options. mergemaster(8) may ask if you want to rebuild the password file and/or run MAKEDEV(8) if you run a FreeBSD version prior to 5.0, and will finish up with an option to remove left-over temporary files. Manual Update

    If you wish to do the update manually, however, you cannot just copy over the files from /usr/src/etc to /etc and have it work. Some of these files must be “installed” first. This is because the /usr/src/etc directory is not a copy of what your /etc directory should look like. In addition, there are files that should be in /etc that are not in /usr/src/etc.

    If you are using mergemaster(8) (as recommended), you can skip forward to the next section.

    The simplest way to do this by hand is to install the files into a new directory, and then work through them looking for differences.

    Backup Your Existing /etc: Although, in theory, nothing is going to touch this directory automatically, it is always better to be sure. So copy your existing /etc directory somewhere safe. Something like:

    # cp -Rp /etc /etc.old

    -R does a recursive copy, -p preserves times, ownerships on files and suchlike.

    You need to build a dummy set of directories to install the new /etc and other files into. /var/tmp/root is a reasonable choice, and there are a number of subdirectories required under this as well.

    # mkdir /var/tmp/root
    # cd /usr/src/etc
    # make DESTDIR=/var/tmp/root distrib-dirs distribution

    This will build the necessary directory structure and install the files. A lot of the subdirectories that have been created under /var/tmp/root are empty and should be deleted. The simplest way to do this is to:

    # cd /var/tmp/root
    # find -d . -type d | xargs rmdir 2>/dev/null

    This will remove all empty directories. (Standard error is redirected to /dev/null to prevent the warnings about the directories that are not empty.)

    /var/tmp/root now contains all the files that should be placed in appropriate locations below /. You now have to go through each of these files, determining how they differ with your existing files.

    Note that some of the files that will have been installed in /var/tmp/root have a leading “.”. At the time of writing the only files like this are shell startup files in /var/tmp/root/ and /var/tmp/root/root/, although there may be others (depending on when you are reading this). Make sure you use ls -a to catch them.

    The simplest way to do this is to use diff(1) to compare the two files:

    # diff /etc/shells /var/tmp/root/etc/shells

    This will show you the differences between your /etc/shells file and the new /var/tmp/root/etc/shells file. Use these to decide whether to merge in changes that you have made or whether to copy over your old file.

    Name the New Root Directory (/var/tmp/root) with a Time Stamp, so You Can Easily Compare Differences Between Versions: Frequently rebuilding the world means that you have to update /etc frequently as well, which can be a bit of a chore.

    You can speed this process up by keeping a copy of the last set of changed files that you merged into /etc. The following procedure gives one idea of how to do this.


    Make the world as normal. When you want to update /etc and the other directories, give the target directory a name based on the current date. If you were doing this on the 14th of February 1998 you could do the following:

    # mkdir /var/tmp/root-19980214
    # cd /usr/src/etc
    # make DESTDIR=/var/tmp/root-19980214 \
    distrib-dirs distribution


    Merge in the changes from this directory as outlined above.

    Do not remove the /var/tmp/root-19980214 directory when you have finished.

    When you have downloaded the latest version of the source and remade it, follow step 1. This will give you a new directory, which might be called /var/tmp/root-19980221 (if you wait a week between doing updates).

    You can now see the differences that have been made in the intervening week using diff(1) to create a recursive diff between the two directories:

    # cd /var/tmp
    # diff -r root-19980214 root-19980221

    Typically, this will be a much smaller set of differences than those between /var/tmp/root-19980221/etc and /etc. Because the set of differences is smaller, it is easier to migrate those changes across into your /etc directory.

    You can now remove the older of the two /var/tmp/root-* directories:

    # rm -rf /var/tmp/root-19980214


    Repeat this process every time you need to merge in changes to /etc.

    You can use date(1) to automate the generation of the directory names:

    # mkdir /var/tmp/root-`date "+%Y%m%d"`

    20.4.12 Update /dev

    Note: If you are running FreeBSD 5.0 or later you can safely skip this section. These versions use devfs(5) to allocate device nodes transparently for the user.

    In most cases, the mergemaster(8) tool will realize when it is necessary to update the device nodes, and offer to complete it automatically. These instructions tell how to update the device nodes manually.

    For safety's sake, this is a multi-step process.


    Copy /var/tmp/root/dev/MAKEDEV to /dev:

    # cp /var/tmp/root/dev/MAKEDEV /dev

    If you used mergemaster(8) to update /etc, then your MAKEDEV script should have been updated already, though it cannot hurt to check (with diff(1)) and copy it manually if necessary.

    Now, take a snapshot of your current /dev. This snapshot needs to contain the permissions, ownerships, major and minor numbers of each filename, but it should not contain the time stamps. The easiest way to do this is to use awk(1) to strip out some of the information:

    # cd /dev
    # ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out


    Remake all the device nodes:

    # sh MAKEDEV all


    Write another snapshot of the directory, this time to /var/tmp/dev2.out. Now look through these two files for any device node that you missed creating. There should not be any, but it is better to be safe than sorry.

    # diff /var/tmp/dev.out /var/tmp/dev2.out

    You are most likely to notice disk slice discrepancies which will involve commands such as:

    # sh MAKEDEV sd0s1

    to recreate the slice entries. Your precise circumstances may vary.

    20.4.13 Update /stand

    Note: This step is included only for completeness. It can safely be omitted. If you are using FreeBSD 5.2 or later, the /rescue directory is automatically updated for the user with current, statically compiled binaries during make installworld, thus obsoleting the need to update /stand (which does not exist at all on FreeBSD 6.0 and later).

    For the sake of completeness, you may want to update the files in /stand as well. These files consist of hard links to the /stand/sysinstall binary. This binary should be statically linked, so that it can work when no other file systems (and in particular /usr) have been mounted.

    # cd /usr/src/release/sysinstall
    # make all install

    20.4.14 Rebooting

    You are now done. After you have verified that everything appears to be in the right place you can reboot the system. A simple shutdown(8) should do it:

    # shutdown -r now

    20.4.15 Finished

    You should now have successfully upgraded your FreeBSD system. Congratulations.

    If things went slightly wrong, it is easy to rebuild a particular piece of the system. For example, if you accidentally deleted /etc/magic as part of the upgrade or merge of /etc, the file(1) command will stop working. In this case, the fix would be to run:

    # cd /usr/src/usr.bin/file
    # make all install

    20.4.16 Questions Do I need to re-make the world for every change? My compile failed with lots of signal 11 (or other signal number) errors. What has happened? Can I remove /usr/obj when I have finished? Can interrupted builds be resumed? How can I speed up making the world? What do I do if something goes wrong? Do I need to re-make the world for every change?

    There is no easy answer to this one, as it depends on the nature of the change. For example, if you just ran CVSup, and it has shown the following files as being updated:


    it probably is not worth rebuilding the entire world. You could just go to the appropriate sub-directories and make all install, and that's about it. But if something major changed, for example src/lib/libc/stdlib then you should either re-make the world, or at least those parts of it that are statically linked (as well as anything else you might have added that is statically linked).

    At the end of the day, it is your call. You might be happy re-making the world every fortnight say, and let changes accumulate over that fortnight. Or you might want to re-make just those things that have changed, and be confident you can spot all the dependencies.

    And, of course, this all depends on how often you want to upgrade, and whether you are tracking FreeBSD-STABLE or FreeBSD-CURRENT. My compile failed with lots of signal 11 (or other signal number) errors. What has happened?

    This is normally indicative of hardware problems. (Re)making the world is an effective way to stress test your hardware, and will frequently throw up memory problems. These normally manifest themselves as the compiler mysteriously dying on receipt of strange signals.

    A sure indicator of this is if you can restart the make and it dies at a different point in the process.

    In this instance there is little you can do except start swapping around the components in your machine to determine which one is failing. Can I remove /usr/obj when I have finished?

    The short answer is yes.

    /usr/obj contains all the object files that were produced during the compilation phase. Normally, one of the first steps in the make buildworld process is to remove this directory and start afresh. In this case, keeping /usr/obj around after you have finished makes little sense, and will free up a large chunk of disk space (currently about 340 MB).

    However, if you know what you are doing you can have make buildworld skip this step. This will make subsequent builds run much faster, since most of sources will not need to be recompiled. The flip side of this is that subtle dependency problems can creep in, causing your build to fail in odd ways. This frequently generates noise on the FreeBSD mailing lists, when one person complains that their build has failed, not realizing that it is because they have tried to cut corners. Can interrupted builds be resumed?

    This depends on how far through the process you got before you found a problem.

    In general (and this is not a hard and fast rule) the make buildworld process builds new copies of essential tools (such as gcc(1), and make(1)) and the system libraries. These tools and libraries are then installed. The new tools and libraries are then used to rebuild themselves, and are installed again. The entire system (now including regular user programs, such as ls(1) or grep(1)) is then rebuilt with the new system files.

    If you are at the last stage, and you know it (because you have looked through the output that you were storing) then you can (fairly safely) do:

    ... fix the problem ...
    # cd /usr/src
    # make -DNOCLEAN all

    This will not undo the work of the previous make buildworld.

    If you see the message:

    Building everything..

    in the make buildworld output then it is probably fairly safe to do so.

    If you do not see that message, or you are not sure, then it is always better to be safe than sorry, and restart the build from scratch. How can I speed up making the world?


    Run in single user mode.

    Put the /usr/src and /usr/obj directories on separate file systems held on separate disks. If possible, put these disks on separate disk controllers.

    Better still, put these file systems across multiple disks using the ccd(4) (concatenated disk driver) device.

    Turn off profiling (set “NOPROFILE=true” in /etc/make.conf). You almost certainly do not need it.

    Also in /etc/make.conf, set CFLAGS to something like -O -pipe. The optimization -O2 is much slower, and the optimization difference between -O and -O2 is normally negligible. -pipe lets the compiler use pipes rather than temporary files for communication, which saves disk access (at the expense of memory).

    Pass the -jn option to make(1) to run multiple processes in parallel. This usually helps regardless of whether you have a single or a multi processor machine.

    The file system holding /usr/src can be mounted (or remounted) with the noatime option. This prevents the file system from recording the file access time. You probably do not need this information anyway.

    # mount -u -o noatime /usr/src

    Warning: The example assumes /usr/src is on its own file system. If it is not (if it is a part of /usr for example) then you will need to use that file system mount point, and not /usr/src.


    The file system holding /usr/obj can be mounted (or remounted) with the async option. This causes disk writes to happen asynchronously. In other words, the write completes immediately, and the data is written to the disk a few seconds later. This allows writes to be clustered together, and can be a dramatic performance boost.

    Warning: Keep in mind that this option makes your file system more fragile. With this option there is an increased chance that, should power fail, the file system will be in an unrecoverable state when the machine restarts.

    If /usr/obj is the only thing on this file system then it is not a problem. If you have other, valuable data on the same file system then ensure your backups are fresh before you enable this option.

    # mount -u -o async /usr/obj

    Warning: As above, if /usr/obj is not on its own file system, replace it in the example with the name of the appropriate mount point. What do I do if something goes wrong?

    Make absolutely sure your environment has no extraneous cruft from earlier builds. This is simple enough.

    # chflags -R noschg /usr/obj/usr
    # rm -rf /usr/obj/usr
    # cd /usr/src
    # make cleandir
    # make cleandir

    Yes, make cleandir really should be run twice.

    Then restart the whole process, starting with make buildworld.

    If you still have problems, send the error and the output of uname -a to FreeBSD general questions mailing list. Be prepared to answer other questions about your setup!

    WTF all of this just to update Telnet???

    Now, there is something called Freebsd-update

    This tool can help you update it, but then you have to set that up. And for some reason you have to use a key.... Why? Why in God's name would you need a key just to download updates? I mean it would be cool if it was something you COULD do, but something you must do?

    So for the other users of Free BSD here, how do you do it? This is WAY to much to do when you consider updates can be found more than once a month.

    If anyone from Free BSD is reading this, PLEASE, find a system that allows updates in a matter that makes more sence.

    This is plain wrong. I mean why do you need to do all this for Telnet of all things?

    On Slackware it would take me a minute at most to update. On Free BSD it would take hours or even a day. Depending on system speed and so on.

    I guess I just needed to get that out. I can't understand why anyone would do this just to update. There has to be a way to do this in the way Linux or even Windows does it where you download a patch, upgrade the program and you're done.

    Hell the only time in Slackware I reboot for a patch is when it's a Kernel. And even then you technically don't have to if you know which portions to redo.

    Anyone else wish to add to this?

  2. #2
    Senior Member IKnowNot's Avatar
    Join Date
    Jan 2003
    Have you read

    Keeping FreeBSD Up-To-Date: A Security Odyssey
    It describes use of
    Binary Security Updates for FreeBSD -- over 100,000 served!
    ( freebsd-update )

    I know you mentioned it, but you made it sound much harder then it is.

    " And maddest of all, to see life as it is and not as it should be" --Miguel Cervantes

  3. #3
    Leftie Linux Lover the_JinX's Avatar
    Join Date
    Nov 2001
    Beverwijk Netherlands
    I agree with IKnowNot..

    It isn't hard at all !! (en thus voted for: No, I feel Free BSD has a great method of updating even if it is like installing a new copy.)
    ASCII stupid question, get a stupid ANSI.
    When in Russia, pet a PETSCII.

    Get your ass over to SLAYRadio the best station for C64 Remixes !

  4. #4
    Have you ever heard of writing a script? ie
    cvsup -g -L 1 /root/sourcesup;
    cd /usr/src;
    make buildworld && make buildkernel KERNCONF=blah && make install K......

    mergemaster is not needed for a patch so its moot

    It takes about 2 minutes of down time to boot in single user and install world and really singleuser mode is not needed most of the time. Its not like you have to do any work the computer does the compiling.

    A 2 second google search finds (did you even look?):

    "For historical reasons, the telnet build is rather messy: Depending
    upon which options you have set in /etc/make.conf, telnet might need
    to be rebuilt from one of four different directories. We decided
    that having everybody run "make buildworld" was far less prone to
    error than trying to explain which particular version of telnet each
    system would need to have rebuilt."
    looks like they were looking out for you

    Bsdupdate needs a key to be secure just as portsnap does, a good idea perhaps?

    You could also just chmod 000 /bin/telnet (most never use it anyway?)

    "And even then you technically don't have to if you know which portions to redo."
    Runtime kernel patching is asking for trouble

  5. #5
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    Originally posted here by whistles
    Have you ever heard of writing a script? ie
    cvsup -g -L 1 /root/sourcesup;
    cd /usr/src;
    make buildworld && make buildkernel KERNCONF=blah && make install K......

    Write a script for what? If I wanted to do this every night I'd install Gentoo.

    mergemaster is not needed for a patch so its moot
    Yes they just pop that in there to **** with you.

    It takes about 2 minutes of down time to boot in single user and install world and really singleuser mode is not needed most of the time. Its not like you have to do any work the computer does the compiling.
    WTF did you think I was thinking? All the Japanese kids in my basement I made memorize numbers before I had a computer got deported.

    A 2 second google search finds
    And actually reading my thread finds that I used telnet as an example only and linked to others.

    (did you even look?):
    Oh heeeellll no. I just sat here pissed and decided to start a flame war.

    "For historical reasons, the telnet build is rather messy: Depending
    upon which options you have set in /etc/make.conf, telnet might need
    to be rebuilt from one of four different directories. We decided
    that having everybody run "make buildworld" was far less prone to
    error than trying to explain which particular version of telnet each
    system would need to have rebuilt."

    looks like they were looking out for you
    Did you just skip over most of what I said like the first line for example?

    Bsdupdate needs a key to be secure just as portsnap does, a good idea perhaps?
    Someone once thought Microsoft Bob was a good idea. Just because it sounds like oen doesn't mean it is.

    You could also just chmod 000 /bin/telnet (most never use it anyway?)
    Again, I believe I've pointed out a few times now that I used Telnet as an example. Read what I actually said and quit making yourself appear incompetent.

    "And even then you technically don't have to if you know which portions to redo."
    Runtime kernel patching is asking for trouble
    So is half assed replying.

  6. #6
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    Oh and Iknownot, perhaps you'd like to check this out.

    Been awake quite a long time but when I searched the file system for the damn /etc file for freebsd-update, I couldn't find it. I started playing with it and it gave a hint on where to find it but it wasn't there. I know I installed it because that was done before I was tired.

  7. #7
    Senior Member IKnowNot's Avatar
    Join Date
    Jan 2003
    freebsd-update is just meant to install binary updates ( security patches ) so you don't have to build them yourself, but it is certainly not as feature-rich as YAST or YUM, nor does it update everything.

    As said in the links provided, it is not really meant for systems which have customized builds. You also can not pick and choose which updates to install, but since these are security patches I do not know why you wouldn't install all of them.

    did you try
    #pkg_info -x freebsd-update

    to see if is actually installed?

    here is the output of whereis on one box:

    # whereis freebsd-update
    freebsd-update: /usr/local/sbin/freebsd-update /usr/local/man/man8/freebsd-update.8.gz /usr/ports/security/freebsd-update

    The supplied freebsd-update.conf.sample file
    ( located in /usr/local/etc/ )
    directs the program to download binaries that the author built. If you know of another more trusted repository you can edit the file. Or just copy it, as stated in the first link above to

    then try it

    Hope this helps.

    BTW, I agree, before FreeBSD is ever seriously considered for regular users as a desktop they will have to come up with a better system for updating. But then again, I don't use it as a desktop.
    " And maddest of all, to see life as it is and not as it should be" --Miguel Cervantes

  8. #8
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    The thing was installed. I know this as I ran it thinking OK cool finally a tool for updates. That's when it said I needed a key and got pissed. It was 3 AM and I'm like "DAMN I do NOT want to be doing this right now"...

    I don't understand the need for the key. I just dont. Why have to go through that JUST to download updates and stuff? Why not make it so pkg_add can do the updates? I know a lot of people from that team, and they do want Free BSD as a desktop.

    But that's not going to happen because let me tell you, users think Windows Update is to much, there is no way in redo the kernel hell they are going to do that at all.

    But thanks for pointing out where it is.

    Though it would be nice to have an actual decent app to do this so that someone installing at 3 AM doesn't want to shoot the CDs.

    port-update is easier to use than that thing.

    Well, it is if you have a fast box and net connection as it takes like 17 hours.

  9. #9
    Just Another Geek
    Join Date
    Jul 2002
    Rotterdam, Netherlands
    First off... There is a HUGE difference between a source upgrade and a binary upgrade.. Most, if not all, linux distros, MacOS, BEOS and/or Windows use some sort of binary upgrade scheme for the base OS and 3rd party software.. The whole cvsup/patching, make world stuff used by FreeBSD is a source upgrade..

    Next, if you track RELENG_6 (currently 6.0-STABLE) you're advised to run mergemaster.. Defaults tend to change.. startup scripts get changed etc.. You might get away without running mergemaster if you track RELENG_6_0 (6.0-RELEASE).. But still, to avoid problems (your system not booting after an upgrade) run mergemaster..

    If you're absolutely sure only telnet is changed you can source upgrade telnet by doing cd /usr/src/usr.bin/telnet && make all install. But you might bite off more then you can chew if any of the dependencies of telnet (or those that are dependend on telnet) are incompatible with the changes. Still, no need to reboot but you're advised to do this in single user mode for obvious reasons.

    pkg_add, pkg_info etc.. are tools designed to install 3rd party packages, not parts of the base OS.

    I rather like using the source upgrade.. It means I get to tweak the compiler options and make the resulting binaries specifically for my machine/architecture.. With a binary upgrade you have no idea what the compiler options where, what optimizations etc.. In short, you're more in control..

    Hell, I've source upgraded all my systems since 3.1.. Never ever had any problems. I only did a binary reinstall with 4.x. But only because the layout (and sizes) of the default partitions changed.

    Edit: Ah, forgot.. There's an option in sysinstall to do a binary upgrade.. But I do believe it does a full reinstall.. I don't know, never used it..

    One other thing.. The easiest way to update a system i've seen until now is Windows update.. How difficult is that? But I've come across many, many users that don't even understand that.. Hell, I'm wondering how those people are even able to turn on their computer..

    Oliver's Law:
    Experience is something you don't get until just after you need it.

  10. #10
    A) writing a script makes it so you only have to do it once, umm thats the whole point

    B) If you don't understand why mergemaster is not needed for a simple patch, do some reading its quite obvious.

    C) If you had looked you would have seen the telnet is an exception not the rule, hence non kernel patches don't need a reboot or to rebuild the kernel, telnet was just done that way for the ease of the masses, i believe that hpux is the only os that a kernel patch does not need a reboot IIRC

    D) Do you even know what the key is they are talking about? A mitm is doable with cvsup, not with portsnap/bsdupdate

    E) Incompetent, your the one complaining about recompiling and rebooting for stuff that has a simple work around

    F) If you are to lazy or dumb to do a simple patch maybe you should just stick with the pointy clicky thing or maybe use bsdupdate its no different than windows update other than typing a command rather than pointing and clicking.

    G) the whole philosophy is about flexability and the ability to change what you want not have everything automated for you in ways you may not want. Bsdupdate is the same as any other systems patching, easier than some i would say. You could also get off your fat lazy ass an write a front end for bsdupdate, Ya could even make it look just like windows update if you wanted.(may have already been done for all i know)

    H) why don't you suggest porting swaret or whatever on a Freebsd mailist and see what kind of replies you get , i figure it will be something like "if you cannot figure out how to patch or don't have the time, then use bsdupdate its easy and thats why its there."

    If i were to make a guess you have probably already been kicked from several #FreeBSD chans and laughed at on mailing lists? Am i right?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts