Mythweb broken after upgrading to Ubuntu 14.04

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:

* The apache2 configtest failed.
Output of config test was:
AH00526: Syntax error on line 30 of /etc/apache2/sites-enabled/mythweb.conf:
Illegal option AllowAll
Action 'configtest' failed.
The Apache error log may have more information.

It turns out Ubuntu 14.04 uses a different version of Apache with different syntax, which breaks the configuration. Thanks to this post I found the fix to be relatively easy:

sudo rm /etc/apache2/sites-available/mythweb.conf
sudo dpkg-reconfigure mythweb
sudo /etc/init.d/apache2 start

After that was done, all was well and upgraded.

Restore Verizon Galaxy S4 to factory firmware

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.

Here is the rundown:

  1. Download Samsung USB drivers from here and install them.
  2. Download ODIN 3.09 here (alternate)
  3. Download PIT file for the S4 here (alternate)
  4. Download full wipe stock firmware here (make sure you’ve backed up anything important) (alternate)
  5. Unzip everything into a common directory
  6. Run ODIN and flash back to factory
    1. Put your phone in ODIN mode by turning the phone off, then pressing and holding power and volume down at the same time. A message will appear, press volume up to confirm and enter ODIN mode.
    2. Plug your phone into USB and run ODIN on your PC. Make sure the odin log says Added!! If it doesn’t, drivers are not installed properly.
    3. Check AP and then press the AP button to specify the firmware file (wait a minute for md5 verification)
    4. Press the PIT button and select the PIT file downloaded
    5. Press start. It will take about ten minutes.
  7. Profit!


When I first tried to do this I soft bricked my phone. I was very confused because everything seemed to be going fine and then suddenly FAIL

<ID:0/003> sbl1.mbn
<ID:0/003> sbl2.mbn
<ID:0/003> sbl3.mbn
Complete(Write) operation failed.
<OSM> All threads completed. (succeeded 0 / failed 1)
<ID:0/003> Removed!!

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!

Manually reproduce flux on your monitor

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!

In short: 3400k in flux roughly equates to:

100% red
76% green
51% blue

Success! My eyes are much more comfortable now.

Troubleshooting high CPU usage in Windows 7

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.

My first thought, of course, was malware. An extensive scan via rootkit scanner, malware scanner, spyware scanner, and anti-virus revealed nothing. Observing running processes with process explorer and startup programs with autoruns revealed nothing suspicious. I installed all Windows updates, updated all typical applications with the help of ninite, and even ran sfc /scannow for good measure. The issue remained!

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 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.


Fix 2600 error

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 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:

Skipping: Authentication / Caching / Block by download size / Antivirus / Extension blocking / MIME type blocking / URL Filter / Content Removal / SSL scanning / Certificate Trust Check / Certificate Date Check
Matching these URLs: ^https?://([A-Za-z0-9.-]*\.)?blizzard\.com/

Use batch script to continually check site status

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.)

The script is below:

 nslookup | findstr "Address" | findstr /V
 ping -n 1
 timeout /t 3
goto loop

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.

 ping -n 1
 timeout /t 1
goto loop

Thanks to Stack Overflow for educating me on how to write a quick loop to emulate the Linux Watch command,  ping only once, and use an application similar to grep to clean up output.


Fix DNS issues after Yosemite upgrade

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)



After removing those files, reboot. That should fix your problem! (At least, it did for me.)

PCI passthrough with Xenserver 6.2

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.

<several lines deleted>
06:00.0 Ethernet controller: Atheros Communications AR8131 Gigabit Ethernet (rev c0)

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.

xe vm-param-set other-config:pci=0/0000:06:00.0 uuid=db4c64e1-44ce-f9f3-3236-0d86df260249

If the VM is running when you issue that command, make sure to shut down (not reboot) the VM, then start it up again.

To add multiple devices to the same VM, simply separate each B:D.F with a comma, like so:

xe vm-param-set other-config:pci=0/0000:06:00.0, 0/0000:07:00.0 uuid=db4c64e1-44ce-f9f3-3236-0d86df260249

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>
<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.