* [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.