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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
