Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 61856 - sys-lib/glibc- fails to complete a stage1 install
Summary: sys-lib/glibc- fails to complete a stage1 install
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All All
: High blocker (vote)
Assignee: The Gentoo Linux Hardened Team
: 61890 62269 (view as bug list)
Depends on:
Reported: 2004-08-26 14:11 UTC by Lance Albertson (RETIRED)
Modified: 2004-09-16 09:29 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---

emerge debug output (debug,9.67 KB, text/plain)
2004-08-27 06:00 UTC, Lance Albertson (RETIRED)
chroot_bootstrap_glibc.log.gz (chroot_bootstrap_glibc.log.gz,6.52 KB, application/octet-stream)
2004-08-30 04:28 UTC, Holger Thon
glibc- (glibc-,982 bytes, patch)
2004-08-30 04:45 UTC, Holger Thon
Details | Diff
glibc- (glibc-,21.14 KB, text/plain)
2004-08-30 04:48 UTC, Holger Thon
emerge_info.txt (emerge_info.txt,2.09 KB, text/plain)
2004-08-30 10:08 UTC, Holger Thon
emerge info output (,2.43 KB, text/plain)
2004-08-30 10:08 UTC, Bernd Waibel
glibc-pkg_setup.diff (glibc-pkg_setup.diff,3.32 KB, patch)
2004-09-01 15:58 UTC, solar (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Lance Albertson (RETIRED) gentoo-dev 2004-08-26 14:11:26 UTC
I was just building a new server today using the latest 2004.2 hardened stage1 tarball. Everything was all working until it tried to merge glibc. This is what I encountered:

 * Checking kernel headers for broken sysctl.h ... yes

 * Your version of:

 *   /linux/sysctl.h

 * is broken (from a user space perspective).  Please apply
 * the following patch:

 * *******************************************************
cat: /var/tmp/portage-pkg/glibc- No such file or directory
 * *******************************************************

 * To fix, just do this:
 * cd /linux/
 * patch -p3 < /var/tmp/portage-pkg/glibc-

!!! ERROR: glibc- failed.
!!! Function pkg_setup, Line 214, Exitcode 0
!!! Broken linux/sysctl.h header included in kernel sources!

!!! Error running pkg_setup

The effected code in the ebuild seems to be this area and I'd like to know who put that there and if they could please fix it. :)

    if [ "$(KV_to_int $(uname -r))" -gt "`KV_to_int '2.5.68'`" ]
        local KERNEL_HEADERS="$(get_KHV "`KV_to_int ${MIN_NPTL_KV}`")"

        einfon "Checking kernel headers for broken sysctl.h ... "
        if ! gcc -I"${KERNEL_HEADERS}" \
                 -c ${FILESDIR}/test-sysctl_h.c -o ${T}/test1.o &> /dev/null
            echo "yes"

Right now I'm stuck at not finishing a stage1 build and don't know where to go. That einfo says to patch that file, but if I do that and rerun won't that be overwritten again? Also, Why can't it fix that file in the first place? This all just seems quite odd to me. Let me know what I can do to help resolve this.


livecd portage # emerge info
Portage 2.0.50-r10 (hardened-x86-2004.0, gcc-3.3.3, glibc-, 2.6.7-gentoo-r11)
System uname: 2.6.7-gentoo-r11 i686 Pentium III (Katmai)
Gentoo Base System version 1.4.16
CFLAGS="-march=pentium3 -O2 -pipe"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium3 -O2 -pipe"
FEATURES="autoaddcvs buildpkg ccache sandbox sfperms strict"
USE="berkdb crypt hardened mmx ncurses pam perl pic pie python readline snmp ssl tcpd x86 xml"
Comment 1 Lance Albertson (RETIRED) gentoo-dev 2004-08-26 21:13:03 UTC
I redid the bootstrap again and the same thing happened. This time I'm posting more of the backlog to show where this fails.. Which is during the merge, while the error is in pkg_setup. Quite odd. 

>>> Done.
>>> extracting info

 * Checking kernel headers for broken sysctl.h ... yes

 * Your version of:

 *   /linux/sysctl.h

 * is broken (from a user space perspective).  Please apply
 * the following patch:

 * *******************************************************
cat: /var/tmp/portage-pkg/glibc- No such file or directory
 * *******************************************************

 * To fix, just do this:
 * cd /linux/
 * patch -p3 < /var/tmp/portage-pkg/glibc-

!!! ERROR: glibc- failed.
!!! Function pkg_setup, Line 214, Exitcode 0
!!! Broken linux/sysctl.h header included in kernel sources!

!!! Error running pkg_setup

real    152m1.455s
user    205m51.244s
sys     38m26.839s
livecd portage # 
Comment 2 Lance Albertson (RETIRED) gentoo-dev 2004-08-27 06:00:07 UTC
Created attachment 38300 [details]
emerge debug output

Here's some output from running emerge -d glibc. Please take a look at see what
happens. I'll be afk most of the day today, so I won't be able to test anything
new. Talking to solar last night, he wondered if it was related to a portage
bug concerning pkg_setup. Somehow pkg_setup is getting run after a merge. He
and I couldn't remember the bug number, but it might be worth finding/asking

Tseng: were you running the same version of portage as me when you tested that
Comment 3 Brandon Hale (RETIRED) gentoo-dev 2004-08-27 10:17:04 UTC
I've done a build from the same stage a dozen times or more,
just verified yesterday that everything bootstraps cleanly.
According to Ramereth, whom I dont doubt, his error message (clearly in
pkg_setup), comes after src_compile. Portage buglet?

The Man says:
<@solar> that could also stem from
<@solar> but I'm pretty sure there is a bug with portage not exporting envvars... 
          ferringb knowsmore about it.
Comment 4 Lance Albertson (RETIRED) gentoo-dev 2004-08-28 05:48:48 UTC
Ok, I just tested the same thing on a P4 that already has Gentoo up and running (all I did was test inside a chroot) and everything built fine which is odd considering this has failed for two days in a row on a livecd on this other box. Is there anything on how the livecd is setup that could cause this error rather than doing it inside a chroot on an already running gentoo machine? I'm at a loss for that answer.
Comment 5 Lance Albertson (RETIRED) gentoo-dev 2004-08-29 19:07:25 UTC
*** Bug 61890 has been marked as a duplicate of this bug. ***
Comment 6 Holger Thon 2004-08-30 04:28:54 UTC
Created attachment 38491 [details]

Same problem here from stage 1 (non hardened). Seems to be a post-packaging
problem in pkg_setup, the log is an strace excerpt of chrooted emerge -K glibc.
It was run after glibc got packaged during bootstrap and failed to merge it to

I trapped down the problem to be in the FILESDIR variable, which is:

so gcc cannot find the test sources. I included them in the ebuild, ebuild
patch to -r1 will follow once glibc emerged successfully on the boostrap-failed
Comment 7 Holger Thon 2004-08-30 04:45:12 UTC
Created attachment 38492 [details, diff]

It worked, so this is the patch against glibc-
Comment 8 Holger Thon 2004-08-30 04:48:32 UTC
Created attachment 38493 [details]

In case you are not familar with patch, this is the full .ebuild.
Comment 9 Lance Albertson (RETIRED) gentoo-dev 2004-08-30 08:47:45 UTC
That fix seems to be more of a hack than a real fix. That doesn't address the reason why ${FILESDIR} is incorrect in the first place. Plus, from what I understand, pkg_setup shouldn't be run after the merge. That should be ran before the package is compiled. Please correct me if I'm wrong! I'm going to try this ebuild for now to see if I can at least get this box built, but like I said, there is still something funky going on with environment variables in that ebuild. 
Comment 10 Holger Thon 2004-08-30 09:23:17 UTC
Yes, so far it's only a hack. I guess the bug is in portage itself? %(

According to man 5 ebuild, FILESDIR="${PORTDIR}/${CATEGORY}/${PN}/files".
So that used in pkg_setup is definitly wrong, because ${PORTDIR}=/usr/portage (see log.gz before). In the log, it looks like FILESDIR="${O}/files", but i found no word about O in the documentation.

The manpage also says, that pkg_setup is for "actions or checks to be preformed before anything else.", i.e. it should also be executed if you emerge a .tbz (packaged ebuild). So the behaviour should be right, though the check before merging is not necessary if merging is done straight after compiling.

PS: Correct me if i got something wrong, i'm not a gentoo developer... :-)
Comment 11 Holger Thon 2004-08-30 10:08:07 UTC
Created attachment 38518 [details]

I guess the following, because my FEATURES also contains buildpkg
(see emerge_info.txt):
When emerging a packaged ebuild, the .ebuild file temporarily goes somewhere
into PORTAGE_TMPDIR before it finally gets merged into /var/db/pkg and the
dirname of that temporary .ebuild (probably stored in envvar O) is used for
constructing the FILESDIR variable, resulting in a wrong FILESDIR.

Could anybody with a faster machine or having python knowledge verify, that
portage behaves like this?
I.e. test, if the first succeeds and the second fails:
1. FEATURES="-buildpkg" emerge glibc
2. FEATURES="buildpkg" emerge glibc

or have a look at the portage sources for setting the FILESDIR variable?
If this is a case, please also file a portage bug... :-)
Comment 12 Bernd Waibel 2004-08-30 10:08:11 UTC
Created attachment 38519 [details]
emerge info output
Comment 13 Bernd Waibel 2004-08-30 10:10:10 UTC
I have a similar problem on a running system. I installed a new machine
yesterday, using the 2004.2 stage1 for x86. All went fine. After base
installation completed I did an emerge sync to install xorg. Then I tried
an emerge -puv system which wants to install glibc-2.3.3-20040420-r1.
The package compiled succesfully, and at the beginning it states, that
my syscntl.h is not(!) broken. But at the merge state, it does another
check of syscntl.h and then fails with the error described herein.
Maybe this will help to find the error.

