Hi, please see attached ebuild for multipath-tools multipath-tools-0.3.7.ebuild my reason for writing this is that current versions of udev appear to no longer contain the devmap_name binary which can be used to identify device mapper nodes in udev rules instead it has been moved into multipath-tools I've also included a patch to alter the /etc/init.d/multipathd script to something more resembling the gentoo standard note: 1. the depend in this script may need to be tweaked a bit 2. multipathd will not start if devfs is in use, you have to be using udev for this also a default set of udev rules is written for multipath into /etc/udev/rules.d/40-multipath.rules I'd imagine that this would fit into sys-fs class also it would appear that it won't compile without a later version of device-mapper so I've added this as a depend you may need to add =sys-libs/device-mapper-1.00.19-r1 to /etc/portage/package.keywords to get this to compile
Created attachment 44248 [details] multipath-tools 0.3.7 ebuild
Created attachment 44249 [details, diff] gentoo patch for the init.d script for multipathd
Something to bear in mind..official kernels dont carry multipath yet. gentoo-dev-sources does though :)
Hi, i tried your ebuild and the compile fails. Does this only work with gentoo-dev sources? Here are my errors: /bin/gzip -9 -c multipathd.8 > multipathd.8.gz make[1]: Leaving directory `/var/tmp/portage/multipath-tools-0.3.7/work/multipath-tools-0.3.7/multipathd' make[1]: Entering directory `/var/tmp/portage/multipath-tools-0.3.7/work/multipath-tools-0.3.7/kpartx' rm -f core *.o *.gz gcc -pipe -g -Wall -Wunused -Wstrict-prototypes -I. -I../libmultipath -c -o bsd.o bsd.c gcc -pipe -g -Wall -Wunused -Wstrict-prototypes -I. -I../libmultipath -c -o dos.o dos.c gcc -pipe -g -Wall -Wunused -Wstrict-prototypes -I. -I../libmultipath -c -o kpartx.o kpartx.c gcc -pipe -g -Wall -Wunused -Wstrict-prototypes -I. -I../libmultipath -c -o solaris.o solaris.c gcc -pipe -g -Wall -Wunused -Wstrict-prototypes -I. -I../libmultipath -c -o unixware.o unixware.c gcc -pipe -g -Wall -Wunused -Wstrict-prototypes -I. -I../libmultipath -c -o gpt.o gpt.c gcc -pipe -g -Wall -Wunused -Wstrict-prototypes -I. -I../libmultipath -c -o crc32.o crc32.c gcc -pipe -g -Wall -Wunused -Wstrict-prototypes -I. -I../libmultipath -c -o lopart.o lopart.c gcc -pipe -g -Wall -Wunused -Wstrict-prototypes -I. -I../libmultipath -c -o xstrncpy.o xstrncpy.c In file included from lopart.c:30: loop.h:82: error: syntax error before "__kernel_old_dev_t" loop.h:82: warning: no semicolon at end of struct or union loop.h:84: error: syntax error before "lo_rdevice" loop.h:84: warning: type defaults to `int' in declaration of `lo_rdevice' loop.h:84: warning: data definition has no type or storage class loop.h:93: error: syntax error before '}' token lopart.c: In function `find_loop_by_file': lopart.c:100: error: storage size of `loopinfo' isn't known lopart.c:100: warning: unused variable `loopinfo' lopart.c: In function `find_unused_loop_device': lopart.c:144: error: storage size of `loopinfo' isn't known lopart.c:144: warning: unused variable `loopinfo' lopart.c: In function `set_loop': lopart.c:225: error: storage size of `loopinfo' isn't known lopart.c:225: warning: unused variable `loopinfo' make[1]: *** [lopart.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/multipath-tools-0.3.7/work/multipath-tools-0.3.7/kpartx' make: *** [recurse] Error 2 !!! ERROR: sys-libs/multipath-tools-0.3.7 failed. !!! Function src_compile, Line 45, Exitcode 2 !!! make failed
so far I tried this on 2.6.9-nitro3 to begin with and I've recently tried it against 2.6.9-gentoo-r4 (by altering KERNEL_BUILD in the Makefiles to compile against the gentoo dev sources) and it seems to be okay looking at the error, I think something in your kernel needs to be patched for this to work, as the error appears relate to loop.h which I think is part of the loopback module in the kernel tree looking at the README for multipath one requirement is: Linux kernel 2.6.0 with udm5 patchset (or greater) http://people.sistina.com/~thornber/dm/ (deprecated) ftp://sources.redhat.com/pub/dm/ so perhaps you need to patch device mapper in the kernel to a later version
I'm using 2.6.9-gentoo-r6 and getting same error as above. You said, that you edited KERNEL_BUILD (in multipath-tools makefiles?), to what did you edit it?
forget about KERNEL_BUILD, this was something I just did to compile / build against a different kernel than the one I was running in order to try and reproduce the error I've actually compiled and booted to 2.6.8-gentoo-r4, but it still compiles okay without the error I've also downgraded to linux26-headers-2.6.8.1 (as I was using / unmasked linux26-headers-2.6.8.1-r1 before) but it still compiles okay I've tried this on 2 different machines one a P4 another an amd64 but I can't get it to fail if it's looking at /usr/include/loop.h then this might be something to do with linux26-headers which version are you using?
Heh. I was using linux-headers (2.4.something). Now I'm installing linux-headers 2.6.8.1. I didn't even know, that there was linux26-headers. :P I'm hoping that these work. :P
Created attachment 44855 [details] multipath-tools-0.3.7-r1.ebuild added linux26-headers as a depend
Works like a charm, though, I had to set RC_DEVICE_TARBALL="yes" in /etc/conf.d/rc in order to get my LVM2-thingie to work.
If you want evms or lvm to show up in a udev system without using the the tarball setting I've just got this working recently see here http://forums.gentoo.org/viewtopic.php?p=1819011#1819011
I guess, we don't need the executable flag on 40-multipath.rules If so, you might add the following to the ebuild. chmod 644 ${D}/etc/udev/rules.d/40-multipath.rules By the way, there is a newer version of multipath-tools available: 0.3.9. Renaming your 0.3.7-r1 ebuild works to install the package. I have not really tested it yet, though.
Created attachment 45645 [details] multipath-tools-0.3.9.ebuild Yep your right, the file isn't executable by default in the src dir, so it must be something in the Makefile making it executable I've added the chmod into the ebuild
This works for me. I found it essential for getting lvm2 and dm-crypt working with udev.
there is a newer version available now: 0.4.2. Just renaming the 0.3.9 ebuild works for me.
0.4.2 also works for me. I recently performed a fresh install with all filesystems (apart from /boot) on lvm2 over dm-crypt using the 20050130 experimental livecd. It would have been much easier with multipath-tools installed on the livecd system. I also needed hashalot for use with dmsetup because cryptsetup breaks when using the new essiv scheme (which is essential to avoid known vulnerabilities).
Created attachment 52074 [details] multipath-tools-0.4.2.ebuild
Created attachment 52512 [details] multipath-tools-0.4.2-r1.ebuild slight alteration to the depends now that device-mapper has moved across from sys-libs to sys-fs
/sbin/multipath from multipath-tools-0.4.2 links to /usr/lib which caused lots of "/sbin/multipath error while loading shared libraries" errors on boot. # ldd /sbin/multipath linux-gate.so.1 => (0xffffe000) libdevmapper.so.1.00 => /lib/libdevmapper.so.1.00 (0xb7fe0000) <----- libsysfs.so.0 => /usr/lib/libsysfs.so.0 (0xb7fd6000) libc.so.6 => /lib/libc.so.6 (0xb7ebc000) /lib/ld-linux.so.2 (0xb7feb000) That library should be either in /lib or this should be compiled statically.
I'm not sure which lib you mean but if you run qpkg -l multipath-tools there are no libs installed as part of multipath-tools it's using libs from other packages linux-gate.so.1 => (0xffffe000) libdevmapper.so.1.00 => /lib/libdevmapper.so.1.00 (0xb7fe0000) <----- libsysfs.so.0 => /usr/lib/libsysfs.so.0 (0xb7fd6000) libc.so.6 => /lib/libc.so.6 (0xb7ebc000) /lib/ld-linux.so.2 (0xb7feb000) device-mapper, sysfsutils, glibc if this is something your trying to use in an initrd then you need to copy the libs across manually or try to compile the package staticly currently the ebuild doesn't have support for the static use flag as I can't see a way or option for a static compile to take place within the source (there's no configure just make) trying to run /sbin/multipath myself just gives the error "device mapper prerequisites not met." I'm not sure what that means but I tend to only use this for kpartx
With sysfsutils-1.2.0 it looks like: # ldd /sbin/multipath libsysfs.so.1 => /usr/lib/libsysfs.so.1 (0xb7fd3000) I cannot emerge multipath-tools statically, there is no static use flag for that.
Sorry, I forgot to mention that /sbin/multipath is called during boot when using LVM2 with initrd created via `genkernel initrd --lvm2 --udev`; so how can I solve this? Just copy the library from /usr/lib to /lib?
wherever /sbin/multipath is run it's going to look for the lib under /usr/lib/ if it's run inside the initrd then the file /usr/lib/libsysfs.so.1 will need to be present inside the initrd's /usr/lib directory if it;s run after the initrd (I think more likely from your description) then it would need to be present inside /usr/lib/ on the root filesystem can I assume that /usr is a seperate mounted directory, not mounted until after multipath? In this case the lib in question would need to be present on the rootfs unmounted version of /usr i.e. # so we can get access to the unmounted version of /usr on the rootfs mkdir /mnt/test mount --bind / /mnt/test mkdir -p /mnt/test/usr/lib cp -a /usr/lib/libsysfs.so.1 /mnt/test/usr/lib/ umount /mnt/test without knowing how your system is setup it's difficult to say
Created attachment 55616 [details] multipath-tools-0.4.3.ebuild New version also slight change to the depends for linux-headers
Comment #23: Yes, /usr is a separate logical LVM2 volume.
Warning there seems to be a bug with respect to using devmap_name from 0.4.3 with udev (lots of other addtional device nodes such as hda5p1 hdap2 etc are created) 0.4.2 is okay though although I've recently found a better way to use device-mapper with udev dmsetup from 1.0.20 onwards now provides the same functionality as devmap_name using dmsetup info -j <major> -m <minor>
Has anybody gotten dmsetup to work in the udev rules in place of devmap_name? The documentation of dmsetup is rather sparse and some of it contradictory. The developers' documentation at Red Hat is often different from the man page. At present it looks as though we are still dependent on multipath-tools to get LVM2 volumes mapped as devices under udev. This means, of course, that the package should *never* depend upon libraries or configuration files that could be stored on LVM2 volumes; all its resources should reside on the root filesystem. Failing that, some hints on getting dmsetup to do something useful would be appreciated.
already done check out the post near the bottom of the page I've done some small scripts for udev that use dmsetup instead of devmap_name http://forums.gentoo.org/viewtopic-t-263996-highlight-.html you'll need device-mapper 1.00.20 at the very least (current version is now above that so no unmasking should be needed with an up to date system) the only thing to look out for is that kpartx (also from multipath) seems to not work too well with this method (some form of timing problem I think with kpartx) but it's possible to get around that with another script if needs be
(In reply to comment #23) > wherever /sbin/multipath is run it's going to look for the lib under /usr/lib/ > if it's run inside the initrd then the file /usr/lib/libsysfs.so.1 will need to be present inside the initrd's /usr/lib directory > > if it;s run after the initrd (I think more likely from your description) > then it would need to be present inside /usr/lib/ on the root filesystem > > can I assume that /usr is a seperate mounted directory, not mounted until after multipath? > In this case the lib in question would need to be present on the rootfs unmounted version of /usr Sorry, what would be the problem with moving the lib under /lib? I use LVM2, have /usr as a separate partition, and got problems with LVM2 linking to readline -> ncurses -> libgpm. I reported this and got this exact fix for my case merged (i.e. libgpm was moved into /lib). Would this have any drawbacks? I think that anything from /bin or /sbin linking to libs outside /lib could be flagged as an ebuild problem, even as a QA notice (there are some for runtime text relocations, which are much less likely to get fixed and cause less problems).
I have raised this issue in bug #82970, which is for sysfsutils-1.2.0 to be released as stable. I hope an ebuild change will be forthcoming that will place libsysfs.so under /lib. It might be prudent to add a symlink under /usr/lib so that exisitng programs that use the previous location can still find the library.
multipath-tools has been in portage a while, closing this bug.
