guruplug 2.6.37 lvm2 problem

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/[email protected]/msg221947.html

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

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" <[email protected]>
To: "LVM general discussion and development" <[email protected]>
Sent: Friday, January 28, 2011 5:51 PM
Subject: [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV

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" <[email protected]>
To: "LVM general discussion and development" <[email protected]>
Sent: Thursday, February 03, 2011 1:23 AM
Subject: Re: [linux-lvm] LVM Hang/Crash during resize2fs after adding new PV

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