Tuxcoder Blog Posts

Ubuntu 12.04 Breaks XBox DVD IR Remote Dongle in LIRC

2013-01-15T00:00:00Z

I'm not sure why Ubuntu continues to break devices after every release, but it's something that seems to happen with increasing frequency. Because of this I try not to change my MythTV setup very often. However with Ubuntu 12.04 out, I decided it was time to upgrade. I then had the fun of working through two non-trivial bugs, this being one of them.

My understanding is that LIRC went through some type of driver re-architecture, and the ubiquitous XBOX IR dongle support got dropped along the way. Eventually I stumbled upon this awesome post by MrPlow that targeted the Natty release. Luckily it is still functioning in 12.04 Precise Pangolin. I'm going to reproduce all of the commands here for completeness.

sudo apt-get build-dep lirc
sudo apt-get install git dialog automake autoconf libtool
git clone git://lirc.git.sourceforge.net/gitroot/lirc/lirc
wget http://old.nabble.com/attachment/31787507/0/lirc_0.9.1_lirc_xbox_driver.patch
cd lirc/
patch -p1 <../lirc_0.9.1_lirc_xbox_driver.patch
vi drivers/lirc_xbox/lirc_xbox.c

Remove, or comment out the line #include <linux/smp_lock.h>.

Finally build the driver and install:

./autogen.sh
./configure -with-driver=userspace
cd drivers/lirc_xbox/
make
sudo make install

Then verify that your /etc/lircd/hardware.conf has the following line:
```
REMOTE_MODULES="lirc_dev lirc_xbox"
```
Reboot

That's all the steps I needed to perform. Just remember that if you ever install a new kernel, you'll likely have to re-run the compilation and install steps over again.

Firefox 17 Mousewheel Scroll Rate Fix

2012-12-04T00:00:00Z

It appears that the last update of of Firefox v17 on Ubuntu 12.10 changed the internal mousewheel scroll rate about:config names. This has the nice effect of breaking any custom scroll rate values.

Like me, you probably made this changes years ago, and are now struggling with a scroll rate designed for you grandmother.

The two values you want to adjust in about:config now are:

mousewheel.min_line_scroll_amount
general.smoothScroll.mouseWheel

Try setting min_line_scroll_amount between 60 and 70. At least on my system this gives me a reasonable scroll rate.

Finally, the smoothScroll.mouseWheel should allow for quick scrolling when either True or False. The effect is really a personal preference, so try both.

And a final tip, all of these changes should take effect in real time, so you don't need to restart Firefox.

Working with Time and Dates in Python

2011-09-14T00:00:00Z

When working with time and date values, Python provides more than one interface.

Module	Description
time	Low-level time methods. Supports `struct_time` format, simple date string IO, conversion to UNIX epoch time.
datetime	High-level date and time methods. This provides a proper interface for adding or subtracting time and dates. Many of the same methods from the time module are supported, but objects are not compatible between the two.

Until you spend some time with both modules, it will be a little unclear how to make the best use of each feature set. Here are a few examples that will demonstrate some of the available techniques.

Convert 'Naive' Datetime to Unix Epoch

This conversion works if you are working in your local time zone.

>>> from datetime import datetime
>>> import time
>>> time.time()
1316032256.260053
>>> now = datetime.now()
>>> int( time.mktime(now.timetuple()) )
1316032260

Convert 'Aware' Datetime to Unix Epoch

In a more advanced case, you might want to compute a Unix time value of a datetime that is outside of your local timezone. For this example 'US/Eastern' is not my local timezone.

>>> from datetime import datetime
>>> from calendar import timegm
>>> from pytz import timezone
>>> import time
>>> time.time()
1317696751.797751
>>> est = timezone('US/Eastern')            # non-local time zone
>>> now_naive = datetime.now()
>>> now_aware = datetime.now(tz=est)
>>> time.mktime(now_aware.timetuple())      # wrong, ignores TZ info
1317718351.0
>>> time.mktime(now_aware.utctimetuple())   # wrong, ignores TZ info
1317732751.0
>>> timegm(now.timetuple())                 # wrong, no TZ info set
1317660506
>>> timegm(now.utctimetuple())              # wrong, no TZ info set
1317660506
>>> timegm(now_aware.timetuple())           # wrong, expects UTC time
1317682351
>>> timegm(now_aware.utctimetuple())        # correct
1317696751

