....... it's still going on!
Well, here in sunny Cambridgeshire, we've had the mother of all thunder storms. It started yesterday night (22nd July 2013) at about 23:30, and raged on until approximately 08:30 the next morning. I've never seen a thunder storm last so long, or crack so loudly.
This has caused me two problems. Firstly, I haven't slept a wink, and I get dreadfully grumpy when I don't sleep. Secondly, this caused a local power outage which meant that half the clocks in the house needed to be reset this morning, including the ruddy microwave, which requires a degree in quantum mechanics to operate.
Anyway! Not only did the outage kill power to my microwave, but also to my server, which from my previous post you'll know has already had me tearing my hair out. My server is all set to restart after a power failure, which it dutifully did, but it did not complete the boot process.
I don't have a monitor connected to my server, it's tucked away neatly out of sight and runs VortexBox quite happily, until today. I "borrowed" the 19" Flat TV from the bedroom and got to work.
I didn't want to see the following message:
Welcome to emergency mode
Oh, what fresh hell is this...!?
Above that not very welcoming message was a series of details relating to a File System Check (fsck). I've never had to enter maintenance mode within Linux before, and I count myself lucky indeed.
I did a little searching and found that one possible cause could be to do with an error in the /etc/fstab file. This rang a bell with me as I had indeed been messing with fstab whilst troubleshooting my Logical Volume issue. I entered my root password to enter Maintenance Mode and set to work.
[vortexbox]# nano /etc/fstab
Sure enough, there was the line I added last week:
UUID=DC9x1x-OEPu-uLAo-9zyr-nTIU-RmIi-Zjiob5 /root/usbtemp lvm2 default 0 0
I commented out the line, saved the file and restarted the server. With fingers crossed and with baited breath, the server restarted fine and was back to normal.
I'm sure there's a moral to this story, but I'm buggered if I know what it is.....
Tuesday, 23 July 2013
Monday, 15 July 2013
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
[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
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
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
[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...?
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)
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
Subscribe to:
Posts (Atom)