Most tech savvy geeks can work their way through a FreeBSD install, even if
they have no prior UNIX experience. However installing an OS and configuring an OS are two totally different things. This article is targeted towards anyone who might be wondering about FreeBSD, but doesn’t know what to do with it after they install it. This isn’t then end-all be-all of FreeBSD howto’s. Just some of the simple stuff. Update: Some of the readers of OSNews have emailed me concerning corrections that need to be made in this article. Dig in (third page) for more.
CVSup
So you’ve taken the first step and installed FreeBSD. Now you’re wondering what to do with this new operating system. Unlike some of the bigger Linux distributions, FreeBSD gives you a basic install, and leaves it upto you to add in what you want. Lets say that you want to set up this box as a SMB file server for your network. To do that we will need to install Samba. This seems like the perfect time to see that “ports tree” that youkeep hearing so much about in action. The first thing we need to do is install
the cvsup package. Cvsup is a utility that reads a conf file, known as a ‘sup-file’ that tells it what server to use, and what to download. In essencewhat it does is it compares your local copy of the ports tree to the copy of the ports tree on the cvsup server. It then downloads everything in the ports tree that is newer than what is on your machine. The easiest way of installing cvsup is with the pkg_add command. All you have to do is login in as root, and type “pkg_add -r cvsup” and it will automatically download the cvsup package from a FreeBSD server and install it. You can also find on the CD under the
/cdrom/Packages/All directory. Now that it is installed, we need to create our custom sup-file. The templates are located in the /usr/share/examples/cvsup directory. We want to copy the ports-supfile someplace where we won’t loose it.
I prefer the /root directory, but copy it wherever you want to. Next we need toedit the file, so open it up in your editor of choice. Note that unless you choose to install your favorite editor during the install you might have to get by with vi for now. First we have to change the cvsup host server, so we go over to freebsd.org and consult the handbook.
After you locate a cvsup server closest to you, change the
“CHANGE_THIS.freebsd.org” to whatever server is closest to you. Now we need to set up which collections we want to download whenever we run cvsup. The ports tree is divided into several sections such as ports-cad, ports-german, etc,
etc. By default the sup-file uses the ports-all collection, which is all of the collections. Since I don’t know any language besides English, I commented out
all of the foreign language collections. NOTE: If you do comment out any of the collections, be sure that you DO comment out the ports-all entry and that you DO NOT accidentally comment out the ports-base entry. Nothing horribly bad will happen if you do other than you will have to cvsup the ports tree again. After you have edited the file, run the command “cvsup ports-supfile”. You should see lots of messages fly by as the ports tree is updated. The time it takes to update depends on two things, the speed of your ‘Net connection, and how long ago you last updated. Depending on how long ago you downloaded the ISO image of the -RELEASE CD it could be pretty outdated, so it could take awhile for the process to complete. In my opinion it is better to answer “Yes” during the install when it asks you if you want to install the ports tree from CDROM. Even though it might be out of date, some of the ports will still be current, which will save you time and bandwidth when you first cvsup.
Mounting CDROM’s
One of the first things I had to do when I first installed FreeBSD was mount my CDROM so that I could install cvsup. I didn’t know about the -r flag yet, but even if you don’t need it for a package, you will probably need to read a CDROM sooner or later. All you have to do is find the device name of your CDROM(look in dmesg | more). After you find that open your /etc/fstab file and add a new
line that consists of /dev/xxx /cdrom cd9660 ro,noauto 0 0 where /dev/xxx is whatever device your CDROM is. After that you have to type “mount /cdrom” and then you can access the contents of the CDROM under the /cdrom
directory. If for some reason you don’t have a /cdrom directory, just type “mkdir /cdrom”. Also, by default you have to be root to mount filesystems, that includes CDROM’s.
Init
The various Linux distro’s(except for slackware) use the sysinitV style of rc files to determine what gets started at boot up. FreeBSD on the other hand uses a bsd-style init system. Essentially all you have to do to start something at
boot time it to write a shell script that starts the program, make the script executable, put a .sh ending on it and place it in the /usr/local/etc/rc.d directory. Note that it is a requirement that the script ends with .sh. Also
note that the /etc directory has several rc.* files, but not a rc.d directory. That’s because by convention you should place your startup scripts in the /usr/local/etc/rc.d directory, in fact you’ll notice that almost anything installed via ports or packages, and for the most part compiled by hand will either install by default in /usr/local/ or /usr/X11R6 instead of /opt and
/usr.
After cvsup completes, you are ready to install some apps! First of all, if your editor of choice isn’t installed already, cd into the /usr/ports/editors directory and have a look around. For instance if I wanted to install the vim
editor I would move into the vim directory and as root type “make”. This command will read the Makefile in that directory and download and compile the newest version of vim. After that completes, type “make install” to actually
install the compiled binaries. After the installation type “make clean” to remove the temporary files created during the compile. In our example we are configuring a Samba server, so go ahead and follow the make, make install, make clean steps for the samba port in the /usr/ports/net/samba directory. After it is installed the smb.conf file is located in the /usr/local/etc/ directory. Also if you would like samba to startautomatically when the OS boots you need to take a quick glance at the startup script in /usr/local/etc/rc.d to make sure that it has the correct suffix. Some
(but not all) ports install the startup script with a .default suffix so that if you want it to start automatically you have to manually rename it. Which is
a good thing, or at least I think it is. At the time of this article’s writing there are 6740 applications in FreeBSD’s port tree, and my ports tree (the Makefiles and any source patches that are required for the port) takes up only 165MB.
This ports tree contains most of the popular open source applications that are available today. These applications can be updated regularly and it would be a huge hassle to constantly check the Web in case a new version of one of your installed packages has been released. This is where the amazing freshports.org comes to the rescue. Freshports is a neat web site dedicated to FreeBSD’s ports tree. You can subscribe to Freshports, and set up a list of watched ports, and then whenever one of your watched ports is upgraded you get an email notification of it! Then all you have to do is sync your ports tree, and upgrade your port. Which brings me to the next subject, package maintenance. As we saw above, pkg_add installs binary packages, and if used with the -r flag it will download the package for you (eg. pkg_add -r bash2 will download and install bash version 2). Now that
we have installed a few packages/ports, type “pkg_info | more” to get a listing of installed software. Don’t be surprised if the “| more” becomes necessary before too long. Also notice that both packages that you installed with pkg_add and also posts that you compiled via the ports tree both show up, pkg_info doesn’t care which way they were installed.
Now we need to delve back into the ports tree again, this time to /usr/ports/sysutils/portupgrade. This extremely handy application takes care of upgrading a previously installed port. Lets say that after installing vim, we
get an email from Freshports telling us that the vim port has been updated. So all we have to do is type “pkg_info | grep vim” to get the “proper” package name for vim (eg. the output I get from this is vim-6.0.185). Then all you have to do is type “portupgrade vim-6.0.185” and goes about the process of downloading, compiling, and upgrading vim. If portupgrade reports that vim doesn’t need upgrading, make sure you cvsup’d your ports tree recently. The tar files that are downloaded from the Internet to be compiled are stored in /usr/ports/distfiles, if your short on disk space that directory is a good place to reclaim disk space. Also note that by installing the portupgrade port, you also get the pkg_deinstall command, which is a nice neat wrapper for pkg_delete. I recommend using pkg_deinstall, it’s much easier to use when it comes time to remove a package that several other packages depend on. One last note on package management, if portupgrade ever tells you that you need to manually run “pkgdb -F”, it is safe to delete what are known as “Stale Dependencies”. They are simply pointers to packages that are either gone, or updated and the database hasn’t been updated to reflect the changes. Upgrading with “make buildworld” One of the best things about FreeBSD is the way that “FreeBSD” itself is a defined set of utilities, and when FreeBSD is updated, so are those included utilities. The most common way of upgrading an existing FreeBSD installation is to with the “make buildworld” and “make installworld” commands.
You can get a copy of the source sup file in
/usr/share/examples/cvsup/stable-cvsup. Be sure to change the host name of the server. Now all you have to do it type “cvsup stable-cvsup”, and you get the latest and greatest copy of the stable source code for Freebsd-4.x. Once again the time it takes for this complete depends on the speed of your Internet connection and the time elapsed since you last cvsup’d the source tree. The ports tree is universal no matter what version of FreeBSD your using, so the ports tree you cvsup on a -STABLE system is the same as what you get if you cvsup on -CURRENT. The source tree however is made up of many versions. There are the -STABLE and the -CURRENT trees. The -CURRENT tree is currently in
testing (think beta) and should not be used on production systems. The -STABLE tree is made up of the “stable” source code. The versions of FreeBSD that is available as ISO’s are simply periodic snapshots of the -STABLE tree. You
should track the -STABLE tree for your production servers, as the -STABLE tree is updated with bug fixes and security patches.
After the cvsup finishes, cd into the /usr/obj directory and make sure that it is empty. When you compile the source code for -STABLE or -CURRENT the temporary files go into the /usr/obj directory. If there are files in this
directory it is possible that they could conflict with the newer files that we are trying to compile. It’s just best to empty that directory before we start. Now cd into the /usr/src directory and type “make buildworld”. The compiles the new code, but does not install it. After that finishes we have to boot into single user mode. Reboot the machine, before you get the message telling you to press Enter to boot /kernel, hit any key. That should drop you at a prompt, type “boot -s /kernel”. In FreeBSD the OS’s kernel is /kernel, what the above command does is tell the loader to boot /kernel into single user mode. After it
boots into single user mode, it will ask for a path to your preferred shell, or use sh by default. After you set the shell, type “fsck -p” which checks the filesystem for inconsistencies. Next type “mount -u /”, this changes status of the / partition from read-only to read-write. Now type “mount -a” – this mounts all of the filesystems in the /etc/fstab file that do NOT have the “noauto”
option. Finally cd into the /usr/src directory and type “make installworld”. This step actually installs the new files from the /usr/obj directory. After it finishes hit the “Ctrl-D” combo to boot the machine into multi-user mode.
Finally, to finish the upgrade we have to compile a new kernel. Now cd into the /usr/src/sys/i386/conf directory. In a default install there should be a LINT and a GENERIC file. The GENERIC file is the conf file for the system’s default kernel; we need to make a copy of it. I copied mine like this “cp GENERIC NATHAN”, you can name your copy anything you want. After that you need to edit
your kernel to add any options you might need or remove ones you don’t need. The kernel conf file contains some comments about what each option does, however for more detailed information look in the LINT file. Don’t edit the
GENERIC file, as every time you cvsup the source tree that file gets replaced with the newer GENERIC file and you would loose your changes. After you have finished editing your file, run “config NATHAN” or whatever you named your
file. The config program parses the file and makes sure that there are no typos or other errors. If for some reason you would need to add debugging info into the kernel run the config program with the -g flag. A kernel with debugging code results in a larger kernel, you probably don’t need it unless your hacking kernel code. After config runs it will instruct you to cd into the
../../compile/NATHAN directory. Once you are in that directory, run “make depend”, which makes sure that you have everything thing needed to compile the kernel, it’s recommended by the config program, however it’s not required. After that finishes simply run “make”, which actually compiles the kernel, once that completes type “make install” which will install the kernel in /kernel. It renames the existing /kernel to /kernel.old, and installs the new one as /kernel. If there is a /kernel.old from a previous compile, it gets
overwritten. After that, all that is left to do is reboot!
If for some reason the new kernel will not boot, drop down to the boot loader prompt like we did when booting into single user mode. Except this time, type “boot /kernel.old”, which will boot the “old” or previous working kernel.
UPDATE!
Some of the readers of OSNEWS have emailed me concerning corrections that need to be made in this article. The next few paragraphs explain what is changed, and why. Please take note that anything said here should be used in place
of anything said above.
1)In the “ports” section I explained that in order to update an installed package via portupgrade that you have to type “pkg_info | grep *name*” to get the “proper” name of the package. I used vim as the example there, and I will
here. Instead of having to type out “portupgrade vim-6.0.85”, you can just type “portupgrade vim”. This way is much easier, and much simpler. Please note that in order for either of these methods to work, your package database has to be free of all stale dependencies. If it isn’t you will just get an error from portupgrade telling you to run “pkgdb -F” manually.
2)Worthy of mention is “portupgrade -ar”. Until this afternoon I didn’t know this even existed! What the -ar does is tell portupgrade to upgrade all installed packages recursively. Which in a nutshell means, upgrade all of my
installed apps, and anything that they depend on fuction. As always, you should cvsup your port’s tree to get the latest version before running portupgrade.
On a server it might not be a good idea to blindly upgrade you apps, but the -ar flags save a lot of time on computers that are used as desktops, or anywhere else that you want the absolute latest version of everything.
3)In the above article I stated that “You should track the -STABLE tree for your production servers, as the -STABLE tree is updated with bug fixes and security patches.” THIS IS WRONG! The -STABLE tree is a development stage just like
-CURRENT. Code that has been tested in -CURRENT is patched and then put into -STABLE for more testing. Think of -CURRENT as alpha quality code, and -STABLE as beta quality. For production servers, the FreeBSD handbook recommends that you use the -RELEASE snapshots. The -RELEASE snapshots are recommended for production servers that must be as stable as possible. When the next -RELEASE
version comes out, you can then edit your cvsup tags to obtain the -RELEASE source code and follow the routine for upgrading via source.
I should note however that both my desktop and server have been running the -STABLE tree for several months. Neither of them have ever had any problems from the effects of running -STABLE. However for critical servers that can’t go
down, run -RELEASE.
4)According to the Handbook, the proper way of building a new kernel is as follows:
cd /usr/src
make buildkernel KERNELCONF=*MYKERNEL*
make installkernel KERNELCONF=*MYKERNEL*
where *MYKERNEL* is whatever you named your edited copy of GENERIC.
This is for installing a new kernel along with a new “system”. As in you should only follow these steps if you have cvsup’d(or updated your source some other way) and have completed the buildworld process. If you are simply compiling a new kernel to add a feature, use the “old” method of config, make, make install. That method is used only when you have *NOT* cvsup’d your source. It would
appear that the old way of doing it still works regardless of whether or not you’ve cvsup’d because that is the way I have done it for almost a year. But the documentation recommends that we use the new way, so we will. Here is a link to the handbook, scroll down towards the bottom
for more info on compiling the kernel.
I would like to thank the reader(s) that emailed me concerning the errors in my article. I’d also like to apologize to the readers, I try to not make mistakes like this, but I’m only human so sometimes they slip though.
Links of Interest
FreeBSD Handbook
A
comparison of -STABLE and -CURRENT
Freshport.org
FreeBSD list of ports
FreeBSD Diary
If you have suggestions and ideas for future FreeBSD-related articles that you would like to see on OSNews, please let me know by emailing me directly.
About the Author:
Nathan Mace is currently a senior enrolled at the University of Charleston, West Virginia, majoring in Computer Information Systems. He is interested in all types of operating systems, expecially Unix-type OSes such as Linux, *BSD’s, and commercial Unices. Nathan can be reached at [email protected]
Really usefull information and well worth a read.
Sim
Oh I forgot Eugenia, the link to freeBSD dosn’t work
Sim
Nice article :0)
I was just configuring a new FreeBSD 4.5 system last night along with an OpenBSD 3.0 system and was running into this issue.
FreeBSD 4.5 and OpenBSD 3.0 were released before the OpenSSH / zlib bugs were found so those two things need to be patched before the systems could be considered safe to connect to the Internet. In OpenBSD this involved cvsing the latest patch cluster for the system and rebuilding the affected binaries. It wasn’t this easy on FreeBSD. I had to look up the individual advisories and download each patch from different paths on the server because I couldn’t find anything on their site as to how to do it any other way.
This is one of the places where OpenBSD’s strict adherance to procedure and documentation made updating the OS much easier then it was under FreeBSD.
Easy way to fix freeBSD’s system is to sync with the cvsup servers (ports tree for OpenSSH and the source tree for the rare occassion a system lib has an error) then make/make install. It’s not overtly complicated.
Is it just me or dosn’t this seem like a hell of a lot of work just to keep your system up to date? Don’t get me wrong, their are certain things I absolutely love about FreeBSD, but I think that overall this is its biggest downfall. I’ve used FreeBSD in the past and this was the part that made me change to Linux. Keeping FreeBSD updated is a lot of work. Most Linux/Binary distributions make this easier with a simple package updater. If FreeBSD came up with an easier way to keep it updated I would definetly switch full time. I heard they’re going to update sysinstall for this very reason but I’m not 100% sure about that.
how can you say that keeping freebsd updated is hard & complicated? all you have to do to keep the system up to date is cvsup the source, compile it, and install it. with the apps it’s even easier. just cvsup the ports tree, and run portupgrade on the app that you want updated
I don’t believe I said complicated or hard. I did mean it’s a lot of work (time consuming).
When compared to:
“apt-get –dist-upgrade” <- that’s it now you’re updated
from `man sysinstall`
This utility is a prototype which lasted several years past its expiration date and is greatly in need of death.
and
This version of sysinstall first appeared in FreeBSD 2.0.
The FreeBSD people are aware of these sort of user issues. Don’t get me wrong, I’d prefer that they spend their time making the network stack faster then making the install easier, but I think people are justified in saying that the install and update procedures are too difficult in FreeBSD.
Gentoo’s ports-based packaging system is rediculously easy. To install the latest kde, for instance, and all dependencies in one single command, type “emerge kde”. That’s it.
But that’s not it. I did a few ports for gentoo back around rc 4/5; and it’s not that easy. Portage failed often, and required major structural redesign. And version conflicts are abound. Daniel while charasmatic and a good writer doens’t seem to have a clear plan of what needs to be in Portage.
Anthony: I don’t see how
“cvsup [cvsupfile] && cd [dir] && make install”
is difficult. The ports system is updated regularly,
I tried Debian, and I don’t really see why everyone likes it so very much. The installer managed to mess up my network card. I couldn’t use dselect [it’s just irritating].
The only linux distribution I particularly liked was Slackware, but it really needed something like ports.
The article is a nice overview, but is rather thin on explanation of the FreeBSD init system. He dismisses the core init stuff as “several rc.*” files. These are critical files, and should be learned by any serious FreeBSD admin. The main configuration for standard system startup is controlled through a file called /etc/rc.conf, which doesn’t actually have the startup scripts, but contains user overrides FROM the default startup inside /etc/defaults/rc.conf. This is a very smart concept, which shields the user from complexity, and shields the system from having a broken startup file. Any changes you make to startup options in /stand/sysinstall will appear in /etc/rc.conf, also. It also contains settings for your NIC cards.
And I know that /usr/local/etc/rc.d is the traditional custom startup script area, for non-core stuff, but FreeBSD also provides for a nice generic startup script called /etc/rc.local. If it is not there, just create it, and any commands you put in there will be run as the system boots.
/etc/rc.local is deprecated. Don’t use it.
First off, /stand/sysinstall works, although it’s not pretty. I don’t care for a flashy graphical install tool, and you /can/ use the cursor keys to select stuff, so it could be worse 🙂
The way a system upgrade is explained is horribly complicated.
this works for me (and is how the handbook tells you to do it too):
cvsup -g L2 stable-supfile
cd /usr/src && make -j4 buildworld && make installworld
make buildkernel KERNCONF=<KERNALNAME>
shutdown now
cd /usr/src
make installkernel KERNCONF=<KERNELNAME>
mergemaster
reboot
As for checking ports:
portversion -l'<‘
(add a -v if you want the version numbers)
and then portupgrade -r <basename> will suffice
(so just ‘portupgrade vim’ for vim.)
After the struggle I had with RPM based Linux distros, this is heaven.
This is certainly something that needed an article written about. Newbies very often show up after installing their new systems and wonder what to do next, and especially how to upgrade. Nice work.
However, slightly wrong information just adds to the general level of confusion and sometimes gets people in trouble, then they decide they hate FreeBSD because something didn’t work for them.
The recommended way to build a new world and kernel is this:
To update from 4.0-RELEASE or later to the most current
4.x-STABLE
———-
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
make installkernel KERNCONF=YOUR_KERNEL_HERE
reboot (in single user)
make installworld
mergemaster
reboot
(Taken straight from /usr/src/UPDATING, which is required reading for upgraders.) Doing as you wrote will work most of the time but this way is supposed to work *all* of the time (and if you do it some other way and have trouble, people will just tell you to do it again this way).
The easiest and most effective way to upgrade ports is this:
cvsup [supfile]
portsdb -Uu
portupgrade -a
portsdb in this usage updates the ports INDEX file so that you don’t have to wait for a new one to have portupgrade see that there are new ports. (It also takes a while; 10 min on a K7-1.33G and 1 hr on a P-166. Not to mention that you can’t cut some of the ports out easily if you do this because make_index will complain about it.)
The -a flag to portupgrade means “all”, it will just upgrade everything that needs it, keeping dependencies straight and doing no more than necessary. (Great utility, absolutely. Many thanks to Akinori MUSHA-san, the author of the portupgrade suite.)
It may also be useful to use the -s flag to cvsup (for both ports and sources), depending on whether you like to muck around with the files you download. See cvsup’s man page for details.
Aren’t you missing the part were you have to copy the Generic kernel, edit it again, and then compile it. This is the part that really annoyed me. You can’t just keep a copy of your modified kernel and keep recompiling form that one because the kernel may have changed. So you have to copy the Generic, and re-edit everytime you want to update. That was a real pain and time consuming. Again, I never said it was difficult, it definetly is not dificult, just time consuming.
For example, you can’t really do an update every night, thats just crazy. What about if you needed to update, 10, 20, 50 servers, again, crazy. You could join the announce mailing list and only do the updates needed for security concerns and then do a make world (to keep you’re system updated) once a week. But I found that everytime I needed to do a security update I felt I might as well just do a make world while I’m at it. Again, this is extremely time consuming.
I love FreeBSD, I have a server at home that used to run FreeBSD but now is running Linux. I would switch back in a second if they could come up with a better way to keep the system updated. With my linux box; I’m subscribed to the mailing list, when an announce comes in about a bug or a security risk, I just have to update that one binary package (and possibley its dependencies but that is take care of by the package updater) and I’m done. I don’t even need to be on the mailing list, I could just have the package updater run every night to check, if there is something that needs to be updated, and have it email me to let me know. I could also have it update automatically at night without my intervention (though I would not recommend this).
I’m saying all this from personel experience. I’ve used them both and without a dought FreeBSD is my favorite overall. But I felt I had to switch because of the hassle I was going throught all the time just to keep my system updated. Once more, not dificult, just time consuming.
i don’t know about anyone else, but as far as the kernel config file goes, i made a copy of GENERIC, edit it to suit my needs, and then when i cvsup the source i use my edited conf file to make the new kernel. i’ve been using freebsd for almost a year, and i’ve been using the same kernel file the whole time. i upgrade to the latest stable about once a month. it’s not required that you re-edit the generic file everytime you want to upgrade
yes, i’ll agree that “make buildworld” takes awhile, expecially on slow machines, so why not build it once on a fast machine and share it out via NFS to the slow machines??
I know that the manual says that you should “shutdown now” before installing world and kernel, but I just want to tell all the BSD newbies that this is completely unnecessary. I *never* reboot into single-user mode to installworld or installkernel with any of my production machines. I just:
make -j4 buildworld && make buildkernel KERNCONF=MYKERNEL && make installworld && make installkernel KERNCONF=MYKERNEL && cp -Rp /etc /etc.old
(-j4 means run 4 threads instead of one. some of my boxes are quad xeons… also, always backup /etc!)
then I come in later, do mergemaster, and then:
at 0400
shutdown -r now
^D
… and I never worry about coming in in the morning to find that the machine can’t boot. unlike what happens with linux 75% of the time.
I keep a file “/usr/src/sys/i386/conf/include” that has all my necessary kernel options. then I:
cp GENERIC MYKERNEL
cat include >> MYKERNEL
… I hated doing it the “hard” way too.. =)
Thanks for the feedback on my comments. I may give FreeBSD another shot.
After reading the article and the comments, I felt I had to make a comment too.
First thing is about the way to do an upgrade. While doing just a ‘make world kernel KERNCONF=[whatever]’ does work, it can be dangerous, especially when we’re talking about major version upgrades (i.e., 3.x -> 4.x, 4.x -> 5.x). The described procedure in /usr/src/UPDATING is the recommended way for several reasons, the biggest being binary incompability. I ran into this when I was still a n00b and upgrading from 3.x to 4.x, and I built and installed world before even thinking of the kernel. Oops. It seemed that the 3.x kernel was unable to run 4.x binaries, which I found out the hard way when the installworld crashed half-way, having replaced almost all the critical binaries with 4.x binaries. As said, I still had the old 3.x kernel, and any new binary that I tried to run, crashed with a SIGSEG (#11). After beating the machine around for some hours, I gave up and started to think about what had happened. When I realized that I needed a reinstall to fix the broken machine, I got quite mad, as this was the only computer I had working at the time, and I was sitting on ISDN. Yuck. After downloading the new -RELEASE ISO, I got on and reinstalled, which fixed it.
Consider this as a warning. The safest way IS with an installkernel and consequent reboot to single mode before installworld. I also know some other people who have had the same, not all too great, experience.
The other thing I see mentioned is that you have to re-edit the kernel configuration file each time you cvsup, which is as someone anonymous pointed out, not necessary. You can keep your old kernel configuration file for quite long, although I would recommend checking it every now and then, especially when there are major or minor version upgrades in the progress. A simple way would be to make two copies of the GENERIX file, one which you rename to whatever is you preferrence, the other something like GENERIC.old (or whatever). By doing this, you can use the second, non-modified version of the GENERIC file (GENERIC.old) to diff against the possibly updated official GENERIC file to see what differences there are.
Third and last point is that building world and the respective kernels for the other machines on one fast machine and sharing it through NFS is quite a time-saver, since a dual 1.2GHz Athlon MP will use about 50 minutes on one buildworld and one buildkernel, while a 486 will take a full 24 hours or so. There are some pitfalls here too, the biggest I’ve encountered is firewalls. If you have a firewall (say ipfw) on the clients that’re installing from the NFS server, with a default-to-deny stance in the kernel, you can run into some problems with /sbin/ipfw and the kernel (the new one you just installed) being out-of-sync, which will cause /sbin/ipfw to seg.fault when you’re trying to run it. And with a default-to-deny stance, you’re pretty much scr****. This is a bit contradictory to what I previously said, but first doing an installkernel, and before the reboot, then do the installworld will go around the particaular problem described above.
One last thing I could mention is that in the default make.conf (/etc/defaults/make.conf) there are some entries starting with SUP_. If you copy these and modify them for your needs, all you need to do when cvsup’ing is ‘cd /usr/src && make update’, which will update the source tree, the ports tree and the docs tree, in addition to running cvsup on the other optional sup-files. This makes being even more lazy simpler.
Anyway, this comment is getting quite long, so I think I’ll call it a day here. I hope someone find my comment useful.
and after that my customized kernel. Looking through the new GENERIC is always recommended and compiling one is too, just in case your cust kernel doesnt boot or something. If dealing with a remote box, well I think you can stick it into one of the boot config files as well as a copy of your former kernel. Than you might quite safely reboot.
Note that this is about reboot after installworld and mergemaster (upgrade ports after reboot). Can’t reboot single user mode and then ssh into the remote box so no try-outs of new kernels in that case. Finish and reboot.
Besides, you should note that you can do binary upgrades from relase to release and then track the RELENG_4_5 branch (and later 4_6, 4_7, etc) to only get bigfixes and security patches, instead of RELENG_4 (= fBSD-STABLE).
If a fix is needed you either apply patch, or cvsup and then either only compile and install that certain part (if it’s easily found) or buils/install world. No fiddling with kernels needed then (unless of course there’s a kernel fix).
You dont need to use CVSup to keek your programs update.
Alot of hardcore linux/anti FreeBSD users seem to say source building is dumb. Even if you choose to think that, with FreeBSD you can use pkg_add -r command to install binary installs of programs AND ALL ITS DEPENDENCES AUTOMATICALLY.
All you do is find your local FreeBSD mirror.
then add the PACKAGESITE enviroment for your csh or bash shell.So I put
setenv PACKAGESITE ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st…
In my /root/.cshrc
You can see it with the “env” command
%env
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/loc al/bin:/usr/X11R6/bin:/root/bin
blah,blah
PACKAGESITE=ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st…
Now if I wanted to install VIM and all its deps of the very latest version of VIM I just do
pkg_add -r vim
and it fetchs it and installs all the deps automatically
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st…… Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st…… Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st…… Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st…… Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st…… Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st…… Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st…… Done.
If I didn’t want the latest builds I would set the environment to
ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4.5-…
You’ve forgotten that many ports are not converted to a package binary. Also what you just explained is how to install new packages not how to keep your entire system updated. One more thing you missed is that even if this worked it would only update the port/packages not the FreeBSD source (e.g. /usr, /etc, kernel, etc) the only way to do this is to cvsup the source and then do a make world. In comparison to what you’ve just explained I would rather go with a cvsup ports and then use portsupgrade, that is the easiest way to go but that was not the issue.