My old computer recently died. It was old enough that I didn’t spend a lot of time trying to fix it. I took the opportunity to get a new one. I have my drives set up so that my “home” partitions are in an LVM volume group. I wanted to move that VG to the new drive on the new machine. This is what worked well for me.
Assuming you have the old drive connected to the new machine the simplest way seemed to be adding the physical volume on the new disk to the VG on the old disk then moving all of the extents that exist in the VG on the old disk to the new. Finally I removed the old disk from the VG.
Here are the steps I took, I will explain each after the code.
vgchange -ay pvcreate /dev/sda5 vgextend MyVG /dev/sda5 vgmove -v /dev/sdb3 /dev/sda5 vgreduce MyVG /dev/sdb3
1: That started up the MyVG volume group on the old HDD. Although it’s not shown above I mounted it and looked around to make sure the files were there and everything looked good.
2: I allocated the partition on the physical disk in the new machine (sda5 for me) to LVM.
3: Here I added the LVM physical volume (pv) created above to the MyVG volume group that up to this point resided only on the old HDD. So now instead of a 100G “disk” only on the 1 HDD I now had a 360G “disk” that actually spanned 2 physical disks.
4: This moved all of the physical extents of MyVG that resided on the old HDD (sdb3 for me) to physical extents on the new HDD. -v just gave me a 15 second rolling counter of the progress. It took about 25 minutes to move 100G or so.
5: This removed the old HDD from the MyVG. Everything is now on the same volume group it has always been on but that VG now resides fully on the new HDD now.
In case you are wondering why I didn’t just keep the old HDD I moved from a desktop machine to a laptop.

Tags: configuration, Linux, lvm, lvm2, pvcreate, Shell, vgchange, vgextend, vgmove, vgreduce
I found myself editing a configuration file (multiple actually) at work today and ran into an issue. The config file looked similar to:
Var_1=A Var_2=B Var_3=C ... Var_146=ABC Var_147=ABD
As it happened I needed to remove one of the lines at position 23. The program that reads/uses these config files has an issue if there is a break in the sequence. So after removing the line with “Var_23″ I needed to shift all of the numbers in following lines down by 1. Here is how I accomplished that.
In vim I put my cursor on the 24 in the line that now follows the “Var_22″ line and performed the following commands:
qa CTRL-X j q 125@a
Here is what happened broken down by line:
1: Here I am recording a macro (q) with the name or identifier of ‘a’. Note you will probably see some indication in the last line that you are in “recording” mode.
2: CTRL-X decrements the number under the cursor. Since I am on the 24 that decrements it to 23.
3: I move down 1 line and now the cursor is on the 25 in the next line.
4: I quit recording the macro. I know have a named (a) macro that includes the commands “decrement the number under the cursor and move down one row”.
5: I perform that named (a) macro 125 times. Now realistically I only needed to do it 123 times. It didn’t seem to matter that I used 125 but YMMV. The first line after the last line I wanted to change was a blank line so I assume the macro quit when the CTRL-X failed. You are probably better off using the exact number.
And there you have it. I successfully renumbered all of the variables below the line I deleted to be in sequence.

Tags: automation, configuration, replace, Shell, variable, vi
You can get Refractor (Prism addon) to work in Ubuntu (and probably other unices) with one added step to the install process.
After installation you need to right click the icon and choose Properties.
In the Command box change “firefox”, for me it was “/usr/lib/firefox-3.0.4/firefox”, to xulrunner.
Tags: configuration, firefox, Linux, prism, refractor, ubuntu, xulrunner