[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

reassign 321717 glibc 2.3.5-1
reassign 321718 glibc 2.3.5-1
reassign 321720 glibc 2.3.5-1
reassign 321721 glibc 2.3.5-1
reassign 321723 glibc 2.3.5-1
reassign 321724 glibc 2.3.5-1
merge 321718 321717 321720 321721 321723 321724
severity 321718 important

On Sun, Aug 07, 2005 at 02:56:10AM -0400, Joe Mason wrote:
> (so far I've found libgcrypt, libcrypto, and libelf, and I'm filing bugs
> for all of them).

I'd rather you hadn't.  None of these libraries are buggy.  In the future,
it would be appreciated if you would open a single bug report describing
your issue, and let the developers sort out where the problem lies.

> Package: upgrade-reports
> Severity: critical

> I just did a dist-upgrade, and every time I try to run a program linked
> with libacl (which includes mv, cp, and ls) I get the following error:

> error while loading shared libraries: libacl.so.1: cannot enable
> executable stack as shared object requires: Error 14

> This makes the entire system unusable.

This error message originates with glibc, and appears to be new as of glibc
2.3.5.  Your reportbug-generated dependency lists confirm that this is the
version you're running.  So this bug, such as it is, belongs to the glibc
package; I've reassigned accordingly.

However, it's also apparent from the system details in your report that your
system is in an unsupported state:

> Google suggests this has something to do with "pax", which I've never 
> heard of and have certainly never installed or enabled.

> -- System Information:
> Debian Release: testing/unstable
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.4.18-bf2.4
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Setting aside the oddity of your apt configuration here, it's evident that
you've tried to upgrade your system to current Debian unstable while running
a kernel from *woody*.  It is the policy of the Debian release team that
direct upgrades from woody to etch will not be supported, and this is an
interesting example of why that policy is warranted.  There have been no
other reports of this problem even though glibc 2.3.5 has been in
preparation for some time, and I have at least one system that is running
glibc 2.3.5 successfully with a 2.4.27 kernel from sarge, so apparently this
is an incompatibility that only exists between pre-sarge kernels and glibc

It should be straightforward for you to fix your system by installing a
2.4.27 kernel from sarge and rebooting the machine, which is the supported
upgrade path in any case.  This means the bug should not be considered
critical; I've downgraded it accordingly.

It is still important that the glibc package be fixed, so that it does not
permit installation on an unsupported kernel.  This has been done in the
past for select architectures, but it seems we now have a reason to bump the
requirement across all architectures, which should give the glibc team a
nice clean start (and a nice clean preinst) for etch. :)

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: