Monthly Archives: December 2014

I recently upgraded my mythbuntu installation from 12.04 to 14.04. For some reason the distribution upgrade tool failed on me. I had to upgrade manually by updating everything in /etc/apt/sources* to point to trusty instead of precise.

After a reboot I was surprised to find out that everything upgraded beautifully except for one thing – mythweb. When I tried to start Apache I was greeted with this lovely message:

My new job has a BYOD policy, which means I can use my personal phone for work use. Before I ascribed to their policy I wanted to make sure my phone was in pristine condition. I wrote earlier about how I rooted and flashed a custom ROM for my phone. This will explain how to un-do all of that and restore it to pristine factory condition.

I got my information from here, which is a great guide on how to do this. I will mirror the files mentioned there as it’s well known that XDA mirrors come and go.

I scratched my head for quite some time before I came across came across this post suggesting it’s a bad USB cable / port. Sure enough, I switched out the cable I was using with the official cable the phone came with, and it worked beautifully!

I recently got a new job which uses a VDI infrastructure. We don’t have individual workstations, but rather terminal into a central server which serves us individual desktops. One unfortunate side effect of this configuration is that f.lux (which I’ve written about before) doesn’t appear to do anything. Research suggests that f.lux must talk directly to display hardware to work – no remote desktops.

A co-worker suggested fiddling with the monitor’s color settings to try and reproduce what f.lux does. I hadn’t thought of that before!

It turns out my monitors have pre-built color temperatures, but the lowest they go is 5400k. My color temperature comfort level is more like 3400k, which as it turns out what most office lighting is.

The monitors allow me to manually select RGB percentages. The trick was translating 3400k (f.lux setting) to percentages of red, green, and blue. Searching Google for the RGB values of 3400k revealed this page, which had some helpful information. 3400k translates to the hex values #ffc184.

The last step was translating that hex to percentages. Googling “ffc183 in percentage rgb” revealed this link, which is what I wanted!

My mother’s laptop has been behaving very strangely lately. CPU usage suddenly would spike to 100% usage inexplicably. It seemed to happen more often when Firefox / Thunderbird were launched, but that wasn’t necessarily the case. The issue would often persist across reboots.

Even more confusing is that when running task manager, process explorer, or performance monitor they all reported 100% CPU usage and with a single process hogging the CPU – themselves! It seemed that whatever was the last process to execute was taking all CPU. It was truly baffling.

A suggestion on superuser.com was to remove the laptop battery and try again. They reported that as the magic bullet for their problem. I had my father remove and re-seat the battery (I was doing all of this remotely.) Magic! Everything worked normally again. Perhaps there was some sort of static electricity buildup causing problems. Truly bizarre.

Recently I tried to install the latest patch for Heroes of the Storm when I got a nasty error code 2600, Whoops! something broke.

Re-installing battle.net didn’t fix the issue. After much frustration I came across this post, which describes situations when you’re behind a caching proxy (which I am.)

I did as it directed, which is to disable the caching function of my proxy and delete anything Blizzard-related from my %temp% folder.

That did the trick. All is well now!

Update: I decided that rather than disabling caching / virus checkings completely I would create an exception in Sophos UTM web access policy. Thanks to the guidance from here I added the following exception:

Recently my blog went down (the ISP running it had downtime.) I wanted to see when it came back up. As a result I wrote a little Windows batch script to continually poll my address in order to do just that.

The script issues a query to the default DNS server as well as pings the address of the blog. I used both since sometimes in Windows a ping will simply use internal system cache, which may be wrong if the IP address hosting my blog changes (it’s address is dynamic.)

I use the /V argument to take out the first bit spit out from the nslookup command, namely the IP address of the nameserver being used.

A simpler version of the script only issues one ping, waits a second, and then repeats the command. This is different from doing ping -t because it forces ping to do a new lookup for the domain name, whereas ping -t only resolves the IP once, then just pings the IP address. That wouldn’t work in my case as the IP of the domain name changes when it comes back online.

