Experiences with FreeBSD 9.0-BETA2

[Brett Glass]

All:

Just spent an afternoon and evening experimenting with FreeBSD 
9.0-BETA2. Overall reaction: so far, it's been pretty stable and 
responsive, but I'm concerned that it may have substantially 
increased memory and CPU requirements relative to previous 
versions. The new installer, while it's streamlined, still has many 
of the quirks of sysinstall (in particular, requiring the user to 
know when to hit "Tab" and when to hit "Enter") and is missing a 
few features upon which I've come to rely.

Here's a description of my experience in more detail.

First thing I noticed, when running the new FreeBSD installer from 
a memory stick image, is that disk partitioning was odd. It 
abandoned standard UNIX parlance, calling what are traditionally 
called "slices" partitions. It also diverged from past practice by 
creating one big UFS filesystem rather than the usual separate 
partitions for /, /tmp, /var, /usr. It then made a separate slice 
(to use the traditional terminology) for swap, rather than 
including it in the slice that contained the big file system. This 
seemed odd; if the file system was being lumped together in one 
place, why break out the swap to an entirely separate slice?

I was experimenting on a system which had an SSD (and therefore 
shouldn't swap), so I altered the automatic configuration by 
deleting all of the slices except the MBR and then trying to 
allocate a slice that just used all of the remaining disk space for 
the file system. When I did, the installer tried to automatically 
create a SECOND MBR slice at the same time it tried to create the 
file system slice (probably a bug). Finally persuaded it not to do 
this. However, I did experience some awkwardness when when I 
pressed "C" for "Create" and the installer did not offer me the 
maximum possible size as a default, as sysinstall did. Exactly how 
big could the file system slice be? There was no way of telling. I 
worked around this by specifying a size which I knew was too big; 
the installer seemed to trim it back to the maximum size it could be.

As I proceeded with the installation, I noticed that the new 
installer didn't run a concurrent shell, or provide a virtual 
terminal that showed progress, as sysinstall did. True, these 
things are probably only for experts, but I missed not having them. 
(Is there a way to turn them back on?) Also found no way to 
intervene in the install immediately after the distributions were 
loaded... a time at which I often do customizations such as 
modifying the files in /usr/share/skel to change the default 
editor. (My fingers have used EMACS ever since the original TECO 
version, so much so that the keystrokes are wired into muscle 
memory. So, I bring in jove as a binary package right away and make 
it the default system editor. Couldn't do that from the concurrent 
shell, before root's account was created, as I usually do.)

Also could not find any way to load binary packages from the 
installer after the install. This is a shame, because ports with 
lots of dependencies can take hours and lots of disk space to 
build; binary packages save me a LOT of time and are necessary for 
systems with limited RAM and disk space.

Next thing I did was try to recompile the kernel to streamline it 
and add features I want compiled in, such as ipfw and dummynet. 
Alas, I saw no sign of the BSD-licensed Clang compiler, for which 
I've waited for many years (I can't believe that now, in 2011, one 
cannot build FreeBSD without GPLed code.) I used a kernel 
configuration from a recent 8-STABLE machine, which was accepted 
with no errors, and then tried to reboot.

I got hung up at the "mountroot" prompt. The system couldn't find 
the root partition specified in /etc/fstab. However, if I manually 
loaded the GENERIC kernel, the system DID boot.

I soon discovered why. An innocuous message that I didn't notice at 
the beginning of installation proclaimed that the GENERIC kernel 
was renaming the SATA SSD, which started out as ad0, to ada0. I 
modified /etc/fstab to use ad0p2 as the root filesystem slice, and 
the system booted the new kernel.

I then explored what had happened in more depth. The problem seemed 
to be that my kernel configuration completely eliminated SCSI. (I 
had no SCSI devices in the system and didn't need or want the bloat 
that came with it.) But when I booted the GENERIC kernel, the SCSI 
subsystem took control of ATA devices, renaming them in the 
process. This is a big violation of POLA; the change and the 
failure to boot were a big surprise.

My SCSI-less kernel worked by sheer good fortune after I changed 
/etc/fstab, because the older ATA drivers, including the atadisk 
driver (which was in my kernel configuration), are still in the 
source tree. (Their man pages seem to have been deleted, though, 
which is not good. Even if they are less used, they should remain 
documented because embedded systems developers will want to be able 
to use them.)

The GENERIC kernel, instead of just using a direct ATA driver, was 
assembling a complex, memory-intensive, and compute-intensive layer 
cake of shims -- including the ata, ahci, da, and scbus drivers, 
not to mention GEOM -- to get to the SATA disk. Since the system I 
was trying to build has only one mass storage device -- a simple 
SSD -- and is tight on RAM, I'd rather go without bloating the 
kernel, slowing the system, or exposing myself to SCSI bugs by 
simply using an ATA driver. With all due respect for the hard work 
of the people who went to the trouble to create all of those shims, 
I hope that it remains possible to do this.

Other oddities:

1) The jove editor worked strangely because, in /etc/ttys, the 
terminal type was set to "xterm" instead of "cons25" by default. (I 
do not run a GUI on servers, so of course there will not be an 
xterm.) As a result, parts of lines kept vanishing from under my 
cursor. However, even after I modified /etc/ttys, I still saw some 
screen artifacts. The maintainer of the console driver should 
probably check it to see whether its termcap entry needs changing.

2) I saw many warnings of lock order reversals under the GENERIC 
kernel, in particular in the file system code. These obviously 
should be fixed before release.

3) The installer offered to enable the TRIM command for the SSD, 
but the SSD I was using did not support it; I got a warning when I 
tried to use tunefs to turn it on.

4) The installer still used the old syntax for Internet addresses 
in /etc/rc.conf instead of the newer one (e.g. ifconfig_fxp0="inet 
192.168.1.1 netmask 255.255.255.0" instead of ipv4_addrs_fxp0="192.168.1.1/24")

For the most part, though, I was able to work around everything and 
produce a system that seems stable. Will be stress-testing it for 
the next several days to see how it holds up.

--Brett Glass