The results show that even though now_naive and now_aware are created at the same time, there is only one valid method to convert now_aware back to the correct Unix time value.

Find Last Occurrence of a Specific Day

This examples demonstrates how to get the date of "Last Sunday" or "Last Tuesday". This could be easily modified to other relative dates.

from datetime import datetime,timedelta
import time

def last_day(day_name):
   days_of_week = ['sunday','monday','tuesday','wednesday',
                   'thursday','friday','saturday']
   target_day = days_of_week.index(day_name.lower())
   delta_day = target_day - datetime.now().isoweekday()
   if delta_day >= 0: delta_day -= 7 # go back 7 days
   return datetime.now() + timedelta(days=delta_day)

Output of the above method is shown when current date was Wednesday, 9/14/2011:

>>> datetime.now()
datetime.datetime(2011, 9, 14, 10, 45, 55, 958258)
>>> for d in ['sunday','monday','tuesday','wednesday',
...           'thursday','friday','saturday']:
...     last_day(d)
...
datetime.datetime(2011, 9, 11, 10, 47, 1, 851355)
datetime.datetime(2011, 9, 12, 10, 47, 1, 851425)
datetime.datetime(2011, 9, 13, 10, 47, 1, 851446)
datetime.datetime(2011, 9, 7, 10, 47, 1, 851466)
datetime.datetime(2011, 9, 8, 10, 47, 1, 851486)
datetime.datetime(2011, 9, 9, 10, 47, 1, 851506)
datetime.datetime(2011, 9, 10, 10, 47, 1, 851526)

Hosting Python WSGI Apps Using Dreamhost

2011-09-08T00:00:00Z

This article is a setup guide for creating a working Python WSGI container inside of the standard Dreamhost environment. This should be very helpful to anyone trying to build a Python webapp using one of the many WSGI frameworks.

First thing to know, is that Dreamhost is not going to support this config for you, and they don't make any guarantee that it work work in the long term. Therefore, if you want a bullet proof system, your best bet is to get a virtual server on which you can fully control the OS stack.

In my case, I experimented with the Flask framework, which is considered pretty basic. This is not a bad thing, since it is easy to get something working quickly, and has some great documentation.

Dreamhost Documentation

Dreamhost has setup a Passenger WSGI wiki page that describes the overall process. You should read over this to get some additional background on how all the various pieces fit together. After you read/skim that, come back here.

Virtualenv Setup (Optional)

Before you begin, make sure to log into your Dreamhost SSH account.

ssh user@machine.dreamhost.com

Your first step should be to create a Python virtualenv environment. This creates a local Python environment that will allow to install and upgrade modules that are not currently installed on the hosted machine.

virtualenv ~/env
. ~/env/bin/activate    # activate the new 'env' environment
pip install virtualenv --upgrade

Note

After this step, every time you need to use or modify the environment, you have to source the . ~/env/bin/active script to configure your shell.

Domain Setup

You'll need a registered domain name to run this configuration on. I don't recommend testing this out on a production domain, however it should be OK to create a new sub-domain for testing.

Using the web interface, go to the Domains → Manage Domains. From the Web Hosting column, select Edit.

The image above shows the necessary changes:

Append /public to the default Web Directory. This is where static files can be served from.
Enable Passenger, by checking the box.

Don't forget to click Save when you are finished.

Python WSGI Setup

Now the final step is to add a script into your domain root directory. These will be executed on each HTTP request by the server. This is where we will delegate our Python app to handle the request and return the necessary response data.

The name of the script must be passenger_wsgi.py. It does not have to be executable. Depending on your WSGI framework, you might need to update a few things, as mine is currently targeted at the Flask framework.

Note

The job of this script is to import and create a Python variable to your WSGI app named application.

passenger_wsgi.py

import sys, os

