I get this incorrect message when I try to start the lvm init scripts: # /etc/init.d/lvm start lvm |* The lvm init-script is written for baselayout-2! lvm |* Please do not use it with baselayout-1!. lvm |* ERROR: lvm failed to start I am running openrc/baselayout2: # qlist openrc |grep '/librc.so$' /usr/lib64/librc.so /lib64/librc.so but the lvm initscripts look for librc.so at /lib/librc.so. As a workaround, I ran: $ cd /lib $ ln -s ../lib64/librc.so After convincing the lvm iniscripts that openrc was installed, I got the following error: # rc-service lvm start lvm |* ERROR: lvm failed to start this is because lvm2 and a few other apps have installed addons to /lib/rcscripts rather than /lib64/rcscripts where openrc looks for them: # qfile /lib/rcscripts sys-fs/cryptsetup (/lib/rcscripts) sys-fs/lvm2 (/lib/rcscripts) sys-fs/device-mapper (/lib/rcscripts) I worked around this by moving all files in /lib/rcscripts into /lib64/rcscripts and making /lib/rcscripts a symlink to /lib64/rcscripts. However, I think that the ebuilds should install the initscript/openrc addons into the correct location. The mdadm ebuild is an example of how to handle this correctly. I also think the scripts should change the check for baselayout2/openrc to something more reasonable than checking if /lib/librc.so exists. mdadm's initscripts also do wrong an look for /lib/rc.so. Maybe this bug report is about too many packages/should be a meta bug/should block a metabug. Reproducible: Always Steps to Reproduce:
Your /lib should be a symlink to /lib64, so as a result this works. If it's not then your system is broken.
(In reply to comment #1) > Your /lib should be a symlink to /lib64, so as a result this works. If it's not > then your system is broken. > The only part of my system which seems to be broken by my not having /lib symlinked to /lib64 is the rc scripts. Not OpenRC itself, but the scripts that attempted to make use of its addons capability. Not to say that OpenRC is correct... Regardless of whether or not /lib/rcscripts should be a symlink to /lib64/rcscripts, other programs which use libraries (like librc.so) always look in /lib64 rather than /lib. I still think it is incorrect for scripts/programs to look for /lib/rc.so when bug #209679 is considered legitimate. Or is /usr/lib* treated differently than /lib* ? Before I haphazardly mess with my /lib* directories, may you answer a few of the following questions? Why does mdadm install scripts to /lib64/rcscripts/addons rather than /lib/rcscripts/addons? Why does OpenRC install files to /lib64/rc rather than /lib/rc? What I'm most interested in is this: what package is responsible for creating /lib as a symlink to /lib64? I just did a fresh binary-package-based reinstall of my system as I upgraded to a new HD and the resulting root doesn't have a symlink. baselayout-2.0.0 is a package that I had in my binpkgs and I'd guess that it would be responsible for the symlink. But it didn't create the symlink when I did the ``somewhat fresh'' binkpkg-based install. Should I file this as another bug? After reading http://devmanual.gentoo.org/archs/amd64/index.html#libdir-links , I am convinced of three things: 1). The devmanual is out of date :-D. My system appears to be using the ``>=2005.0/no-symlink'' option, but there are not profiles with the names described in the devman in ${PORTDIR}/profiles. 2). OpenRC is looking for scripts in the wrong place: /lib64. The devmanual says arch-independent stuff should go in /lib. I'd consider shell-scripts to be arch-independent. This means OpenRC has to move /lib64/rc to /lib/rc and the same for /lib64/rcscripts. Now do I have to fire a bug at OpenRC? Does Roy Marples, who is respected by Gentoo, respect the Gentoo devmanual? This idea of arch-independent stuff makes sense to me. 3). Any rc-script which looks for /lib/librc.so is also incorrect - librc.so is a native binary containing arch specific code and _should_ be looked for in /lib64. Any program which _should_ look for that binary will be linked by binutils and binutils will automatically look in /lib64 when appropriate. I don't think shell-scripts are supposed to deal with files that ld can find easily when given ``-lrc''. Maybe this is what this bug's scope should be reduced to - finding a better way to determine if openrc is installed. ``rc --version | grep OpenRC 2>/dev/null >/dev/null'' might work? Sorry for the long and drawn out comment: maybe what I've said belongs in a ml rather than bugcomment?
I did a fix for now, no revision bump, re-emerge to get it. I raised an email on the -dev list, because I can see other places with breakage on no-symlink profiles with 64-bit userspace.
(In reply to comment #3) > I did a fix for now, no revision bump, re-emerge to get it. Thanks > I raised an email on the -dev list, because I can see other places with > breakage on no-symlink profiles with 64-bit userspace. I am interested to hear what comes of this. Maybe I'm just crazy and should just symlink my /lib dirs - yet I still am interested in the ``arch neutral'' idea...
