When you use ROOT to install baselayout into an empty chroot dir, it screws up the /lib -> /lib64 thing. Instead of the former being a symlink to the latter, both end up as dirs and content gets split between them resulting in an unusable system. It appears that the cause of this problem is glibc. kagome chroot # ROOT=/home/agaffney/dev/gli/livecd/chroot/amd64-2 emerge -pK baselayout These are the packages that I would merge, in order: Calculating dependencies ...done! [binary N ] sys-libs/gpm-1.20.1-r5 to /home/agaffney/dev/gli/livecd/chroot/amd64-2/ [binary N ] sys-devel/patch-2.5.9-r1 to /home/agaffney/dev/gli/livecd/chroot/amd64-2/ [binary N ] sys-libs/ncurses-5.5-r1 to /home/agaffney/dev/gli/livecd/chroot/amd64-2/ [binary N ] app-shells/bash-3.1_p7 to /home/agaffney/dev/gli/livecd/chroot/amd64-2/ [binary N ] sys-libs/readline-5.1_p2 to /home/agaffney/dev/gli/livecd/chroot/amd64-2/ [binary N ] sys-apps/sysvinit-2.86-r3 to /home/agaffney/dev/gli/livecd/chroot/amd64-2/ [binary N ] sys-libs/timezone-data-2006a to /home/agaffney/dev/gli/livecd/chroot/amd64-2/ [binary N ] sys-libs/glibc-2.3.6-r2 to /home/agaffney/dev/gli/livecd/chroot/amd64-2/ [binary N ] sys-devel/gettext-0.14.5 to /home/agaffney/dev/gli/livecd/chroot/amd64-2/ [binary N ] sys-apps/coreutils-5.93 to /home/agaffney/dev/gli/livecd/chroot/amd64-2/ [binary N ] sys-apps/baselayout-1.12.0_pre15-r1 to /home/agaffney/dev/gli/livecd/chroot/amd64-2/ glibc installs the following: var/db/pkg/sys-libs/glibc-2.3.6-r2/CONTENTS:sym /lib/ld-linux.so.2 -> ../lib32/ld-linux.so.2 1139501863 before baselayout is installed, which creates /lib as a dir. When baselayout is installed, /lib already exists, so I assume that it skips (or just silently fails) creating the /lib -> /lib64 symlink. The end result is a very broken system. You get weird stuff like the init scripts not being able to find their stuff since they look in /lib/rcscripts/awk/ and the stuff is actually in /lib64/rcscripts/awk/. While this doesn't affect most users (the stage tarball already has the symlink to begin with), it is still an issue. I'm running into this with the installer on amd64 (which was how I discovered it), but I'm working around it (not tested yet) by creating /lib64 as a dir and /lib as a symlink to /lib64 before I ever install anything into the chroot.
*** This bug has been marked as a duplicate of 133547 ***
Where was this actually fixed? The same procedure yields a proper /lib{,32,64} setup now, but it doesn't appear that the current version of glibc creates the symlink that was causing problems anymore. If the fix was in baselayout, I can't really properly test this anymore. Looking in /usr, I'm seeing that the problem may still exist. kagome lib64 # ls -l /home/agaffney/dev/gli/livecd/chroot/amd64-2/usr/ total 40 drwxr-xr-x 2 root root 4096 May 18 18:51 bin drwxr-xr-x 26 root root 4096 May 18 18:51 include drwxr-sr-x 2 root root 4096 May 18 18:51 lib drwxr-sr-x 4 root root 4096 May 18 18:51 lib32 drwxr-xr-x 6 root root 4096 May 18 18:51 lib64 drwxr-xr-x 9 root root 4096 May 18 18:51 local drwxr-xr-x 2 root root 4096 May 18 18:51 portage drwxr-xr-x 2 root root 4096 May 18 18:51 sbin drwxr-xr-x 14 root root 4096 May 18 18:51 share drwxr-xr-x 2 root root 4096 May 18 18:51 src kagome lib64 # ls -l /home/agaffney/dev/gli/livecd/chroot/amd64-2/usr/lib total 0 lrwxrwxrwx 1 root root 17 May 18 18:51 locale -> /usr/lib64/locale This symlink is created by glibc (the previous problem child) being installed before baselayout and creating /usr/lib as a dir. sys-libs/glibc-2.4-r3/CONTENTS:sym /usr/lib/locale -> /usr/lib64/locale 1147996278
glibc-2.4-r3+ and glibc-2.3.6-r4+ do the right thing now
