A few months ago I lost my main workstation that also doubled as my backup server, my web development server, the white noise generator and over all everything machine for my home network.

On that system I run Arch Linux, like do for all of my systems except for my daughters which runs Edubuntu 8.04. I had all of my internal hard drives setup on LVM2 (Logical Volume Manager) partitions. When that system went down I was a shocked. To this day my beloved system still isn’t up and working correctly. So, in the mean time I was able to gather some old PC parts I had sitting in boxes and build out my “official” storage solution.

My storage solution is built up using a dual Pentium III 700 Mhz system with 256MB of RAM, a 4 port SATA PCI card, four 1 Terabyte hard drive & a 20Gig system drive. Over all it is a clunker besides the 4TB of hard drive space. But you are hear to read about my storage system & to know how to re-access your stranded LVM2 partitions.

Step 1: Move the functional hard drive(s) into a system that can read the LVM mappings (This means you have all the proper kernel modules installed & corresponding LVM software). Now if you have multiple drives that make up your LVM mappings, then you need to be able to have all drives accessible in one system. For me I only had one large drive mapped out to different volumes. I was able to add my drive to my storage server by using an external USB case.

Step 2: Once that the drive(s) is physically accessible in new system, you need to know what are the Physical Volume(s) (PV), Volume Groups (VG) & Logical Volume(s) (LV). To obtain this information run the following commands with root privileges & take note of the VG & LV names.

Step 2a: Show the list of available physical volumes by running su -c ‘pvdisplay’ .

[testuser ~]$ su -c 'pvdisplay'
--- Physical volume ---
 PV Name               /dev/sdf3
 VG Name               VolGroup00
 PV Size               150.56 GiB / not usable 2.66 MiB
 Allocatable           yes
 PE Size               4.00 MiB
 Total PE              38542
 Free PE               14222
 Allocated PE          24320
 PV UUID               YSFO73-x3IY-wNTg-CUND-e3wT-7Whb-yLk4iO

 ...

Step 2b: Show the list of available volume groups by running su -c ‘vgdisplay’ .

[testuser ~]$ su -c 'vgdisplay'
  --- Volume group ---
  VG Name               VolGroup00
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  25
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               150.55 GiB
  PE Size               4.00 MiB
  Total PE              38542
  Alloc PE / Size       24320 / 95.00 GiB
  Free  PE / Size       14222 / 55.55 GiB
  VG UUID               oGX7wj-BLCd-6M8Q-3hPc-8wVN-r7jR-3Z6dgU

  ...

Step 2c: Show the list of available logical volume by running su -c ‘lvdisplay’ .

[testuser ~]$ su -c 'lvdisplay'
  --- Logical volume ---
  LV Name                /dev/VolGroup00/Root
  VG Name                VolGroup00
  LV UUID                lnKn4G-BH0d-tn38-KJuz-o1ci-afVD-ncm5Zn
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                15.00 GiB
  Current LE             3840
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

  --- Logical volume ---
  LV Name                /dev/VolGroup00/Home
  VG Name                VolGroup00
  LV UUID                l7oeK7-YKNV-KS2c-fXvO-hXpe-hIQP-LsqFxR
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                80.00 GiB
  Current LE             20480
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:3

  ...

Step 3: Now that you have the volume group name you need to make the volume(s) accessible on the new system. That is done by exporting (aka removing) the historical volume mappings, importing the volume group into the new system & activating the volume group.

Step 3a: Export the volume group with su -c ‘vgexport <replace with volume group>’

[testuser ~]$ vgimport VolGroup00
 Volume group "VolGroup00" is not exported

Step 3b: Importing the Volume Group using pvscan & then su -c ‘vgimport <replace with volume group’

[testuser ~]$ su -c 'pvscan'
 PV /dev/sdf3    is in exported VG VolGroup00 [150.55 GiB / 55.55 GiB free]
 PV /dev/md0    VG RaidArray    lvm2 [2.73 TiB / 1.17 TiB free]
 Total: 2 [897.09 GiB] / in use: 2 [897.09 GiB] / in no VG: 0 [0   ]

[testuser ~]$ su -c 'vgimport VolGroup00'
  Volume group "VolGroup00" successfully imported

Step 3c: Activating the Volume Group by using su -c ‘vgchange -ay ‘

[testuser ~]$ su -c 'vgchange -ay VolGroup00'
  2 logical volume(s) in volume group "VolGroup00" now active

Now that you have imported & activated the volume group,  you should be able to list the available logical volume drive mappings under /dev/mapper/.

ls -l /dev/mapper/

Step 4: The next step is to mount the logical volumes to check the integrity of the data. I would also suggest doing an file system check (fsck) of the partitions on logical volume before mounting them.

That it. You are ready to resume using your LVM partitions on your new system.

- Ken

LVM resource used for this post:

• HOW-To http://www.tldp.org/HOWTO/html_single/LVM-HOWTO/#recipemovevgtonewsys
• Helpful link: http://www.linuxquestions.org/questions/linux-software-2/remounting-a-lvm-partitioned-disk-on-new-box-136693/

