Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

LVM Problem -- Please Help

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


tdmyth at yahoo

Aug 14, 2006, 11:45 AM

Post #1 of 16 (3487 views)
Permalink
LVM Problem -- Please Help

Greetings all. I am hoping that you can, once again, help me out. Thanks for all previous assistance. :-)

This weekend, I added a new SATA drive to my Myth backend. It appeared to add into the volume group without any problem, though I did not get it to the point where the space was accessible. I planned to further research that problem; however, before I solved that one, I inadvertently created a new problem. The new drive was designated as /dev/sda.

I was suspicious about the new drive because it was clicking loudly, so I shut down cleanly and disconnected it. Yes, I then rebooted without the SATA drive connected thereby "breaking" my volume group. I did not know that when I re-connected and booted up again, the volume group would remain broken.

The system reports a missing physical volume of UUID ### and then reports an unknown physical volume with the same UUID. I have spent 5 hours trying to recover this. It seems as though the tools / commands are there, but I don't know how to do it (or something else is wrong). I am hoping that someone can give me a suggestion on how to re-link the UUID for the SATA drive to the volume group. Thanks, in advance! Here are some details:

[root [at] mythserve ~]# pvdisplay
Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
--- Physical volume ---
PV Name /dev/hda5
VG Name VolGroup00
PV Size 66.12 GB / not usable 0
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 16926
Free PE 0
Allocated PE 16926
PV UUID 317l2C-oay1-TWFG-5NTX-XJS3-vLal-Xh5bBL

--- Physical volume ---
PV Name /dev/hdb
VG Name VolGroup00
PV Size 298.09 GB / not usable 0
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 76311
Free PE 0
Allocated PE 76311
PV UUID nfLxS1-0u3t-5Zr9-57iu-1oZe-Bkkd-75SERQ

--- Physical volume ---
PV Name unknown device
VG Name VolGroup00
PV Size 232.88 GB / not usable 0
Allocatable yes
PE Size (KByte) 4096
Total PE 59617
Free PE 225
Allocated PE 59392
PV UUID fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv

[root [at] mythserve ~]# vgdisplay
Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
Couldn't find all physical volumes for volume group VolGroup00.
Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
Couldn't find all physical volumes for volume group VolGroup00.
Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
Couldn't find all physical volumes for volume group VolGroup00.
Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
Couldn't find all physical volumes for volume group VolGroup00.
Volume group "VolGroup00" doesn't exist

[root [at] mythserve ~]# pvcreate -u fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv /dev/sda
Device /dev/sda not found.

[root [at] mythserve ~]# vgcfgrestore -tnVolGroup00 /dev/VolGroup00
Test mode: Metadata will NOT be updated.
Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
Couldn't find all physical volumes for volume group VolGroup00.
Restore failed.



---------------------------------
Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta.


drescherjm at gmail

Aug 14, 2006, 1:31 PM

Post #2 of 16 (3383 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

> [root [at] mythserve ~]# pvcreate -u
> fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv /dev/sda
> Device /dev/sda not found.
>
?? Confused ?? Is the SATA (/dev/sda) disk working?

John
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


tdmyth at yahoo

Aug 14, 2006, 3:52 PM

Post #3 of 16 (3401 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

>> Greetings all. I am hoping that you can, once again, help me out. Thanks for
>> all previous assistance. :-)
>>
>>This weekend, I added a new SATA drive to my Myth backend. It appeared
>> to add into the volume group without any problem, though I did not get it to
>> the point where the space was accessible. I planned to further research that
>> problem; however, before I solved that one, I inadvertently created a new
>> problem. The new drive was designated as /dev/sda.
>>
>> I was suspicious about the new drive because it was clicking loudly, so I
>> shut down cleanly and disconnected it. Yes, I then rebooted without the
>> SATA drive connected thereby "breaking" my volume group. I did not know
>> that when I re-connected and booted up again, the volume group would
>> remain broken.
>>
>> The system reports a missing physical volume of UUID ### and then reports
>> an unknown physical volume with the same UUID. I have spent 5 hours
>> trying to recover this. It seems as though the tools / commands are there,
>> but I don't know how to do it (or something else is wrong). I am hoping that
>> someone can give me a suggestion on how to re-link the UUID for the SATA
>> drive to the volume group. Thanks, in advance! Here are some details:
>>
>>[root [at] mythserve ~]# pvdisplay
>> Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
>> Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
>> --- Physical volume ---
>> PV Name /dev/hda5
>> VG Name VolGroup00
>> PV Size 66.12 GB / not usable 0
>> Allocatable yes (but full)
>> PE Size (KByte) 4096
>> Total PE 16926
>> Free PE 0
>> Allocated PE 16926
>> PV UUID 317l2C-oay1-TWFG-5NTX-XJS3-vLal-Xh5bBL
>>
>> --- Physical volume ---
>> PV Name /dev/hdb
>> VG Name VolGroup00
>> PV Size 298.09 GB / not usable 0
>> Allocatable yes (but full)
>> PE Size (KByte) 4096
>> Total PE 76311
>> Free PE 0
>> Allocated PE 76311
>> PV UUID nfLxS1-0u3t-5Zr9-57iu-1oZe-Bkkd-75SERQ
>>
>> --- Physical volume ---
>> PV Name unknown device
>> VG Name VolGroup00
>> PV Size 232.88 GB / not usable 0
>> Allocatable yes
>> PE Size (KByte) 4096
>> Total PE 59617
>> Free PE 225
>> Allocated PE 59392
>> PV UUID fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv
>>
>>[root [at] mythserve ~]# vgdisplay
>> Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
>> Couldn't find all physical volumes for volume group VolGroup00.
>> Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
>> Couldn't find all physical volumes for volume group VolGroup00.
>> Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
>> Couldn't find all physical volumes for volume group VolGroup00.
>> Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
>> Couldn't find all physical volumes for volume group VolGroup00.
>> Volume group "VolGroup00" doesn't exist
>>
>>[root [at] mythserve ~]# pvcreate -u fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv /dev/sda
>> Device /dev/sda not found.
>>
>>[root [at] mythserve ~]# vgcfgrestore -tnVolGroup00 /dev/VolGroup00
>> Test mode: Metadata will NOT be updated.
>> Couldn't find device with uuid 'fxlccO-4li0-nmyD-9avZ-Vc60-GGWX-jUhqOv'.
>> Couldn't find all physical volumes for volume group VolGroup00.
>> Restore failed.
John Drescher <drescherjm [at] gmail> wrote: Date: Mon, 14 Aug 2006 17:56:33 -0400
From: "John Drescher" <drescherjm [at] gmail>
To: Tom+Dale <tdmyth [at] yahoo>
Subject: Re: [mythtv-users] LVM Problem -- Please Help

