The summary says it all: % ldd /sbin/cryptsetup|grep usr libpopt.so.0 => /usr/lib/libpopt.so.0 (0xb7ec4000) libcryptsetup.so.0 => /usr/lib/libcryptsetup.so.0 (0xb7eb6000) libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7e28000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7e23000) This should be allowed for a program which could be involved in booting a system. Those libs should be installed int /lib (that's especially true for the one that comes with the package itself). Building it statically doesn't quite work because it would require libdevmapper.a which would be provided by a statically linked lvm2. However, trying to rebuild lvm2 statically tries to pull in baselayout-1 on a baselayout-2 system. Reproducible: Always Steps to Reproduce: Install dynamically linked cryptsetup (on a system with encrypted LVs). Reboot :( Actual Results: Fails to find libpopt.so -> no dmcrypt mappings created.
(In reply to comment #0) > This should be allowed for a program which could be involved in booting a > system. Ooops, there's missing a big fat "not", of course. "This should not be allowed...".
so build it with USE=static
(In reply to comment #2) > so build it with USE=static Please read the above again. I tried.
Static linking is not the best thing to do. This is especially true in an application that is related to system security. Let's assume there is a security flaw found in libgcrypt and fixed soon after. I install the new version and all dynamically linked apps are secure again. But unfortunately had cryptsetup linked statically :-( Too bad. It's a simple rule of thumb: Whatever is installed into / should have its deps installed there, too. No need for insecure static linking.
dont waste your breath on static vs security lectures the libraries cryptsetup uses really have no chance of being moved to / now that i think about it, the ebuild i was looking at was a local one. you must have enabled USE=dynamic. the entire point of this flag was to workaround usage of libs in a separate /usr. you didnt post `emerge --info` like every bugzilla page tells you to. cryptsetup is working fine for me on stable x86.
(In reply to comment #5) > dont waste your breath on static vs security lectures > > the libraries cryptsetup uses really have no chance of being moved to / Why not? > now that i think about it, the ebuild i was looking at was a local one. you > must have enabled USE=dynamic. Of course I do. > the entire point of this flag was to workaround > usage of libs in a separate /usr. I really would prefer a proper solution over a workaround. > you didnt post `emerge --info` like every bugzilla page tells you to. > cryptsetup is working fine for me on stable x86. I'm on unstable x86, here's the relevant USE flags for cryptsetup. # paludis -q cryptsetup * sys-fs/cryptsetup gentoo: 0.1-r3 1.0.5-r1 1.0.6-r2 {:0} installed: 1.0.6-r2* {:0} Description: Tool to setup encrypted devices with dm-crypt Homepage: http://luks.endorphin.org/ http://code.google.com/p/cryptsetup/ License: GPL-2 Installed time: Wed Apr 22 06:30:09 2009 Use flags: (dynamic) (nls) (-selinux) From repositories: gentoo Installed using: paludis-0.36.0 However, as written above, I tried building it statically, but it fails: i686-pc-linux-gnu-gcc -O2 -march=native -fomit-frame-pointer -pipe -Wl,-O1 -o cryptsetup -static cryptsetup.o /usr/lib/libpopt.a ../lib/.libs/libcryptsetup.a -ldevmapper /usr/lib/libgcrypt.a -L/usr/lib /usr/lib/libgpg-error.a -luuid make[2]: Leaving directory `/gentoo/build/sys-fs-cryptsetup-1.0.6-r2/work/cryptsetup-1.0.6/src' make[1]: Leaving directory `/gentoo/build/sys-fs-cryptsetup-1.0.6-r2/work/cryptsetup-1.0.6' /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/ld: cannot find -ldevmapper collect2: ld returned 1 exit status make[2]: *** [cryptsetup] Error 1 This is because lvm2 is not built statically either. If I try to do this, it wants to pull in baselayout-1
(In reply to comment #5) > cryptsetup is working fine for me on stable x86. Do you actually use it while booting your system? Do you have /usr on a separate, encrypted partition/LV?
there's no point in encrypting /usr as it's full of code that is readily available on the internet, so i dont waste time on it. i encrypt my home partition and it works fine of course on stable systems. static linking with device-mapper is about the only issue here that needs to be resolved
*** Bug 297560 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > there's no point in encrypting /usr as it's full of code that is readily > available on the internet, so i dont waste time on it. i encrypt my home > partition and it works fine of course on stable systems. > You don't need to have /usr encrypted in order to make dynamic linking a problem. It is sufficient to have /usr on a separate partition and make use of /etc/conf.d/dmcrypt on baselayout-1. During boot, it tries to unlock the partitions specified in dmcrypt before mounting anything else, including /usr.
only if you configure your system that way
(In reply to comment #11) > only if you configure your system that way > Where and how do I configure this? Is this documented anywhere? Of course, I could hack the init scripts but I wouldn't call this configuration ;)
dont run the script in the boot runlevel if you dont have weird sep partitions like /usr or /var
(In reply to comment #13) > dont run the script in the boot runlevel if you dont have weird sep partitions > like /usr or /var > Ehm, I don't want to sound impolite, so please accept my apology if the following sounds wrong: You do notice that I'm a user and therefore - unwise stated otherwise - you should expect my system to run with the software versions you devs deem safe and supported, i.e. "stable" without any ACCEPT_KEYWORDS except the default one? That means I'm running baselayout-1. You don't explicitly activate the dmcrypt init-script in baselayout-1 and therefore there is (AFAIK) no sane way to change the script from boot runlevel to something else.
baselayout-1 is largely EOL. i could lie and say we're working on a solution if it makes you feel better, but the fact of the matter is that things work as i described in baselayout-2/openrc, so we're not going to do heavy work in baselayout-1. we'll simply let things stabilize.
(In reply to comment #15) > baselayout-1 is largely EOL. i could lie and say we're working on a solution > if it makes you feel better, but the fact of the matter is that things work as > i described in baselayout-2/openrc, so we're not going to do heavy work in > baselayout-1. we'll simply let things stabilize. > I'm fine with that. Saying "fixed in next major release" is something different from "problem does not exist". ;) In the mean time, for me it is an acceptable yet ugly workaround to simply copy the necessary libraries and their respective symlinks from /usr/lib64 to /lib64. For me (and the record, in case another poor soul stumbles upon this), that's libpopt, libgcrypt and libgpg-error. As I've said, ugly as hell, but it works and is easy enough to revert once the root cause is gone.
We currently require that the initramfs mounts /usr. I don't think we are going to take the effort to move libs from /usr/lib to /lib to support separate-/usr systems.