DEBUG   = True
ROOT    = os.path.dirname(os.path.abspath(__file__))
INTERP  = '/home/USERNAME/env/bin/python'  # fix 'USERNAME'

sys.path.insert(1,ROOT)
if sys.executable != INTERP:
   os.execl(INTERP, INTERP, *sys.argv)

from myapp import app as application

if DEBUG:
   application.debug=True
   from werkzeug_debugger_appengine import get_debugged_app
   application = get_debugged_app(application)

Let me go over a few of the details:

The first main code block updates your sys.path define. This allows the execution environment make use of any virtualenv packages you have installed.
The next block pulls in your WSGI application. In this case, it's called myapp and sitting in the domain root directory. As long as its somewhere in your Python path, it should be fine. Notice that it imports the app as application.
The final block is a trick for people using Flask and/or Werkzeug. This provides a work-around for the runtime debugger on Dreamhost. See the next section for additional setup.

Warning

Do not run a production system in debug mode. It very likely will not be secure.

Important

The WSGI application container is not restarted for every request. When you make changes to your app, you should reset the session by running touch tmp/restart.txt. This will work in most cases, but if not, the other option is to run pkill python.

Enabling the Werkzeug Debugger

If you plan to do any active development on the Dreamhost side, this step will simplify your efforts. Werkzeug comes with a really nice debugging engine, but it does not work with the Dreamhost configuration by default.

For example, if you have a simple Python coding error in your app, it will result in the following:

Default Dreamhost WSGI HTTP response on Python error.

In this mode, you're out of luck. The only option is to startup a local server where you can go back and test the app. In some cases it might be a big effort just to replicate the bug.

With the Werkzeug Debugger enabled and patched, you'll get a much nicer output:

Patched Dreamhost WSGI HTTP response on Python error.

The patched version will not give you any interactive UI, but you get a pretty nice stack trace, file name and line number where the error occurred.

There are few steps for enabling this:

Download and install the patch source code from github.

mkdir ~/src
cd ~/src
git clone https://github.com/nshah/werkzeug-debugger-appengine.git
cd werkzeug-debugger-appengine
python setup.py install

If you followed all the previous steps, thats it. If not, you have to go back and edit your passenger_wsgi.py script to enable the patch. At the end of the file, modify the application reference:
```
application.debug=True
from werkzeug_debugger_appengine import get_debugged_app
application = get_debugged_app(application)
```

Ubuntu 11.04 Adobe Flash Player Display Errors

2011-05-26T00:00:00Z

If your Flash Player is glitching in Firefox and displaying annoying solid blocks that hide the flash media, try this fix:

add-apt-repository ppa:sevenmachines/flash
apt-get update
apt-get install flashplugin64-installer

via Ubuntu 11.04 x64 and flickering Flash fix

Reclaim Wasted Hard Disk Space on Ext Volumes

2011-05-11T00:00:00Z

If you're running any of the Ext file systems, you can get back a lot of free space by running a simple command.

sudo tune2fs -m 0 /dev/sdX

By default, Ext systems reserve 5% of space on the file system in case it is need by the OS. This command will set the reserved system space to 0%.

For non-root volumes, keeping this reserved space around is not necessary. For a 1TB volume, this could account for up to 50GB of wasted space.

How To Install a Minimal Ubuntu Server OS on a VirtualBox Instance

2010-03-27T00:00:00Z

Most people are not aware that you can install a baseline Ubuntu system in under 1GB of space. This makes it great for a headless system, such as an embedded mini-ITX board. Even for a desktop, you might want to start with a bare-minimum Ubuntu package set and then customize the rest. All this can be accomplished very quickly, and easily using a few tips. For this post, I'll explain how to use Ubuntu Karmic 9.10 and VirtualBox to create a small virtual Linux server.

To start off this tutorial, make sure you have a Ubuntu (or similar) desktop system with VirtualBox configured and installed correctly.