>
> Well, it was working (despite the loud clicking) before I shut down and
> disconnected it. After booting up with the drive re-connected, it
> appears to be running physically, but the "Device /dev/sda not found."
> error was confusing to me as well. I assume that this is why the other
> commands are not working. Should linux have picked up the /dev/sda
> on boot once it was re-connected, despite my earlier mistake of b
> ooting once without it connected?
>
Spinning is not enough for a drive to work. To me it sounds like you
have a fatal drive head crash where one of the read/write heads have
hit the drive platter itself (normally the heads float on a very fine
layer of air just above the platter but not actually in contact) which
causes physical damage to the heads and the dirve platters. If the
damage is so severe the heads will not read anything.

John
Thanks for your responses, John. I apologize about replying directly instead of to the list--I need to pay attention to the "To:" line. :-)

Considering the clicking sound, I realize that the drive may have fatally crashed; however, it was operating until I disconnected it. I guess I'd just like some confirmation on these questions:

1) Is the error about not finding /dev/sda a definitive reason as to why the other commands failed (pvcreate -u... & vgcfgrestore -tn ...)? It seems to me that the drive needed a successful pvcreate in order to be added to the volume group, but I confess that I don't remember precisely how things transpired. So if linux doesn't see it right away, does that mean it's dead?

2) If the drive was not dead, should linux have picked up the /dev/sda on boot once it was re-connected, despite my earlier mistake of booting once without it connected?

3) If the drive is okay, and /dev/sda were being recognized, how would I go about re-linking the UUID to the physical volume?

4) Can an identical replacement drive be put in and given the UUID in order to recover data from the rest of the logical volume?

Thanks again to anyone who can assist!


---------------------------------
Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta.


chris at cpr

Aug 14, 2006, 11:26 PM

Post #4 of 16 (3379 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

On Mon, Aug 14, 2006 at 03:52:19PM -0700, Tom+Dale wrote:
> >> I was suspicious about the new drive because it was clicking loudly, so I
> >> shut down cleanly and disconnected it.

This can be caused by a lot of problems, not all of which are
fatal. Since it's a new drive you just added to your machine, the
power supply has to be at least considered. If the clicking sound
is only once every 1 or 2 seconds then it could be caused by the
drive power-cycling. Try unplugging *all* of your other hard
drives (so the machine won't try to boot) and see if the clicking
goes away. If so then you need to buy a bigger power supply.
Another cause of clicking is a failure of the drive's controller
card. On my old Western Digital drives that usually resulted in a
click rate of around 4Hz. If the clicking is very spread out or
doesn't start right away when the power is turned on then it could
be a thermal issue.

> >> The system reports a missing physical volume of UUID ### and then reports
> >> an unknown physical volume with the same UUID.

I use mdadm instead of lvm, but the rules are probably similar: if
you specify an actual device name for an array component then the
array will not recognize that component if the device name is
changed. The trivial work-around in mdadm is to change the config
file so that it searches for components using only the uuid.

> 1) Is the error about not finding /dev/sda a definitive reason as to why the
> other commands failed (pvcreate -u... & vgcfgrestore -tn ...)? It seems to me
> that the drive needed a successful pvcreate in order to be added to the volume
> group, but I confess that I don't remember precisely how things transpired. So
> if linux doesn't see it right away, does that mean it's dead?

To answer the first part of that question: yes. If Linux did not
find a device at /dev/sda then almost any command that refers to
/dev/hda will fail. As for the last part: no. Just because Linux
didn't see the drive doesn't mean it's dead. There are lots of
reasons why Linux might not see a drive, ranging from BIOS settings
to missing kernel modules.

> 2) If the drive was not dead, should linux have picked up the /dev/sda on boot
> once it was re-connected, despite my earlier mistake of booting once without it
> connected?

Yes. Assuming the drive is in fact not dead and that you're still
running the same kernel (with SATA support loaded) and the cables
are all correct, then you should be able to see it mentioned in
/var/log/messages as part of the boot messages.

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


tdmyth at yahoo

Aug 15, 2006, 6:01 AM

Post #5 of 16 (3370 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

chris [at] cpr wrote: On Mon, Aug 14, 2006 at 03:52:19PM -0700, Tom+Dale wrote:
> >> I was suspicious about the new drive because it was clicking loudly, so I
> >> shut down cleanly and disconnected it.

This can be caused by a lot of problems, not all of which are
fatal. Since it's a new drive you just added to your machine, the
power supply has to be at least considered. If the clicking sound
is only once every 1 or 2 seconds then it could be caused by the
drive power-cycling. Try unplugging *all* of your other hard
drives (so the machine won't try to boot) and see if the clicking
goes away. If so then you need to buy a bigger power supply.
Another cause of clicking is a failure of the drive's controller
card. On my old Western Digital drives that usually resulted in a
click rate of around 4Hz. If the clicking is very spread out or
doesn't start right away when the power is turned on then it could
be a thermal issue.

> >> The system reports a missing physical volume of UUID ### and then reports
> >> an unknown physical volume with the same UUID.

I use mdadm instead of lvm, but the rules are probably similar: if
you specify an actual device name for an array component then the
array will not recognize that component if the device name is
changed. The trivial work-around in mdadm is to change the config
file so that it searches for components using only the uuid.

> 1) Is the error about not finding /dev/sda a definitive reason as to why the
> other commands failed (pvcreate -u... & vgcfgrestore -tn ...)? It seems to me
> that the drive needed a successful pvcreate in order to be added to the volume
> group, but I confess that I don't remember precisely how things transpired. So
> if linux doesn't see it right away, does that mean it's dead?

To answer the first part of that question: yes. If Linux did not
find a device at /dev/sda then almost any command that refers to
/dev/hda will fail. As for the last part: no. Just because Linux
didn't see the drive doesn't mean it's dead. There are lots of
reasons why Linux might not see a drive, ranging from BIOS settings
to missing kernel modules.

> 2) If the drive was not dead, should linux have picked up the /dev/sda on boot
> once it was re-connected, despite my earlier mistake of booting once without it
> connected?

Yes. Assuming the drive is in fact not dead and that you're still
running the same kernel (with SATA support loaded) and the cables
are all correct, then you should be able to see it mentioned in
/var/log/messages as part of the boot messages.

