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