Turns out that insserv(8) isn’t happy on Ubuntu 9.10 or 10.04, so now vmware-config-tools.pl falls back to using update-rc.d(8). However, since old rc.d links have been left behind, update-rc.d won’t do anything at all. On top of that vmware-config-tools.pl calls it incorrectly.

Before running vmware-config-tools.pl or vmware-tools-upgrader first remove all the rc.d links:

cd /etc
rm -f rc?.d/*vmware-tools

On one of my systems I had multiple links at each run level, with different priorities, left behind from earlier VMware Tools installations. I guess regular manual inspection of the state of the links is warranted.

You may also want to apply this patch to vmware-config-tools.pl before running it:

--- vmware-config-tools.pl.orig 2010-06-06 19:45:49.176241344 -0400
+++ vmware-config-tools.pl      2010-06-06 20:25:56.000000000 -0400
@@ -1495,7 +1495,7 @@
    if ($gHelper{'update-rc.d'} ne '') {
      if (0 == system(shell_string($gHelper{'update-rc.d'}) . " " . $service
                     . " start " . $S_level . " S ."
-                     . " start " . $K_level . " 0 6 .")) {
+                     . " stop " . $K_level . " 0 6 .")) {
        return;
      }
    }

If your Linux kernel is 2.6.32 or later, the vmci module probably isn’t compiling for you either. Unpack the sources:

cd /tmp
tar -xvf /usr/lib/vmware-tools/modules/source/vmci.tar

Then apply this patch:

--- vmci-only.old/vmciKernelIf.c        2010-05-07 00:11:18.000000000 -0400
+++ vmci-only/vmciKernelIf.c    2010-06-06 20:39:40.693377830 -0400
@@ -44,6 +44,7 @@
 #include "compat_page.h"
 #include "compat_mm.h"
 #include "compat_highmem.h"
+#include "compat_sched.h"
 #include "vm_basic_types.h"
 #include "pgtbl.h"
 #include <linux/vmalloc.h>

Then replace the source tar with the patched files:

cd /tmp
tar -cvf /usr/lib/vmware-tools/modules/source/vmci.tar vmci-only

Now run vmware-config-tools.pl and everything should compile fine and you should have good start and stop links in your rc.d directories. Note that a start link is only installed in run level S: that’s okay, as according to the documentation that level is always run on boot. Seems to hold true, as the tools are now loaded fine on my systems.

When debugging the issue, I saw that a ping running on the system would often just sit there, not sending more packets, sometimes for seconds on end (I didn’t always wait to see if it would ever continue). Since hitting a key on the keyboard would immediately be echoed back, it wasn’t a problem with the terminal or ssh connection. Pinging the system from another would work without problems. Interrupting ping would report no packet loss (which was true — you can’t lose replies to packets you didn’t send).

My best guess is that the alternative scheduler chosen by the Ubuntu developers for the server kernels doesn’t work as intended on AMD CPUs (or just the Athlon XP, or some other part of the hardware I’m using).

My “fix” was to switch to Debian 5.0 (lenny), which doesn’t exhibit this problem at all.

I could have tried with the desktop edition of Ubuntu, but can’t really spare the time right now. Especially since I now have something that works reliably again.

I did try with different network hardware, though. I was originally using an SMC card based on ns83820 (but for some reason not reporting anything at all with ethtool — works fine with the gsip driver on NetBSD). I then switched to a Netwjork “brand” card based on r8169 (well liked by ethtool). No difference, but stayed with the latter (working ethtool is always nice).

aptitude install asterisk
m-a a-i zaptel
modprobe ztdummy

Also add ztdummy to /etc/modules so it gets loaded when the system starts.

If the m-a command is not found, install the module-assistant package.

Yesterday I ran into a problem, though, which was only saved by having remote console access. I have a system with a slightly more complicated disk setup: it has two SCSI disks running as a RAID 1 array using md and lvm. Upon rebooting after the upgrade, the system didn’t reappear on the network. What I found on the console was the initramfs panic shell: the root file system had not been found. Rebooting the old etch kernel worked fine.

The workaround proved to be very simple, once I distilled it from the search engine results. Just add rootdelay=10 to the kernel options in the bootloader. I’m using GRUB so this translates to editing the kopt line in /boot/grub/menu.lst and running update-grub.

I had also added raid1 to modules in /etc/initramfs-tools and regenerated the initrd, but that (alone) didn’t help. I’m not even sure it is needed at all — it might already be included anyway when using MODULES=most in initramfs.conf.

It was my second Debian Linux system with IPv6 connectivity that gave me a start. I built one more system and got the same results. I could have sworn the first one had worked fine without any tricks. I considered it, but decided I’d rather not abandon IPv6 on Linux. After all, I had it running on all the other platforms (NetBSD, Mac OS X, Windows).

I used tcpdump to inspect the traffic closer. I ran this command in one window on a system that works without problems:

    tcpdump ip6

I simultaneously used ping6 in another window on the same system to initiate traffic to other systems. This revealed that the problematic Linux systems never answer to neighbor solicitation messages.

At this point I realized that both of the problem systems were using the same network card (gsip aka ns83820). I swapped in one of my older favorites, 3Com 3C905C-TXM (ex aka 3c59x). Indeed, now the system works fine, although at a lower speed due to the different hardware.

Searching for ns83820 took me to a message about net driver updates that has patches to fix multicast handling for a number of Linux network drivers. The problem was now clear: the network card wouldn’t be programmed to receive the multicast traffic even if multicast addresses were configured on the interface. And we know IPv6 relies on multicast, for example for neighbor solicitation.

I figured I could “fix” this if I just get the card programmed into promiscuous mode. The easiest way to do that is to make the interface part of a bridge! Just edit /etc/network/interfaces and replace all instances of eth0 with br0. Then add a statement to configure the ports of the new bridge interface. The result could look like this:

    auto br0
    iface br0 inet dhcp
        bridge_ports all

It’s a kludge, but it works well. Since this system is going to be running Xen, it will need a bridge anyway.

I quickly looked at ethtool as well, but didn’t see an option to frob the promiscuous mode setting. It might be impossible to support such an option, given that the drivers make decisions about the setting based on the interface configuration.