for emerge info see attachment emerge info output.
Comment 14 Nicholas Jones (RETIRED) gentoo-dev 2004-08-30 12:29:44 UTC
EBUILD BUG -- My thoughts:

FILESDIR is not a valid place to look with BINARY packages.
Those experiencing the problem more than likely have
FEATURES=buildpkg set and the ebuild is trying to use the
repository for the patch and getting a different FILESDIR
than one would have set when compiling.

Results in: unpack, compile, package, -->merge package<--

At which point there should be NO accessing of the portage

Final verdict: Do not use O, FILESDIR or any other related
variable when past the install stage .of an ebuild.
Comment 15 Nicholas Jones (RETIRED) gentoo-dev 2004-08-30 12:36:21 UTC
As Ramereth has pointed out the pkg_setup part...

I'm still working on an answer that is more reasonable.

Do not depend on filesdir in the setup function. It gets called for
every invocation of and thus in the merge phase it breaks.
Comment 16 Lance Albertson (RETIRED) gentoo-dev 2004-08-30 14:11:38 UTC
I just confirmed that: 

FEATURES="-buildpkg" emerge glibc

Does infact bypass this bug.

Nick: thanks for pointing out those errors and insight into the problem! Hopefully we can narrow down what exactly is causing this.
Comment 17 klavs klavsen 2004-08-30 23:22:53 UTC
After a long night of bootstrapping (it's a 800mhz via C3 :) I can confirm that the first-mentioned patch, does indeed fix the problem :)

I'll continue, and see what else turns up, on my new hardened box :)

Thanks for your insight.
Comment 18 solar (RETIRED) gentoo-dev 2004-09-01 15:23:24 UTC
*** Bug 62269 has been marked as a duplicate of this bug. ***
Comment 19 Sean Davidson 2004-09-01 15:36:17 UTC
This is really due to the fact that the ebuild script for kernels -gt 2.5.58
tries to check that the /usr/src/linux/include/linux/sysctl.h file can be used
from user space but at least with 2.6.7 and later kernel headers it can never
be because /usr/src/linux/include/linux/list.h completely forbids this with
the condition

#ifdef __KERNEL_
#warning "don't include kernel headers in userspace"
#endif /* __KERNEL__ */

so either the ebuild is wrong now with 2.6.x kernel header files or the
kernel header needs to be fixed.  The 2.4.x list.h kernel header file does
not have this warning conditional.
Comment 20 SpanKY gentoo-dev 2004-09-01 15:45:07 UTC
the problem comes in that the linux-headers installed in /usr/include are too old so the ebuild moves to trying to use the /usr/src/linux/include headers ... so if your linux-headers are setup properly, the ebuild shouldnt try to use /usr/src/linux
Comment 21 solar (RETIRED) gentoo-dev 2004-09-01 15:58:13 UTC
Created attachment 38714 [details, diff]

This should solve the problem here.
We rename the pkg_setup() function to glibc_setup() and only call glibc_setup()

when we are in the src_unpack()

We also disable the FORCE_DOWNGRADE check as well. It's fails on the vercmp.
Comment 22 solar (RETIRED) gentoo-dev 2004-09-02 21:51:46 UTC
Can you please fix the python FORCE_DOWNGRADE check? We had to temp disable in a few revision of glibc (that's your code right?)

Can you patch your existing ebuild and try again? If the bodx has already been 
worked around and/or put into production then could you please test in a chroot with the glibc-pkg_setup.diff posted here.

cd $(portageq envvar PORTDIR)/sys-libs/glibc
cvs update -d -P
wget -q -O - '' | patch
ebuild glibc- digest
ebuild glibc- digest
ACCCEPT_KEYWORDS=~x86 emerge glibc -pv
# Motivation stems from comment #14
Comment 23 solar (RETIRED) gentoo-dev 2004-09-06 13:12:59 UTC

Ok I updated it anyway.