Thanks for the help, Chris. I had not mentioned earlier that this is a new motherboard and power supply, too. I have checked the BIOS at boot, and learned that the SATA drive does not show up unless I probe for it. I know that is different than when it was installed the very first time. Also, the probe returns what must be a guess, because it is incorrectly identifying the drive. When it was installed on Friday, the system recognized it correctly with the drive model number and size whereas now it comes up with something else entirely. Looking at the boot messages, I see that the _volume_ reports a failure to mount, but I don't see the drive mentioned.
>>
>> 3) If the drive is okay, and /dev/sda were being recognized, how would I go
>> about re-linking the UUID to the physical volume?
>>
>> 4) Can an identical replacement drive be put in and given the UUID in order
>> to recover data from the rest of the logical volume?
>>
>>
I have made arrangements to RMA this drive (NewEgg really has excellent customer service). So my other questions weigh heavily on my mind (i.e., will I lose ~200GB of data from the still functioning drives that were part of this LVM? Or will I be able to put in an identical, functioning replacement and give it a UUID that the LVM likes in order to access my original drives?

Thanks again


---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.


glandix at lloydnet

Aug 15, 2006, 9:23 AM

Post #6 of 16 (3365 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

Tom+Dale wrote:
> I have made arrangements to RMA this drive (NewEgg really has excellent
> customer service). So my other questions weigh heavily on my mind
> (i.e., will I lose ~200GB of data from the still functioning drives that
> were part of this LVM? Or will I be able to put in an identical,
> functioning replacement and give it a UUID that the LVM likes in order
> to access my original drives?

[.side note, make sure you read the whole e-mail before starting to type
commands as i'm not 100% sure, since my situation was a little different
:) ... and if i'm wrong on anything, please anyone speak up so this guy
doesn't lose any data on my behalf!]

hopefully not! ;) ... i had a (slightly) similar issue earlier this week
when i upgraded my mobo/cpu and reinstalled FC5 for my mythbackend OS
... my issue was that i had the LVM volume spanned across 3 disks, one
being /dev/hda, which i had a feeling was starting to crap out ... what
you need to do is type:

pvdisplay

you should get information about the physical drives involved in any of
your LVM volumes ... it will show something like "unknown" for the PV
Name (instead of /dev/sda1) for the SATA drive that's gone bad ... but,
for the "Allocatable" line, it should show "yes" (hopefully not "yes
(but full)") ... i assume since you noticed the sounds fairly quickly,
you or your system hadn't had time to write information to that drive
yet ... if that's the case, you're definitely safe! :)

so, we'll assume that no data has been written to that drive yet ... to
remove the physical volume (pv) from the volume group (vg), you have to
use vgreduce:

vgreduce [volumeGroupName] /dev/sda[0-9]

where [volumeGroupName] is *gasp* your volume group name ;) and [0-9] is
whatever partition you were using on your SATA drive ... i'm guessing
it's probably 1 ...

that's the normal way of removing a physical volume from a volume group,
BUT, if that doesn't work (i can't recall, but that might give you an
error saying it can't find drive with UUID XXXX.....), you'll have to run:

vgreduce --removemissing [volumeGroupName]

that will just remove any missing physical volumes from the volume group
and after that, you should be able to mount your vg again ...

now, one thing with my situation that you don't have in yours is that my
drive was working well enough that i could resize my ReiserFS partition
down by 63GB (the size of the partition on /dev/hda that was part of my
volume group) before doing any of this .. then, i used pvmove to move
any data from that drive to the others (since mine definitely was in
use) ... after that i used pvremove prematurely to remove the LVM
information from the physical volume ... at that point, i was where you
are ... with a volume group that did not work because it was looking for
that drive, but that drive (as far as LVM was concerned) was missing ...
from that point, i followed the above instructions... i can't recall,
but you may have to do a vgchange -a n [volumeGroupName] to tell your
system that the volume group is not available before you do any of the
above ... and then vgchange -a y [volumeGroupName] to tell your system
it's back online after the above ... you should be able to do this w/o
any reboots, which (for me) helps, because you get to the end point
faster! :) ... also, if you do have data on your SATA drive and you need
to use pvmove and resize your filesystem (if you can get the drive to
work long enough), remember that pvmove and resize_reiserfs or resize2fs
can take a LOOOOOOOOOONG time ... my pvmove for 63GB of data took
overnight to finish :S

i hope this helps you out! i know how terrifying it can be thinking you
might lose 100's of gigs worth of data!!! sorry this isn't very
organized ... just kinda a quick brain dump, since i just did this on
Sunday of this week!

-g-
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


tdmyth at yahoo

Aug 15, 2006, 10:39 AM

Post #7 of 16 (3337 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

"gLaNDix (Jesse Kaufman)" <glandix [at] lloydnet> wrote: Tom+Dale wrote:
> I have made arrangements to RMA this drive (NewEgg really has excellent
> customer service). So my other questions weigh heavily on my mind
> (i.e., will I lose ~200GB of data from the still functioning drives that
> were part of this LVM? Or will I be able to put in an identical,
> functioning replacement and give it a UUID that the LVM likes in order
> to access my original drives?

[.side note, make sure you read the whole e-mail before starting to type
commands as i'm not 100% sure, since my situation was a little different
:) ... and if i'm wrong on anything, please anyone speak up so this guy
doesn't lose any data on my behalf!]

hopefully not! ;) ... i had a (slightly) similar issue earlier this week
when i upgraded my mobo/cpu and reinstalled FC5 for my mythbackend OS
... my issue was that i had the LVM volume spanned across 3 disks, one
being /dev/hda, which i had a feeling was starting to crap out ... what
you need to do is type:

pvdisplay

you should get information about the physical drives involved in any of
your LVM volumes ... it will show something like "unknown" for the PV
Name (instead of /dev/sda1) for the SATA drive that's gone bad ... but,
for the "Allocatable" line, it should show "yes" (hopefully not "yes
(but full)") ... i assume since you noticed the sounds fairly quickly,
you or your system hadn't had time to write information to that drive
yet ... if that's the case, you're definitely safe! :)

so, we'll assume that no data has been written to that drive yet ... to
remove the physical volume (pv) from the volume group (vg), you have to
use vgreduce:

vgreduce [volumeGroupName] /dev/sda[0-9]

where [volumeGroupName] is *gasp* your volume group name ;) and [0-9] is
whatever partition you were using on your SATA drive ... i'm guessing
it's probably 1 ...

that's the normal way of removing a physical volume from a volume group,
BUT, if that doesn't work (i can't recall, but that might give you an
error saying it can't find drive with UUID XXXX.....), you'll have to run:

vgreduce --removemissing [volumeGroupName]

that will just remove any missing physical volumes from the volume group
and after that, you should be able to mount your vg again ...

now, one thing with my situation that you don't have in yours is that my
drive was working well enough that i could resize my ReiserFS partition
down by 63GB (the size of the partition on /dev/hda that was part of my
volume group) before doing any of this .. then, i used pvmove to move
any data from that drive to the others (since mine definitely was in
use) ... after that i used pvremove prematurely to remove the LVM
information from the physical volume ... at that point, i was where you
are ... with a volume group that did not work because it was looking for
that drive, but that drive (as far as LVM was concerned) was missing ...
from that point, i followed the above instructions... i can't recall,
but you may have to do a vgchange -a n [volumeGroupName] to tell your
system that the volume group is not available before you do any of the
above ... and then vgchange -a y [volumeGroupName] to tell your system
it's back online after the above ... you should be able to do this w/o
any reboots, which (for me) helps, because you get to the end point
faster! :) ... also, if you do have data on your SATA drive and you need
to use pvmove and resize your filesystem (if you can get the drive to
work long enough), remember that pvmove and resize_reiserfs or resize2fs
can take a LOOOOOOOOOONG time ... my pvmove for 63GB of data took
overnight to finish :S

i hope this helps you out! i know how terrifying it can be thinking you
might lose 100's of gigs worth of data!!! sorry this isn't very
organized ... just kinda a quick brain dump, since i just did this on
Sunday of this week!