My wife’s macbook pro started behaving strangely after upgrading to Yosemite from Mavericks. The initial upgrade went smoothly but over time certain applications began to quit working. The Pandora desktop client suddenly could never connect. Tunnelbick completely broke no matter what I did. Dnslookups all were fine but pings hung forever, eventually saying they couldn’t resolve a hostname.

It turns out that Yosemite changed the way Mac OSX resolves DNS records from mDNSresponder to dnsdiscoveryd. The issue I had only happened from and upgrade – clean installs didn’t have the issue

The fix for this madness, taken from here, is to remove a few network configuration files and reboot.

First, disconnect from any networks you’re connected to. Then, go to /Library/Preferences/SystemConfiguration/ and remove the following files (if they exist)

PCI passthrough is a great way to mix virtualization with bare metal hardware. It allows you to pass physical hardware to virtual machines. In order to do PCI passthrough you will need compatible hardware (a CPU and chipset that support it.) Intel’s nomenclature for this is VT-d; AMD’s is IOMMU. It’s difficult (although not impossible) to get consumer level hardware that supports this. It’s much easier to obtain with server grade hardware.

Why would you want to pass physical hardware to virtual machines? In my case, it’s to turn a single system into a super server. Instead of having separate physical systems for NAS, gaming, and TV recording (my three uses) you can have one physical system do all three. While this is possible with one single OS, it’s much easier to manage these functions if they are in their own separate OS (especially if you’re using appliance VMs such as FreeNAS.) PCI Passthrough allows you to get the best of both worlds – better security by isolating functions, easier backup/restore, and physical hardware access.

Citrix Xenserver 6.2 supports PCI passthrough beautifully. A great comprehensive guide on how to configure PCI passthrough can be found here.

Xenserver 6.2 no longer requires any configuration beforehand to get PCI passthrough to work. To pass a device to a VM all you need to do is obtain its the bus, device, function (B:D.F) via lspci, then pass that through to the VM.

The B:D.F of the above device (a network adapter) is 06:00.0. To then pass this device to a virtual machine we use the xe vm-param-set command with the other-config:pci= parameter, adding 0/0000: to the beginning of the B:D.F, then specifying the UUID of the VM in question.

Sometimes if you pass multiple PCI devices to a single VM only one of those devices is recognized by the VM. If that is the case, try passing the B:D.F of each piece of hardware in a different order

If you ever want to remove a hardware mapping to a VM, issue the following:

xe vm-param-clear param-name=other-config uuid=<UUID of VM>

There is still a case where you want to modify Xenserver’s configuration with regard to PCI passthrough. On occasion you will have hardware that you do not want the hypervisor to ever know about (in the above example, the hypervisor can use the hardware until you power on a VM that has passthrough enabled for it.)

In my case, I don’t want the hypervisor to ever see the storage controller I’m passing to my NAS VM. I found this out the hard way. If you don’t modify your xenserver configuration to ignore storage controllers that you then pass through to a VM, the entire hypervisor will completely lock up if you happen to reboot that VM. Why? Because when that VM reboots it releases the storage controller back to the hypervisor, which promptly enumerates and re-names all of its attached drives. It often leads to a case of re-naming /dev/sda, promptly “losing” the root device, and kernel panicking.

So, if you are passing things you never want the hypervisor to see, you need to modify its boot configuration to “hide” those devices from it. Edit /boot/extlinux.conf and append pciback.hide=(B:D.F) to the Linux command line, right after the splash parameter

vi /boot/extlinux.conf
<navigate to right after the word splash>
i
pciback.hide=(06:00.0)(01:00.0)
<esc> :wq
extlinux -i /boot

The above example excludes two devices. Multiple devices simply go next to each other in their own parenthesis, but the format is the same if you only passing a single device.

Reboot the hypervisor, and you are good to go. You can now pass hardware through to VMs to your heart’s content.