I have tried all combinations of Device-mapper 1.02.02, 1.02.03, 1.02.05 with LVM2 2.01.09 and 2.02.05 and the same problem happens: lvcreate -L 2G -n kk vg /dev/ram0: ioctl BLKBSZGET failed: Invalid argument /dev/ram0: ioctl BLKBSZGET failed: Invalid argument /dev/ram1: ioctl BLKBSZGET failed: Invalid argument /dev/ram1: ioctl BLKBSZGET failed: Invalid argument /dev/ram2: ioctl BLKBSZGET failed: Invalid argument /dev/ram2: ioctl BLKBSZGET failed: Invalid argument /dev/ram3: ioctl BLKBSZGET failed: Invalid argument /dev/ram3: ioctl BLKBSZGET failed: Invalid argument /dev/ram4: ioctl BLKBSZGET failed: Invalid argument /dev/ram4: ioctl BLKBSZGET failed: Invalid argument /dev/ram5: ioctl BLKBSZGET failed: Invalid argument /dev/ram5: ioctl BLKBSZGET failed: Invalid argument /dev/ram6: ioctl BLKBSZGET failed: Invalid argument /dev/ram6: ioctl BLKBSZGET failed: Invalid argument /dev/ram7: ioctl BLKBSZGET failed: Invalid argument /dev/ram7: ioctl BLKBSZGET failed: Invalid argument /dev/ram8: ioctl BLKBSZGET failed: Invalid argument /dev/ram8: ioctl BLKBSZGET failed: Invalid argument /dev/ram9: ioctl BLKBSZGET failed: Invalid argument /dev/ram9: ioctl BLKBSZGET failed: Invalid argument /dev/ram10: ioctl BLKBSZGET failed: Invalid argument /dev/ram10: ioctl BLKBSZGET failed: Invalid argument /dev/ram11: ioctl BLKBSZGET failed: Invalid argument /dev/ram11: ioctl BLKBSZGET failed: Invalid argument /dev/ram12: ioctl BLKBSZGET failed: Invalid argument /dev/ram12: ioctl BLKBSZGET failed: Invalid argument /dev/ram13: ioctl BLKBSZGET failed: Invalid argument /dev/ram13: ioctl BLKBSZGET failed: Invalid argument /dev/ram14: ioctl BLKBSZGET failed: Invalid argument /dev/ram14: ioctl BLKBSZGET failed: Invalid argument /dev/ram15: ioctl BLKBSZGET failed: Invalid argument /dev/ram15: ioctl BLKBSZGET failed: Invalid argument device-mapper: table ioctl failed: Invalid argument Failed to activate new LV. emerge info Portage 2203-svn (hardened/x86, gcc-3.4.5-vanilla, glibc-2.3.6-r3, 2.4.32-grsec-vs1.2.10-KB1 i686) ================================================================= System uname: 2.4.32-grsec-vs1.2.10-KB1 i686 Intel(R) Celeron(R) CPU 2.40GHz Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5, 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.4.26-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg digest distlocks fixpackages nostrip sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/usr/src" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X509 bash-completion berkdb bzip2 chroot crypt debug dlloader erandom expat glibc hardened hpn linuxthreads-tls md5sum ncurses nls pam pam_chroot pam_console pam_timestamp pcre perl pwdb python readline sftplogging ssl tcpd udev userlocales x86 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
device-mapper 1.01.00 with lvm2 2.01.09 is the last combination I know that still works fine, but device-mapper 1.01.00 is no longer in the portage tree.
this bug is dup of bug #120511 that is already solved. Stabilisation querry in bug #136172
Sorry, but u false, this is *not* the same bug! Pls read what this bug is about! We can build lvm2, but when we use it, it generates an improper usage of the device-mapper under layer, and make a lot of trouble. Luckily lvm2 makes backup a lot, and my pvmove command makes unusable a 1,2 TB lvm logical volume, but with vgcfgrestore command i could restore the old config and filesystem. But i should d this pvmove, so pls give me an advice what _exact_ version of lvm2 or device-mapper i should use to not run into this bug? ty, tsabi
Try w/ sys-fs/lvm2-2.02.06 and sys-fs/device-mapper-1.02.08.
*** Bug 145545 has been marked as a duplicate of this bug. ***
I had the "pvmove not working" situation before, but after i upgraded to sys-fs/device-mapper-1.02.09 and sys-fs/lvm2-2.02.06 it works well for me. I really dont know this is based on the same bug or not, but my error is resolved.
(In reply to comment #4) > Try w/ sys-fs/lvm2-2.02.06 and sys-fs/device-mapper-1.02.08. (In reply to comment #6) > I had the "pvmove not working" situation before, but after i upgraded to > sys-fs/device-mapper-1.02.09 and sys-fs/lvm2-2.02.06 it works well for me. > > I really dont know this is based on the same bug or not, but my error is > resolved. Ok, so since the version mismatch looks to be the cause of both this and Bug 145545 and the fix is to upgrade to device-mapper-1.02.08, what's required to get device-mapper-1.02.08 stabilized?
lvm2 2.02.06 is stable and appears to work properly
(In reply to comment #8) > lvm2 2.02.06 is stable and appears to work properly Not quite. lvm2.02.06 and device-mapper-1.02.07 don't play nice together (as I said above in comment #7). This isn't resolved yet until a new device-mapper gets itself stabilized.
(In reply to comment #8) > lvm2 2.02.06 is stable and appears to work properly That's not the point, it still doesn't work <=sys-fs/device-mapper-1.02.07. Needs a fixed dependency and newer device-mapper version stable.
*** Bug 148760 has been marked as a duplicate of this bug. ***
device-mapper 1.02.07 is buggy. please, bump version.
1.02.10 is in the tree (going stable), does this bug exist on that version? Also I am just about to add 1.02.12
(In reply to comment #13) > 1.02.10 is in the tree (going stable), does this bug exist on that version? > Also I am just about to add 1.02.12 > No, doesn't exist.
marking fixed as 1.02.10 is stable in most places