Re: synlink strangeness with chroot

2005-12-22 Thread Jonathan Brandmeyer 
On Fri, 2005-12-23 at 01:17 +0100, Goswin von Brederlow wrote:
> Jonathan Brandmeyer <[EMAIL PROTECTED]> writes:

> > 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.
> 
> Is that symlink absolute and thereby broken?

Eventually, yes.

(identical in ia32 or amd64)
/usr/lib/libncurses.so.5 -> libtermcap.so
/usr/lib/libtermcap.so -> libncurses.so
/usr/lib/libncurses.so -> /lib/libncurses.so.5
/lib/libncurses.so.5 -> libncurses.so.5.5

> > Weirdly, file -L /mnt/root32/usr/lib/libncurses.so.5 prints
> > ... ELF 64-bit LSB shared object, AMD x86-64 ...
> 
> Which would indicate it links to /lib/libncurses.so* instead of
> ../../lib/libncurses.so*. This might be a more common problem.

This isn't fully comprehensive, but it looks like only a handful of core
libraries are affected in this way.  This is from a desktop system,
running GNOME with a few extra GTK and QT apps.

$ for i in /mnt/root32/usr/lib/* ; do file -L $i | grep AMD ; done
/mnt/root32/usr/lib/libanl.so: ELF 64-bit LSB shared object, AMD x86-64,
version 1 (SYSV), stripped
/mnt/root32/usr/lib/libBrokenLocale.so: ELF 64-bit LSB shared object,
AMD x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libcidn.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libcom_err.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libcrypt.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libcurses.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libdl.so: ELF 64-bit LSB shared object, AMD x86-64,
version 1 (SYSV), stripped
/mnt/root32/usr/lib/libe2p.so: ELF 64-bit LSB shared object, AMD x86-64,
version 1 (SYSV), stripped
/mnt/root32/usr/lib/libext2fs.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libm.so: ELF 64-bit LSB shared object, AMD x86-64,
version 1 (SYSV), stripped
/mnt/root32/usr/lib/libncurses.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libncurses.so.5: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libnsl.so: ELF 64-bit LSB shared object, AMD x86-64,
version 1 (SYSV), stripped
/mnt/root32/usr/lib/libnss_compat.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libnss_dns.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libnss_files.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libnss_hesiod.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libnss_nisplus.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libnss_nis.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libpamc.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libpam_misc.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libpam.so: ELF 64-bit LSB shared object, AMD x86-64,
version 1 (SYSV), stripped
/mnt/root32/usr/lib/libpopt.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libresolv.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/librt.so: ELF 64-bit LSB shared object, AMD x86-64,
version 1 (SYSV), stripped
/mnt/root32/usr/lib/libtermcap.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libthread_db.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped
/mnt/root32/usr/lib/libutil.so: ELF 64-bit LSB shared object, AMD
x86-64, version 1 (SYSV), stripped



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: synlink strangeness with chroot

2005-12-22 Thread Goswin von Brederlow 
Jonathan Brandmeyer <[EMAIL PROTECTED]> writes:

> 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.

Is that symlink absolut and thereby broken? It should only fullfill
the 32bit needs and should not show up for 64bit binaries.

> Weirdly, file -L /mnt/root32/usr/lib/libncurses.so.5 prints
> ... ELF 64-bit LSB shared object, AMD x86-64 ...

Which would indicate it links to /lib/libncurses.so* instead of
../../lib/libncurses.so*. This might be a more common problem.


I wouldn't use the chroot in the ld.so.conf. Use ia32-libs for the
basics and dchroot for bigger stuff.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

synlink strangeness with chroot

2005-12-22 Thread Jonathan Brandmeyer 
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 (0x2abc3000)
libreadline.so.5 => /lib/libreadline.so.5 (0x2acd4000)
libselinux.so.1 => /lib/libselinux.so.1 (0x2ae13000)
libdl.so.2 => /lib/libdl.so.2 (0x2af26000)
libncurses.so.5 => /mnt/root32/usr/lib/libncurses.so.5
(0x2b029000)
libc.so.6 => /lib/libc.so.6 (0x2b186000)
/lib64/ld-linux-x86-64.so.2 (0x2aaab000)

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]