-g-
Thanks. This is somewhat reassuring, but there's a significant difference in our situations as you have fortunately set up your LVM with ReiserFS whereas we dutifully followed the suggestion in Jarod's outstanding guide and we have used XFS. Now, too late, I have seen this _accurate_ assessment by Brandon:

http://www.gossamer-threads.com/lists/mythtv/users/149838

In fact, we had added the SATA drive to the LVM thinking that we could pvmove the data and then remove the 320GB drive for use in another box. It was not until we'd added it into the LVM that we realized you cannot reduce an XFS volume group. The solution at that point was to try and copy all that data off somehow, somewhere...maybe buy yet another big drive. Having the new drive fail was just icing on a nightmarish cake. :-/

For those who may have missed it, I included the results of several commands in my original post including pvdisplay, vgdisplay, pvcreate -u, and vgcfgrestore:

http://www.gossamer-threads.com/lists/mythtv/users/218185

Again, I appreciate your help, and I remain hopeful that I don't lose all that data!

-Tom-

---------------------------------
Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta.


glandix at lloydnet

Aug 15, 2006, 3:06 PM

Post #8 of 16 (3325 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

Tom+Dale wrote:
> In fact, we had added the SATA drive to the LVM thinking that we could
> pvmove the data and then remove the 320GB drive for use in another box.
> It was not until we'd added it into the LVM that we realized you cannot
> reduce an XFS volume group.

so you had already "grown" the XFS filesystem to use the entire space in
the volume group? i didn't see that in the original post, so i was
assuming you hadn't resized the filesystem yet. if not, then no data
will be on that drive and you can safely remove the physical volume from
the volume group. otherwise, i'm not sure, since i don't have any
experience with XFS, just ReiserFS and ext3

-g-
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


tdmyth at yahoo

Aug 15, 2006, 9:41 PM

Post #9 of 16 (3341 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

"gLaNDix (Jesse Kaufman)" <glandix [at] lloydnet> wrote: Tom+Dale wrote:
> In fact, we had added the SATA drive to the LVM thinking that we
> could pvmove the data and then remove the 320GB drive for use in
> another box. It was not until we'd added it into the LVM that we
> realized you cannot reduce an XFS volume group.

so you had already "grown" the XFS filesystem to use the entire space in
the volume group? i didn't see that in the original post, so i was
assuming you hadn't resized the filesystem yet. if not, then no data
will be on that drive and you can safely remove the physical volume from
the volume group. otherwise, i'm not sure, since i don't have any
experience with XFS, just ReiserFS and ext3

-g-
Right, I believe that we grown the volume group to include the new drive. I did not say that in my first message because LVM is all new to me so I'm not really sure how far we got, technically. Functionally, I know that we gave up before figuring out why MythTV only recognized the original disk space (excluding the new drive).

As newbies struggling to get a clue in the wee hours of Saturday morning, we adjourned at that point, planning to do more research later. When I checked things Saturday afternoon, I discovered the clicking sound of the new drive and suspected other trouble.

From the output of pvdisplay, it looks to me like most of the PEs are unavailable which I interpreted to mean that they are part of VolGroup00 and not available for assignment to another group. That's only a guess on my part. I'm hopeful that since MythTV didn't report the added space as available, perhaps no data was written there. More importantly, I'm hopeful that we can substitute an identical replacement disk, assign it the UUID from the failed one, and then at least be able to access the data on the original two physical volumes. We'll have to deal with our [larger than planned] logical volume in a separate step. Finally, we'll switch to ReiserFS having learned our lesson.


---------------------------------
How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.


glandix at lloydnet

Aug 15, 2006, 11:16 PM

Post #10 of 16 (3336 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

Tom+Dale wrote:

> Right, I believe that we grown the volume group to include the new
> drive. I did not say that in my first message because LVM is all new to
> me so I'm not really sure how far we got, technically. Functionally, I
> know that we gave up before figuring out why MythTV only recognized the
> original disk space (excluding the new drive).

that makes sense that myth (and the os in general) would not see the
space on that drive yet, since the logical volume has grown, but the
filesystem has not yet ... think of it as kinda similar to the
"standard" partitioning schemes ... let's say you have a 100GB drive and
create a 75GB partition on it ... that 25GB left over is still there,
but since it's unpartitioned space, nothing will "see" it ...


> As newbies struggling to get a clue in the wee hours of Saturday
> morning, we adjourned at that point, planning to do more research
> later. When I checked things Saturday afternoon, I discovered the
> clicking sound of the new drive and suspected other trouble.

yeah, i know how that goes ... until this weekend, all i knew about lvm
was copy/paste of commands from http://www.tldp.org/HOWTO/LVM-HOWTO (a
very good resource, by the way). when i had the missing physical volume
error, i googled and that's how i found out about the --removemissing
argument to vgreduce.

you can actually run 'vgreduce -t [volumeGroup] /dev/sda' (-t means
"test") and it will tell you if it can't remove the physical volume
because it is still used... you can also run 'vgreduce -t
--removemissing [volumeGroup]' and it will tell you what exactly will be
removed (according to the man page)...

also, according to the man page, it mentions a '--partial' option which
will do it's best to use the physical volumes it is able to find and
will use /dev/ioerror in place of any missing drives ... that may let
you be able to at least access your data ... maybe 'vgchange -ay
--partial [volumeGroup]' will let you activate it to make sure all your
data is there and do any backups? if it's all there, you could most
likely replace /dev/sda with a new drive and give it the old drive's
UUID (make sure to write down what it is before doing anything!) it's
definitely worth a shot! :)

anyway, i'm in no way claiming to be an expert on this ... after this
weekend, i had to read and read and read all the man pages and docs on
lvm to fix my problem and i at least think i have a decent understanding
... remember, almost any lvm command will accept the --test/-t option so
you can do a "dry-run" to see what might have happened if you did it for
real ...

when googling, i ran across this nice "simple introduction to lvm" ...
you might find it helpful, too:
http://www.debian-administration.org/articles/410

-g-
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


tdmyth at yahoo

Aug 17, 2006, 9:13 PM

Post #11 of 16 (3295 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

"gLaNDix (Jesse Kaufman)" <glandix [at] lloydnet> wrote: Tom+Dale wrote:

> Right, I believe that we grown the volume group to include the new
> drive. I did not say that in my first message because LVM is all new to
> me so I'm not really sure how far we got, technically. Functionally, I
> know that we gave up before figuring out why MythTV only recognized the
> original disk space (excluding the new drive).

that makes sense that myth (and the os in general) would not see the
space on that drive yet, since the logical volume has grown, but the
filesystem has not yet ... think of it as kinda similar to the
"standard" partitioning schemes ... let's say you have a 100GB drive and
create a 75GB partition on it ... that 25GB left over is still there,
but since it's unpartitioned space, nothing will "see" it ...


> As newbies struggling to get a clue in the wee hours of Saturday
> morning, we adjourned at that point, planning to do more research
> later. When I checked things Saturday afternoon, I discovered the
> clicking sound of the new drive and suspected other trouble.

