Package: open-vm-tools Version: 2008.11.18-130226-1 Severity: normal Not sure on bug severity -- this is arguably not really a problem with open-vm-tools itself, but is a problem that can be fixed there. Feel free to reset it without any worry that I'd be upset.
We were having trouble with the open-vm-tools init script not properly initializing the network. It would unload the regular network driver, but when it loaded vmxnet, it didn't initialize. Today, I finally tracked this problem down to how we were building initramfs images. We build initramfs images on our systems with the "dep" option, which includes all modules that appear to be necessary on the running system. Whatever algorithm it uses recongnizes vmxnet if open-vm-modules is already installed on the system and includes it in the initramfs image. Then, when the system boots, it loads both network drivers. vmxnet sees that the other network driver is loaded and presumably disables itself; at least, it doesn't seem to do anything beyond say that it's loaded. Then, when the open-vm-tools init script unloads the regular network driver and loads vmxnet, vmxnet is already loaded, doesn't reinitialize, and the system ends up with no network. The workaround I tested and confirmed today is to unload vmxnet in the init script as well. In other words, right before modprobe -r pcnet32, add modprobe -r vmxnet. This is harmless if it's not already loaded, but if it were loaded by the initramfs image, this will remove it and the subsequent modprobe will load it and force initialization. Better, of course, is to remove vmxnet from the initramfs image, but it's hard to do that while using dep. As near as I can tell, there's no blacklist mechanism, so we would need to explicitly list all modules that should go into the image. This workaround was easier for us, and I don't think it should hurt anything else. The only problem that I can think of is that if you run open-vm-tools start twice in a row, with this change it would reinitialize the network whereas before it wouldn't. That isn't a problem for us; I don't know if it would be for anyone else. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