The other day I had an issue with my main Virtual Machine (VM) image at work. Inside the VM runs a version of Windows XP SP3 that I use for application automation testing and manual testing. The issue I was having was my VM was out of virtual disk space.

On my work laptop I run 64bit Arch Linux and the virtual machine software I run is VirtualBox version 3.0.2. VirtualBox has server me well over the past few year, but the one issue I have always run into with running VMs is disk space constraints. I typically give a VM the least amount of space it will need to run the operating system and the essential applications that I will need for testing and/or development. For Windows XP that is usually 8GB and for Windows Vista it is about 10 to 12 gigs.

So as I mentioned, I was running out of space on my main VM. I bitched about it on identica/twitter and received a great response to my complaining. Excid3 mentioned that I should create a new larger virtual disk and then use dd to clone the original virtual disk over to the new virtual disk. Once I read that it was like getting slapped in the face. I was shocked and ashamed that I never thought of doing that in the past.

The last time I looked into cloning a virtual disk, I did a google search and most of the suggestions mention creating a second virtual disk, but then using something like Symantec’s Ghost, PartImage or Clonezilla to perform the task of duplicating the disk data structure. I tried this solution once before and it ended in disaster and a waste of time.

Now with new insight and a fresh idea [something I should have thought of before] I set up to add a bit of extra space to my main dev/test VM. First I created a new 10GB virtual disk using the VirtualBox Virtual Media Manager. While creating the virtual disk I was downloading the ISO image of SystemResuceCD. Once the virtual disk was created, I went into the settings of my VM and added the new virtual disk as a secondary IDE drive. I then set the VM to point to the SystemRescueCD ISO and boot from that ISO image. Once I was booted into the SystemRescueCD environment I executed the following command:

dd if=/dev/sda of=/dev/sdb bs=64

I let the duplication process run it’s course, which took about 15 to 20 minutes. Plus, since I am a bit paranoid, I was running the following bash script from a terminal on the physical system from inside the folder that holds my virtual disk to make sure the virtual disk was being created:

while x=0
  do
  ls -lh *.vdi
  df -h | grep home
  sleep 2
done

Once the dd process was complete I shut down the VM, released the SystemRescueCD ISO image, then I changed the order of the primary virtual disk to the new disk and booted the VM to make sure the all was good. Once I was certain the new virtual disk  was good, I shut down the VM, re-mounted the SystemRescueCD ISO to the VM and booted the VM to re-enter the SystemRescueCD environment. Once inside, I ran a startx to bring of a graphical interface for running gparted (Gnome Partition Editor). I then used gparted to expand the unused portion of the virtual disk from 8GB to 10 GB. Once that was completed, I rebooted the VM & unmounted the ISO. Windows run a CHKD on the expanded virtual disk and my VM came to life with an addition 2 gigs of space.

Thanks to Excid3 I now have a new & quicker process for expanding the virtual disk size constrains I set upon myself.

-Ken

Update 2009-09-22: This post has been out of date for a while. I will write up and new post soon.

I am an Arch Linux user and have recently been getting more and more involved in microblogging using the Free Software based system called identi.ca. Identi.ca is base on the Laconica open microblogging framework. In order to have a richer experience using a microblogging web service such as identi.ca, it helps to have some type of a desktop client. There are Free as in Beer microblogging clients that run on top of Adobe Air, but I wanted a Free as in Speech microblogging application that runs on natively on Linux. The current application of choice is Gwibber Gwibber is an open source microblogging client for GNOME created by Ryan Paul (a.ka. segphault). Gwibber supports Twitter, Jaiku, Facebook, Pownce, Identi.ca and other popular social web services.

If you are using a Linux distribution from one of the more “Popular” distributions,  the installation of Gwibber isn’t all that complicated. All you have to do is point to the identified repositories for your distribution and install Gwibber. But, for a rolling release distribution like Arch Linux, the process is a bit harder. The reason for the difficulty is that Gwibber is tailored towards the libraries that are currently available in the non rolling release cycle Linux distributions like Fedora & Ubuntu.

Here are the steps I used to install Gwibber on Arch Linux.

Tools needed:

1. Terminal Prompt
2. Super User (aka Root) privileges
3. Internet Access (that is a given, you are reading this blog post )

Dependencies:

1. Libwebkit 1.0.1 (as of this writing libwebkit is at version 1.1.0)
2. pywebkitgtk-svn between rev 88 to 100
3. Current version of all other dependencies (‘dbus-python’ ‘gnome-python’ ‘python-notify’ ‘python-simplejson’ ‘python-egenix-mx-base’ ‘python-distutils-extra’ ‘pil’ ‘python-feedparser’ ‘pyxdg’ ‘gnome-python-desktop’)

Installing Libwebkit:

Obtaining Libwebkit version 1.0.1

Libwebkit is generally available from the extra repository provided by Arch Linux. The only issues is, Gwibber is written against version 1.0.1 of libwebkit and not version 1.1.0 which is provided by the extra repository. To obtain an older version of an Arch package you can either look in the local cache on your system in

    /var/cache/packman/pkg/

