Re: Confused: nvidia on AMD64???

2005-12-22 Thread Jonathan Brandmeyer 
On Thu, 2005-12-22 at 18:46 +0100, Joost Kraaijeveld wrote:
 Hi,
 
 I just put a NVidia GeForce FX 5200 into my machine (my Matrox 550
 will not work properly with Xinerama after the update to x.org). I
 followed several howto's (even from the people that wrote it worked,
 e.g. Stefan Salewski's NVidia driver successfully installed! and his
 link http://home.comcast.net/~andrex/Debian-nVidia/installation.html)
 but I cannot apt-get the nvidia-kernel-source from any of the
 mentioned repositories. 
 
 Is it possible to compile the module on a AMD64 system? Where can I
 apt-get the packages mentioned in howto above for  AMD64?
 
 TIA

Make sure that non-free is in /etc/apt/sources.list.  It is not there by
default.

HTH,
-Jonathan


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

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]

Recovery options

2005-12-12 Thread Jonathan Brandmeyer 
I'm currently running an Athlon64 machine with IA32 and AMD64 Debian Sid
installs, using a shared /home partition, all on LVM2.

The latest upgrade to initramfs-tools (I think) broke booting from LVM
on the AMD64 side.  I would like to revert to the older version, but I
don't have any means of running programs on that partition.

There used to be -amd64 kernels in the Debian IA32 repository, but I
can't find one any more recent than 2.6.8, which doesn't work with the
latest udev and initramfs-tools.

Alternatively, I could use a livecd of some kind, but all of the AMD64
versions I've found are marked highly experimental.  So, does anyone
have a good recommendation for one?  It really only needs to be powerful
enough to chroot into my system and run mkinitramfs (eg, must user
kernel 2.6.12+).

Thanks,
-Jonathan


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