linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
* [linux-lvm] guruplug 2.6.37 lvm2 problem
@ 2011-01-27 18:25 Jason
  2011-01-28 16:51 ` [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV Fredrik Skog
  2011-02-02 15:31 ` [linux-lvm] guruplug 2.6.37 lvm2 problem Milan Broz
  0 siblings, 2 replies; 5+ messages in thread
From: Jason @ 2011-01-27 18:25 UTC (permalink / raw)
  To: linux-lvm

All,

I have a small problem that's I've been beating my head against for two 
days.

I've installed debian onto an sdcard according to [1].  This required a 
new U-boot [2].  For grins, I chose encrypted LVM.  It works fine with 
the 2.6.33.3flipflip kernel [3].  However, I'm trying to get 2.6.37 
vanilla to work.

I think I'm almost there except that lvm2 segfaults every time right 
after I enter the password.  So, I jumped into initramfs and ran 'lvm 
pvscan -v -v -v -v' for both kernels.  Here's the output:

### 'lvm pvscan -v -v -v -v' on 2.6.33.3flipflip #######################
(initramfs) lvm pvscan -v -v -v -v
#lvmcmdline.c:1035         Processing: pvscan -v -v -v -v
#lvmcmdline.c:1038         O_DIRECT will be used
#config/config.c:987       Setting global/locking_type to 1
#config/config.c:987       Setting global/wait_for_locks to 1
#locking/locking.c:240       File-based locking selected.
#config/config.c:964       Setting global/locking_dir to /var/lock/lvm
#locking/file_locking.c:235       Locking /var/lock/lvm/P_global WB
#locking/file_locking.c:141         _do_flock /var/lock/lvm/P_global:aux WB
#locking/file_locking.c:141         _do_flock /var/lock/lvm/P_global WB
#locking/file_locking.c:51         _undo_flock /var/lock/lvm/P_global:aux
#filters/filter-persistent.c:56     Wiping cache of LVM-capable devices
#device/dev-cache.c:247         /dev/block/1:0: Already in device cache

...snip...

#device/dev-io.c:487         Opened /dev/dm-0 RO
#device/dev-io.c:260       /dev/dm-0: size is 30820344 sectors
#device/dev-io.c:533         Closed /dev/dm-0
#device/dev-io.c:260       /dev/dm-0: size is 30820344 sectors
#device/dev-io.c:487         Opened /dev/dm-0 RO O_DIRECT
#device/dev-io.c:134         /dev/dm-0: block size is 4096 bytes
#device/dev-io.c:533         Closed /dev/dm-0
#filters/filter-composite.c:31         Using /dev/dm-0
#device/dev-io.c:487         Opened /dev/dm-0 RO O_DIRECT
#device/dev-io.c:134         /dev/dm-0: block size is 4096 bytes
#label/label.c:160       /dev/dm-0: lvm2 label detected
#cache/lvmcache.c:1136         lvmcache: /dev/dm-0: now in VG 
#orphans_lvm2 (#orphans_lvm2)
#format_text/format-text.c:1137         /dev/dm-0: Found metadata at 
6656 size 1158 (in area at 4096 size 192512) for debian (UUID_WAS_HERE)
#cache/lvmcache.c:1136         lvmcache: /dev/dm-0: now in VG debian 
with 1 mdas
#cache/lvmcache.c:923         lvmcache: /dev/dm-0: setting debian VGID 
to UUID_WAS_HERE
#cache/lvmcache.c:1173         lvmcache: /dev/dm-0: VG debian: Set 
creation host to debian.
#device/dev-io.c:533         Closed /dev/dm-0
#device/dev-io.c:487         Opened /dev/ram1 RO

...snip...