Download one of the Ubuntu mini.iso Installer Image.
[Optional] Configure apt-cacher-ng on your local system. This will speed up the installation process, if you want to start over at any point.
Create a new VirtualBox machine with the following configuration:
- Hard Disk: 1GB or larger
- Base memory: 256MB to 512MB
- Network Mode: Bridged Adapter
After creating the system, assign the mini.iso image you downloaded as the media for the emulated CD drive.
Now start the virtual machine. It should boot the Ubuntu install boot prompt. Select the Command Line option to continue to the installer.
From the installer, continue following the default options:
- Set the system host name.
- Choose your local Ubuntu mirror.
- [Optional] Set HTTP Proxy (when running apt-cacher-ng): http://installer-host:3142/
When you reach the disk partition step, use the following options:
- Choose the Manual method.
- Verify there is a single root partition filling the entire virtual disk.
- Optionally, choose to enable noatime on the partitions.
- Ignore any warnings about missing swap space, and confirm you wish to erase the entire device. After this the base system will continue to install.
The software package will finish and the grub boot loader should install. Before restarting the system, make sure to unmount the ISO file in the virtual drive.

From this point forward, the virtual machine can now boot and allow you to log in as the user you configured during the install process.

Share Files Over BitTorrent Using a Local Tracker and Client in Linux

2009-05-24T00:00:00Z

Everyone has heard of the BitTorrent protocol. It's widely used to quickly distribute large files with a low-bandwidth connection. There are also a lot of other features in BitTorrent that make it superior to either HTTP or FTP. For example, pseudo archives, built-in checksums, partial-download resumes, and send/receive bandwidth capping.

This post will show you how to share your personal files using BitTorrent tools that come standard with Ubuntu Linux (Jaunty 9.04). This article will cover the following steps:

Configuring and running a local "tracker" server.
Building torrent files from your personal file(s) you wish to share.
Auto-seed and share your active torrent files.

Configure a Local BitTorrent Tracker Server

Before creating a torrent file, you should have an active tracker server configured and running. It is perfectly acceptable to use a public tracker, but running a personal tracker lets your clients connect over a private network (192.168.*). Also, if your torrent files are for commercial use, you likely do not want trust the reliability of your service to a third party.

The BitTorrent tracker server must be accessible to all your clients. Also, it must have either a static DNS or IP address so your clients can always contact it.

From the command line, install Bittornado, start the tracker, and verify it is running:

$ sudo apt-get install bittornado
$ bttrack --port 6969 --dfile ~/.bttrack/dstate --logfile ~/.bttrack/tracker.log --nat_check 0 --scrape_allowed full
$ firefox http://localhost:6969

The bttrack command will start a tracker that allows clients behind NAT connections. Connecting to the tracker port in FireFox will display a page with known torrents and status of each one.

Finally, be aware that with this configuration, the server will register all torrent files it is notified of. So, potentially someone could use this tracker for their own torrents. If you are on private network this may not be an issue, or you can use additional options to restrict the torrents allowed on the tracker:

--allowed_dir $HOME/btfiles --parse_dir_interval 10 --allow_get 1

These additional arguments to bttrack will force the tracker to only use files located the the ~HOME/btfiles directory. Remember, if you use these options, your torrents must be manually copied into this directory before the tracker will accept seeding requests.

Advanced Bttrack Config and Settings

Simplify the tracker startup with a simple shell script:

$ cat <<EOF > bin/bttrack.sh
#!/bin/bash

PORT=6969
DFILE="$HOME/.bttrack/dstate"
LFILE="$HOME/.bttrack/tracker.log"
# GET="--allowed_dir $HOME/btfiles --allow_get 1 --parse_dir_interval 10"
OPTS="--nat_check 0 --scrape_allowed full"

mkdir -p $HOME/.bttrack
bttrack --port $PORT --dfile $DFILE --logfile $LFILE $GET $OPTS
EOF

$ chmod 755 bin/bttrack.sh

You may want to add bttrack to your systems init.d startup scripts. Start with a copy of the default service skeleton file from /etc/init.d/skeleton:

$ sudo cp /etc/init.d/skeleton /etc/init.d/bttrack
$ sudo vi /etc/init.d/bttrack

Replace the top section of the /etc/init.d/bttrack file using the example code below. Notice that the --dstate and --logfile values have been changed to a more standard location.

