If the internal copy of LVM2 is used (which is 2.02.28), one can get the same errors as reported in bug 207612. Please bump and use a later copy of LVM2 (2.02.37 is stable currently).
I second this.
You can second this all you want. Have you actually bumped the version in genkernel.conf and tried build an initramfs with it and booting?
I have seen the failures using the internally specified copy. Then I installed the latest ebuild and it used the system copy, which booted. I have not tried editing it so it uses the latest version as an internal copy -- does that cause problems?
I emerged genkernel-9999 today (to get the fix for bug #276753), bumped LVM to latest stable i.e. 2.02.36 in genkernel.conf and it properly booted my RAID+LUKS+LVM system with hardened-sources-2.6.29. I had previously experienced this issue on 2 other systems although I didn't try on this one without bumping LVM. Denis.
And you're sure that you moved your system lvm and lvm.static binaries out of the way so that it would compile lvm internally?
actually people (still) having CONFIG_SYSFS_DEPRECATED or the newer CONFIG_SYSFS_DEPRECATED_V2 set in their kernel will not suffer from this bug. bumping genkernel's internal versions to: DEVICE_MAPPER_VER="1.02.24" LVM_VER="2.02.31" in /etc/genkernel.conf resolves the issue which has not been related to lvm vs. lvm.static at any time but the way block devices are listed in sysfs (i.e. /sys/block/* have become symlinks and older versions of LVM simply ignore rather than follow them). as a side note: I've tried even higher version numbers of LVM here - but they all failed to compile from within calling "genkernel ramdisk"..
to sum things up that means to: - bump the internal version numbers in genkernel.conf to address people that do not have USE=static on sys-fs/lvm2 and/or use >=lvm2-2.02.48-r1 with <genkernel-9999 (wrt bug #276753) - stablize >=genkernel-3.4.10.905-r1 (which then has bug #276753 fixed)
lvm2-2.02.51-r1 became stable for x86. It tooks me hours to find that I had to update genkernel to be able to boot my system again because I have my root partition in a LVM2 volume. So, I think it's quite urgent to stablize >=genkernel-3.4.10.905-r1.
Thanks François for that comment! This has nearly been a disaster here... until I found your solution. Please stabilize the newer genkernel version! Otherwise I guess *ALL* current stable gentoo machines with root on LVM2 are not able to boot ATM.
It's going to be a year old bug soon and yet it managed to hit me. Please bump versions.
I currently cannot get LVM2 compiling from genkernel. I get errors for all of 2.02.28, 2.02.36 and 2.02.74. I have tried applying patches from Gentoo ebuilds, too. Please help me getting a newer version compiling. These commands can get you started. # git clone git://git.overlays.gentoo.org/proj/genkernel.git # git checkout -t origin/experimental # sudo mv /sbin/lvm.static{,_BACKUP} # sudo GK_SHARE="$PWD" ./genkernel initramfs Patches found in ${GK_SHARE}/patches/lvm/${LVM_VER}/ are auto-applied for you.
Created attachment 259742 [details, diff] Fix for LVM 2.02.28 Builds for me, but haven't try to boot from it. Tested just for 2.02.28. Please let me know I did it right, then I will continue for other versions.
Forgot to mention what I did, so here goes: 1) Removed --export-dynamic from configure script. 2) Added -fPIC flags. 3) Made modules internal or none.
Amadeusz, patch applied, thank you!
I just tried booting with the resulting LVM 2.02.28 - it doesn't find the volume group. I'll try to look into it. Help welcome.
Created attachment 259976 [details, diff] 0001-Fix-for-LVM-2.02.72-compilation.patch Do we have to support previous versions of LVM? LVM 2.02.72 doesn't need external device-mapper package. It has libdm integrated. Builds without the problem with provided patch. I've checked also resulting binary. ./lvm vgdisplay returns expected results. Although I haven't booted resulting image.
(In reply to comment #16) > Created an attachment (id=259976) [details] > 0001-Fix-for-LVM-2.02.72-compilation.patch Thanks! > Do we have to support previous versions of LVM? Maybe not. > [..] Although I haven't booted resulting image. Boots perfect in with Luks over here.
(In reply to comment #17) > > Do we have to support previous versions of LVM? > > Maybe not. So, just let me know if it will be required to look at previous versions. I don't won't to do useless work. :-)
Newer LVM is fine as long as you don't need to support older kernels. The new LVM will not work correctly with kernels older than a certain release. Similarly, new kernels require the new LVM.