#label/label.c:270         Using cached label for /dev/dm-0
#device/dev-io.c:487         Opened /dev/dm-0 RO O_DIRECT
#device/dev-io.c:134         /dev/dm-0: block size is 4096 bytes
#label/label.c:270         Using cached label for /dev/dm-0
#format_text/format-text.c:498         Read debian metadata (3) from 
/dev/dm-0 at 6656 size 1158
#device/dev-io.c:533         Closed /dev/dm-0
#metadata/pv_manip.c:296         /dev/dm-0 0:      0   3592: root(0:0)
#metadata/pv_manip.c:296         /dev/dm-0 1:   3592    170: swap_1(0:0)
   PV /dev/dm-0   VG debian   lvm2 [14.70 GiB / 0    free]
   Total: 1 [14.70 GiB] / in use: 1 [14.70 GiB] / in no VG: 0 [0   ]
#locking/file_locking.c:74       Unlocking /var/lock/lvm/P_global
#locking/file_locking.c:51         _undo_flock /var/lock/lvm/P_global
(initramfs)
########################################################################

And then the failure:

### 'lvm pvscan -v -v -v -v' on 2.6.37 #################################
(initramfs) lvm pvscan -v -v -v -v
#lvmcmdline.c:1035         Processing: pvscan -v -v -v -v
#lvmcmdline.c:1038         O_DIRECT will be used
#config/config.c:987       Setting global/locking_type to 1
#config/config.c:987       Setting global/wait_for_locks to 1
#locking/locking.c:240       File-based locking selected.
#config/config.c:964       Setting global/locking_dir to /var/lock/lvm
#locking/file_locking.c:235       Locking /var/lock/lvm/P_global WB
#locking/file_locking.c:141         _do_flock /var/lock/lvm/P_global:aux WB
#locking/file_locking.c:141         _do_flock /var/lock/lvm/P_global WB
#locking/file_locking.c:51         _undo_flock /var/lock/lvm/P_global:aux
#filters/filter-persistent.c:56     Wiping cache of LVM-capable devices
#device/dev-cache.c:262         /dev/block/253:0: Added to device cache

...snip...

#pvscan.c:134     Walking through all physical volumes
#device/dev-io.c:443         /dev/sda: open failed: No medium found
#filters/filter.c:143         /dev/sda: Skipping: open failed
#device/dev-io.c:487         Opened /dev/dm-0 RO
#device/dev-io.c:260       /dev/dm-0: size is 30820344 sectors
#device/dev-io.c:533         Closed /dev/dm-0
#device/dev-io.c:260       /dev/dm-0: size is 30820344 sectors
#device/dev-io.c:487         Opened /dev/dm-0 RO O_DIRECT
#device/dev-io.c:134         /dev/dm-0: block size is 4096 bytes
#device/dev-io.c:533         Closed /dev/dm-0
#filters/filter-composite.c:31         Using /dev/dm-0
#device/dev-io.c:487         Opened /dev/dm-0 RO O_DIRECT
#device/dev-io.c:134         /dev/dm-0: block size is 4096 bytes
Segmentation fault
(initramfs)
########################################################################

/dev/dm-0 is the decrypted device containing the LVM.

### Versions ###########################################################
(initramfs) lvm version
   LVM version:     2.02.66(2) (2010-05-20)
   Library version: 1.02.48 (2010-05-20)
   Driver version:  4.17.0
(initramfs)
########################################################################

Based on a Gentoo bug [4] and a Debian bug [5], I'm not the first to 
encounter this.  I have tried all combinations of 
CONFIG_SYSFS_DEPRECATED and CONFIG_SYSFS_DEPRECATED_V2, without luck. 
I've also tried --sysinit and --ignorelockingfailure with similar results.

Tracing the lvm2 code, it looks like the segfault may lie in 
lib/label/label.c:107 _find_labeller().  Probably after line 120, 
dev_read() and before line 160, log_very_verbose()...

As I'm fairly new to embedded debian, what's the easiest path to fix 
this?  I'm running out of ideas.  I'd _really_ prefer to keep 2.6.37, 
it's a bragging rights thing...  ;-)

