Windows, hey? Who'd have it...!?

I long for the day when I'm in a job where I can abandon Windows as the Enterprise Operating System of choice, and switch to a more stable, more reliable and generally quicker Operating System. With more firms moving to the likes of Ubuntu and Mac OSX, and Cloud Services becoming more prevalent I can't see any reason why Windows needs to be the de facto standard for Enterprises any more.  This being said, I am unfortunately stuck with it.

The 'it' being Windows 7, which I'll admit is my second favourite Windows OS of all time (Windows 98SE sits at the number one spot), and has been a solid OS since it's release in 2009.  I found a very strange quirk in Windows 7 a few months ago after an update.  I'm afraid I don't know which of the updates was involved as they're all managed by my employers IT team.  This update somehow removed all of the default entries in the Windows Sounds dialog box.

This meant that all of the default Windows beeps, clangs and donks were gone. Not only that, but all of the Microsoft Outlook mail notification sounds and the Microsoft Lync ringtones as well.  This is quite an inconvenience when you need to explain to your boss why you haven't been answering the phone or any e-mails.

Being the tinkerer that I am, I checked the Windows Sound dialog from Control Panel and found an entirely empty list.

What the...?

The IT Team mentioned above were a tad stumped and could offer no real solution short of a rebuild of the laptop. As much as I understand the many benefits of a full rebuild: the speed increase for one, and the resulting tidiness of the desktop, I didn't much fancy the idea of going through the usual headache of backup and restore jobs and the inevitable items which get forgotten.  I thanked the team for their time, and decided to go it alone. Thanking my lucky stars that my employer trusts me with administrative rights on my machine.

After a few minutes of Googling, I managed to identify that the Sound Dialog draws its listing from a Registry Key, namely:

HKEY_CURRENT_USER\AppEvents\Schemes\Apps\.Default\

When navigating to this Key in my own registry, I could see that it was devoid of entries.

Rather than scouring the internet looking for a dodgy registry file to download, I decided to fire up VirtualBox, and using my Windows 7 DVD I installed a fresh OS onto a new Virtual PC.  Once this was up and running I configured a Shared Folder to enable me to share files between my PC and the new virtual machine.

Navigating the registry in my fresh Windows 7 OS, I exported the above registry key to the Shared Folder.  Back on my broken PC I found the exported registry file and imported it into my registry. A quick reboot later, and all my sounds were back, as good as new.

If you don't have the time, inclination or know-how to try this yourself, you can download the registry file I exported from Google Drive.

A Tale of two Logical Volumes

I have been using VortexBox 2.2 for a while now, and I have to say that it is absolutely fantastic. 

No only is it a centralised SAMBA server which stores all of my music and movies (which would have been enough for me), but it is also a DLNA server which allows me to watch my movies from my Xbox 360, as well as a CD AutoRipper and a SubSonic Server which means I get all my music wherever I am.

So taken am I with this lovely little box of mine, that I decided to treat it to an upgrade. A nice 500GB drive to expand my movie and music collection.  This is where came a little undone.

I didn't want to run the new HDD as an external USB drive or as a secondary drive, which would have been a simple solution, but I thought I'd take the opportunity to start from scratch. After considerable fiddling in the early days of my VortexBox I had no idea whether I had broken anything or tweaked it a little too far (this would not have been the first time ladies and gents).

Instead, I swapped the old drive for the new, and grabbed my VortexBox 2.2 CD. Merrily I reinstalled the VortexBox with the default install option and went to make a cup of tea.

Tea drunk, and VortexBox installed, I got the basic settings configured. Hostname, IP Address, etc.  The next step would be to transfer all the files from the old drive to the new. I connected the drive to VortexBox, and began:

Log into the box
ssh root@vortexbox

Check the disks to find their designations

[vortexbox]# parted -l
[-------Output suppressed-------]
Model: WDC WD25 00BB-55GUC0 (scsi)
Disk /dev/sdb: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2097kB  1049kB                     bios_grub
 2      2097kB  526MB   524MB   ext4         ext4  boot

 3      526MB   250GB   250GB                      lvm

Ah ha! There it is, /dev/sdb3 at 250GB in size, that must be the one!

Now, where am I at the moment?

[vortexbox]# pwd
/root

Okay, here we go, make a temp directory...

[vortexbox]# mkdir usbtemp

check it's there...

[vortexbox]# ls -l
total 60
-rw------- 1 root root  3149 Jul 13 15:10 anaconda-ks.cfg
-rw-r--r-- 1 root root 32107 Jul 13 15:10 install.log
-rw-r--r-- 1 root root  9217 Jul 13 15:07 install.log.syslog
-rw-r--r-- 1 root root     0 Jul 13 14:13 install_vortexbox.log
-rw-r--r-- 1 root root    76 Jul 13 14:13 musicutil.conf
drwxr-xr-x 7 root root  4096 Jul  5 20:40 usbtemp

and mount the drive:

[vortexbox]# mount /dev/sdb3 /root/usbtemp
mount: unknown filesystem type "LVM2_member"

Errrrrrm....... OK! What's going on...!? 

Now, a little research showed me that the VortexBox default installation sets up a GUID Partition Table (GPT), rather than using an MBR-based partition table. The differences can be found here.  This means that the volume containing all of my data is contained within a Logical Volume, not a physical one. Now the benefits of handling volumes in this way are many, far too many for me to go into, but the crux of the matter is that I had unwittingly put myself in a position where I could not mount my old HDD on my new VortexBox.
FYI! If you don't want to use GPT, you can specify this when running the install cd.  Highlight the installation option you want from the Grub Menu, and press the TAB key on your keyboard. Then add a space to the end of the line and type nogpt. Press Enter to begin the install.

