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/

To all my fellow WordPress users, please make sure you update to version 2.8.4 if you are on version 2.8.3. There is a documented exploit out in the wild that can reset your admin password.

You can get full details about the exploit on Darknet.org.uk. Here is a link to the post.

I had to pimp this nerdcore rap video by daleochase called “Coder Girl”. I like the idea of the song, but I don’t like the usage of all the Crapple products. But, baggers can’t be choosers when it comes to freely distributed music.

Have a look & listen . . .

You can follow daleochase on twitter & get the lyrics to his this song here.

Visit his web site @ http://syntaxbeats.squarespace.com/

- Ken

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