yeah, i know how that goes ... until this weekend, all i knew about lvm
was copy/paste of commands from http://www.tldp.org/HOWTO/LVM-HOWTO (a
very good resource, by the way). when i had the missing physical volume
error, i googled and that's how i found out about the --removemissing
argument to vgreduce.

you can actually run 'vgreduce -t [volumeGroup] /dev/sda' (-t means
"test") and it will tell you if it can't remove the physical volume
because it is still used... you can also run 'vgreduce -t
--removemissing [volumeGroup]' and it will tell you what exactly will be
removed (according to the man page)...

also, according to the man page, it mentions a '--partial' option which
will do it's best to use the physical volumes it is able to find and
will use /dev/ioerror in place of any missing drives ... that may let
you be able to at least access your data ... maybe 'vgchange -ay
--partial [volumeGroup]' will let you activate it to make sure all your
data is there and do any backups? if it's all there, you could most
likely replace /dev/sda with a new drive and give it the old drive's
UUID (make sure to write down what it is before doing anything!) it's
definitely worth a shot! :)

anyway, i'm in no way claiming to be an expert on this ... after this
weekend, i had to read and read and read all the man pages and docs on
lvm to fix my problem and i at least think i have a decent understanding
... remember, almost any lvm command will accept the --test/-t option so
you can do a "dry-run" to see what might have happened if you did it for
real ...

when googling, i ran across this nice "simple introduction to lvm" ...
you might find it helpful, too:
http://www.debian-administration.org/articles/410

-g-
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Well, that nasty thing called "work" got in the way of my troubleshooting until now. I have tried a few of your suggestions with what appears to be limited success, though I cannot be sure.

First, I tried "vgreduce --removemissing VolGroup00" which seemed to work. Then, I tried "vgchange -ay --partial VolGroup00" which also appeared to complete successfully. Next I tried "ls /video" which reported nothing in the directory (this would not be correct if the volume group was working). Next, I tried:

[root [at] mythserve ~]# mount -a
mount: special device /dev/VolGroup00/LogVol00 does not exist

Now I didn't know what else to try so I guessed at a few commands without any succes. I'm floundering here...can anyone suggest anything else to try? Did I somehow lose the data? It seems to me that I should be able to access it still. I feel like I just need to tell the system how to find the logical volume LogVol00. It doesn't show up under /dev, but I don't know if that matters.

Thanks everyone!

Other commands and responses that I got today:

[root [at] mythserve ~]# vgchange -a y VolGroup00
0 logical volume(s) in volume group "VolGroup00" now active

[root [at] mythserve ~]# pvdisplay
--- Physical volume ---
PV Name /dev/hda5
VG Name VolGroup00
PV Size 66.12 GB / not usable 0
Allocatable yes
PE Size (KByte) 4096
Total PE 16926
Free PE 16926
Allocated PE 0
PV UUID 317l2C-oay1-TWFG-5NTX-XJS3-vLal-Xh5bBL

--- Physical volume ---
PV Name /dev/hdb
VG Name VolGroup00
PV Size 298.09 GB / not usable 0
Allocatable yes
PE Size (KByte) 4096
Total PE 76311
Free PE 76311
Allocated PE 0
PV UUID nfLxS1-0u3t-5Zr9-57iu-1oZe-Bkkd-75SERQ

[root [at] mythserve ~]# vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2

[root [at] mythserve ~]# vgck -vv VolGroup00
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Using volume group(s) on command line
Locking /var/lock/lvm/V_VolGroup00 RB
Finding volume group "VolGroup00"
/dev/sda: No label detected
/dev/hda1: No label detected
/dev/hda2: No label detected
/dev/hda3: No label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Unlocking /var/lock/lvm/V_VolGroup00



---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.


glandix at lloydnet

Aug 18, 2006, 7:40 PM

Post #12 of 16 (3255 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

Tom+Dale wrote:

> Now I didn't know what else to try so I guessed at a few commands
> without any succes. I'm floundering here...can anyone suggest anything
> else to try? Did I somehow lose the data? It seems to me that I should
> be able to access it still. I feel like I just need to tell the system
> how to find the logical volume LogVol00. It doesn't show up under /dev,
> but I don't know if that matters.

it looks like most of what i'm seeing is vg* and pv* commands ... have
you tried any of the lv* commands? for instance, lvdiskscan, lvscan,
lvdisplay, or lvchange? for details on them, read the man pages, since
i just quickly ran through a few that looked like they might be related
to figuring more info out

-g-
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


tdmyth at yahoo

Aug 19, 2006, 7:41 AM

Post #13 of 16 (3253 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

"gLaNDix (Jesse Kaufman)" <glandix [at] lloydnet> wrote: Tom+Dale wrote:

> Now I didn't know what else to try so I guessed at a few commands
> without any succes. I'm floundering here...can anyone suggest anything
> else to try? Did I somehow lose the data? It seems to me that I should
> be able to access it still. I feel like I just need to tell the system
> how to find the logical volume LogVol00. It doesn't show up under /dev,
> but I don't know if that matters.

it looks like most of what i'm seeing is vg* and pv* commands ... have
you tried any of the lv* commands? for instance, lvdiskscan, lvscan,
lvdisplay, or lvchange? for details on them, read the man pages, since
i just quickly ran through a few that looked like they might be related
to figuring more info out

-g-



Thanks for the response. I guess I should have mentioned the results from lv* commands I tried (lvdiskscan appears not to be a Fedora command). I'm afraid to do anything with lvcreate because I don't want to step on what's there--unless I am misunderstanding how things work. It looks to me like the volume group is there, but the system can't find or doesn't know the label. I wonder how to tell it that the label was LogVol00.

Here are some results:

[root [at] mythserve ~]# lvchange -vvvay /dev/VolGroup00/LogVol00
Processing: lvchange -vvvay /dev/VolGroup00/LogVol00
O_DIRECT will be used
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Using logical volume(s) on command line
Locking /var/lock/lvm/V_VolGroup00 WB
Opened /dev/sda RW
/dev/sda: block size is 4096 bytes
/dev/sda: No label detected
Opened /dev/hda1 RW
/dev/hda1: block size is 1024 bytes
/dev/hda1: No label detected
Opened /dev/hda2 RW
/dev/hda2: block size is 4096 bytes
/dev/hda2: No label detected
Opened /dev/hda3 RW
/dev/hda3: block size is 4096 bytes
/dev/hda3: No label detected
Opened /dev/hda5 RW
/dev/hda5: block size is 512 bytes
/dev/hda5: lvm2 label detected
lvmcache: /dev/hda5 now orphaned
lvmcache: /dev/hda5 now in VG VolGroup00
Opened /dev/hdb RW
/dev/hdb: block size is 4096 bytes
/dev/hdb: lvm2 label detected
lvmcache: /dev/hdb now orphaned
lvmcache: /dev/hdb now in VG VolGroup00
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hda5 at 18944 size 720
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hdb at 16896 size 720
One or more specified logical volume(s) not found.
Unlocking /var/lock/lvm/V_VolGroup00
Closed /dev/sda
Closed /dev/hda1
Closed /dev/hda2
Closed /dev/hda3
Closed /dev/hda5
Closed /dev/hdb
[root [at] mythserve ~]# lvscan -vvv
Processing: lvscan -vvv
O_DIRECT will be used
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Finding all logical volumes
Opened /dev/sda RO
/dev/sda: block size is 4096 bytes
/dev/sda: No label detected
Closed /dev/sda
Opened /dev/hda1 RO
/dev/hda1: block size is 1024 bytes
/dev/hda1: No label detected
Closed /dev/hda1
Opened /dev/hda2 RO
/dev/hda2: block size is 4096 bytes
/dev/hda2: No label detected
Closed /dev/hda2
Opened /dev/hda3 RO
/dev/hda3: block size is 4096 bytes
/dev/hda3: No label detected
Closed /dev/hda3
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
/dev/hda5: lvm2 label detected
Closed /dev/hda5
lvmcache: /dev/hda5 now orphaned
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
Closed /dev/hda5
lvmcache: /dev/hda5 now in VG VolGroup00
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
/dev/hdb: lvm2 label detected
Closed /dev/hdb
lvmcache: /dev/hdb now orphaned
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
Closed /dev/hdb
lvmcache: /dev/hdb now in VG VolGroup00
Locking /var/lock/lvm/V_VolGroup00 RB
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
/dev/hda5: lvm2 label detected
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hda5 at 18944 size 720
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hdb at 16896 size 720
Unlocking /var/lock/lvm/V_VolGroup00
Closed /dev/hda5
Closed /dev/hdb
[root [at] mythserve ~]# lvdisplay -vvv
Processing: lvdisplay -vvv
O_DIRECT will be used
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Finding all logical volumes
Opened /dev/sda RO
/dev/sda: block size is 4096 bytes
/dev/sda: No label detected
Closed /dev/sda
Opened /dev/hda1 RO
/dev/hda1: block size is 1024 bytes
/dev/hda1: No label detected
Closed /dev/hda1
Opened /dev/hda2 RO
/dev/hda2: block size is 4096 bytes
/dev/hda2: No label detected
Closed /dev/hda2
Opened /dev/hda3 RO
/dev/hda3: block size is 4096 bytes
/dev/hda3: No label detected
Closed /dev/hda3
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
/dev/hda5: lvm2 label detected
Closed /dev/hda5
lvmcache: /dev/hda5 now orphaned
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
Closed /dev/hda5
lvmcache: /dev/hda5 now in VG VolGroup00
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
/dev/hdb: lvm2 label detected
Closed /dev/hdb
lvmcache: /dev/hdb now orphaned
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
Closed /dev/hdb
lvmcache: /dev/hdb now in VG VolGroup00
Locking /var/lock/lvm/V_VolGroup00 RB
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
/dev/hda5: lvm2 label detected
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hda5 at 18944 size 720
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hdb at 16896 size 720
Unlocking /var/lock/lvm/V_VolGroup00
Closed /dev/hda5
Closed /dev/hdb





---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.


tdmyth at yahoo

Sep 11, 2006, 10:31 PM

Post #14 of 16 (3141 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

Tom+Dale <tdmyth [at] yahoo> wrote: "gLaNDix (Jesse Kaufman)" <glandix [at] lloydnet> wrote: Tom+Dale wrote:

> Now I didn't know what else to try so I guessed at a few commands
> without any succes. I'm floundering here...can anyone suggest anything
> else to try? Did I somehow lose the data? It seems to me that I should
> be able to access it still. I feel like I just need to tell the system
> how to find the logical volume LogVol00. It doesn't show up under /dev,
> but I don't know if that matters.

it looks like most of what i'm seeing is vg* and pv* commands ... have
you tried any of the lv* commands? for instance, lvdiskscan, lvscan,
lvdisplay, or lvchange? for details on them, read the man pages, since
i just quickly ran through a few that looked like they might be related
to figuring more info out

-g-



Thanks for the response. I guess I should have mentioned the results from lv* commands I tried (lvdiskscan appears not to be a Fedora command). I'm afraid to do anything with lvcreate because I don't want to step on what's there--unless I am misunderstanding how things work. It looks to me like the volume group is there, but the system can't find or doesn't know the label. I wonder how to tell it that the label was LogVol00.

Here are some results:

[root [at] mythserve ~]# lvchange -vvvay /dev/VolGroup00/LogVol00
Processing: lvchange -vvvay /dev/VolGroup00/LogVol00
O_DIRECT will be used
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Using logical volume(s) on command line
Locking /var/lock/lvm/V_VolGroup00 WB
Opened /dev/sda RW
/dev/sda: block size is 4096 bytes
/dev/sda: No label detected
Opened /dev/hda1 RW
/dev/hda1: block size is 1024 bytes
/dev/hda1: No label detected
Opened /dev/hda2 RW
/dev/hda2: block size is 4096 bytes
/dev/hda2: No label detected
Opened /dev/hda3 RW
/dev/hda3: block size is 4096 bytes
/dev/hda3: No label detected
Opened /dev/hda5 RW
/dev/hda5: block size is 512 bytes
/dev/hda5: lvm2 label detected
lvmcache: /dev/hda5 now orphaned
lvmcache: /dev/hda5 now in VG VolGroup00
Opened /dev/hdb RW
/dev/hdb: block size is 4096 bytes
/dev/hdb: lvm2 label detected
lvmcache: /dev/hdb now orphaned
lvmcache: /dev/hdb now in VG VolGroup00
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hda5 at 18944 size 720
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hdb at 16896 size 720
One or more specified logical volume(s) not found.
Unlocking /var/lock/lvm/V_VolGroup00
Closed /dev/sda
Closed /dev/hda1
Closed /dev/hda2
Closed /dev/hda3
Closed /dev/hda5
Closed /dev/hdb
[root [at] mythserve ~]# lvscan -vvv
Processing: lvscan -vvv
O_DIRECT will be used
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Finding all logical volumes
Opened /dev/sda RO
/dev/sda: block size is 4096 bytes
/dev/sda: No label detected
Closed /dev/sda
Opened /dev/hda1 RO
/dev/hda1: block size is 1024 bytes
/dev/hda1: No label detected
Closed /dev/hda1
Opened /dev/hda2 RO
/dev/hda2: block size is 4096 bytes
/dev/hda2: No label detected
Closed /dev/hda2
Opened /dev/hda3 RO
/dev/hda3: block size is 4096 bytes
/dev/hda3: No label detected
Closed /dev/hda3
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
/dev/hda5: lvm2 label detected
Closed /dev/hda5
lvmcache: /dev/hda5 now orphaned
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
Closed /dev/hda5
lvmcache: /dev/hda5 now in VG VolGroup00
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
/dev/hdb: lvm2 label detected
Closed /dev/hdb
lvmcache: /dev/hdb now orphaned
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
Closed /dev/hdb
lvmcache: /dev/hdb now in VG VolGroup00
Locking /var/lock/lvm/V_VolGroup00 RB
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
/dev/hda5: lvm2 label detected
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hda5 at 18944 size 720
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hdb at 16896 size 720
Unlocking /var/lock/lvm/V_VolGroup00
Closed /dev/hda5
Closed /dev/hdb
[root [at] mythserve ~]# lvdisplay -vvv
Processing: lvdisplay -vvv
O_DIRECT will be used
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Finding all logical volumes
Opened /dev/sda RO
/dev/sda: block size is 4096 bytes
/dev/sda: No label detected
Closed /dev/sda
Opened /dev/hda1 RO
/dev/hda1: block size is 1024 bytes
/dev/hda1: No label detected
Closed /dev/hda1
Opened /dev/hda2 RO
/dev/hda2: block size is 4096 bytes
/dev/hda2: No label detected
Closed /dev/hda2
Opened /dev/hda3 RO
/dev/hda3: block size is 4096 bytes
/dev/hda3: No label detected
Closed /dev/hda3
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
/dev/hda5: lvm2 label detected
Closed /dev/hda5
lvmcache: /dev/hda5 now orphaned
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
Closed /dev/hda5
lvmcache: /dev/hda5 now in VG VolGroup00
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
/dev/hdb: lvm2 label detected
Closed /dev/hdb
lvmcache: /dev/hdb now orphaned
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
Closed /dev/hdb
lvmcache: /dev/hdb now in VG VolGroup00
Locking /var/lock/lvm/V_VolGroup00 RB
Opened /dev/hda5 RO
/dev/hda5: block size is 512 bytes
/dev/hda5: lvm2 label detected
Opened /dev/hdb RO
/dev/hdb: block size is 4096 bytes
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hda5 at 18944 size 720
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Read VolGroup00 metadata (11) from /dev/hdb at 16896 size 720
Unlocking /var/lock/lvm/V_VolGroup00
Closed /dev/hda5
Closed /dev/hdb


