Posted: 08/11/2009 Ron Scheckelhoff
The Perpetual Upgrade Machine

Well, I finally broke down and committed myself. (No, not to the luny bin, but to the upgrade of my FreeBSD 7.1 installation) The luny bin is what happens afterwards.

The user of every operating system goes through the dreaded upgrade cycle, and it occasionally has it's benefits. Some new feature or performance accelerator will be seen as the motivator, and becomes the reason that normally sensible people will put themselves through the rigours of the process.

Version 7.2 sports the hal daemon, a little program that asynchronously and automatically picks up on things that heretofore had to be manually enabled. Great idea, except that (at least on my machine), it clobbered the Xorg/Gnome GUI performance to the point that it became an irritation to use the system.

The keyboard occasionally stuttered like a drunken sailor, and the mouse crossed the screen in great leaps, awkwardly and jerkily, stopping after each leap to catch a breath. My first response was to disable the hald daemon, which I did only to discover that the new setup for FreeBSD demands that the daemon be running in order for Gnome to operate properly. I did a quick search of the internet to determine if the hal daemon could be extracted easily, and was informed that I would be more likely to golf a low score with a blindfold.

I really don't know if the aforementioned golf analogy is par or not, and anybody has permission to set me straight on this.

Editor's note: All of the issues of the previous three paragraphs were eliminated simply by adding another 512MB chunk of memory.

Note: Depending upon how you choose to install your Xorg and Gnome environments, you may need to add the following requisite entries in your /etc/rc.conf file:


enable_hald="YES"
enable_dbus="YES"

None of this really bothers me, because I know that ultimately the "enhancements" such as hal will bring this operating system closer to the point of playing an equal hand against it's Linux counterparts (in the GUI realm), and that is a good thing. I consider FreeBSD to already have the upper hand in the server realm. So, the first edition of FreeBSD with hald gets a passing grade from me. It just needs a little improvement, which I am sure will be forthcoming in Version 8 .

With each passing increment of the Xorg system assemblage, there is a greater and greater emphasis on the "Look ma, no hands" completely automagic kind of operation. The Xorg libraries shipped with FreeBSD 7.2 do this admirably in conjunction with my Intel 82845G/GL Brookdale-G/GE chipset Integrated Graphics Device hardware when I completely remove the usual /etc/X11/xorg.conf file from the system.

This, being day one of the upgrade process, will not see all of my favorite programs installed on version 7.2. I had collected quite a few "goodies" that over time had become indispensable parts of my FreeBSD 7.1 system environment.

One of the things that had caught my eye recently was the FreeBSD version of Sun's VirtualBox environment, and I noticed that the most viable work being done on that project was targeted specifically to the 7.2 version of the OS. Previously I had successfully used VirtualBox on the Debian operating system, and liked it. Just as we speak, I have executed the make command in the directory containing the new FreeBSD 7.2 port for VirtualBox. More on that (and whether it works) later.

For some reason unknown, the sound volume control (that has always been automagically installed by "BSD < 7.2"), was dropped from the standard installation image for FreeBSD 7.2, and I had to manually install that.

The kernel module loaded with "kldload snd_driver" still loads (among others) a driver that works with my <Intel ICH4 (828001DB)> sound card, as reported by "/dev/sndstat", and so sound works like a charm.

My trusty FreeBSD 7.1 installation runs Flash with flair, thanks to the improved "Fedora Core 8" compatibility level supplied with it. The same combination (flashplugin9 w/fc-8) failed to work within Firefox on version 7.2. It's not a Flash issue, per se, because the Flashplayer applet still runs just fine on FreeBSD 7.2. More on any attempts to resolve this will follow ....

X seems to take about three times as long (compared to FBSD 7.1) to launch into the Gnome Desktop, but I am not sure what portion of the blame should be apportioned to Xorg, what portion to Hal, and what portion to Gnome. It is not terribly objectionable, mind you. It's just that with the extra wait-time, I can no longer brag to my wife (while she uses Windows on the other side of the room) that she uses a sllooowww operating system.

Another thing about the latest (7.2) version has had an impact on yours truly. Some of the older drivers have been dropped from the GENERIC kernel. Since I work with old hardware as a matter of common practice, I was affected in that one of my computers no longer is able to access a cdrom drive stamped with vintage: ancient. How ancient? My mail server is a 1993 model (66 Mhz, 32MB RAM, FreeBSD 7.0) which of course runs the Four Calorie Mail daemon. To upgrade that machine will require a kernel upgrade, but I've decided to wait a bit anyways, so it's not a pressing matter. Our company used to sell those 1993 66Mhz gems (in 1993). Damned if we didn't build them well! As the old adage goes ... don't fix/replace it if it ain't broken and is still capable!

Having pulled the bits and pieces together well enough to say "Yes, I think that the version 7.2 upgrade is worth the time and effort required", I then asked myself "what exactly am I going to do with it?"


As I mentioned at the beginning of this article, I did have a purpose in mind for this particular upgrade. Recently having tried the Sun Microsystems VirtualBox environment on Debian Etch, I had become enthused about it, and wanted to give it a try, but while using the FreeBSD operating system (as the "host" system) instead of Linux Debian Etch.


Etch is just fine, mind you, and it's the only *nix OS that the rest of my immediate family will tolerate. With VirtualBox, I reasoned, I could keep my favorite OS as the host, and the rest of the fam could have their beloved Etch. Additionally, the switching back and forth between various virtualized clients and the host could be done without ever rebooting the system - all the better.

The graphic (above) shows my FreebSD 7.2 OS and Desktop with VirtualBox and one instance each of a Debian Etch and Haiku operating system running on top of it.

The installation of the VirtualBox environment on FreeBSD 7.2 went very smoothly, with the only caveat being that some patience for long compiler operations might be a a good thing to have as a prerequisite.

First, I pulled the make-files down from Freshports, using the revision shown:

# New ports collection makefile for:	virtualbox
# Date created:		2009-05-02
# Whom:			Bernhard Froehlich 
#
# $FreeBSD: ports/emulators/virtualbox/Makefile,v 1.4 2009/06/17 20:52:53 beat Exp $
#

PORTNAME=	virtualbox
DISTVERSION=	2.2.51.r20457
PORTREVISION=	3
    

I noticed that the revision, only a few days later, had moved to 3.0, indicating (perhaps) a rapidly changing codebase. I extracted the port tarball, and started the build process. Approximately eighteen hours later, my 1.8 GHz Dell computer completed the job.

A couple setup considerations are well documented in various places, and here I repeat them:


1 - Load the kernel module for the system with: kldload vboxdrv, and put the vboxdrv_load="YES" config line into /boot/loader.conf to make it persistent across reboots.

2 - Mount the procfs with: mount -t procfs proc /proc, and put the proc /proc procfs rw 0 0 line into the /etc/fstab file in order to make it persist across reboots.

3 - Add a regular user to the VirtualBox group with: pw groupmod vboxusers -m ron (in my case)

Start Up with a Haiku client

After the gruelling eighteen hour build, subsequent installation of the binaries, and the kernel module and procfs startup, I clicked on the newly added VirtualBox graphical user interface menu item, and the GUI immediately appeared, ready to accept the instructions for the creation of a new virtual machine. I had a Haiku OS image lying around (really, who doesn't?), and after I created a virtual machine, my intention was to attach the Haiku hard drive image to the machine. The first attempt failed to attach, providing a message that indicated the Haiku image was not in the "vdi" format, as required by VirtualBox.

The simple fix for that conundrum was to use the VBoxManage tool to convert the Haiku hard drive image to the vdi format, thusly:

VBoxManage convertdd my-haiku-image haiku-image-developer.vdi

Magically, the image was converted to the "vdi" format, and it was simple matter to use the VirtualBox graphical user interface to attach the new haiku-image-developer.vdi image to the newly created virtual machine. Anyone wishing to duplicate this fearsome feat may find a nice selection of Haiku-OS snapshot images at http://www.haiku-os.org (Not affiliated with this author)

Note that the default location for the vdi image files is in ~/.VirtualBox/HardDisks/


The Haiku OS immediately booted when I started the virtual machine that I had set up for it, and immediately I was able to connect to the Internet using the web browser from within Haiku. This was surprising, as I had heard that networking in the FreeBSD hosted version of VirtualBox was in a state of flux. Well, it (sort of) is ... more on that later.

What had happened is that I had made some initial setup configuration settings while creating the virtual machine, wherein I selected the "NAT" option for the network. When the NAT option is selected, VirtualBox sets up a logical "internal" NAT/DHCP environment and within it the 10.0.2.x subnet is used for the VirtualBox clients. Note that my FreeBSD 7.2 (real) machine that is the host for VirtualBox is on subnet 10.0.1.x (not really relevant), and is behind another NAT router that is connected to my ISP connection (66.233.x.x).


Since Haiku defaults to DHCP if you don't play with the network config, a connection was automatically configured for me via the VirtualBox DHCP, creating entries of 10.0.2.2 for the gateway, 10.0.2.3 for DNS, and 10.0.2.15 for the client (Haiku) address. This information about the "logical NAT/DHCP" functionality supplied by VirtualBox was provided via the link to Micheal Powell's nabble mail message:

http://www.nabble.com/virtualbox-networking-s etup-td20467278.html

Trying a Solaris Client

While the previous section explained how a disk image can be attached to a virtual machine, the following explanation details the use of standard installation media (CD/DVD), but with a twist ...

A nice feature associated with the VirtualBox environment gives the administrator the ability to attach multiple ISO-9660 image files as logical cdrom drives. I found this feature to be useful when I wanted to install Solaris 10 into a virtual machine, but the Solaris installer was not happy with my physical CDROM drive.

While I found that Solaris 10 could be installed in this manner, I made the determination that the multiple layering of emulations eventually takes a noticable toll, resulting in a rather slow installation speed when using ZFS without a surplus of memory.

After waiting for three hours for the installer to drudge through disk #1, I aborted the installation and restarted it with the UFS file system selected. After the restart, the installation proceded at a rate comparable with other types of operating systems (Linux, etc).

In order to mount the "logical" CDROMs, I first created files from the original Solaris installation CD set:

dd if=/dev/acd0 of=.VirtualBox/HardDrives/solinst1.iso bs=2048
dd if=/dev/acd0 of=.VirtualBox/HardDrives/solinst2.iso bs=2048
dd if=/dev/acd0 of=.VirtualBox/HardDrives/solinst3.iso bs=2048
dd if=/dev/acd0 of=.VirtualBox/HardDrives/solinst4.iso bs=2048
dd if=/dev/acd0 of=.VirtualBox/HardDrives/solinst5.iso bs=2048



After the files had been created, I used the VirtualBox Management GUI to set the virtual CD/DVD mount options for the virtual machine that I created for Solaris, mounting the "solinst1.iso based" disk first.

When I restarted the virtual machine, it booted from .VirtualBox/HardDrives/solinst1.iso, and I plodded through the standard installation process. One thing to note about the installation is that towards the end of CD#1, a message will appear in the console proclaiming that "The Installation of CD1 is complete!". When that message is displayed, many people may think that it is time to reboot the system, because there are no other messages for quite a while afterwards. Resist the urge to do that! More installation processing follows in about five minutes. After I finally did see a shell prompt, I clicked on the menu and shut-down the virtual machine. Then I used the VirtualBox Management GUI to select disk #2, and restarted the virtual machine.

The virtual machine booted from the virtual machine's hard-drive-based virtual hard disk, and began to copy the packages from the virtual CDROM drive mounted with disk #2.

Actually, you can unmount and mount new virtual CDROM disks "on the fly" from the "devices" menu on the virtual machine's console. It is not necessary to use the VirtualBox GUI for this. For the remainder of the installation set, I swapped the installation CD disks via the "devices" menu.

One thing I might add to the list of ideas for better VirtualBox performance, and that thing relates to memory. I originally started to play around with the FreeBSD 7.2 hosted VirtualBox environment using a physical machine with only 256MB of memory. It was really too slow to be usable. I "graduated" the machine to 768MB of memory, and the performance improved to a level that I would say is quite good. The time spent running the environment in "low memory" conditions was gratifiying, because I was impressed with the way that the environment never crashed, even when the system had thrashed itself nearly to a standstill. Many programs do not fare well under such conditions, but this particular virtualizing environment stood up to the storm, albeit at a very slow pace.

Some readers might think that even 768MB is a slight figure for computer memory in 2009. We are talking however; about a person (moi), who still uses a 1993 computer for his email service (in 2009).

The Result: The virtualized instance of Solaris¹ 10 on the FreeBSD 7.2 Desktop

Any virtualizing environment has overhead, and such is the case with VirtualBox. Solaris is not known for fast booting, and it fares no better when it is virtualized. Once booted, however; I found that while it was not as snappy as the host desktop running FreeBSD, it was tolerably speedy.

Setting up the Debian Etch Client

I decided to use a new iso image downloaded directly from the source as the foundation for the virtualized Etch client build. The link to the image follows:

http://cdimage.debian.org/cdimage/archive/4.0_r8/i386/iso-cd/debian-40r8-i386-CD-1.iso

I used the downloaded image for the virtual CDROM mount in VirtualBox, and installed the Linux operating system following the same methodology that I used to install Solaris. (Fewer disks, of course).

I decided to try to get a feel for how well the virtualized version performed as compared to the "real deal". Towards that end, I used the Gimp image editor program to do some "real world" things like edit a picture of my favorite rodent ...

This opossum is not for stew ... my favorite little opossum picture being edited with Gimp in the newly created virtualized Debian Etch session ...

Since some readers may want to know what depth of function can be attributed to ... the virtual environment, I have loaded a flash-enabled Debian Etch instance with a web page containing my little dawg.swf dog viewer. One can see that it works just fine, as does the audio (even though Debian uses ALSA!) This might seem surprising at first thought, but it is the result of the emulation of the Intel sound device (It may be configured in the VirtualBox GUI [sound] section).





What a crafty way to run ALSA on a FreeBSD box ... (well, sort of).

Just in case anyone is interested, the fiesty little rodent (actually opossums are marsupials) has been posted in more viewable scale on my flickr page:


http://www.flickr.com/photos/40460718@N03/

I really have been strongly impressed by the strength of performance related to this FreeBSD port. The authors, porters, and committer(s) seem to have presented this new port in a non-plussed way, but it really is damned good stuff. They mention that testers are needed, to drive out the bugs. Well, I'm just not finding any, and so for the moment, at least, I don't have much debugging info to provide.

To be continued ...

Attribution: This site and it's authors have absolutely no affiliation with, and are not endorsed by FreeBSD, Debian, Microsoft, Sun, Adobe, Haiku-OS, or any other entities mentioned on this opinion page.

More info about Haiku operating system from the source at: http://www.haiku-os.org

More info about FreeBSD operating system from the source at: http://www.freebsd.org

More info on Sun's VirtualBox environment at: http://www.virtualbox.org

¹ More info on Sun's Solaris 10 operating system at: http://www.sun.com

More info about Flash, as described in this editorial, at: http://www.adobe.com

Note: The use of any of the information on these pages is entirely at the user's risk. No guarantee of accuracy is suggested or implied, and this information has been collated primarily for the use of Datazygte staff. The information is what it is, it is "as is", and nothing more. No license is given for redistribution or commercial use, and no use beyond the satisfaction of intellectual curiosity is expected. Neither the company nor the individual contributors may be held liable for any direct, indirect, or consequential damages, however caused, and on any theory of liability, arising out of or as a result of contact with any information on this site ...