Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 71703 - multipath-tools-0.3.7.ebuild (New Package)
Summary: multipath-tools-0.3.7.ebuild (New Package)
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Gentoo's Team for Core System packages
Keywords: EBUILD
Depends on:
Reported: 2004-11-18 15:17 UTC by Richard Westwell
Modified: 2005-12-06 09:17 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---

multipath-tools 0.3.7 ebuild (multipath-tools-0.3.7.ebuild,1.59 KB, text/plain)
2004-11-18 15:19 UTC, Richard Westwell
gentoo patch for the init.d script for multipathd (multipath-tools-gentoo-init.patch,1.35 KB, patch)
2004-11-18 15:20 UTC, Richard Westwell
Details | Diff
multipath-tools-0.3.7-r1.ebuild (multipath-tools-0.3.7-r1.ebuild,1.62 KB, application/octet-stream)
2004-11-28 04:11 UTC, Richard Westwell
multipath-tools-0.3.9.ebuild (multipath-tools-0.3.9.ebuild,1.74 KB, application/octet-stream)
2004-12-09 16:34 UTC, Richard Westwell
multipath-tools-0.4.2.ebuild (multipath-tools-0.4.2.ebuild,1.74 KB, text/plain)
2005-02-24 17:01 UTC, Richard Westwell
multipath-tools-0.4.2-r1.ebuild (multipath-tools-0.4.2-r1.ebuild,1.73 KB, text/plain)
2005-03-02 16:28 UTC, Richard Westwell
multipath-tools-0.4.3.ebuild (multipath-tools-0.4.3.ebuild,1.73 KB, text/plain)
2005-04-07 16:58 UTC, Richard Westwell

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Westwell 2004-11-18 15:17:33 UTC

please see attached ebuild for multipath-tools

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
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
Comment 1 Richard Westwell 2004-11-18 15:19:02 UTC
Created attachment 44248 [details]
multipath-tools 0.3.7 ebuild
Comment 2 Richard Westwell 2004-11-18 15:20:23 UTC
Created attachment 44249 [details, diff]
gentoo patch for the init.d script for multipathd
Comment 3 Daniel Drake (RETIRED) gentoo-dev 2004-11-18 15:52:05 UTC
Something to bear in mind..official kernels dont carry multipath yet. gentoo-dev-sources does though :)
Comment 4 Daniel Kerwin 2004-11-19 05:22:46 UTC

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

Comment 5 Richard Westwell 2004-11-20 10:31:05 UTC
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) (deprecated)

so perhaps you need to patch device mapper in the kernel to a later version
Comment 6 Oskari Timperi 2004-11-25 06:18:18 UTC
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?
Comment 7 Richard Westwell 2004-11-27 17:36:07 UTC
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-
(as I was using / unmasked linux26-headers- 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?
Comment 8 Oskari Timperi 2004-11-28 00:05:36 UTC
Heh. I was using linux-headers (2.4.something). Now I'm installing linux-headers I didn't even know, that there was linux26-headers. :P I'm hoping that these work. :P
Comment 9 Richard Westwell 2004-11-28 04:11:39 UTC
Created attachment 44855 [details]

added linux26-headers as a depend
Comment 10 Oskari Timperi 2004-11-28 10:01:51 UTC
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.
Comment 11 Richard Westwell 2004-11-28 13:54:58 UTC
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
Comment 12 Urs Joss 2004-12-08 05:12:43 UTC
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.
Comment 13 Richard Westwell 2004-12-09 16:34:10 UTC
Created attachment 45645 [details]

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
Comment 14 Michael Ossmann 2005-01-26 19:26:41 UTC
This works for me.  I found it essential for getting lvm2 and dm-crypt working with udev.
Comment 15 Peter Beutner 2005-01-29 05:25:46 UTC
there is a newer version available now: 0.4.2. Just renaming the 0.3.9 ebuild works for me.
Comment 16 Michael Ossmann 2005-02-15 13:18:46 UTC
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).
Comment 17 Richard Westwell 2005-02-24 17:01:21 UTC
Created attachment 52074 [details]
Comment 18 Richard Westwell 2005-03-02 16:28:16 UTC
Created attachment 52512 [details]

slight alteration to the depends now that device-mapper has moved across from
sys-libs to sys-fs
Comment 19 Jakub Moc (RETIRED) gentoo-dev 2005-03-24 10:23:09 UTC
/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 =>  (0xffffe000) => /lib/ (0xb7fe0000) <----- => /usr/lib/ (0xb7fd6000) => /lib/ (0xb7ebc000)
        /lib/ (0xb7feb000)

That library should be either in /lib or this should be compiled statically.
Comment 20 Richard Westwell 2005-03-30 15:03:01 UTC
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 =>  (0xffffe000) => /lib/ (0xb7fe0000) <----- => /usr/lib/ (0xb7fd6000) => /lib/ (0xb7ebc000)
        /lib/ (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
Comment 21 Jakub Moc (RETIRED) gentoo-dev 2005-03-31 02:19:17 UTC
With sysfsutils-1.2.0 it looks like:

# ldd /sbin/multipath => /usr/lib/ (0xb7fd3000)

I cannot emerge multipath-tools statically, there is no static use flag for that. 
Comment 22 Jakub Moc (RETIRED) gentoo-dev 2005-03-31 02:25:44 UTC
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? 
Comment 23 Richard Westwell 2005-04-07 16:47:20 UTC
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/ 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

# 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/ /mnt/test/usr/lib/
umount /mnt/test

without knowing how your system is setup it's difficult to say
Comment 24 Richard Westwell 2005-04-07 16:58:28 UTC
Created attachment 55616 [details]

New version
also slight change to the depends for linux-headers
Comment 25 Jakub Moc (RETIRED) gentoo-dev 2005-04-07 23:52:54 UTC
Comment #23: Yes, /usr is a separate logical LVM2 volume. 
Comment 26 Richard Westwell 2005-04-09 16:12:06 UTC
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>
Comment 27 David W Noon 2005-05-05 08:02:38 UTC
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.
Comment 28 Richard Westwell 2005-05-12 12:45:30 UTC
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

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
Comment 29 BlaisorBlade 2005-05-24 09:52:24 UTC
(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/ 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 
Comment 30 David W Noon 2005-05-24 15:19:24 UTC
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 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.
Comment 31 Daniel Drake (RETIRED) gentoo-dev 2005-12-06 09:17:33 UTC
multipath-tools has been in portage a while, closing this bug.