Greetings to all:
This followup is for the benefit of those who may run into a similar problem in the future. I was, at last, able to solve this problem. I was right all along...the data was there. So when I started experimenting with the archive files associated with LVM, I stumbled on success. Someone suggested "vgcfgrestore" might work; however, I had to use trial & error with the -t (test) parameter in order to figure this out. By that I mean reading the LVM HowTo and various man pages did not clarify much for me. So here are the steps that I took:
--------------------------------------------------------
[root [at] mythserve lvm]# vgcfgrestore -tf /etc/lvm/archive/VolGroup00_00000.vg
Test mode: Metadata will NOT be updated.
Please specify a *single* volume group to restore.
[root [at] mythserve lvm]# vgcfgrestore -tf /etc/lvm/archive/VolGroup00_00000.vg Vol
Group00
Test mode: Metadata will NOT be updated.
Restored volume group VolGroup00
[root [at] mythserve lvm]# vgcfgrestore -tvf /etc/lvm/archive/VolGroup00_00000.vg Vo
lGroup00
Test mode: Metadata will NOT be updated.
Restored volume group VolGroup00
Test mode: Wiping internal cache
Wiping internal VG cache
[root [at] mythserve lvm]# vgcfgrestore -tvvf /etc/lvm/archive/VolGroup00_00000.vg V
olGroup00
Test mode: Metadata will NOT be updated.
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Locking /var/lock/lvm/P_orphans WB
Locking /var/lock/lvm/V_VolGroup00 W
/dev/hda1: No label detected
/dev/hda2: No label detected
/dev/hda3: No label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Restored volume group VolGroup00
Unlocking /var/lock/lvm/V_VolGroup00
Unlocking /var/lock/lvm/P_orphans
Test mode: Wiping internal cache
Wiping internal VG cache
[root [at] mythserve lvm]# vgcfgrestore -vvf /etc/lvm/archive/VolGroup00_00000.vg Vo
lGroup00
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Locking /var/lock/lvm/P_orphans WB
Locking /var/lock/lvm/V_VolGroup00 W
/dev/hda1: No label detected
/dev/hda2: No label detected
/dev/hda3: No label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Restored volume group VolGroup00
Unlocking /var/lock/lvm/V_VolGroup00
Unlocking /var/lock/lvm/P_orphans
[root [at] mythserve lvm]# lvscan
inactive '/dev/VolGroup00/LogVol00' [364.21 GB] inherit
[root [at] mythserve lvm]# lvchange -tv -ay /dev/VolGroup00/LogVol00
Test mode: Metadata will NOT be updated.
Using logical volume(s) on command line
Activating logical volume "LogVol00"
Found volume group "VolGroup00"
Test mode: Wiping internal cache
Wiping internal VG cache
[root [at] mythserve lvm]# lvchange -v -ay /dev/VolGroup00/LogVol00
Using logical volume(s) on command line
Activating logical volume "LogVol00"
Found volume group "VolGroup00"
Loading VolGroup00-LogVol00
[root [at] mythserve lvm]# mount -a
------------------------------------------------------------------------
That did it! We were able to copy our data off the volume and recover the whole system. I hope this helps someone else down the road.

-Tom-



---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.


mythtv at ausiv

Sep 13, 2006, 8:06 PM

Post #15 of 16 (3100 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

