<b><i>"gLaNDix (Jesse Kaufman)" <glandix@lloydnet.org></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Tom+Dale wrote:<br>> I have made arrangements to RMA this drive (NewEgg really has excellent <br>> customer service). So my other questions weigh heavily on my mind <br>> (i.e., will I lose ~200GB of data from the still functioning drives that <br>> were part of this LVM? Or will I be able to put in an identical, <br>> functioning replacement and give it a UUID that the LVM likes in order <br>> to access my original drives?<br><br>[side note, make sure you read the whole e-mail before starting to type <br>commands as i'm not 100% sure, since my situation was a little different <br>:) ... and if i'm wrong on anything, please anyone speak up so this guy <br>doesn't lose any data on my behalf!]<br><br>hopefully not! ;) ... i had a (slightly) similar issue earlier this week
<br>when i upgraded my mobo/cpu and reinstalled FC5 for my mythbackend OS <br>... my issue was that i had the LVM volume spanned across 3 disks, one <br>being /dev/hda, which i had a feeling was starting to crap out ... what <br>you need to do is type:<br><br>pvdisplay<br><br>you should get information about the physical drives involved in any of <br>your LVM volumes ... it will show something like "unknown" for the PV <br>Name (instead of /dev/sda1) for the SATA drive that's gone bad ... but, <br>for the "Allocatable" line, it should show "yes" (hopefully not "yes <br>(but full)") ... i assume since you noticed the sounds fairly quickly, <br>you or your system hadn't had time to write information to that drive <br>yet ... if that's the case, you're definitely safe! :)<br><br>so, we'll assume that no data has been written to that drive yet ... to <br>remove the physical volume (pv) from the volume group (vg), you have to <br>use vgreduce:<br><br>vgreduce [volumeGroupName]
/dev/sda[0-9]<br><br>where [volumeGroupName] is *gasp* your volume group name ;) and [0-9] is <br>whatever partition you were using on your SATA drive ... i'm guessing <br>it's probably 1 ...<br><br>that's the normal way of removing a physical volume from a volume group, <br>BUT, if that doesn't work (i can't recall, but that might give you an <br>error saying it can't find drive with UUID XXXX.....), you'll have to run:<br><br>vgreduce --removemissing [volumeGroupName]<br><br>that will just remove any missing physical volumes from the volume group <br>and after that, you should be able to mount your vg again ...<br><br>now, one thing with my situation that you don't have in yours is that my <br>drive was working well enough that i could resize my ReiserFS partition <br>down by 63GB (the size of the partition on /dev/hda that was part of my <br>volume group) before doing any of this .. then, i used pvmove to move <br>any data from that drive to the others (since mine
definitely was in <br>use) ... after that i used pvremove prematurely to remove the LVM <br>information from the physical volume ... at that point, i was where you <br>are ... with a volume group that did not work because it was looking for <br>that drive, but that drive (as far as LVM was concerned) was missing ... <br>from that point, i followed the above instructions... i can't recall, <br>but you may have to do a vgchange -a n [volumeGroupName] to tell your <br>system that the volume group is not available before you do any of the <br>above ... and then vgchange -a y [volumeGroupName] to tell your system <br>it's back online after the above ... you should be able to do this w/o <br>any reboots, which (for me) helps, because you get to the end point <br>faster! :) ... also, if you do have data on your SATA drive and you need <br>to use pvmove and resize your filesystem (if you can get the drive to <br>work long enough), remember that pvmove and resize_reiserfs or
resize2fs <br>can take a LOOOOOOOOOONG time ... my pvmove for 63GB of data took <br>overnight to finish :S<br><br>i hope this helps you out! i know how terrifying it can be thinking you <br>might lose 100's of gigs worth of data!!! sorry this isn't very <br>organized ... just kinda a quick brain dump, since i just did this on <br>Sunday of this week!<br><br>-g-<br></blockquote>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:<br><br>http://www.gossamer-threads.com/lists/mythtv/users/149838<br><br>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. :-/<br><br>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:<br><br>http://www.gossamer-threads.com/lists/mythtv/users/218185<br><br>Again, I appreciate your help, and I remain hopeful that I don't lose all that data!<br><br>-Tom-<p> 
<hr size=1>Do you Yahoo!?<br> Next-gen email? Have it all with the <a href="http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers"> all-new Yahoo! Mail Beta.</a>