Install tip: disklabel partitions

I've got a quick tip regarding how you partition your FreeBSD slice when you are installing. I'm not going to address the D0S partitions (or disk slices as they're usually called in FreeBSD), but the FreeBSD partitions that will be put within the slice (or slices) that you install FreeBSD into. This is covered in the Handbook in the section "2.6.5 Creating Partitions Using Disklabel" found here (as of this writing).

What I suggest is that you alter the default/auto partition recommendations of sysinstall by, at least, eliminating the "/tmp" partition, doubling (at least) the "/var" partition, and then sym-linking "/tmp" to "/var/tmp".

To do this is easy enough. During the install, when I get to the label editor screen I first press the 'A' to see the auto-defaults. Make a quick note of the order and sizes if you need it (I do) and then arrow down and delete all of the proposed partitions. (Remember they haven't actually been created yet.) Then re-add them in the same order, entering your new sizes (and skipping "/tmp"). I usually make "/" a little bigger, too. I would add "/" at 256M, swap at 1xRAM (assuming you've got plenty of RAM, 2xRAM otherwise), "/var" at 1G (for a workstation, more for a server), and the rest to "/usr". Then (important!), remember to create the sym-link as soon as you've rebooted. As root, these commands should do it:

cd /
mv tmp/.* var/tmp/
mv tmp/* var/tmp/
rmdir tmp
ln -s /var/tmp

That's it. You're done!

I first got the idea to modify the default partitions from Greg Lehey's book, "The Complete FreeBSD." (A good book and freely available on-line now. See here.) The crucial point he made is that having many partitions was largely a defense against unreliable filesystems. But, filesystems have gotten much better in recent years. Given that, you shouldn't break up your disk into so many pieces without good reasons -- it creates unnecessary bottlenecks ("warning: filesystem full"). His specific recommendation was pretty radical, though: a single, large "/" partition of 4-6 GB, and the remainder of the space in a "/home" partition. (He was assuming a 20GB disk in his example.) I see the advantages of this, especially if you do a lot of work in your home directory that will use space. But, this recommendation has not stood the test of time, as my "/usr" partition is very often much larger than 6GB (to say nothing of when I must extract and compile a large port). Granted, disks (and software) are much larger than when Greg first wrote that, but it still fails to allow for the considerable wildcard of how much third-party software you may eventually end up installing. Also, if you let "/usr" and "/var" ride on "/" you've lost the advantages of the soft-updates for that IO ... or you've enabled soft-updates on your "/" partition and I don't like either of those options.

This article has become longer than I expected. I will follow-up on it soon with my thoughts on why and when you should throw in an extra partition.

portupgrade problems: "already installed"

munk over at freebsd.munk.me.uk writes this in his recent post "Portupgrade fails to upgrade dependencies":

An example is when I just went to run the weekly 'portupgrade -arR' and whilst upgrading p5-PathTools-3.21, portupgrade found that another port - p5-Scalar-List-Utils-1.18 - also needed upgrading. Unfortunately the upgrade of that port failed with the following error:

===>  Checking if lang/p5-Scalar-List-Utils already installed
===>   p5-Scalar-List-Utils-1.18,1 is already installed
     You may wish to ``make deinstall'' and install this port again
     by ``make reinstall'' to upgrade it properly.
     If you really wish to overwrite the old port of lang/p5-Scalar-List-Utils
     without deleting it first, set the variable "FORCE_PKG_REGISTER"
     in your environment or the "make install" command line.
*** Error code 1

Stop in /home/munk/ports/lang/p5-Scalar-List-Utils.
*** Error code 1

Stop in /home/munk/ports/devel/p5-PathTools.

This is not how portupgrade usually works, but I've definitely seen this sort of thing before. Normally, it can find the dependencies and upgrade them in order (even if you only use the '-a' option alone). Though, order isn't even critical, since it builds first (without dependencies), then uninstalls the old one, and then jerry-rigs the dependencies as necessary when installing.

Tracing the errors, it appears that the first error is coming from ports system itself ("p5-Scalar-List-Utils-1.18,1 is already installed You may wish to ...."), not portupgrade, and that the p5-PathTools build/make called the p5-Scalar-List-Utils make/install (via the ports system, not portupgrade) . So, portupgrade's dependency ordering (and/or dependency rigging) has gone wrong somewhere.

When I get similar errors, I usually go back and attempt to portupgrade the problem port by itself (with whatever massaging might be necessary). To be clear, the "problem port" is the one appearing first in the traceback (in this case p5-Scalar-List-Utils-1.18,1). Then I proceed with another 'portupgrade -a' to finish up. This method has been reliable.

I recommend that when you see an error like the above, that you first attempt to tackle the problem port or ports one by one with a solo portupgrade. In fact, this should be how you handle a number of ports system errors that show through in a portupgrade run. The "FORCE_PKG_REGISTER" solution mentioned in the error output above is the ports system's no-frills, damn-the-torpedoes solution and might cause problems in the future as it has the potential to leave old files behind. (Okay, a little cruft never hurt anybody, but we still don't like it.)

Hardly relevant footnotes

But, I keep thinking back to those options: '-arR'. This is pure speculation, but could there be a conflict between them? The 'r' and 'R' options should be completely unnecessary when you have the 'a' option. ... Well, there's no need to guess -- I checked the portupgrade script (portupgrade-2.1.3.3_1,2 on my system) and they've already handled that: both recursion options are set false when 'all' is set and neither recursion option will be set if 'all' is already set.

Here's something to watch in the future: do these errors occur more with build dependencies or run dependencies? (This one was a run dependency.)