On Thu, Dec 01, 2005 at 10:37:47PM +0100, maximilian attems wrote: > tags 337176 moreinfo > tags 337607 moreinfo > stop > > On Wed, 02 Nov 2005, Daniel Jacobowitz wrote: > > > The generated initrd has ld.so in /lib, but no /lib64 symlink. But the ELF > > interpreter of all amd64 binaries points to /lib64. So the kernel fails to > > load /bin/sh. > > > > I'm going to try with the directory manually created next. > > > please retest with latest initramfs-tools and udev from unstable, > that issue should be fixed, i`ve at least 2 reported successes.
I've got good news and bad news :-) It basically works. However, there was one problem. I have a 32-bit Debian chroot on this amd64 machine, and its library directories are in /etc/ld.so.conf. Which basically works. But, due to a quirk in ldconfig and some Debian-specific rules on symlinks out of /usr, I've got this: [EMAIL PROTECTED]:~% ls -l /space/chroot/i686/usr/lib/libncurses.so.5 lrwxrwxrwx 1 root root 13 Sep 27 10:15 /space/chroot/i686/usr/lib/libncurses.so.5 -> libtermcap.so [EMAIL PROTECTED]:~% ls -l /space/chroot/i686/usr/lib/libtermcap.so lrwxrwxrwx 1 root root 13 Oct 28 09:37 /space/chroot/i686/usr/lib/libtermcap.so -> libncurses.so [EMAIL PROTECTED]:~% ls -l /space/chroot/i686/usr/lib/libncurses.so lrwxrwxrwx 1 root root 20 Oct 28 09:37 /space/chroot/i686/usr/lib/libncurses.so -> /lib/libncurses.so.5 Note, it's pointing all the way back to the 64-bit library. My 64-bit programs run using /space/chroot/i686/usr/lib/libncurses.so.5 by default. mkinitramfs-tools successfully copies this to the ramdisk. It does not copy ld.so.conf, however, and I don't remember whether it runs ldconfig. If it did those, this would work. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