Does anyone know where exactly the error is coming from?  Is there a 
missing sysfs entry?  My desktop (Ubuntu 10.04) runs 2.6.37 fine, but 
with an older lvm2 (2.02.54(1), lib 1.02.39, driver 4.18.0).  Getting a 
coredump out of the initrd is proving difficult...

thanks for any input,

Jason.


[1] 
http://bzed.de/posts/2010/05/installing_debian_on_the_guruplug_server_plus/
[2] http://oinkzwurgl.org/guruplug_uboot
[3] http://oinkzwurgl.org/guruplug_kernel
[4] http://bugs.gentoo.org/show_bug.cgi?id=292833
[5] 
http://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg221947.html

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV
  2011-01-27 18:25 [linux-lvm] guruplug 2.6.37 lvm2 problem Jason
@ 2011-01-28 16:51 ` Fredrik Skog
  2011-02-03  0:23   ` Fredrik Skog
  2011-02-02 15:31 ` [linux-lvm] guruplug 2.6.37 lvm2 problem Milan Broz
  1 sibling, 1 reply; 5+ messages in thread
From: Fredrik Skog @ 2011-01-28 16:51 UTC (permalink / raw)
  To: LVM general discussion and development

Hello

I'm somewhat a newbie at LVM and have encountered a real problem for me.
during resize2fs after extending my LV i ended up with a crash. Now I'm 
worried I have lost all my old data.
How can i proceed to get the volume in working order?
Any help would be greatly appreciated.

NoFear ~ # lvextend -L+400G /dev/vgftp/lvftp
  Extending logical volume lvftp to 4.16 TiB
  Logical volume lvftp successfully resized
NoFear ~ # umount /dev/vgftp/lvftp
NoFear ~ # resize2fs /dev/vgftp/lvftp
resize2fs 1.41.10 (10-Feb-2009)
Please run 'e2fsck -f /dev/vgftp/lvftp' first.

NoFear ~ # e2fsck -f /dev/vgftp/lvftp
e2fsck 1.41.10 (10-Feb-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  +21741823 +21741951 +21742207 +21742973 +21742975 
+21743102 +21743231 +21743484 +21743487 +21743612 +21743615 +21743740 
+21743868 +21744125 +21744127 +21744639 +21745149 +21746047 +21746559 
+21746687 +21746942 +21747327 +21747710 +21747967 +21748092 +21748223 
+21748735 +(21748990--21748991) +21749118 +(21749372--21749373) +21749501 
+21749503 +21749887 +21750143 +21750398 +21750655 +21750909 +21751037 
+21751165 +(21751549--21751550) +21751676 +21751807 +21751934
Fix<y>? yes

Block bitmap differences:  +33341823 +33343103 +33343356 +33343359 +33343484 
+33343487 +33343612 +33343740 +33343997 +33343999 +33345919 +33346431 
+33346559 +33346814 +33347199 +33347582 +33347839 +33348095 +33348607 
+33348862 +(33349244--33349245) +33349373 +33349759 +33350015 +33350781 
+33350909 +33351037 +33351422y^Hy
 +33351679
Fix<y>? yes

---- SNIPP ----

Block bitmap differences:  +26067327 +26068607 +26068860 +26068863 +26068988 
+26068991 +26069116 +26069244 +26069501 +26069503 +26071423 +26071935 
+26072063 +26072318 +26072703 +26073343 +26073599 +26074111 +26074366 
+(26074748--26074749) +26074877 +26075263 +26075519 +26076285 +26076413 
+26076541 +26077183
Fix<y>? yes


/dev/vgftp/lvftp: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vgftp/lvftp: 308343/505479168 files (18.3% non-contiguous), 
1006593162/1010942976 blocks

NoFear ~ # e2fsck -f /dev/vgftp/lvftp
e2fsck 1.41.10 (10-Feb-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vgftp/lvftp: 308343/505479168 files (18.3% non-contiguous), 
1006593162/1010942976 blocks
NoFear ~ # resize2fs /dev/vgftp/lvftp
resize2fs 1.41.10 (10-Feb-2009)
Resizing the filesystem on /dev/vgftp/lvftp to 1115800576 (4k) blocks.
** CRASH / HANG **

25hours waiting and nothing happens. No disk io going on or anything.
I have no backups or anythin of this volume. What can i do do revert the 
process to get the disks back? I have not done anything at all after the 
crash/hang in fear of destroying something.

Thanks for any input
/Fredrik Skog 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [linux-lvm] guruplug 2.6.37 lvm2 problem
  2011-01-27 18:25 [linux-lvm] guruplug 2.6.37 lvm2 problem Jason
  2011-01-28 16:51 ` [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV Fredrik Skog
@ 2011-02-02 15:31 ` Milan Broz
  1 sibling, 0 replies; 5+ messages in thread
From: Milan Broz @ 2011-02-02 15:31 UTC (permalink / raw)
  To: LVM general discussion and development; +Cc: Jason

On 01/27/2011 07:25 PM, Jason wrote:
> I have a small problem that's I've been beating my head against for two 
> days.
> 
> I've installed debian onto an sdcard according to [1].  This required a 
> new U-boot [2].  For grins, I chose encrypted LVM.  It works fine with 
> the 2.6.33.3flipflip kernel [3].  However, I'm trying to get 2.6.37 
> vanilla to work.
> 
> I think I'm almost there except that lvm2 segfaults every time right 
> after I enter the password.  So, I jumped into initramfs and ran 'lvm 
> pvscan -v -v -v -v' for both kernels.  Here's the output:

GuruPlug is ARM arch, right?

Can you recompile lvm without O_DIRECT support (--disable-o_direct)
and try it again?

I know that ARM had wrongly implemented direct-io (it was kernel problem),
so let's try this first.

Milan

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV
  2011-01-28 16:51 ` [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV Fredrik Skog
@ 2011-02-03  0:23   ` Fredrik Skog
  2011-02-03 15:46     ` Fredrik Skog
  0 siblings, 1 reply; 5+ messages in thread
From: Fredrik Skog @ 2011-02-03  0:23 UTC (permalink / raw)
  To: LVM general discussion and development

Hello everyone,

Any help on rhis matter would be really appreciated. Right now i have no 
clue on how to proceed in trying to rescue my data.

Thanks

/Fredrik Skog

----- Original Message ----- 
From: "Fredrik Skog" <fredrik.skog@rodang.se>
To: "LVM general discussion and development" <linux-lvm@redhat.com>
Sent: Friday, January 28, 2011 5:51 PM
Subject: [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV


> Hello
>
> I'm somewhat a newbie at LVM and have encountered a real problem for me.
> during resize2fs after extending my LV i ended up with a crash. Now I'm 
> worried I have lost all my old data.
> How can i proceed to get the volume in working order?
> Any help would be greatly appreciated.
>
> NoFear ~ # lvextend -L+400G /dev/vgftp/lvftp
>  Extending logical volume lvftp to 4.16 TiB
>  Logical volume lvftp successfully resized
> NoFear ~ # umount /dev/vgftp/lvftp
> NoFear ~ # resize2fs /dev/vgftp/lvftp
> resize2fs 1.41.10 (10-Feb-2009)
> Please run 'e2fsck -f /dev/vgftp/lvftp' first.
>
> NoFear ~ # e2fsck -f /dev/vgftp/lvftp
> e2fsck 1.41.10 (10-Feb-2009)
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> Block bitmap differences:  +21741823 +21741951 +21742207 +21742973 
> +21742975 +21743102 +21743231 +21743484 +21743487 +21743612 +21743615 
> +21743740 +21743868 +21744125 +21744127 +21744639 +21745149 +21746047 
> +21746559 +21746687 +21746942 +21747327 +21747710 +21747967 +21748092 
> +21748223 +21748735 +(21748990--21748991) +21749118 +(21749372--21749373) 
> +21749501 +21749503 +21749887 +21750143 +21750398 +21750655 +21750909 
> +21751037 +21751165 +(21751549--21751550) +21751676 +21751807 +21751934
> Fix<y>? yes
>
> Block bitmap differences:  +33341823 +33343103 +33343356 +33343359 
> +33343484 +33343487 +33343612 +33343740 +33343997 +33343999 +33345919 
> +33346431 +33346559 +33346814 +33347199 +33347582 +33347839 +33348095 
> +33348607 +33348862 +(33349244--33349245) +33349373 +33349759 +33350015 
> +33350781 +33350909 +33351037 +33351422y^Hy
> +33351679
> Fix<y>? yes
>
> ---- SNIPP ----
>
> Block bitmap differences:  +26067327 +26068607 +26068860 +26068863 
> +26068988 +26068991 +26069116 +26069244 +26069501 +26069503 +26071423 
> +26071935 +26072063 +26072318 +26072703 +26073343 +26073599 +26074111 
> +26074366 +(26074748--26074749) +26074877 +26075263 +26075519 +26076285 
> +26076413 +26076541 +26077183
> Fix<y>? yes
>
>
> /dev/vgftp/lvftp: ***** FILE SYSTEM WAS MODIFIED *****
> /dev/vgftp/lvftp: 308343/505479168 files (18.3% non-contiguous), 
> 1006593162/1010942976 blocks
>
> NoFear ~ # e2fsck -f /dev/vgftp/lvftp
> e2fsck 1.41.10 (10-Feb-2009)
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> /dev/vgftp/lvftp: 308343/505479168 files (18.3% non-contiguous), 
> 1006593162/1010942976 blocks
> NoFear ~ # resize2fs /dev/vgftp/lvftp
> resize2fs 1.41.10 (10-Feb-2009)
> Resizing the filesystem on /dev/vgftp/lvftp to 1115800576 (4k) blocks.
> ** CRASH / HANG **
>
> 25hours waiting and nothing happens. No disk io going on or anything.
> I have no backups or anythin of this volume. What can i do do revert the 
> process to get the disks back? I have not done anything at all after the 
> crash/hang in fear of destroying something.
>
> Thanks for any input
> /Fredrik Skog
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV
  2011-02-03  0:23   ` Fredrik Skog
@ 2011-02-03 15:46     ` Fredrik Skog
  0 siblings, 0 replies; 5+ messages in thread
From: Fredrik Skog @ 2011-02-03 15:46 UTC (permalink / raw)
  To: LVM general discussion and development

Hello,

Today i tried to run e2fsck on my volume but it just hangs. i tried to mount 
it, it hangs.
Do I dare to reboot or will the machine refuse to start when it tries to 
mount the lost LVM volume?

thanks
/Fredrik Skog

----- Original Message ----- 
From: "Fredrik Skog" <fredrik.skog@rodang.se>
To: "LVM general discussion and development" <linux-lvm@redhat.com>
Sent: Thursday, February 03, 2011 1:23 AM
Subject: Re: [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV


> Hello everyone,
>
> Any help on rhis matter would be really appreciated. Right now i have no 
> clue on how to proceed in trying to rescue my data.
>
> Thanks
>
> /Fredrik Skog
>
> ----- Original Message ----- 
> From: "Fredrik Skog" <fredrik.skog@rodang.se>
> To: "LVM general discussion and development" <linux-lvm@redhat.com>
> Sent: Friday, January 28, 2011 5:51 PM
> Subject: [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV
>
>
>> Hello
>>
>> I'm somewhat a newbie at LVM and have encountered a real problem for me.
>> during resize2fs after extending my LV i ended up with a crash. Now I'm 
>> worried I have lost all my old data.
>> How can i proceed to get the volume in working order?
>> Any help would be greatly appreciated.
>>
>> NoFear ~ # lvextend -L+400G /dev/vgftp/lvftp
>>  Extending logical volume lvftp to 4.16 TiB
>>  Logical volume lvftp successfully resized
>> NoFear ~ # umount /dev/vgftp/lvftp
>> NoFear ~ # resize2fs /dev/vgftp/lvftp
>> resize2fs 1.41.10 (10-Feb-2009)
>> Please run 'e2fsck -f /dev/vgftp/lvftp' first.
>>
>> NoFear ~ # e2fsck -f /dev/vgftp/lvftp
>> e2fsck 1.41.10 (10-Feb-2009)
>> Pass 1: Checking inodes, blocks, and sizes
>> Pass 2: Checking directory structure
>> Pass 3: Checking directory connectivity
>> Pass 4: Checking reference counts
>> Pass 5: Checking group summary information
>> Block bitmap differences:  +21741823 +21741951 +21742207 +21742973 
>> +21742975 +21743102 +21743231 +21743484 +21743487 +21743612 +21743615 
>> +21743740 +21743868 +21744125 +21744127 +21744639 +21745149 +21746047 
>> +21746559 +21746687 +21746942 +21747327 +21747710 +21747967 +21748092 
>> +21748223 +21748735 +(21748990--21748991) +21749118 +(21749372--21749373) 
>> +21749501 +21749503 +21749887 +21750143 +21750398 +21750655 +21750909 
>> +21751037 +21751165 +(21751549--21751550) +21751676 +21751807 +21751934
>> Fix<y>? yes
>>
>> Block bitmap differences:  +33341823 +33343103 +33343356 +33343359 
>> +33343484 +33343487 +33343612 +33343740 +33343997 +33343999 +33345919 
>> +33346431 +33346559 +33346814 +33347199 +33347582 +33347839 +33348095 
>> +33348607 +33348862 +(33349244--33349245) +33349373 +33349759 +33350015 
>> +33350781 +33350909 +33351037 +33351422y^Hy
>> +33351679
>> Fix<y>? yes
>>
>> ---- SNIPP ----
>>
>> Block bitmap differences:  +26067327 +26068607 +26068860 +26068863 
>> +26068988 +26068991 +26069116 +26069244 +26069501 +26069503 +26071423 
>> +26071935 +26072063 +26072318 +26072703 +26073343 +26073599 +26074111 
>> +26074366 +(26074748--26074749) +26074877 +26075263 +26075519 +26076285 
>> +26076413 +26076541 +26077183
>> Fix<y>? yes
>>
>>
>> /dev/vgftp/lvftp: ***** FILE SYSTEM WAS MODIFIED *****
>> /dev/vgftp/lvftp: 308343/505479168 files (18.3% non-contiguous), 
>> 1006593162/1010942976 blocks
>>
>> NoFear ~ # e2fsck -f /dev/vgftp/lvftp
>> e2fsck 1.41.10 (10-Feb-2009)
>> Pass 1: Checking inodes, blocks, and sizes
>> Pass 2: Checking directory structure
>> Pass 3: Checking directory connectivity
>> Pass 4: Checking reference counts
>> Pass 5: Checking group summary information
>> /dev/vgftp/lvftp: 308343/505479168 files (18.3% non-contiguous), 
>> 1006593162/1010942976 blocks
>> NoFear ~ # resize2fs /dev/vgftp/lvftp
>> resize2fs 1.41.10 (10-Feb-2009)
>> Resizing the filesystem on /dev/vgftp/lvftp to 1115800576 (4k) blocks.
>> ** CRASH / HANG **
>>
>> 25hours waiting and nothing happens. No disk io going on or anything.
>> I have no backups or anythin of this volume. What can i do do revert the 
>> process to get the disks back? I have not done anything at all after the 
>> crash/hang in fear of destroying something.
>>
>> Thanks for any input
>> /Fredrik Skog
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ 

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-02-03 15:46 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-27 18:25 [linux-lvm] guruplug 2.6.37 lvm2 problem Jason
2011-01-28 16:51 ` [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV Fredrik Skog
2011-02-03  0:23   ` Fredrik Skog
2011-02-03 15:46     ` Fredrik Skog
2011-02-02 15:31 ` [linux-lvm] guruplug 2.6.37 lvm2 problem Milan Broz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).