Bug#321718: Upgrade caused many libs to complain about "executable stack"
On Sun, Aug 07, 2005 at 01:51:35AM -0700, Steve Langasek wrote:
> 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
> thanks
>
> 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.
Sorry - I was rather annoyed because I logged on to IRC, and halfway
through explaining what I'd found out on Google about the problem and
why I had no idea where to look next, somebody cut me off and says,
"Just google for the answer, fix it, and then log the solution in the
BTS!" And everyone else ignored me. So I figured if I was being told
rudely to use the BTS, I should file some bugs, and I had no idea which
package was the root cause. I didn't notice the catch-all "upgrade
problems" package until I'd already filed some other ones.
> > 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.
I downgraded to glibc from testing. Here are some more details - I'm
not sure how to attach it to the glibc bug.
I was able to build "execstack" statically on another machine. Running
"execstack -c" on most of the libs giving the error made it go away, but
not for libcrypto.so. I assume libcrypto actually does require an
executable stack, unlike the others who were just accidentally marked
that way.
When I downgraded glibc, I noticed it uninstalling a package called
"libselinux1" - that looks very suspicious, but I don't know if it was
installed during the upgrade or if I installed it a while ago and forgot
about it. I could have sworn I hadn't been playing around with any
security patches on this machine, but I guess if I had been that could
have caused the problem.
> 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
The apt configuration is because I was running apt-cacher (pointed at
localhost). One of the first things that broke was apache, which
apt-cacher depends on, so that I had to overwrite my sources.list with a
more standard one to get apt working again. When I did that, I
accidentally put "stable" instead of "unstable". I had actually been
running unstable for months, but hadn't done a dist-upgrade for a long
time.
So:
1. install unstable
2. months later, dist-upgrade (which fails to finish)
3. overwrite sources.list with one pointing to stable
4. apt-get update
I think that's why it was listed as "prefers stable" at that point.
> 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
> 2.3.5.
As I said, I've been running sarge for quite some time, but I hadn't
upgraded my kernel for ages. I try to avoid touching the kernel as long
as it's working - I'd assumed dist-upgrade would notice if the kernel
needed to be upgraded, and warn me.
> 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
Oops, I guess that'd be the warning I was expecting.
Thanks for the prompt reply.
Joe
Reply to: