In my ancient post on Scripting up some tabs with konsole in kde was for 3.5 era and dcop. I had a lot of scripts that would just blast open windows in a konsole session, automatically connecting to my various machines in the remote computer lab. Depending on what I was doing, I could just exec a sript from the desktop to connect and use a suite of machines in a tabbed konsole session.

With dbus, and the 4.x kde upgrade I lost all that. Recently I've started trying to convert the old stuff to dbus.

For example, setting tab titles:

$ dbus-send --session --dest=$KONSOLE_DBUS_SERVICE --type=method_call --print-reply /Sessions/35 org.kde.konsole.Session.setTitle int32:1 string:"title"
method return sender=:1.88 -> dest=:1.187 reply_serial=2

It unfortuantely took me a long time to figure this out. One, since dbus-send spits out an incorrect error when the parameters are wrong. Instead of 'incorrect parameter,' you get 'no such method.' This makes sense from a OO standpoint since 'no such method' exists with 'those parameters''

$ dbus-send --session --dest=$KONSOLE_DBUS_SERVICE --type=method_call --print-reply /Sessions/35 org.kde.konsole.Session.setTitle
Error org.freedesktop.DBus.Error.UnknownMethod: No such method 'setTitle' in interface 'org.kde.konsole.Session' at object path '/Sessions/35' (signature '')

dbus-send supports all sorts of types, and from introspection, I knew setTitle needed a int and a string. dbus-send supports all types of things int16, int32, etc..
Without looking at the source, you just kind of have to guess which types to send.

$ qdbus $KONSOLE_DBUS_SERVICE /Sessions/35
method void org.kde.konsole.Session.close()
method QByteArray org.kde.konsole.Session.codec()
method QStringList org.kde.konsole.Session.environment()
method bool org.kde.konsole.Session.flowControlEnabled()
method int org.kde.konsole.Session.foregroundProcessId()
method bool org.kde.konsole.Session.isMonitorActivity()
method bool org.kde.konsole.Session.isMonitorSilence()
method int org.kde.konsole.Session.processId()
method void org.kde.konsole.Session.sendMouseEvent(int buttons, int column, int line, int eventType)
method void org.kde.konsole.Session.sendText(QString text)
method bool org.kde.konsole.Session.setCodec(QByteArray codec)
method void org.kde.konsole.Session.setEnvironment(QStringList environment)
method void org.kde.konsole.Session.setFlowControlEnabled(bool enabled)
method void org.kde.konsole.Session.setMonitorActivity(bool)
method void org.kde.konsole.Session.setMonitorSilence(bool)
method void org.kde.konsole.Session.setMonitorSilenceSeconds(int seconds)
method void org.kde.konsole.Session.setTitle(int role, QString title)
method QString org.kde.konsole.Session.title(int role)
method QDBusVariant org.freedesktop.DBus.Properties.Get(QString interface_name, QString property_name)
method QVariantMap org.freedesktop.DBus.Properties.GetAll(QString interface_name)
method void org.freedesktop.DBus.Properties.Set(QString interface_name, QString property_name, QDBusVariant value)
method QString org.freedesktop.DBus.Introspectable.Introspect()

Now onto, auto new tabs, title naming, and finishing the conversion.

Despite the really decrepit solutions you can find via Google, this is really easy.

1. create a "Movemail account"
2. exit thunderbird
3. cd ~/.thunderbird/{random}.default/Mail/localhost
4. ln -sf /var/mail/{username} Inbox
5. re-startup thunderbird
6. read mail.

For many years I've been verifying our products stack at work with the TAHI organization's v6eval engine and conformance test suite. One of the good and bad things about it is that it ran on FreeBSD -- pretty much only on FreeBSD.

This is because in the beginning this organization also were also sponsoring the KAME stack that you could drop right into the FreeBSD kernel sources and come out with a highly compliant ipv6 stack. Well, like anything that was FreeBSD only, that made it difficult to run in a company that did Linux development.

It wasn't long before people tasked with ipv6 verification and strapped by Linux systems began attempting to port it. IBM first posted a patch to get the v6eval engine running, and they did a really good job. That was posted on some long lost IBM site, but I had a copy and saved it off to help people out with their Linux systems here. This patch worked for a long time, as long as you didn't upgrade your old 2.2 or 2.4 based Linux system.

That patch I have archived here: v6eval-2.2b6_linux.patch

Recently the v6eval code was updated so that it would, a. run on modern FreeBSD systems, and b. compile on modern C++ compilers. This change was good, because it actually made the code more portable in a way. A while back on the TAHI users email list a patch was posted for Fedora 8. This patch was based on the Debian port and makes changes for Fedora 8.

That patch I have archived here: v6eval_fedora8.diff

Here's the original message from the list (you can pull it from the TAHI user archives if you choose -- I removed the emails addresses/names).

Date: Thu, 3 Apr 2008 13:31:45 -0700
Subject: [users:00660] Re: Running Tahi on Linux

Here is the patch file for v6eval-3.0.12.  Naturally the Tahi folk released a new version while I was building and verifying this patch file.

To use this, install the source from Tahi onto a Fedora 8 system and use the 'patch' command to apply this patch.  You should then be able to use 'make' as before to
build the system and 'make install' to install it in /usr/local/v6eval.  Note that there are probably some dependancies that I'm glossing over.  If you have problems
building, let me know and I'll try to help you figure out what packages you need to install.  The compiler does issue a lot of warnings about virtual functions that I
didn't chase down, but the system seems to still work for me.

While this patch is meant to be applied to the base source as available from Tahi, I won't claim to be the one who did all the necessary modifications.  I started
with the tahi-linux package that according to the change log came from Kazuo Hiekata at IBM, then made changes to get it to compile on Fedora 8.  My modification
mostly involved the Makefiles.  Guess I should add my name to the change log as well.  Maybe next time.

Let me know if there are any issues.

The Fedora/Debian patch has some good bits but makes WAY too many unnecessary changes (reformatting code, rewriting Makefiles -- no big deal as it was someones rough personal copy posted to a list). When I ported to the automated test system here I did the following and was able to port it in just under a day:

• extract the latest tarball
  
• grab 'pmake' package for my distribution and install (*BSD style make)
  
• grab 'byacc' package for my distribution and install (*BSD style yacc)
  
• apply minimalist 2.2b6 patch (read the instructions at the top of the patch file text)
  
• attempt to compile, and fix issues.
  
• pull very specific Linux OS related issues from Fedora/Debian patch over to extracted area.
  

That's it.

I maintain several systems that I use day to day at my Job. One of these is a box I use for mostly code compilation that run Gentoo. The machine runs on a Tyan S2822-D, aka Thunder K8SD Pro.

When I decided to wipe this machine, which was running CentOS 3.x at the time, and drop Gentoo on it, I had been out of the Linux Kernel compilation game for quite a while. To make a long story short, I could not find the correct Kernel compile options (which have become inordinately numerous and bloated) in the 2.6 kernel to make this beast boot. The internet was very little use as to which ones I needed as well. After a couple days of free time spent trying to get the correct options, I gave up and used what did boot -- Gentoo's genkernel package.

Since I ply mostly with FreeBSD systems, having a 'GENERIC' kernel was very familiar to me, and I wrote it down as a 'good move overall' for the future. However, after many moons of regular 'emerge --sync' and 'emerge -vuD world' success stories, I came across a update that broke my genkernel compilation. I couldn't find any hints from internet groups or google searches. Last week I broke down and decided to fix the damn thing myself.

The error was fleeting to say the least and NOT logged in /var/log/genkernel.log. The compilation always died after the kernel compilation and during the busybox compilation. busybox in genkernel is 1.7.4 and gentoo's genkernel ships several patches to it. The compilation would die during this patch process. The error would appear only on the terminal and would not be logged:

patch: **** File shell/ash.c seems to be locked by somebody else under Perforce

There was a whole bunch of other failures that would make this scroll by, so unless you happened to troll the backbuffer you wouldn't catch this as the failure. To it's credit the gentoo genkernel process does mention the failure to patch as the key failure.

So I simulated the patch process, I ran 'tar -xjpf /usr/portage/distfiles/busybox-1.7.4.tar.bz2' in /var/tmp and ran 'patch -p1 < /usr/share/genkernel/patches/busybox/1.7.4/1.7.4-ash-timeout.diff' from the extracted directory. Sure enough, same error.

It turns out that since permissions are extracted by default with the tar command under the build process, patch has '-g' ON BY DEFAULT (from the manpage):

       -g num  or  --get=num
          This option controls patch's actions when a file is under RCS or SCCS control, and does not exist or is read-only and matches the default  ver-
          sion,  or  when a file is under ClearCase or Perforce control and does not exist.  If num is positive, patch gets (or checks out) the file from
          the revision control system; if zero, patch ignores RCS, ClearCase, Perforce, and SCCS and does not get the file; and if negative,  patch  asks
          the  user  whether to get the file.  The default value of this option is given by the value of the PATCH_GET environment variable if it is set;
          if not, the default value is zero if patch is conforming to POSIX, negative otherwise.

I was not amused. Anyway, I moved patch from /usr/bin/ to /usr/bin/patch.org and wrote this wrapper in /usr/bin/patch:

#!/bin/bash
/usr/bin/patch.org -g0 $@
exit $?

genkernel now compiles.

I have a scanjet 6300c at home, and for quite a while now, the glass on the innards side of the scanner has had a thin film or fog like quality to it. My wife was scanning pictures in and was complaining that the little 'all-in-one' scanner/printer/copier scans much better than the 6300. True enough the scans on the 6300c have a fog or haze to them (like when you have the contrast too high and the colors get less defined) .

Well, I'd been adverse to actually doing something about it since the manual and HP's online documentation stated you cannot clean the inside of the glass on the 6000 series. However, after a few web searches I found some third party evidence that you can open it up safely and clean the innards.

Sure enough, it was _extremely_ easy. Just pop the scan lid off (the manual shows you how so you can attach the page feeder), and then pop two screw covers on the front end of the glass top portion of the scanner. After that just take a torqx-10 head and undo 4 screws holding the lid on.

With the lid off, it's obvious you do not want to remove the glass since it's packed tightly with spacers that look like they would break easily if you tried. However, since it's just a hunk of plastic and glass, it's fairly easy to clean in place.

Cleaning it, according to the common sense instructions here:

http://h10025.www1.hp.com/ewfrf/wc/document?docname=bps02788&lc=en&cc=us&product=60104&dlc=

I discovered there was a thin sheen of oil residue on the bottom side of the glass. Apparently, I deduced, the manufacturing oil/grease used on the head, plastic belt, and gears evaporates from the heat of the lamp and gets plastered on the glass. This happens slowly over time, but will always affect picture quality.

After several thorough cleanings with some photo lens cleaner and cloth, both my wife and I could not see any residue or streaks on either side of the glass when held up to the light from several angles.

I then used some mini-vac attachments to suck up a very tiny amount of dust that had collected on the bottom (the chassis on this model is probably not as air tight as it could be) and then I used compressed air to blow off the mirrors and light. I then popped the scan glass back on, re-tightened the screws and replaced the scan lid.

Some test scans proved a world of difference in quality. I'll probably be maintaining a clean schedule with it now every three months.

[14:21] do you have your peril sensitive sunglasses?
[14:21] (and your towel?)
[14:26] damn. I only brought my perl sensitive sunglasses.

I was trying to convert a piece of network software to FreeBSD. Unfortunately, even though the author quotes "should compile on any POSIX like OS," it doesn't (POSIX != LINUX). It should be obvious, when they drop things like:

  if (ioctl (sock, SIOCGIFADDR, &ifr) < 0)

throughout the code. So the above is from a section of code trying to obtain the MAC address on a interface. Doing this task on FreeBSD can be done through ioctl(), but is discouraged by the developers. They encourage you to use getifaddrs(). This strange and wonderful function grabs all sorts of information from the interface list, however, a couple of things are not obvious about it's use. If you really want to play arround with IF_LINK type addresses on the interfaces returned you need to be using sockaddr_dl not just sockaddr. Overloading sockaddr with magic casting is the new pink these days and thats what's required. It confused me at first since the manpage has:

         struct ifaddrs   *ifa_next;         /* Pointer to next struct */
         char             *ifa_name;         /* Interface name */
         u_int             ifa_flags;        /* Interface flags */
         struct sockaddr  *ifa_addr;         /* Interface address */
         struct sockaddr  *ifa_netmask;      /* Interface netmask */
         struct sockaddr  *ifa_broadaddr;    /* Interface broadcast address */
         struct sockaddr  *ifa_dstaddr;      /* P2P interface destination */
         void             *ifa_data;         /* Address specific data */

for the structure.. same with /usr/include/ifaddrs.h. It turns out copying sa_data of sa_len from your friendly struct sockaddr does not give your the ethernet address from ifa_addr. :( :( :( :(. Too make a long story short:

/* getmac.c -- retrieve the mac address from a interface name */
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <net/if_dl.h>
#include <ifaddrs.h>

int main(int argc, char ** argv)
{
    struct ifaddrs   *ifaphead;
    unsigned char *   if_mac;
    int               found = 0;
    struct ifaddrs   *ifap;
    struct sockaddr_dl *sdl = NULL;

    if (argc < 2)
    {
        fprintf(stderr,"usage:\n");
        fprintf(stderr,"\t %s <interface name>\n",argv[0]);
        exit(1);
    }

    if (getifaddrs(&ifaphead) != 0)
    {
        perror("get_if_name: getifaddrs() failed");
        exit(1);
    }

    for (ifap = ifaphead; ifap && !found; ifap = ifap->ifa_next)
    {
        if ((ifap->ifa_addr->sa_family == AF_LINK))
        {
            if (strlen(ifap->ifa_name) == strlen(argv[1]))
                if (strcmp(ifap->ifa_name,argv[1]) == 0)
                {
                    found = 1;
                    sdl = (struct sockaddr_dl *)ifap->ifa_addr;
                    if (sdl)
                    {
                        /* I was returning this from a function before converting
                         * this snippet, which is why I make a copy here on the heap */
                        if_mac = malloc(sdl->sdl_alen);
                        memcpy(if_mac, LLADDR(sdl), sdl->sdl_alen);
                    }
                }
        }
    }
    if (!found)
    {
        fprintf (stderr,"Can't find interface %s.\n",argv[1]);
        if(ifaphead)
            freeifaddrs(ifaphead);
        exit(1);
    }

    fprintf (stdout, "%02X%02X%02X%02X%02X%02X\n",
        if_mac[0] , if_mac[1] , if_mac[2] ,
        if_mac[3] , if_mac[4] , if_mac[5] );

    if(ifaphead)
        freeifaddrs(ifaphead);
        
    exit(0);
}

The following is a simple shell script using the KDE dcop client to open new tabs in konqueror (or a new instance of konqueror if it's not running). I use this from pine's url-viewers setting to launch new tabs with a url contained in a email.

#!/bin/sh

KONQ_WIN=`dcop konq* | head -1`

if [ "$KONQ_WIN" = "" ]; then
    /usr/local/bin/konqueror $1 &
else
    NEW_TAB=`dcop $KONQ_WIN konqueror-mainwindow#1 action newtab`
    dcop $NEW_TAB activate
    dcop $KONQ_WIN konqueror-mainwindow#1 openURL $1
fi
return 0

Last two weeks I had been working on and off on a problem related to ACPI and some 1u servers using MSI-9618 motherboards. After booting freebsd, I couldn't get the second NIC to work at all, it turns out after looking at 'vmstat -i' that em0 and em1 where sharing an interrupt:

# vmstat -i
interrupt                          total       rate
irq3: sio1                      52807402         55
irq4: sio0                          1604          0
irq14: ata0                           36          0
irq16: em0 em1+                  2527378          2
irq19: uhci1+                      86991          0
cpu0: timer                   1886077214       2000
cpu1: timer                   1886076861       2000
Total                         3827577486       4058

From past experience I knew this was from poor resource assignment from the BIOS when ACPI isn't enabled. So I built and installed the acpi.ko modules and installed it. These are webware 1185s from pogolinux. The chassis manual that comes with it labels them as P1-103 series and a part number as MS-9218 1U rackmounts.

Then when I booted, right after it should be switching to multi-user, it appeared to hang. I enabled ALT_BREAK_TO_DEBUGER in the kernel and tried again, except the keycode for break to debugger did nothing. I posted about the hang on the freebsd-acpi list with no response. Then out of hand I tried sshing to the box... it worked! So it wasn't really hung, just the serial console was unresponsive.

Now looking closer at the dmesg I realized the resources for sio0 and sio1 were wrong! sio0 was getting 0x2F8 and sio1 was getting 0x3F8 when it should be the other way around. I rechecked the BIOS settings, everything was ok. I downloaded a new BIOS from the MSI taiwan site that stated the fix was for 'redhat 4' installs. That didn't work.

I posted to freebsd-acpi again with what I knew. This time I got a reply and after some back and forth, I generated a new .asl file that would probe sio0 and sio1 in the correct order! Now all my interrupts are assigned correctly:

[root@pogo-1 ~]# vmstat -i
interrupt                          total       rate
irq1: atkbd0                           6          0
irq3: sio1                      13587145         55
irq4: sio0                          1243          0
irq14: ata0                           36          0
irq16: em0 uhci3                    3237          0
irq17: em1                            21          0
irq19: uhci1+                      66550          0
cpu0: timer                    485520843       2000
cpu1: timer                    485520575       2000
Total                          984699656       4056

And everything seems to be working great, although my post's problem according to the resulting discussion on freebsd-acpi seems to be more common than imagined!

One of the things I also use regularly at work is wget. In order to work on compression I needed a tool that would recursively spider a web site and had the appropriate features, but would also support compression. At the time, nothing out there supported this, so a year ago or so I finished a patch to wget to add compression.

You can check out the latest version of wget using the subversion repository outlined here. Apply this patch from the top directory and as long as your OS has zlib support, then you should be able to use the '-z' switch this patch adds to request compressed files from a webserver.

wget-zlib-04202006.patch

Here's an example how a 39K download turns into a 10K download with compression, and downloads in half the time.

$ ./wget http://172.16.17.1/index.html
--13:22:32--  http://172.16.17.1/index.html
Connecting to 172.16.17.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 39599 (39K) [text/html]
Saving to: `index.html'

100%[=======================================>] 39,599      --.-K/s   in 0.005s

13:22:32 (8.39 MB/s) - `index.html' saved [39599/39599]

$ ./wget -z http://172.16.17.1/index.html
--13:22:39--  http://172.16.17.1/index.html
Connecting to 172.16.17.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10546 (10K) [text/html]
Saving to: `index.html.1'

100%[=======================================>] 10,546      --.-K/s   in 0.002s

13:22:39 (5.62 MB/s) - `index.html.1' saved [10546/10546]

$ diff index.html index.html.1
$ echo $?
0

In my job, I deal with a lot of tcp traffic, esp http, and ipv6.

For awhile I've been using both bozohttpd and Apache.
I used bozohttpd because it's simple, light weight, command line driven and easy to hack on. The big win for bozohttpd was the fact you could drop it into inetd and let inetd take care of the ipv6 compliance side. However, bozohttpd is lacking in several useful features and in many cases is missing some standards compliancy -- so in those cases I used Apache. Everyone here tests with Apache, but I absolutely despise Apache's convoluted "do everything" configuration and setup. It can take me hours to remember, research and setup even simple changes (esp if it requires a missing module!). Compiling Apache can be a royal PITA... Basically, it's too flexible.

Recently I've taken a liking to lighttpd. It's very fast, easily configurable, and restricted enough in it's feature set to allow easy module configuration. It only has one problem. You could use it for ipv6 and not ipv4 or vice versa. Common mistake really, people never take the time and effort to use sock storage structure and properly do a dual stack server, they try to 'hack' their ipv4 server into v6 with #ifdefs, etc. Bad bad bad. I digress.

Adjusting lighttpd to work on v4 and v6 in the same process was easy. Easy that is if you're using freebsd.

sysctl net.inet6.ip6.v6only=0

Then set up lighttpd to serve v6 addressing, and you're set. This basically enables v4 compat ipv6 addressing like ::ffff:172.16.17.1, so all their #ifdef'd ipv6 only code still chomps on the numbers just fine and listening on :: still gets you v4 traffic.

[root@moby bin]$ cat bipcons.sh
#!/bin/sh

SESSIONS="
d44
co-04
c62-29
co-02
co-05
d84-1
d84-2
"

KONSOLE=`dcopclient $KONSOLE_DCOP`
CURSESSION=$KONSOLE_DCOP_SESSION
for A in $SESSIONS; do
NEWSESSION=`dcop $KONSOLE konsole newSession $A`
dcop $KONSOLE $NEWSESSION renameSession $A
# your command here on the next line!
dcop $KONSOLE $NEWSESSION sendSession "console $A"
done
dcop $CURSESSION closeSession

The above shell script I have saved to a icon on my kde desktop. The icon properties run this in the command section:

/usr/local/bin/konsole --script -e ~/bin/bipcons.sh

Basically it opens a new tab for each entry in $SESSIONS, assigns the tab name to that entry ($A) and then runs a command on that entry as well. In this example, the remote console app (http://www.conserver.com). Of course that app could be anything, like ssh.

Very useful stuff. Took me a long time to dig up this information on the web, so I'm posting it here for posterity.

Here's a slightly out of date HOW-TO I wrote that has kept me somewhat sane when using RedHat 9 (DeadRat):

Keeping your RH9 box up to date with apt
----------------------------------------

Apt, normally a base part of the debian Linux distrobution has been ported
to RedHat and rpm. Apt makes it extremely easy to keep up to date with the
latest fixes and packages from the official RedHat distribution. Apt also
does all the dependancy checking for you. Thus keeping your installation
sane as well as up to date. It will not let you install incompatible package
sets.

- Start here:
http://apt.freshrpms.net

- download the apt for RedHat 9 package.

- install the apt for RedHat 9 package:

rpm -Uhv apt-0.5.5cnc5-fr2.i386.rpm

- update the package list:

apt-get update

You can 'cron' this command if you like. Use the really quiet mode to
prevent email unless there's an error. 'apt-get -qq update'

- upgrade your installed packages:

apt-get upgrade

You can also 'cron' this command. I prefer to use the 'download' only
switch. This way I get a email report from std out about the packages
that are ready to be updated. I can then manually do a 'apt-get update'
at my convienance and resolve conflicts if they occur.

download only mode: 'apt-get -y -q -d upgrade'

- erase old 'out of date' packages from the local cache"

apt-get autoclean

You should cron this one, for a once a week operation.

- installing new packages and their dependancies via apt:

You have to know the package name first:

browse http://ayo.freshrpms.net/redhat/9/i386/ to find the packages available.
(this pointer is stored in /etc/apt/sources.list and may update/change)

Once you find the package you want, install it.

apt-get install vim-X11

You don't need to specify the version, or the file name.

- checking on dependancies for available packages:

You can see the dependancy and package descriptions for packages in the
local cache:

apt-cache showpkg vim-X11

Use this command to decide if it's worth installing, investigating what
you're missing, etc..

wow, teh suck!

[root@adkinson245 root]$ konqueror
konqueror: ERROR: Error in BrowserExtension::actionSlotMap(), unknown action : searchProvider
ASSERT: "data->bitmap" in kernel/qbitmap.cpp (222)
konqueror: ERROR: : couldn't create slave : Unable to create io-slave:
klauncher said: Error loading 'kio_http'.
konqueror:
konqueror: ERROR: Error in BrowserExtension::actionSlotMap(), unknown action : searchProvider

No web browsing available. The http render component works in other components, so it's just the network protocol object that seems hosed.

I can't figure this one out, but a full rebuild of kde would probably fix it. These are using the fruitsalad builds.

This thread mentions the problem. But no real resolution.

I was experiencing softupdate inconsistencies and actual data-loss in 4-stable on my main workstation which has a large 30gig EIDE drive on it. Turning off softupdates and disabling dma in -stable made most of the corruption go away, but it was still there.

I decided to upgrade the workstation to freebsd-current and see if ATANG would fix my problem. So far it has fixed the disk issue, but it broke my mouse. ums(4) is losing interrupts and the mouse is unusable. I have to attribute this to my chipset and the new interrupt code. I'm going to be playing around with different settings to try to get my usb trackball back, currently I'm recompiling with NO_MIXED_MODE to see if this might fix my issue. *cross fingers*

I notice that ULE still needs some work however, I experienced several instances while buildworld/buildkernel is humming in the background where apps never get slices or not enough slices to continue correctly (most visible with knode).

So far -current is fairly stable if I ignore the ums issue and use the trackball in ps/2 mode with the adapter.

To natural selection (www.natural-selection.org). Thanks mike.

So I have several boxes at work installed with 5.0. One particular box I was having trouble with inetd connections sending reset when the box was under a significant amount of httpd load. No problem, I just adjusted inetd to start with '-R0' and problem solved.

After I did this, it occurred to me that I could easily update the box to -current by NFS mounting /usr/src and /usr/obj from the machine I track -current on and run make installkernel, reboot, installworld, etc.. to get it up to date fairly quickly. I should have stopped myself right there.

At first make installkernel complained about this line in Makefile.inc1

745: (${TARGET_ARCH} != ${MACHINE_ARCH} || ${BOOTSTRAPPING} < 501101)

Which was really weird since ${BOOTSTRAPPING} is 0, not "0" and it's complaining about string comparisons. Oh well, I changed '<' to '!=' since it would accomplish the same thing.

Installkernel succeeded and I rebooted single user into the new kernel, remounted /usr/src and /usr/obj off the -current box and began to run makeinstallworld (after mergemaster -p of course). This is where things got ugly. The install died somewhere in in the middle of nowhere leaving me with no ld-elf.so.1 and half installed new DYNAMICROOT /bin, /sbin, etc... ARGHH!! I couldn't do anything that wasn't built into the shell at this point.

THANK GOD for a statically linked mountd. I was able to finally mount /rescue off of the -current box and proceed to copy just enough to selectively 'make install' certain portions of the tree! After it was fairly stable, I re-ran 'make installworld' and succeeded. I think NO_DYNAMICROOT=yo will be in the -current boxen's make.conf from now on.