|Xen network bridge||Tuesday 30th August 2011|
Since VMWare have stopped supporting VMWare Server 2.0 and it no longer seems to be possible to get working under the latest Linux Kernels without some serious tinkering I'm being forced to look at alternatives.|
I've been playing about with the Xen Hypervisor as it comes bundled with openSUSE (I'm on 11.4). It works in a slightly different way than VMWare, and I'm not convinced of it's reliability yet. But more on this later when I've settled on my final decision.
My main stumbling block in setting things up was getting networking to play-ball. The installation did a good job of getting it half-way there, but didn't quite set everything up and instead broke the networking on my host. After some digging and yet more IRC conversations I got it working and thought I'd note it here.
The problem I was having was the virtual network device on my guest machine was not getting an IP address from DHCP (which runs on the host).
Xen requires a "bridged" network device on the host to allow your guests to access the network as-if they were connected directly. The YaST Xen installation process will add a bridge for each of your physical devices. So if you have eth0, it'll create a br0. The Xen documentation covers all this in detail if you're not using something like YaST to do it for you.
It will also try and apply all the settings from eth0 to br0, but might not be entirely successful. So this is where you have to pick up the pieces. In the br0 configuration you have to "encapsulate" the physical device, eth0; which now for all intents and purposes becomes a duff redundant device. eth0 will need setting to no IP address or 0.0.0.0 (whichever floats your boat). I don't know why bridging works like this in Linux, and I don't really care.
The main problem I had was that my gateway and all my services were setup on eth0, so this all failed. You will need to manually change your default gateway and rebind your services to br0. Essentially eth0 doesn't exist, it's been replaced with br0.
My lack of IP address stemmed from the fact that I had setup br0, but not rebound dhcpd to said device. Once this had been fixed and restarted everything sprung into life.
|SoundBlaster woes||Tuesday 23rd August 2011|
The Creative SoundBlaster Audigy 2 ZS was one of Creative's bigger successes and it still finds itself working away in computers.|
There was a minor hiccup with the migration to 64-bit, but that was soon resolved - or was it?
I've recently given my computer a much needed RAM upgrade from a pathetic 3GB to 9GB. Since then my microphone has packed up. I didn't spot the correlation myself, but after some searching around forums I discovered other people complaining about the problem.
Creative drivers just don't seem to be able to handle 64-bit system with 64-bit levels of memory (e.g. over 4GB). I'm not sure if this has been fixed in more recent cards, the question has been asked, but nobody has answered.
This bug report highlights the issue and has been marked as urgent by Creative staff - in 2009. There has been a subsequent driver released, but this seemingly hasn't resolved the issues.
I know I need to switch to a PCI Express sound card relatively soon. New motherboards are already dropping support for PCI, and my current one I can only use PCI if I don't have a second double-slot graphics card (which I intend to later this year).
I've had a large number of Creative products over the years. Hardware wise things are very well built, but software and customer service is appalling. If you buy a Creative product you can't really expect it to work for the first six months of it's existence, and then it'll break pretty quickly after that. It's simply not worth the effort buying from such a poor brand. They have always been full of potential but have failed where it matters - keeping the punters happy.
Alas, having the monopoly on sound-cards (patents and licenses) and not putting any effort into it means the sound-card front is pretty rotten.
If you want 3D sound in games then you need a Creative card. People will whitter on about how EAX is dead, but it's not. It may not being actively developed any more and is long due for burial, but it's still stinking up new and old games (backwards compatibility is important). This is a real shame, and it's so disappointing.
|vjscor ClickOnce||Thursday 18th August 2011|
Another day, another crappy application being flogged as an Enterprise quality product.|
Somebody in our business wants to try out an application from some company, but the web-based installer (.NET ClickOnce) doesn't work.
It bails with an error:
"Unable to install or run the application. The application requires that assembly vjscor Version 188.8.131.52 be installed in the Global Assembly Cache (GAC) first."
Simple, it's missing the "vjscor" assembly from .NET. Ah, but .NET 2.0 is installed, and so is the Visual J# Redistributable package. In fact, looking at the Global Assembly Cache the assembly is listed.
After much playing with Process Monitor I narrow it down to the installer looking for the assembly in the GAC_32 directory, when it doesn't find it, it bails. Checking the GAC again shows vjscor listed under MSIL processor architecture so the assembly is installed under the GAC_MSIL directory.
MSIL should be fine, as this will run on any CPU and get compiled by .NET JIT when it comes to execute, but for some reason something is hard-coded for the x86 version. A comparison of computers that the software does work on showed that those with it working had the assembly only for x86.
Turns out there are several versions of the J# Redistributable package. The one that installs vjscor into the x86 directory is J# Version 2.0 (note: not the second edition package, which installs the MSIL version).
You will need to remove all versions of the package before installing the correct version. Although you can then later reinstall the newer versions which will work along side (I think, I don't actually know anybody else who uses J#).
|More driver fun||Wednesday 3rd August 2011|
I was wondering what would happen if my kernel was updated with this Atheros AR8131 driver.|
Turns out, it breaks.
And if you don't have all the source code for your new Linux available then you can't compile it. *argh*
Again, the folk on the #opensuse channel helped out wonderfully and I managed to recover my system by copying the kernel module from the previous kernel into the appropriate place. Luckily this update was minor enough to allow this, but you cannot rely on this working always.
So in my case it was /usr/lib/modules/184.108.40.206-0.7-desktop/kernel/drivers/net/atl1e/atl1e.ko and then move it to the same directory but for your net kernel version.
Running "modprobe atl1e" reinstalls it to the kernel and "rcnetwork restart" restarts the network, "ipconfig -a" should list the network card once again.
In my case I found rebooting didn't solve it. I had to set the "module" against the eth0 hardware. With openSUSE this is easily done with Yast. I'm sure it's fairly easy normally too... search is your friend.
|Linux and Atheros AR8131||Monday 1st August 2011|
My home-server has a nasty habit of failing to POST - after a power-cut (and the UPS running out of juice) the usual flicking of power switches in strange patterns didn't convince it to boot.|
I tend to use my desktop internals as pass-me-down parts for my server when I upgrade it. But even though my desktop is 3 years old, the money involved in making an upgrade worth-while was too high (although I did use my shopping trip as an excuse to buy an extra 6GB for the desktop). So instead I hunted down the cheapest Sandy Bridge parts I could find - as latest technology is a must when buying new, but top-of-the-range is not so important for serving up files. I opted for a MSI H61M-P21 (B3) mATX board, which has a H61 chipset so supports a GPU-on-CPU setup, and a healthy dollop of RAM.
Having Linux on my server is a bonus, as it's fairly resistant to being dumped onto new hardware and just getting on with it. But complex RAID drives often get in the way. Nope, mdraid wins again and it all booted fine - apart from the network card.
The built-in gigabit NIC reports itself as:
02:00.0 Ethernet controller: Atheros Communications Device 1083 (rev c0)
Model: "Attansic Ethernet controller"
Vendor: pci 0x1969 "Attansic Technology Corp."
Device: pci 0x1083
SubVendor: pci 0x1462 "Micro-Star International Co., Ltd."
SubDevice: pci 0x7680
The only information I had was the rather useful:
"Unable to configure the network card because the kernel device (eth0, wlan0) is not present. This is mostly caused by missing firmware (for wlan devices)."
Turns out, in the Linux world, the word "firmware" is used for drivers (where I always thought firmware was something that was written onto a ROM.
A little research lead me to the chipset of the NIC being an "Atheros AR8131", part of the Atheros AR813x family, or Atheros AR81 family (depending on where you look). Linux drivers for many of the Atheros cards are bundled with the kernel, apart from this one. Follow the dozens of links from around the Internet to the driver download got me nowhere as Atheros has recently been bought by Qualcomm and their web-site has vanished. It's still available via the Internet Archive, but not the download.
So for your viewing pleasure, I've mirrored it temporarily:
Installation seemed to be a fairly normal affair, you have to have your kernel sources (so bugger knows what happens if your kernel updates automatically), and do the usual sort of:
gzip -d AR81Family-linux-v220.127.116.11.tar.gz
tar xf AR81Family-linux-v18.104.22.168.tar
Alas, on my kernel (2.6.37) I was thrown an error:
"Makefile:105: *** Linux kernel source not configured - missing autoconf.h. Stop."
Super! This time I have to thank the openSUSE IRC community for helping me dig out the relevant fix by a very helpful Ubuntu community member.
Again, as the Ubuntu forums are far from reliable and also require signing-up to download files, I've mirrored the patch provided. I hope the author doesn't mind (the driver is GPL):
Installation is fairly simple too, pop it into the src directory for the driver, and run the command:
patch -p1 < AR81Family-linux-v1-22.214.171.124.patch
Then you can do the installation process as above (if you've already try that, run "make clean" first).
I hope this helps somebody else - it'll probably help me in a few months when I need to reapply it...