1 |
Ok it finished the pvmove and all my lv's are now back to a healthy |
2 |
state. Gotta love when it works how its supposed to. |
3 |
|
4 |
-David |
5 |
|
6 |
On 6/1/05, David Miller <david3d@×××××.com> wrote: |
7 |
> Well to answer my own question after looking in the man page for |
8 |
> pvmove I have just run it again with no arguments and it has resumed |
9 |
> where it left off. Which will hopefully resurect the one logical |
10 |
> volume that at the moment cannot be mounted. I'll let you know how it |
11 |
> goes. |
12 |
> |
13 |
> -David |
14 |
> |
15 |
> On 6/1/05, David Miller <david3d@×××××.com> wrote: |
16 |
> > Well the server did a kernel dump last night while doing the pvmove. |
17 |
> > Resulting in one logical volume being corrupted in the process. Not a |
18 |
> > big deal as the data is on tape. However now lvdisplay still lists |
19 |
> > the pvmove0 logical volume. So how do I clean up what was left |
20 |
> > behind? |
21 |
> > |
22 |
> > -David |
23 |
> > |
24 |
> > On 5/31/05, Benjamin Smee <strerror@g.o> wrote: |
25 |
> > > lo, |
26 |
> > > |
27 |
> > > On Tuesday 31 May 2005 17:49, David Miller wrote: |
28 |
> > > > I've been running LVM2 now for some time but recently I have not |
29 |
> > > > been able to update device-mapper or lvm2 without vgscan failing to |
30 |
> > > > find all the pv's. So I'm stuck using lvm2-2.00.25 and device-mapper |
31 |
> > > > 1.00.19-r2. |
32 |
> > > > Now one thing to note is that a few of my pv's were added as the |
33 |
> > > > entire device rather than a partition. Could this be throwing a newer |
34 |
> > > > version for a loop since it may first be looking for an LVM partition |
35 |
> > > > before looking for a vg metadata? Or have I just overlooked something |
36 |
> > > > that I need to do in order to migrate my current vg's up to the newer |
37 |
> > > > versions? |
38 |
> > > |
39 |
> > > There is nothing that you need to do to "migrate" your lvm2 partitions to a |
40 |
> > > newer format, whatever problem that you have will be something local not |
41 |
> > > generic as many people are successfully using the latest versions of both |
42 |
> > > with no problems. You could start off running the vgscan in debug mode and |
43 |
> > > letting us know the relevant output, and if that fails try running it with a |
44 |
> > > strace or similar util to see precisely what is happening. Other pertinant |
45 |
> > > questions are things like, are you using udev? with persistant devices (ie |
46 |
> > > the tarball option in the rc.conf) what version of baselayout are you using, |
47 |
> > > do you have devfs enabled? |
48 |
> > > |
49 |
> > > regards, |
50 |
> > > |
51 |
> > > -- |
52 |
> > > Benjamin Smee (strerror) |
53 |
> > > 497F 5E98 1FA0 C313 EA0B 08C7 004A 66ED 448B E78C |
54 |
> > > |
55 |
> > > |
56 |
> > > |
57 |
> > |
58 |
> |
59 |
|
60 |
-- |
61 |
gentoo-server@g.o mailing list |