Plumbing….

I have come across a common issue with my Lucid computers. After installing festival, the command echo "Hello world" | festival --tts gives me an error, “can’t open /dev/dsp”. I found the fix, although I do not remember where.

While upgrading my kid’s computer and installing the web proxy and filter (see article titled “SquidGuard Blacklists…“), I ran across a real problem. Wireless would start only after a user logged into their desktop, so the system had no IP address until then. However, without an IP, Dansguardian would fail to start. I tried scripting the problem away, essentially waiting indefinitely until a periodic check showed an IP address in use and then starting the services, but this did not work. I played around with making an init script under /etc/init.d and using “update-rc.d” to create the proper sym links. This also did not work. I tried manually defining the wireless network using /etc/network interfaces and creating a /etc/wpa_supplicant.conf file. This did not work.

It was then I remembered a server I had built at work, using Ubuntu-9.04, in which I had stripped off all of the GUI/desktop stuff, leaving a bare-bones server instead. It worked fine on the network, and did not have Network Manager installed. Looking in the init script folder under /etc/init.d, I found a NetworkManager service, so I made it non-executable (“sudo chmod -x /etc/inint.d/NetworkManager“), and ran “sudo update-rc.d -f NetworkManager remove” to get rid of the startup links. After that, the wireless network started on boot just fine, with no need for user interaction, and the services for the proxy and filters started flawlessly (I added them into /etc/network/interfaces).

So, Network Manager was stepping all over /etc/network/interfaces. Not anymore. I could have removed the package, but other packages will then be removed, and I don’t want that.

For someone having trouble with their manual wireless setup, here are my scrubbed /etc/network/interfaces and /etc/wpa_supplicant.conf files:

I have upgraded all my systems to KDE 4.3.1 very successfully, and it is gorgeous. While still slower than LXDE (this will likely always be the case), it is much better than the 4.2 that shipped with Jaunty. I have also upgraded to OpenOffice 3.1.1, the latest stable Wine, and I have updated Xorg as well – all from the PPA (Personal Packages Archive) site. Here is how, and from where:

Hope this helps, but YMMV. This is only a “howto if you want”, not a “recommendation that you do”. If things blow up, well, that’s the risk you take. I find it encouraging, however, that across four different Kubuntu 9.04 systems, I have not had any problems from these upgrades, and found that many fixes and improvements had taken place.

Ultimately, this article is really to help me for future upgrades. But if you get something good from here, that’s cool too.

Assuming you have already installed the 2.6 31 kernel, this link has a patch and script to modify the modules VMware compiles when you run the vmware-config.pl script. The script is for 2.6.30.4 and later kernels, and works fine for 2.6.31.

Run the vmware-install.sh script that came with VMware Server 2.0.1, but DO NOT run the vmware-config.pl script at the end.

Get the patch script – vmware-server.2.0.1_x64-modules-2.6.30.4-fix.sh and make it executable.

Get the patch – vmware-server.2.0.1_x64-modules-2.6.30.4-fix.patch.

Make a directory, say, /usr/src/vmware-patches and cd to it.

Copy the patch, the script and the four module sources (/usr/lib/vmware/modules/source/*.tar) to the patch directory you are now in.

Run the patch – it should build for 64-bit systems. I do not know about 32-bit systems…

Run the vmware-config.pl command, and install as normal.

There have been reports of minor script errors, so you may need to make some slight edits. Or you may not – I had no trouble. If you need to reinstall, make sure you stop the vmware services, rmmod the vmware modules, and delete everything in the /usr/lib/vmware/modules directory before re-running the installer-patch-config steps above. You will also need to delete the modules from your system – running the installer should generate a failure message telling you what files to delete from where. Successfully running the installer will put everything you need back in the /usr/lib/vmware/modules directory.

As I was unable to boot from the iso file itself in the VMware Server 2 web console (don’t ask me why), I was forced to burn this to a CD and boot the VM off of it (it boot s so fast, I had to set it to boot to the BIOS first and make the CD drive the first boot device).

I followed the defaults offered up by the boot CD and reset (blanked) my password.

Removed the CD and booted the VM, got right into my account just fine.

Created a new password.

I won’t soon forget this password now. What a pain. Hope this helps – I looked at John the Ripper and a couple others, but this tool really did the trick.

I finally decided to get VMware Server running on my new kernel. Whenever the kernel is updated, there are some things you can count on having to reinstall, such as NVidia video drivers and VMware installations. I expected problems, so my methodology was to attempt a normal install, expect failure, and search on the resulting errors. This did not pan out, so I tried the VMware Community Forums, and I found this little gem on how to patch the VMware modules:

I downloaded the patch and shell script, ran the script, and followed the directions of the output:

Move original files that could cause issues with VMware – “mv /usr/lib/vmware/modules/binary /usr/lib/vmware/modules/binary-orig“

Run the config again, without the -d option (otherwise, root would be the only user allowed to log into the web interface) – “vmware-config.pl“

Essentially, there were no problems getting everything running. Now I have to figure out what my password was to log into my Windows XP VM. I have to complete some online training that can only be done in Windows (thanks a ton). I would hate to have to crack my way in to my own VM….

Huge thanks out to both michelmase and Krellan for the patches and scripts!

I went ahead and decided to upgrade my kernel, and to go to the latest NVIDIA driver (180.51). I downloaded the kernel and the nvidia driver file, built the kernel, and removed the nvidia restricted driver. This is on a 64-bit build of Kubuntu 9.04.

However, I was not done.

When I tried to install the kernel image file, I kept getting dkms errors relating to nvidia-common. I eventually removed the nvidia packages using “apt-get remove --purge nvidia*” (as root), but this still would not allow me to install the kernel. Also my xorg.conf file was empty.

I fixed xorg by typing “dpkg-reconfigure xserver-xorg” and adding in the line “Driver "vesa" ” to the “Device” section, so I would have something when I rebooted.

Only when I removed dkms (“apt-get remove dkms“), was I able to install kernel 2.6.30.1. I use lilo since I run RAID-10, but did not have to update the /etc/lilo.conf file. Upon reboot, I stopped X with “/etc/init.d/kdm stop“.

I next installed the NVidia driver first (and chose to install the 32-bit compatibility files as well). After that, I ran “nvidia-xconfig” and my xorg file was ready. When testing with the “X” command, it just pulled up a blank screen, but I took a chance and started KDM (“/etc/init.d/kdm start“).