and see if the libwebkit-1.0.1-1-{architecture type}.pkg.tar.gz exists. If it does not exist, then you will have to pull the package from one of Arch repo archives. I used the archive provided by Schlunix.org. Here are links to the i686 & x86_64 packages

Once you have obtained the libwebkit 1.0.1 package, lets make sure that no other version of libwebkit or webkitgtk is installed on your system.

    Run:
     $ pacman -Qs webkit

If results are returned

    Example:
        $ pacman -Qs webkit
        local/libwebkit 1.1.0-0.41121
        an opensource web content engine, derived from KHTML and KJS from KDE

remove the installed package

    Run:
        su -c 'pacman -Rd libwebkit'

Install libwebkit 1.0.1

    Run:
        su -c 'pacman -U {path to libwebkit}/libwebkit-1.0.1-1-{architecture type}.pkg.tar.gz'

Installing pywebkitgtk-svn:

Currently pywebkitgtk is only available from the AUR or directly from the pywebkitgtk web site. Source based packages from the AUR work well to get the latest version of from the development repository, but to get Gwibber to work correctly we need a specific revision from the svn repository. To accomplish this, `makepkg` has an option called “–holdrev”. This option prevents automatic version bumping from development centric PKGBUILDs. In other words, makepkg will use the specified revision identified in the PKGBUILD file.

Semi-automated install using Yaourt:

Steps:

    Run:
        yaourt -S --holdver pywebkitgtk-svn

    Type a `y` when prompted to "Edit the PKGBUILD".

    Change line 5 from pkgver=57 to pkgver=100. Save the file and close your editor.

    Type an `n` when prompted to "Edit the PKGBUILD" a second time.

    Type a `y` when asked "Continue the building of pywebkitgtk-svn ? [Y/n]"

    After the package is built
    Type a `y` when prompted to "Continue installing pywebkitgtk-svn? [Y/n]".

Manual install:

Download the pywebkitgtk-svn tar ball from the Pywebkitgtk-svn AUR page.

Uncompress the tar ball:

    Run:
        tar xzf pywebkitgtk-svn.tar.gz

Editing the PKGBUILD File:

CD into pywebkitgtk-svn

    Run:
        cd pywebkitgtk-svn/

Edit the PKGBUILD file with one of the following commands:

    vi PKGBUILD
        or
    gedit PKGBUILD
        or
    nano PKGBUILD

Change line 5 from pkgver=57 to pkgver=100. Save the file and close  your editor

Build pywebkitgtk-svn:

    Run:
        makepkg --holdver

Install the pywebkitgtk-svn package:

    Run:
        su -c 'pacman -U pywebkitgtk-svn-100-1-{architecture type}.pkg.tar.gz'

Installing Gwibber from bzr using Yaourt

Gwibber is not currently in the mainline repositories of Arch Linux. However, you can get the files needed to build Gwibber from this AUR page and then build package manually or by using application Yaourt.

Semi-automated Install using Yaourt:

    Run:
        yaourt -S gwibber-bzr

    Type `y` when prompted to "Edit the PKGBUILD" for gwibber-bzr.

    Edit `depends` values on line 11 from 'pywebkitgtk>=1.1' to 'pywebkitgtk'

    Type `n` when prompted to "Edit the PKGBIULD" for gwibber-bzr

    Type `n` when prompted to "Edit gwibber.install"

    Type `y` when prompted to "Continue the building of gwibber-bzr ? [Y/n]"

    Allow the install of any remaining dependencies and select `n` to Edit any of the remaining PKGBUILD files.

    Type `y` when prompted to "Continue installing gwibber-bzr? [Y/n]"

Manual Install:

Download the gwibber-bzr tar ball from the Gwibber-bzr AUR page.

Uncompress the tar ball:

    Run:
        tar xzf gwibber-bzr.tar.gz

Editing the PKGBUILD File:

CD into gwibber-bzr

    Run:
        cd gwibber-bzr/

Edit the PKGBUILD file with one of the following commands:

    vi PKGBUILD
        or
    gedit PKGBUILD
        or
    nano PKGBUILD

    Edit `depends` values on line 11 from 'pywebkitgtk>=1.1' to 'pywebkitgtk'.
    Save the file and close  your editor

Build gwibber-bzr:

At this point you have to make sure that you have all the dependencies of gwibber installed or the next step will fail. You can run the following step to see what dependencies you don’t have installed. Then you can install them using pacman, yaourt or if needed manually build the packages from their respective AUR page.

    Run:
        makepkg

Install the gwibber-bzr package:

    Run:
        su -c 'pacman -U gwibber-bzr-272-1-{architecture type}.pkg.tar.gz'

Starting Gwibber:

Using Gnome:

    Click Applications -> Internet -> Gwibber Microblogging Client

Using the terminal or a launcher:

    enter gwibber

Creating an account in Gwibber:

    On the menu bar click Account -> Create -> (select your microblogging service of choice)

Happy Denting, Tweeting or whatever other verb describes your microblogging actions.

-ks

UPDATE: Thanks to Usul’s comment. I have updated this How-To to not edit the gwibber-bzr package and change the pywebkitgtk dependency.