PATH=/usr/sbin:/usr/bin:/sbin:/bin
DESC="BitTorrent protocol tracker"
NAME=bttrack
DAEMON=/usr/bin/$NAME
DAEMON_ARGS="--dfile /var/run/$NAME/dstate --logfile /var/log/$NAME.log
   --port 6969 --nat_check 0 --scrape_allowed full"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

do_start()
{
 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
  || return 1
 start-stop-daemon --start --background --make-pidfile --quiet --pidfile $PIDFILE \
      --exec $DAEMON -- $DAEMON_ARGS \
  || return 2
}

Create a Torrent File

The next step is to create one or more torrents files to provide the necessary information to begin seeding files inside of a BitTorrent Client. The following command is not the only method you can use. The other options for creating torrents is using a graphical client, such as Deluge or Transmission. I prefer the command line, since it is more concise:

$ sudo apt-get install bittornado
$ btmakemetafile --piece_size_pow2 SIZE http://URL.COM:PORT/announce SOURCE --target OUTPUT.torrent

SIZE [OPTIONAL]: The torrent's "piece" size as a power of 2, where a "piece" is the smallest transferable unit of data. For example, 512KB (19) and 1MB (20). If not defined, this value is selected automatically. For fast connections, use a larger value such as 4MB (22).
http://URL.COM:PORT/announce: The address of the tracker and port number. The address can either be a DNS name or IP number.
SOURCE: The location of source directory or list of file(s) to add to the torrent.
OUTPUT.torrent [OPTIONAL]: The output name of the torrent file. Changing the name after creating the torrent file will break some BitTorrent clients, so set the name hear. If you leave this value empty, the torrent file will be named using the <strong>SOURCE</strong> name.
--announce_list LIST [OPTIONAL]: If your tracker has more than one DNS or IP, use this optional argument to set all tracker addresses. Make sure to duplicate the primary announce address, http://URL.COM:PORT/announce, in this list as well. The list can be "," separated for equal tiered trackers, or use "|" separator to indicate secondary trackers. See the man page for more details.

Seeding and Sharing Torrent Files

After you've created the torrent files for seeding, the final step is to start them from any BitTorrent client. If you need to seed files for an extended period of time, I recommend using rTorrent inside of a screen session. This allows you to run the client in the background, and pull-up the text-based GUI at any time.

The following steps will create an rTorrent configuration file that will automatically load torrents from a target directory and begin seeding:

$ cat <<EOF > ~/.rtorrent.rc
check_hash = no
session = ~/.rtorrent
directory = /data/torrents
schedule = watch_directory,5,5,load_start=/data/torrents/autostart/*.torrent
schedule = untied_directory,5,5,stop_untied=
EOF
$ sudo apt-get install rtorrent screen
$ screen rtorrent

rTorrent should be running in the current terminal. If you are not familiar with screen, here are a few keyboard shortcuts for navigation:

<Ctrl-a> ?: Show screen's help
<Ctrl-a> d: Detach the screen session
<Ctrl-a> k: Kill current screen session
<Ctrl-a> c: Create a new shell window in screen
<Ctrl-a> n: Show next window
<Ctrl-a> p: Show previous window

If you close the screen session, you can reconnect with the command "screen -r".

After launching rTorrent, it is now possible to start seeding the torrents.

Move (or create a symbolic link to) the torrent data into rTorrent's "download" directory. The default download directory is defined in the rtorrent.rc file.
Notice that in the rtorrent.rc file, it also specified the "watch" directory. Place the new torrent files in the "watch" directory, and they will be picked-up by rTorrent.
Go back to the rTorrent GUI, and verify that the torrent is being re-hashed and seeded properly.
Copy or e-mail the *.torrent files you have created to anyone that you want to share your files with.

Mounting Unknown RAID+LVM Volumes Step-by-Step

2009-05-02T00:00:00Z

Every time your system boots, startup scripts will handle all disk mounting tasks. This is good, yet unfortunate if you ever run in to problems, because you're going to need to know how to get things up without the help of the scripts. On my systems, I run a combination of LVM volumes on top of multiple RAID arrays. This provides data integrity and future flexibility to add more space as needed, and makes recovery very complicated.

There are two cases where you will eventually need to know how this all works. The most likely case is recovering from a boot failure, in which you are relatively familiar with the configuration. An even more difficult case is mounting a set of unknown drives with a RAID/LVM configuration. Keep reading and I'll explain how you can handle even the hardest case like a pro.

Warning

If there is a chance you will be mounting two or more LVM Volume Groups with identical names, then read the warning at end before continuing.

After installing all the drives into the system, verify they are detected in /dev/sd*:

$ ls /dev/sd*
/dev/sda   /dev/sdb   /dev/sdc   /dev/sdd   /dev/sde   /dev/sdf   /dev/sdf3
/dev/sda1  /dev/sdb1  /dev/sdc1  /dev/sdd1  /dev/sde1  /dev/sdf1  /dev/sdf4
/dev/sda2  /dev/sdb2  /dev/sdc2  /dev/sdd2  /dev/sde2  /dev/sdf2

Find out which partitions of those are mounted:

$ df -lhx tmpfs
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/lvm_vg0-root
                       10G  3.7G  6.4G  37% /
/dev/mapper/lvm_vg0-home
                      160G   83G   78G  52% /home
/dev/md0               99M   16M   79M  17% /boot

This output doesn't directly indicate what partitions are being used. Instead it indicates two LVM volumes; /dev/mapper/lvm_vg0-root, /dev/mapper/lvm_vg0-home and one RAID array; /dev/md0. The next steps will reduce this info to the physical partitions.

Lookup the two LVM volumes lvm_vg0-root and lvm_vg0-home to determine the LVM volume group (VG):

$ sudo lvdisplay | grep 'VG Name'
  VG Name                lvm_vg0
  VG Name                lvm_vg0

The LVM VG, lvm_vg0, maps to one ore more physical volumes:

$ sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/md1
  VG Name               lvm_vg0
  PV Size               297.99 GB / not usable 3.25 MB
  Allocatable           yes
  PE Size (KByte)       4096
  Total PE              76285
  Free PE               32765
  Allocated PE          43520
  PV UUID               mD6jat-SvPv-dOop-P3qZ-T7zC-r8ke-xSYRSj

This output shows us that the LVM physical volume (PV) is using /dev/md1.

Now, lookup md0 (from the top step) and md1 devices:

$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid10 sde2[0] sdd2[1]
      312466688 blocks 64K chunks 2 far-copies [2/2] [UU]

md0 : active raid1 sde1[0] sdd1[1]
      104320 blocks [2/2] [UU]

OK, so the final answer is that md1 is using partitions: sde2, sdd2 and array md0 is using partitions: sde1, sdd1.

Now, create list of unmounted partitions, by filtering out the mounted partitions:

$ ls --color=none /dev/sd* | grep [0-9] | egrep -v 'sde2|sdd2|sde1|sdd1'
/dev/sda1
/dev/sda2
/dev/sdb1
/dev/sdb2
/dev/sdc1
/dev/sdc2
/dev/sdf1
/dev/sdf2
/dev/sdf3
/dev/sdf4

To find RAID partitions, every device can be scanned for volume UUID value:

$ mdadm --examine /dev/sda1 | grep UUID
           UUID : ae9a1594:27fc3cec:ceff8456:d50a26a6

With a little more work, all the unmounted devices can be scanned in a single pass:

$ ls --color=none /dev/sd* | grep [0-9] | egrep -v 'sde2|sdd2|sde1|sdd1' | xargs -i sh -c 'sudo mdadm --examine {} | grep -H --label={} UUID'
/dev/sda1:           UUID : ae9a1594:27fc3cec:ceff8456:d50a26a6
/dev/sda2:           UUID : cd72d060:e1139a47:8d379926:979de13e
/dev/sdb1:           UUID : ae9a1594:27fc3cec:ceff8456:d50a26a6
/dev/sdb2:           UUID : 2eb0a293:e7705a2f:8d379926:979de13e
mdadm: No md superblock detected on /dev/sdc1.
/dev/sdc2:           UUID : 29d74ba3:2dff5d1d:e1635e97:4ded1971
mdadm: No md superblock detected on /dev/sdf1.
/dev/sdf2:           UUID : 29d74ba3:2dff5d1d:e1635e97:4ded1971
/dev/sdf3:           UUID : 2eb0a293:e7705a2f:8d379926:979de13e
/dev/sdf4:           UUID : cd72d060:e1139a47:8d379926:979de13e

It looks like every device is part of a RAID array except /dev/sdc1 and /dev/sdf1.

Manually sort the list in the last step by the UUID values. Every matching UUID value indicates a single RAID array. Here is what your list should look like:

/dev/sda1:           UUID : ae9a1594:27fc3cec:ceff8456:d50a26a6
/dev/sdb1:           UUID : ae9a1594:27fc3cec:ceff8456:d50a26a6
-----
/dev/sda2:           UUID : cd72d060:e1139a47:8d379926:979de13e
/dev/sdf4:           UUID : cd72d060:e1139a47:8d379926:979de13e
-----
/dev/sdb2:           UUID : 2eb0a293:e7705a2f:8d379926:979de13e
/dev/sdf3:           UUID : 2eb0a293:e7705a2f:8d379926:979de13e
-----
/dev/sdc2:           UUID : 29d74ba3:2dff5d1d:e1635e97:4ded1971
/dev/sdf2:           UUID : 29d74ba3:2dff5d1d:e1635e97:4ded1971

Using these value, assemble each RAID array. The /dev/md* is not important as long as you choose a value that does not currently exists in the system.:

$ sudo mdadm --assemble /dev/md2 /dev/sda1 /dev/sdb1
mdadm: /dev/md2 has been started with 2 drives.

$ sudo mdadm --assemble /dev/md3 /dev/sda2 /dev/sdf4
mdadm: /dev/md3 has been started with 2 drives.

$ sudo mdadm --assemble /dev/md4 /dev/sdb2 /dev/sdf3
mdadm: /dev/md4 has been started with 2 drives.

$ sudo mdadm --assemble /dev/md5 /dev/sdc2 /dev/sdf2
mdadm: /dev/md5 has been started with 2 drives.

Now check that all the previous steps by printing the mdstat file:

$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md5 : active raid10 sdc2[0] sdf2[1]
      488281984 blocks 64K chunks 2 far-copies [2/2] [UU]

md4 : active raid10 sdb2[0] sdf3[1]
      244094080 blocks 64K chunks 2 far-copies [2/2] [UU]

md3 : active raid10 sda2[0] sdf4[1]
      244094080 blocks 64K chunks 2 far-copies [2/2] [UU]

md2 : active raid1 sdb1[0] sda1[1]
      104320 blocks [2/2] [UU]

md1 : active raid10 sde2[0] sdd2[1]
      312466688 blocks 64K chunks 2 far-copies [2/2] [UU]

md0 : active raid1 sde1[0] sdd1[1]
      104320 blocks [2/2] [UU]

unused devices: <none>

When you are happy with the device mappings, update the /etc/mdadm/mdadm.conf file:
```
$ sudo sh -c 'mdadm --detail --scan >> /etc/mdadm/mdadm.conf'
```
After this step, edit the file to remove any old entries.

Important

Because of a bug in mdadm, change the "metadata" version from "00.90" to "0.90".

Now, with the RAID arrays active, scan for LVM volumes. First the physical volumes (PV):

$ sudo pvscan
  PV /dev/md4   VG lvm_vg0   lvm2 [232.79 GB / 0    free]
  PV /dev/md3   VG lvm_vg0   lvm2 [232.79 GB / 956.00 MB free]
  PV /dev/md5   VG lvm_vg0   lvm2 [465.66 GB / 274.60 GB free]
  PV /dev/md1   VG lvm_vg0   lvm2 [297.99 GB / 127.99 GB free]
  Total: 4 [1.20 TB] / in use: 4 [1.20 TB] / in no VG: 0 [0   ]

Next the volume groups (VG):

$ sudo vgdisplay
  --- Volume group ---
  VG Name               lvm_vg0
  System ID
  Format                lvm2
  Metadata Areas        3
  Metadata Sequence No  58
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               1
  Max PV                0
  Cur PV                3
  Act PV                3
  VG Size               931.23 GB
  PE Size               4.00 MB
  Total PE              238395
  Alloc PE / Size       167859 / 655.70 GB
  Free  PE / Size       70536 / 275.53 GB
  VG UUID               yLjVr3-BKkp-BW33-QIsh-rpZX-byL7-bzF2Xg

  --- Volume group ---
  VG Name               lvm_vg0
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               297.99 GB
  PE Size               4.00 MB
  Total PE              76285
  Alloc PE / Size       43520 / 170.00 GB
  Free  PE / Size       32765 / 127.99 GB
  VG UUID               138ikB-v1Z0-381g-Qvi8-dWN2-pgJ7-namuLh

Warning

Be very careful if your system indicates identically named LVM Volume Groups (shown above). LVM will NOT let you mount the volumes from one or all of the groups. You must resolve the name conflict before continuing.

Additionally, you will not be able to rename LVM VGs if either the old or new VG has mounted logical volumes! If one of your VG's LV's is the root volume, you will have to resort to a live-boot CD.

A VG can be renamed with the following command:

$ vgrename vg0-old vg0-new

Finally, mount the new volumes and update your /etc/fstab like normal.

Better Google Keyboard Shortcuts using Greasemonkey

2009-03-05T00:00:00Z

Caution!

This post should only be used for historical reference. I am no longer supporting the Greasemonkey script at this time.

I used to be one of those "simple" folk using Google the normal way. This has got to be one of the most aggravating experiences. Even more so when looking for answers on an obscure topic. This is because Google is tricky to use, and getting results always takes multiple attempts. Even with a good search, it's likely the best match is buried a few pages in. The action of typing, scrolling, mousing, then clicking a few links, only to "rinse and repeat" 15 seconds later is enough to inflame my wrist with an RSI in under 20 minutes. After a full day of work, this becomes hazardous to your health.

You might be thinking that this kind of thing doesn't bother you. Well, just wait until you try Google with optimized keyboard shortcuts. You will never want to go back, I promise!

Since sometime back in 2008, I have been using the Google Experimental Keyboard Search feature to the point that it is almost second nature. With it, I can bring up a search and get 10 result pages loading in the background, in under 5 seconds. The speed comes from the fact that you can search and open selected results without ever having to leave the keyboard. Try it out for yourself.

You can easily enable this feature, but there are a few minor annoyances you have to deal with:

The "stickiness" of the feature is tricky and I frequently find that the Google search page eventually resets back to the default mode. The only way to solve this it seems is to go back and re-join the experiment.
There is no way to skip forward or back in the search results. Essentially you are stuck to the first page of results. This actually used to not be an issue, but sometime around late 2008 the J/K keys were disabled from jumping to the next and previous result pages.

Greasemonkey Script

Ok, so what is the solution to the bugs? The answer is Greasemonkey. If you haven't heard of Greasemonkey, it is an add-on for Firefox users (you do use Firefox right?) to tweak any web page you download with custom JavaScript code.

I wrote a custom Greasemonkey script that will always enable the Google Experimental Keyboard Search feature. This script also solves the other two bugs listed above.

Setup

Using Greasemonkey and user scripts is easy.

If you do not have Greasemonkey, install it from the Mozilla Add-on page. Restart Firefox.
Install my Google Search Enhanced Keyboard Navigation user script with the Installer Link.

Usage

After the script is installed, the Google search result page will have a selection arrow on the left-hand side. The arrow indicates the active link that can be opened.

The following keyboard commands can control the page navigation:

Key	Action
H	Opens the previous results page.
J	Selects the next result.
K	Selects the previous result.
L	Opens the next results page.
O	Opens the selected result.
<Enter>	Opens the selected result.
/	Puts the cursor in the search box.
<Esc>	Removes the cursor from the search box.

Happy Googling!