Now, back to the action!
Unwilling to be beaten by my own foolishness, I trudged on and searched the internet until my fingers were sore. What was apparent, was that I now had two logical volume groups with the same name in the same system.  Since the VortexBox install is merely a CD, and doesn't know what I was up to, it used the same standard naming format for the Volume Group, VolGroup, and all the Logical Volumes lv_root, lv_swap and lv_storage.

The fix!
Firstly, I needed to scan the physical disks to find all of the Volume Groups which were available:
[vortexbox]# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup" using metadata type lvm2
  Found volume group "VolGroup" using metadata type lvm2

Right, now which one's which...?

[vortexbox]# lvscan
  inactive            '/dev/VolGroup/lv_storage' [212.34 GiB] inherit
  inactive            '/dev/VolGroup/lv_root' [19.53 GiB] inherit
  inactive            '/dev/VolGroup/lv_swap' [512.00 MiB] inherit

OK, so they're in there somewhere, but they're inactive (we can tell this from the size of the storage volume at nealry 250GB, it should be the one). OK. How can I make them active? I can't mount the VolGroup name to mount it, as that's already in use by the new installation. I'll need to rename the Volume Group to be able to interact with it, but can't just rename VolGroup, coz it won't know which one.

Luckily, you can rename a Volume Group by using the UUID, or Universally Unique IDentifier.  But what is the UUID?

[vortexbox]# vgs -v

    Finding all volume groups

    Finding volume group "VolGroup"

    Finding volume group "VolGroup"

VG          Attr   Ext    #PV #LV #SN VSize   VFree VG UUID

VolGroup    wz--n- 32.00m   1   3   0 465.25g    0  9K4XZ2-6GLM-OZGS-izaS-HBCy-lRLf-WrTj56

VolGroup    wz--n- 32.00m   1   3   0 232.38g    0  USivDb-2Okr-om29-gG74-fsxI-BUCa-dF5jef

Here we can see that the vgs -v command has found two Logical Volumes, and is displaying the associated UUIDs. From  this example, you can see that my new HDD is 500GB, with a Volume size of 465.25g, and my old drive which was a 250GB has a Volume size of 232.38g. So that means the volume group I want to rename is on the bottom line with a UUID of USivDb-2Okr-om29-gG74-fsxI-BUCa-dF5jef.

Brilliant!

The next thing I need to do then, is change the Volume Group name. The following command fixed it for me:

[vortexbox]# vgrename USivDb-2Okr-om29-gG74-fsxI-BUCa-dF5jef VolGroupOLD

  Volume group "VolGroup" successfully renamed to "VolGroupOLD"

Outstanding!

I now have two Volume Groups , one is the newly installed VolGroup, and the one from my old drive is now named VolGroupOLD.

So now, we need to rescan the disks for volume groups

[vortexbox]# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroupOLD" using metadata type lvm2
  Found volume group "VolGroup" using metadata type lvm2

Nice one, so the two Volume Groups can now be identified, so lets scan the Logical Volumes:

[vortexbox]# lvscan
  inactive            '/dev/VolGroupOLD/lv_storage' [212.34 GiB] inherit
  inactive            '/dev/VolGroupOLD/lv_root' [19.53 GiB] inherit
  inactive            '/dev/VolGroupOLD/lv_swap' [512.00 MiB] inherit
  ACTIVE            '/dev/VolGroup/lv_storage' [438.72 GiB] inherit
  ACTIVE            '/dev/VolGroup/lv_root' [19.53 GiB] inherit
  ACTIVE            '/dev/VolGroup/lv_swap' [512.00 MiB] inherit

We can now see that the system is able to tell the difference between the volumes now. So, how to activate the OLD volumes?  vgchange -ay will activate all known volume groups on the system.

[vortexbox]# vgchange -ay
 3 logical volume(s) in volume group "VolGroup" now active

 3 logical volume(s) in volume group "VolGroupOLD" now active

This is great news indeed, if you run lvscan again, you will see that they are all now marked as ACTIVE.

[vortexbox]# lvscan
  ACTIVE            '/dev/VolGroupOLD/lv_storage' [212.34 GiB] inherit
  ACTIVE            '/dev/VolGroupOLD/lv_root' [19.53 GiB] inherit
  ACTIVE            '/dev/VolGroupOLD/lv_swap' [512.00 MiB] inherit
  ACTIVE            '/dev/VolGroup/lv_storage' [438.72 GiB] inherit
  ACTIVE            '/dev/VolGroup/lv_root' [19.53 GiB] inherit
  ACTIVE            '/dev/VolGroup/lv_swap' [512.00 MiB] inherit

All that's left to do, is mount the volume to my temporary directory...

[vortexbox]# mount /dev/VolGroupOLD/lv_storage /root/usbtemp
[vortexbox]# mount
[-------Output surpressed-------]
/dev/mapper/VolGroup-lv_storage on /storage type ext4 (rw,relatime,data=ordered)

/dev/mapper/VolGroupOLD-lv_storage on /root/usbtemp type ext4 (rw,relatime,data=                                                                                                                     ordered)

And that's your lot. Once the drive was mapped, all I had to do was copy the content from the temporary location (/root/usbtemp) to the new storage location (/storage).

I hope this helps someone out  there, and don't forget to un-mount your drive once you're done.

[vortexbox]# umount /dev/mapper/VolGroupOLD-lv_storage