>
> Greetings to all:
> This followup is for the benefit of those who may run into a similar
> problem in the future. I was, at last, able to solve this problem. I was
> right all along...the data was there. So when I started experimenting with
> the archive files associated with LVM, I stumbled on success. Someone
> suggested "vgcfgrestore" might work; however, I had to use trial & error
> with the -t (test) parameter in order to figure this out. By that I mean
> reading the LVM HowTo and various man pages did not clarify much for me. So
> here are the steps that I took:
> --------------------------------------------------------
> [root [at] mythserve lvm]# vgcfgrestore -tf
> /etc/lvm/archive/VolGroup00_00000.vg
> Test mode: Metadata will NOT be updated.
> Please specify a *single* volume group to restore.
> [root [at] mythserve lvm]# vgcfgrestore -tf
> /etc/lvm/archive/VolGroup00_00000.vg Vol
> Group00
> Test mode: Metadata will NOT be updated.
> Restored volume group VolGroup00
> [root [at] mythserve lvm]# vgcfgrestore -tvf
> /etc/lvm/archive/VolGroup00_00000.vg Vo
> lGroup00
> Test mode: Metadata will NOT be updated.
> Restored volume group VolGroup00
> Test mode: Wiping internal cache
> Wiping internal VG cache
> [root [at] mythserve lvm]# vgcfgrestore -tvvf
> /etc/lvm/archive/VolGroup00_00000.vg V
> olGroup00
> Test mode: Metadata will NOT be updated.
> Setting global/locking_type to 1
> Setting global/locking_dir to /var/lock/lvm
> File-based locking enabled.
> Locking /var/lock/lvm/P_orphans WB
> Locking /var/lock/lvm/V_VolGroup00 W
> /dev/hda1: No label detected
> /dev/hda2: No label detected
> /dev/hda3: No label detected
> /dev/hda5: lvm2 label detected
> /dev/hdb: lvm2 label detected
> /dev/hda5: lvm2 label detected
> /dev/hdb: lvm2 label detected
> Restored volume group VolGroup00
> Unlocking /var/lock/lvm/V_VolGroup00
> Unlocking /var/lock/lvm/P_orphans
> Test mode: Wiping internal cache
> Wiping internal VG cache
> [root [at] mythserve lvm]# vgcfgrestore -vvf
> /etc/lvm/archive/VolGroup00_00000.vg Vo
> lGroup00
> Setting global/locking_type to 1
> Setting global/locking_dir to /var/lock/lvm
> File-based locking enabled.
> Locking /var/lock/lvm/P_orphans WB
> Locking /var/lock/lvm/V_VolGroup00 W
> /dev/hda1: No label detected
> /dev/hda2: No label detected
> /dev/hda3: No label detected
> /dev/hda5: lvm2 label detected
> /dev/hdb: lvm2 label detected
> /dev/hda5: lvm2 label detected
> /dev/hdb: lvm2 label detected
> Restored volume group VolGroup00
> Unlocking /var/lock/lvm/V_VolGroup00
> Unlocking /var/lock/lvm/P_orphans
> [root [at] mythserve lvm]# lvscan
> inactive '/dev/VolGroup00/LogVol00' [364.21 GB] inherit
> [root [at] mythserve lvm]# lvchange -tv -ay /dev/VolGroup00/LogVol00
> Test mode: Metadata will NOT be updated.
> Using logical volume(s) on command line
> Activating logical volume "LogVol00"
> Found volume group "VolGroup00"
> Test mode: Wiping internal cache
> Wiping internal VG cache
> [root [at] mythserve lvm]# lvchange -v -ay /dev/VolGroup00/LogVol00
> Using logical volume(s) on command line
> Activating logical volume "LogVol00"
> Found volume group "VolGroup00"
> Loading VolGroup00-LogVol00
> [root [at] mythserve lvm]# mount -a
> ------------------------------------------------------------------------
> That did it! We were able to copy our data off the volume and recover the
> whole system. I hope this helps someone else down the road.
>
> -Tom-
>

Tom:
Today I did something silly that puts me in a perdicament similar to yours.
From what I've seen the results I am getting are very similar to the results
you were getting at the beginning -- errors about not being able to find the
device with a given uuid, etc.

When I try to reassign the UUID, I get errors about improper UUID format.

What did you do in order to reassign the UUID to the faulty drive? I've not
been able to find that in any of your explanations.

Thanks,
-Austin


tdmyth at yahoo

Sep 24, 2006, 5:52 PM

Post #16 of 16 (3002 views)
Permalink
Re: LVM Problem -- Please Help [In reply to]

Austin Roberts <mythtv [at] ausiv> wrote: Greetings to all:
This followup is for the benefit of those who may run into a similar problem in the future. I was, at last, able to solve this problem. I was right all along...the data was there. So when I started experimenting with the archive files associated with LVM, I stumbled on success. Someone suggested "vgcfgrestore" might work; however, I had to use trial & error with the -t (test) parameter in order to figure this out. By that I mean reading the LVM HowTo and various man pages did not clarify much for me. So here are the steps that I took:
--------------------------------------------------------
[root [at] mythserve lvm]# vgcfgrestore -tf /etc/lvm/archive/VolGroup00_00000.vg
Test mode: Metadata will NOT be updated.
Please specify a *single* volume group to restore.
[root [at] mythserve lvm]# vgcfgrestore -tf /etc/lvm/archive/VolGroup00_00000.vg Vol
Group00
Test mode: Metadata will NOT be updated.
Restored volume group VolGroup00
[root [at] mythserve lvm]# vgcfgrestore -tvf /etc/lvm/archive/VolGroup00_00000.vg Vo
lGroup00
Test mode: Metadata will NOT be updated.
Restored volume group VolGroup00
Test mode: Wiping internal cache
Wiping internal VG cache
[root [at] mythserve lvm]# vgcfgrestore -tvvf /etc/lvm/archive/VolGroup00_00000.vg V
olGroup00
Test mode: Metadata will NOT be updated.
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Locking /var/lock/lvm/P_orphans WB
Locking /var/lock/lvm/V_VolGroup00 W
/dev/hda1: No label detected
/dev/hda2: No label detected
/dev/hda3: No label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Restored volume group VolGroup00
Unlocking /var/lock/lvm/V_VolGroup00
Unlocking /var/lock/lvm/P_orphans
Test mode: Wiping internal cache
Wiping internal VG cache
[root [at] mythserve lvm]# vgcfgrestore -vvf /etc/lvm/archive/VolGroup00_00000.vg Vo
lGroup00
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Locking /var/lock/lvm/P_orphans WB
Locking /var/lock/lvm/V_VolGroup00 W
/dev/hda1: No label detected
/dev/hda2: No label detected
/dev/hda3: No label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
/dev/hda5: lvm2 label detected
/dev/hdb: lvm2 label detected
Restored volume group VolGroup00
Unlocking /var/lock/lvm/V_VolGroup00
Unlocking /var/lock/lvm/P_orphans
[root [at] mythserve lvm]# lvscan
inactive '/dev/VolGroup00/LogVol00' [364.21 GB] inherit
[root [at] mythserve lvm]# lvchange -tv -ay /dev/VolGroup00/LogVol00
Test mode: Metadata will NOT be updated.
Using logical volume(s) on command line
Activating logical volume "LogVol00"
Found volume group "VolGroup00"
Test mode: Wiping internal cache
Wiping internal VG cache
[root [at] mythserve lvm]# lvchange -v -ay /dev/VolGroup00/LogVol00
Using logical volume(s) on command line
Activating logical volume "LogVol00"
Found volume group "VolGroup00"
Loading VolGroup00-LogVol00
[root [at] mythserve lvm]# mount -a
------------------------------------------------------------------------
That did it! We were able to copy our data off the volume and recover the whole system. I hope this helps someone else down the road.

-Tom-


Tom:
Today I did something silly that puts me in a perdicament similar to yours. From what I've seen the results I am getting are very similar to the results you were getting at the beginning -- errors about not being able to find the device with a given uuid, etc.

When I try to reassign the UUID, I get errors about improper UUID format.

What did you do in order to reassign the UUID to the faulty drive? I've not been able to find that in any of your explanations.

Thanks,
-Austin

Austin,

I'm sorry I didn't respond sooner...I had not seen your post until today. Unfortunately for you, I didn't go the route of reassigning the UUID to the faulty drive. When I removed it, I tried to find an answer or someone who could help me with that. Even the LVM mailing list was not helpful on that issue (it's extremely low volume compared to this list). Ultimately, I followed someone's suggestion of issuing the command "vgreduce --removemissing VolGroup00" which allowed me to move on without the previously added, faulty drive.

Still, it seems like you should have been able to use vgcfgrestore to get the metadata back, unless you don't have the backup and archive files available.

Also, there's some information about restoring UUIDs here:
http://tldp.org/HOWTO/LVM-HOWTO/recovermetadata.html

Hopefully you were able to recover the volume by now...

-Tom-



---------------------------------
Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business.

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.