All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.