Cross-posting to the BTS since its relevant to this bug, and might lead to closing it out.
I am running a Debian Sid AMD64 root partition alongside a full Sid i386 partition. Right now, the 32-bit partition is used mostly as a chroot to run openoffice and mplayer, using the directions on the Debian AMD64 howto. I also use it as a full desktop install as a backup. All of my "partitions" are managed using LVM. vgchange, which is used to initialize LVM in an initramfs, depends on libncurses.so.5 (the binary for vgchange is actually located at /lib/lvm-200/lvm). When you follow the FAQ directions to add an ia32 chroot's lib directories to /etc/ld.so.conf[1], ldconfig causes vgchange's dependency on libncurses.so.5 to appear to be satisfied using $(chroot_path)/usr/lib/libncurses.so.5[2], which is itself a symlink. When mkinitramfs builds the initramfs, it dereferences that symlink and places the dereferenced file into the same location in the initramfs image (eg, /mnt/root32/usr/lib/libncurses.so.5). Since that location is not on the library search path in the initramfs, vgchange fails to run, the root fs cannot be found, and the system fails to boot. There's a whole lot of strangeness going on here (at least to me), so I ask the experts: Which package(s) is/are at fault? Should the HOWTO be changed to not recommend adding the chroot's libs to /etc/ld.so.conf? Thanks, -Jonathan [1] Mine looks like this: /usr/X11R6/lib # chroot i386 libs /mnt/root32/lib /mnt/root32/usr/lib /mnt/root32/usr/X11R6/lib [2] ldd /lib/lvm-200/lvm returns: libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x00002aaaaabc3000) libreadline.so.5 => /lib/libreadline.so.5 (0x00002aaaaacd4000) libselinux.so.1 => /lib/libselinux.so.1 (0x00002aaaaae13000) libdl.so.2 => /lib/libdl.so.2 (0x00002aaaaaf26000) libncurses.so.5 => /mnt/root32/usr/lib/libncurses.so.5 (0x00002aaaab029000) libc.so.6 => /lib/libc.so.6 (0x00002aaaab186000) /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) Weirdly, file -L /mnt/root32/usr/lib/libncurses.so.5 prints ... ELF 64-bit LSB shared object, AMD x86-64 ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
