Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 279260 - linux-2.6.26 does not return ENOSYS for unknown syscalls with x86 binaries under x86_64 kernel
Summary: linux-2.6.26 does not return ENOSYS for unknown syscalls with x86 binaries un...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High critical (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL: http://lkml.org/lkml/2009/2/6/477
Whiteboard: [linux < 2.6.27.20] [linux >= 2.6.28 ...
Keywords:
Depends on:
Blocks: 279374
  Show dependency tree
 
Reported: 2009-07-27 05:35 UTC by Andrew Gaffney (RETIRED)
Modified: 2018-01-20 19:14 UTC (History)
13 users (show)

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


Attachments
syscall patch for RHEL5-based openvz-sources kernel (2.6.18-RHEL5-ia32-syscall-fix.patch,1.05 KB, patch)
2009-09-22 04:19 UTC, Daniel Robbins
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Gaffney (RETIRED) gentoo-dev 2009-07-27 05:35:34 UTC
Ever since sys-libs/glibc-2.9_p20081201-r2 was marked stable for x86 on June 26, every stage3-i486 has failed in the same way:

Running stage3-chroot.sh in chroot /release/buildroot/x86-dev/tmp/default/stage3-i486-20090721/
Traceback (most recent call last):
  File "/usr/sbin/env-update", line 27, in <module>
    import portage
  File "//usr/lib/portage/pym/portage/__init__.py", line 96, in <module>
    from portage.data import ostype, lchown, userland, secpass, uid, wheelgid, \
  File "//usr/lib/portage/pym/portage/data.py", line 14, in <module>
    ostype=platform.system()
  File "/usr/lib/python2.5/platform.py", line 1058, in system
    return uname()[0]
  File "/usr/lib/python2.5/platform.py", line 1024, in uname
    processor = _syscmd_uname('-p','')
  File "/usr/lib/python2.5/platform.py", line 810, in _syscmd_uname
    output = string.strip(f.read())
IOError: [Errno 9] Bad file descriptor

No other arch hits this, including i686. I don't know for certain that it's glibc, but the timing of the stabilization and the failures it just too close for it to be anything else.

Due to the failure of the stage3-i486, there hasn't been a x86 installcd built in almost 4 weeks. The installcd built 4 weeks ago doesn't boot due to the squashfs-tools-4.0 issue, so we currently have no working x86 installcd images. I'm calling this one critical for this reason.
Comment 1 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2009-08-02 00:10:28 UTC
This week the last x86 iso left the mirrors, which means there is no iso available from the main mirrors atm. This is a major bug =/ (also see bug 279974_
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2009-08-02 02:31:26 UTC
Does i586 still work? Maybe time to move the minimum version up?

releng: can you test the i586 build?
Comment 3 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-02 04:13:58 UTC
I have not yet tested i586. The idea was to make i586 the new "minimum", but there will be a handful of people that bitch. It'd be nice to get this fixed, though.
Comment 4 Mark Loeser (RETIRED) gentoo-dev 2009-08-02 22:42:00 UTC
I'd be interested to know if i586 works, and if newer versions of glibc work fine with i486.
Comment 5 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-04 04:46:42 UTC
I tested glibc-2.10.1 with i486 and encountered the same issue. I have to create a special stage3-i586 seed to do a full i586 run to test.
Comment 6 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-05 13:07:37 UTC
Okay, now we've got an issue. I see the same failure when using CHOST=i586-pc-linux-gnu and -mtune=i686. However, i686 remains unaffected by this issue.
Comment 7 Denis Loginov 2009-08-06 17:10:44 UTC
(In reply to comment #6)
> Okay, now we've got an issue. I see the same failure when using
> CHOST=i586-pc-linux-gnu and -mtune=i686. However, i686 remains unaffected by
> this issue.
> 
Please, see also Bug 230968 (it's about passwd option issue - the patch was proposed a while ago, but hasn't been commited).
Comment 8 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-06 17:58:47 UTC
WTF does that have to do with this bug? Please don't hijack bugs
Comment 9 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-08 21:11:31 UTC
I'm beginning to wonder if this isn't just an issue with python. I just did a couple of tests inside the chroot for the last failed build:

poseidon ~ # python -c 'import os; f = os.popen("uname -p"); foo = f.readlines()'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor
close failed in file object destructor:
IOError: [Errno 9] Bad file descriptor
AMD Opteron(tm) Processor 844

What appears to happen here is that the output of 'uname -p' gets dumped straight to the console instead of STDOUT being redirected into a pipe by the os.popen() call. Any subsequent operations on 'f' result in the "Bad file descriptor" error bring called. Whatever the issue is, it's not caused by the 'uname' command. I tried the above with 'cat /etc/issue' and saw the same behavior.

poseidon ~ # perl -e 'open F, "uname -p |"; $foo = <F>; close(F); print $foo;'
AMD Opteron(tm) Processor 844

Doing the equivalent (I believe) in perl results in no issue. If I remove the print statement, nothing shows at all, so there's no "bleedthrough" like we're seeing from python.

Could this be a weird interaction between >=glibc-2.9 and python-2.5 only on i[45]86-pc-linux-gnu?
Comment 10 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-09 03:55:34 UTC
Arfever has asked me to test this with python-2.6. I'm seeing the same behavior.
Comment 11 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-09 15:07:04 UTC
I've just run another build falling back to sys-libs/glibc-2.8_p20080602-r1. This build works without issue. I think we can safely say this is glibc's fault.
Comment 12 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-16 02:14:47 UTC
Okay, so this just got a bit weirder. I have a chroot that I used to upgrade a stage3-i486-2008.0 to i586. I had upgraded glibc to 2.9 in the process but gcc stayed at 4.1.2. Both python 2.4 and 2.5 work without issue.

I'm now upgrading gcc to 4.3.2 in the chroot and then I'll rebuild glibc.
Comment 13 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-16 16:09:20 UTC
Okay, so even after upgrading gcc to 4.3.2 and rebuilding glibc in the chroot, it doesn't break. I'm exploring other avenues for reproducing it outside of catalyst.
Comment 14 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-16 19:07:42 UTC
After running bootstrap.sh in the chroot, the problem is reproducible. For those playing along it home, it looks like the steps to reproduce are:

* Grab http://gentoo.osuosl.org/releases/x86/2008.0/stages/stage3-x86-2008.0.tar.bz2
* Latest tree
* Run 'env-update' and see it work
* emerge gcc glibc python (latest stable for all)
* /usr/portage/scripts/bootstrap.sh
* Run 'env-update' and see python throw a bitch fit
* Run "python -c 'import os; f = os.popen("uname -p"); foo = f.readlines()'" for a reduced test case

I haven't tested this exact procedure, but my "toying around" in the chroot seems to amount to the above
Comment 15 SpanKY gentoo-dev 2009-08-17 18:39:15 UTC
i suspect your host kernel version may matter.  2.6.25-hardened-r13 seems to work fine for me (miranda).
Comment 16 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-17 18:45:08 UTC
I'm seeing this on poseidon, which is running 2.6.26-gentoo-r3
Comment 17 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-17 18:53:04 UTC
It looks like bug 271367 might be related
Comment 18 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-17 18:55:04 UTC
Bug 250342 also looks related
Comment 19 SpanKY gentoo-dev 2009-08-17 21:12:30 UTC
only thing you need to do is extract the tarball:
 - update portage (which pulls in python)
 - update linux-headers
 - update glibc

then the simple popen test fails
Comment 20 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-17 22:26:33 UTC
After finding those other bugs, that makes a lot more sense.
Comment 21 SpanKY gentoo-dev 2009-08-18 08:14:22 UTC
this appears to be a 32bit-on-64bit syscall() issue on 2.6.26 systems

any unknown syscall does not properly return ENOSYS.  so if we look at linux-2.6.26/include/asm-x86/unistd_32.h, we see the max syscall is:
#define __NR_timerfd_gettime    326

so some simple code:
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>
int main()
{
    long i, r;
    int e;
    for (i = 325; i < 330; ++i) {
        errno = 0;
        r = syscall(i, 1, 2, 3, 4, 5, 6);
        e = errno;
        printf("syscall(%i) = %lx (%i = %s)\n", i, r, e, strerror(e));
    }
    return 0;
}

which gives us:
syscall(325) = ffffffff (14 = Bad address)
syscall(326) = ffffffff (22 = Invalid argument)
syscall(327) = 147 (0 = Success)
syscall(328) = 148 (0 = Success)
syscall(329) = 149 (0 = Success)

327+ should be returning -1 and setting errno to ENOSYS on a linux-2.6.26 system.  testing the static binary (so the exact same userspace code is run for each test) on a 2.6.25 and a 2.6.30.4 (with larger range) shows correct behavior.  testing a 64bit binary on 2.6.26 works fine.

i dont feel like setting up a 2.6.27+ system and/or bisecting the kernel to figure out when/how/why this was fixed.
Comment 22 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-18 16:17:56 UTC
Why does this affect CHOST=i[45]86-pc-linux-gnu but not CHOST=i686-pc-linux-gnu?
Comment 23 SpanKY gentoo-dev 2009-08-18 17:42:57 UTC
my guess is that i[45]86 uses the int 0x80 mechanism while i686 uses the sysenter mechanism

the test code here is only using the int 0x80 mech
Comment 24 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-19 02:20:51 UTC
What would it take to modify the test case to use the other facility in order to verify that assumption?
Comment 25 SpanKY gentoo-dev 2009-08-19 04:42:50 UTC
i looked at the syscall disassembly, but if you want raw assembly yourself, you can write it
Comment 26 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-19 15:27:11 UTC
Ah, I get it. You're just using glibc's syscall() which happens to be implemented with int 0x80 mechanism in the i486 chroot's glibc where you're running the test.
Comment 27 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-20 00:23:18 UTC
So, can someone suggest some possible workarounds for this issue? Would downgrading the kernel on poseidon to 2.6.25 work?

Kernel team, do you know if this was fixed in later versions of the kernel?
Comment 28 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-20 00:28:11 UTC
I just noticed vapier's comment that 2.6.30.x seems to work. Does anybody know if something more "stable" like hardened-sources-2.6.28-r9 will work?
Comment 29 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-20 00:31:37 UTC
I found the upstream kernel issue. Here's the patch that addresses the issue.

http://lkml.indiana.edu/hypermail/linux/kernel/0902.0/03021.html
Comment 30 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-20 00:33:34 UTC
Here's a better link with proper formatting.

http://lkml.org/lkml/2009/2/6/477
Comment 31 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-20 00:50:34 UTC
According to the changelog, this went in in 2.6.28.8. It appears that hardened-sources-2.6.28-r9 has this fix. I guess I'll be upgrading poseidon to that kernel. 
Comment 32 Kerin Millar 2009-08-20 01:08:49 UTC
Yes, hardened-sources-2.6.28-r9 has the fix. Current stable versions of both gentoo-sources and hardened-sources are fine. I don't know about other kernels; I've updated the status whiteboard in case anyone cares.
Comment 33 Andrew Gaffney (RETIRED) gentoo-dev 2009-08-20 19:49:51 UTC
After upgrading poseidon's kernel to 2.6.28-hardened-r9, I'm no longer able to reproduce the problem. Next week's x86 autobuild should work just fine. I think it's safe to close this bug. Thanks vapier.
Comment 34 SpanKY gentoo-dev 2009-08-21 05:45:38 UTC
ive added a pkg_setup() check

http://sources.gentoo.org/sys-libs/glibc/files/eblits/pkg_setup.eblit?r1=1.3&r2=1.4
Comment 35 Daniel Robbins 2009-08-25 14:46:39 UTC
For some strange reason, we have not had this problem with Metro while building in a 2.6.18-based OpenVZ VE (our "x86" build has an "i486-pc-linux-gnu" CHOST.) So right now, the new safety check in sys-libs/glibc bombs the glibc build out for no good reason. I'm going to investigate whether this patch can easily apply to a RHEL5 2.6.18-based OpenVZ kernel but if anyone has any additional info on why I may not be hitting this issue, please post. Thanks.
Comment 36 SpanKY gentoo-dev 2009-08-25 19:23:48 UTC
your assertion that you havent had this problem is dangerously optimistic.  while pipe() screwing up is quickly detected (because a lot of things depend on it), there are a ton of locations in glibc where similar mechanisms are used (newer functions are used and if ENOSYS occurs, fall back to old methods).

unless you can show that your kernel actually returns ENOSYS and thus the test is throwing a false positive, your system is broken end of story.  the check isnt being dropped.

you're using a RHEL kernel which means the "2.6.18" is largely irrelevant.  RHEL kernels backport *a ton of crap*, and there is certainly history in our bugzilla and elsewhere of it not always being correct.
Comment 37 Daniel Robbins 2009-08-26 05:49:26 UTC
OK, here's some questions - if I build stages on a system with a "broken" kernel, are the resultant stages "broken"? Or can I unbreak them simply by running them on an updated kernel?

Also, your test applies for all CHOSTS, not just i486-pc-linux-gnu. Is this correct? i[56]86-pc-linux-gnu and x86_64-pc-linux-gnu didn't experience this issue, so why abort when glibc is built for these CHOSTS?

Final question - if I do have "broken" stages, but they seem to work just fine, what exactly is broken about them? What kind of things can or will break?

Thanks for the info.
Comment 38 SpanKY gentoo-dev 2009-08-26 20:33:54 UTC
the resulting binaries should be fine.  using a fixed kernel is sufficient.

i know the test runs for all CHOSTs.  a broken kernel is a broken kernel.  glibc isnt the only thing that makes syscalls directly.

as for your last question, that's a pretty obvious answer.  if i dont notice i have internal bleeding, i must be fine right ?
Comment 39 Daniel Robbins 2009-09-21 19:34:26 UTC
My point is that if this is a kernel bug, then "fixing" it by causing the glibc build to abort is not addressing the root cause of this problem. A proper resolution would mean to ensure that all stable/unstable kernels in the Portage tree do not exhibit this bug. This is not currently the case.

If you go back to the original bug report, the original problem was that "every stage3-i486 has failed in the same way." This apparently was due to a kernel bug. Based on your answers (if I am understanding correctly) there was nothing wrong with the stages themselves, but due to the syscall code in the particular kernels being used. Is this correct?

If I am understanding correctly, then this bug is not resolved as openvz-sources triggers the implemented work-around (abort glibc ebuild) but there is not a newer RHEL5-based kernel which resolves this issue. Thus this bug is still open for some kernels. The implemented work-around simply has glibc to abort building and upgrade kernels. This presumes that such an upgraded kernel is available, which for some users, there isn't.

Comment 40 Daniel Robbins 2009-09-21 19:35:54 UTC
s/building and upgrade kernels/building and tell the user to upgrade kernels/
Comment 41 Andrew Gaffney (RETIRED) gentoo-dev 2009-09-22 02:34:37 UTC
I'm not sure what you're expecting to hear. If the user's kernel is broken and there isn't a newer one available, then they're stuck at glibc-2.8. There's no magic wand you can wave over this situation to make it any different.
Comment 42 Daniel Robbins 2009-09-22 03:09:40 UTC
How about fixing your broken kernels?
Comment 43 Daniel Robbins 2009-09-22 03:57:14 UTC
Note: I am not being grumpy, it's an honest question. I am currently testing the ia32entry.S patch you referenced applied to the latest openvz-sources to see if it resolves the bug with that kernel.
Comment 44 Daniel Robbins 2009-09-22 04:18:32 UTC
The patch does appear to resolve the issue with openvz-sources-2.6.18.028.062.3. This is a RHEL5-based kernel. The only change that was necessary to the original patch was modifying it to look for the old /x86_64/ directory instead of the /x86/ directory. I will attach this patch. Since RHEL5 kernels are pretty wacky, and this was a pretty straightforward fix, it offers some indication that fixing other kernels will be relatively straightforward as well.
Comment 45 Daniel Robbins 2009-09-22 04:19:22 UTC
Created attachment 204878 [details, diff]
syscall patch for RHEL5-based openvz-sources kernel
Comment 46 SpanKY gentoo-dev 2009-09-22 15:10:09 UTC
i dont know how you expect us to fix kernels for people when we arent involved in random RHEL kernels in any way.  if some kernel package is broken *in the portage tree*, then feel free to file a new bug that relies on this one for the maintainer *of that package*.
Comment 47 Daniel Robbins 2009-09-22 16:21:29 UTC
Vapier, this kernel I supplied a patch for is in the Gentoo portage tree.

I'll cc pva and we've also sent the fix upstream to kir@openvz.org. 

I don't want to take responsibility for fixing all the Gentoo kernels, but we are trying to fix openvz-sources. 

I do think that proper resolution of this bug would require all faulty kernels to be removed from the Portage tree, or replaced with patched kernels. Otherwise users may mistakenly use a kernel that would result in glibc and potentially other things failing.
Comment 48 Peter Volkov (RETIRED) gentoo-dev 2009-09-22 19:33:03 UTC
Daniel, I've dropped affected 2.6.18 kernels from the tree (RHEL5 based are really bad choice if you don't use redhat's .config and vanilla are not that secure). 2.6.27 are based on 2.6.27.21 kernel so we are safe here.
Comment 49 Daniel Robbins 2009-09-22 19:49:24 UTC
Peter, Jeff Mitchell has opened a new bug to track issues with the openvz-sources stable kernels. It is bug #285998. I don't think the 2.6.27 branch is good for production OpenVZ use, I've tested 2.6.27 for several months and found it to be quite unstable. Take a look at #285998 and maybe consider adding it as a good production option :)

Comment 50 Peter Volkov (RETIRED) gentoo-dev 2009-09-22 20:17:04 UTC
(In reply to comment #49)
> Peter, bug #285998

I don't see that bug mentions 2.6.27 anywhere... But you are right 2.6.27 has some issues (e.g. bug 281391) that were fixed in 2.6.27 stable tree and I'm going to backport that patches asap.

> I've tested 2.6.27 for several months and found it to be quite unstable.

I'm interested in bug reports and I'm sure upstream is interested in bugs too since they suggested us to use 2.6.27 kernel.
Comment 51 Jeff Mitchell 2009-09-22 20:31:12 UTC
Peter, did you mean *all* 2.6.18 kernels?

The RHEL/OpenVZ-patch 2.6.18 kernel is the only supported OpenVZ kernel by upstream, and the only one supporting resource limits. Dropping it from the tree would be a large mistake for OpenVZ-on-Gentoo users.
Comment 52 Peter Volkov (RETIRED) gentoo-dev 2009-09-22 21:11:53 UTC
(In reply to comment #51)
> Peter, did you mean *all* 2.6.18 kernels?

yes.

Vanilla 2.6.18 kernels are really security nightmare (practically no security patches was there).
rhel5 based kernels -- too many combinations of .config options make fail to build and and even if you manage to build kernel in case your .config differs from upstream it's quite possible that kernel will be buggy as nobody tested such configuration...

And our recent stable compiler unable to build 2.6.18 kernels (unfixable without using newer kernel).

> The RHEL/OpenVZ-patch 2.6.18 kernel is the only supported OpenVZ kernel by
> upstream

2.6.27 is supported: http://wiki.openvz.org/Download/kernel/2.6.27 ... or what do you mean by that?

Actually last time I've contacted upstream, they suggested Gentoo to move toward 2.6.27.

> and the only one supporting resource limits.

What resource limits are missed in 2.6.27?
Comment 53 Jeff Mitchell 2009-09-22 22:06:39 UTC
(In reply to comment #52)
> Vanilla 2.6.18 kernels are really security nightmare (practically no security
> patches was there).

Right, I have no problem with that...only the OVZ ones specifically.

> rhel5 based kernels -- too many combinations of .config options make fail to
> build and and even if you manage to build kernel in case your .config differs
> from upstream it's quite possible that kernel will be buggy as nobody tested
> such configuration...

Which is why there are warnings about using one of the provided configs from the OpenVZ site if one isn't working for you.

Really, I don't see how a strong warning at merge time making this clear wouldn't suffice (just as there is for the GCC 4.1 issue).

> And our recent stable compiler unable to build 2.6.18 kernels (unfixable
> without using newer kernel).

With GCC slotted it's not hard to keep a 4.1 version around and use gcc-config...

> > The RHEL/OpenVZ-patch 2.6.18 kernel is the only supported OpenVZ kernel by
> > upstream
> 
> 2.6.27 is supported: http://wiki.openvz.org/Download/kernel/2.6.27 ... or what
> do you mean by that?
> 
> Actually last time I've contacted upstream, they suggested Gentoo to move
> toward 2.6.27.
> 

Well...the wiki still doesn't list 2.6.27 as "stable"...the answers I got just now in #openvz is that they are focused on 2.6.27 because upstream kernel devs will support it longer than 2.6.18, but it is still buggy.

> What resource limits are missed in 2.6.27?

cpulimit (http://wiki.openvz.org/Resource_shortage#cpulimit)

I'm not sure when it is slated to return, but it is useful for thermal reasons (keeping a longer but cooler load as opposed to higher but much hotter load), for one example.

The bottom line is that I have actually used 2.6.27 OVZ kernels and been forced to downgrade because of bugs and kernel panics. I ran into issues with aivazovsky that made it unusable; when briullov came out, it fixed some issues and introduced more. While they actively fix them, the 2.6.18 kernel (once compiled, and with GCC 4.1) is solid enough for production use, which is not something I've yet experienced with 2.6.27; and the OVZ developers do not yet consider it to be stable.
Comment 54 Peter Volkov (RETIRED) gentoo-dev 2009-09-22 23:44:11 UTC
(In reply to comment #53)
> > Vanilla 2.6.18 kernels are really security nightmare (practically no
> > security patches was there).
> 
> Right, I have no problem with that...only the OVZ ones specifically.

I mean 2.6.18 OVZ kernels without rhel patchsets - the ones that were based on "vanilla" kernel, not on rhel5 kernel. In Gentoo the only stable 2.6.18 OVZ kernels were "vanilla" based kernels and RHEL5 based were ~arch only always. So you want me to put back ~arch kernels...

> > > The RHEL/OpenVZ-patch 2.6.18 kernel is the only supported OpenVZ kernel by
> > > upstream

> Well...the wiki still doesn't list 2.6.27 as "stable"...

I think in sense they understand "stable" Gentoo is unstable. Userland moves rather fast in Gentoo and it is hardly tested against old kernels: we already saw regression with coreutils. udev-146 needs new kernels. And with time more kernel dependent software will require newer kernels. There is another issue with 2.6.18 as well: obviously no new hardware support and also rhel5 backports support - such backports tend to oops... At least I had such issue with new enough server.

> the answers I got just now in #openvz is that they are focused on 2.6.27
> because upstream kernel devs will support it longer than 2.6.18, but it is
> still buggy.
 
> > What resource limits are missed in 2.6.27?
> 
> cpulimit (http://wiki.openvz.org/Resource_shortage#cpulimit)
> I'm not sure when it is slated to return, but it is useful
 
cpuunits still in place. This feature could be useful but it's not that radical to keep old kernel just for it, isn't it?


I've already moved all my VZ systems to 2.6.27 and for Gentoo I'm sure we need something better then three years old kernel. If you really want old kernel, then I'll put rhel5 based kernel back. But note, your help to maintain this kernel is necessary or I'll drop it as next issue comes out, since I'm not using this kernel anywhere...
Comment 55 Peter Volkov (RETIRED) gentoo-dev 2009-09-22 23:54:04 UTC
Daniel patch from comment #45 will be dropped as it's already exist in 2.6.18.028.064.7.
Comment 56 Jeff Mitchell 2009-09-23 00:18:36 UTC
(In reply to comment #54)
> I think in sense they understand "stable" Gentoo is unstable. Userland moves
> rather fast in Gentoo and it is hardly tested against old kernels: we already
> saw regression with coreutils. udev-146 needs new kernels. And with time more
> kernel dependent software will require newer kernels. There is another issue
> with 2.6.18 as well: obviously no new hardware support and also rhel5 backports
> support - such backports tend to oops... At least I had such issue with new
> enough server.

My new server had oopses with 2.6.27 openvz(-aivazovsky) because of bugs in the VZ patch  :-|  Seems like it's kind of a crapshoot which ends up being worse: incomplete VZ support or backported RH drivers.

> > cpulimit (http://wiki.openvz.org/Resource_shortage#cpulimit)
> > I'm not sure when it is slated to return, but it is useful
> 
> cpuunits still in place. This feature could be useful but it's not that radical
> to keep old kernel just for it, isn't it?

There are some other use cases besides thermal issues, especially for hosting providers.

> I've already moved all my VZ systems to 2.6.27 and for Gentoo I'm sure we need
> something better then three years old kernel. If you really want old kernel,
> then I'll put rhel5 based kernel back. But note, your help to maintain this
> kernel is necessary or I'll drop it as next issue comes out, since I'm not
> using this kernel anywhere...

Will do. I'll be keeping an eye on OpenVZ releases and will put together new 2.6.18 ebuilds (such as I did for 064.7) as necessary (and I'll keep testing new 2.6.27 releases as they come :-)  ).

Thanks a bunch.
Comment 57 SpanKY gentoo-dev 2009-09-23 17:09:28 UTC
this stopped being related to the toolchain long ago, and we dont care about broken kernels, so cc -> gone
Comment 58 Lorinc Czegledi 2014-02-11 19:05:42 UTC
first of all sorry for bumping this old thread

summary: anyone running into this error should disable running auditd when trying to upgrade glibc

story: today I tried updating to glibc-2.17 from glibc-2.15 as first of items in emerge -uDN world and it bailed with the message

"Your old kernel is broken.  You need to update it to"
"a newer version as syscall(<bignum>) will break."
"http://bugs.gentoo.org/279260"

it took some time researching duplicating, compiling the syscall code that does the test:

cat syscalltest.c

#include <unistd.h>
#include <sys/syscall.h>
int main(){return syscall(1000)!=-1;}

gcc syscalltest.c

then running the result:

a.out

Segmentation fault

tried different kernels to no avail

what however helped, was turning off auditd

/etc/init.d/auditd stop

auditd as in sys-process/audit-2.1.3-r1

maybe newer versions or different configs of audit will not result in this strange error, but for all others, here is your solution 

happy emerging glibc
Comment 59 josef.95 2014-08-04 05:39:44 UTC
(In reply to Lorinc Czegledi from comment #58)

This now should be fixed in linux-3.15.8
See https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.15.8
Comment 60 Ondrej Zary 2014-08-11 06:48:15 UTC
Just got this when trying to upgrade glibc-2.17 to glibc-2.19-r1. Kernel is the latest stable kernel (gentoo-sources-3.14.14) and the machine is 32-bit only (Celeron based on PII).

 * Your old kernel is broken.  You need to update it to
 * a newer version as syscall(<bignum>) will break.
 * http://bugs.gentoo.org/279260
 * ERROR: sys-libs/glibc-2.19-r1::gentoo failed (setup phase):
 *   keeping your system alive, say thank you
 *
 * Call stack:
 *              ebuild.sh, line  93:  Called pkg_setup
 *   glibc-2.19-r1.ebuild, line 151:  Called eblit-run 'pkg_setup'
 *   glibc-2.19-r1.ebuild, line 137:  Called eblit-glibc-pkg_setup
 *        pkg_setup.eblit, line  75:  Called die
 * The specific snippet of code:
 *                      die "keeping your system alive, say thank you"
 *
 * If you need support, post the output of `emerge --info '=sys-libs/glibc-2.19-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-libs/glibc-2.19-r1::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/portage/sys-libs/glibc-2.19-r1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/portage/sys-libs/glibc-2.19-r1/temp/die.env'.
 * Working directory: '/usr/lib/portage/pym'
 * S: '/var/tmp/portage/portage/sys-libs/glibc-2.19-r1/work/glibc-2.19'

>>> Failed to emerge sys-libs/glibc-2.19-r1, Log file:
Comment 62 Ondrej Zary 2014-08-11 10:54:39 UTC
So gentoo-sources-3.14.15 or 3.14.16 should be marked stable to fix this problem.
Comment 63 Mike Pagano gentoo-dev 2014-08-11 14:51:42 UTC
Only x86 is affected, correct?
Comment 64 Ondrej Zary 2014-08-12 06:30:36 UTC
Yes, x86 only.

It was broken in 3.14.10 by commit b83627d417975fa8681344384ac55a1c4751f55f
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.14.y&id=b83627d417975fa8681344384ac55a1c4751f55f

Fixed in 3.14.15 by commit 80705fca953d4f2983d5197401de4ce7af7699d3
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.14.y&id=80705fca953d4f2983d5197401de4ce7af7699d3
Comment 65 Mike Pagano gentoo-dev 2014-08-12 11:23:49 UTC
(In reply to Ondrej Zary from comment #64)
> Yes, x86 only.
> 
> It was broken in 3.14.10 by commit b83627d417975fa8681344384ac55a1c4751f55f
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/
> ?h=linux-3.14.y&id=b83627d417975fa8681344384ac55a1c4751f55f
> 
> Fixed in 3.14.15 by commit 80705fca953d4f2983d5197401de4ce7af7699d3
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/
> ?h=linux-3.14.y&id=80705fca953d4f2983d5197401de4ce7af7699d3


Thanks for the reply, I've asked for x86 stabilization in bug #518600
Comment 66 Robert R. Richter 2014-08-17 11:10:59 UTC
What about the 3.10.x kernels?

I am currently running 3.10.46, will 3.10.53 address this problem?
Comment 67 Willard Dawson 2015-05-01 20:59:13 UTC
I just got this error attempting to build glibc:

>>> Emerging (1 of 99) sys-libs/glibc-2.20-r2::gentoo
 * glibc-2.20.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ...                [ ok ]
 * glibc-2.20-patches-4.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...     [ ok ]
make -j1 -s glibc-test 
make -j1 -s glibc-test 
 * Your old kernel is broken.  You need to update it to
 * a newer version as syscall(<bignum>) will break.
 * http://bugs.gentoo.org/279260
 * ERROR: sys-libs/glibc-2.20-r2::gentoo failed (setup phase):
 *   keeping your system alive, say thank you


However, my kernel should be "fixed," right?

brick ~ # uname -a
Linux brick 3.15.5-pentoo #1 SMP PREEMPT Mon Dec 8 03:53:48 EST 2014 i686 Intel(R) Pentium(R) 4 CPU 2.20GHz GenuineIntel GNU/Linux


... or...?
Comment 68 Rick Farina (Zero_Chaos) gentoo-dev 2015-05-02 14:45:00 UTC
(In reply to Willard Dawson from comment #67)
> I just got this error attempting to build glibc:
> 
> >>> Emerging (1 of 99) sys-libs/glibc-2.20-r2::gentoo
>  * glibc-2.20.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ...                [
> ok ]
>  * glibc-2.20-patches-4.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...     [
> ok ]
> make -j1 -s glibc-test 
> make -j1 -s glibc-test 
>  * Your old kernel is broken.  You need to update it to
>  * a newer version as syscall(<bignum>) will break.
>  * http://bugs.gentoo.org/279260
>  * ERROR: sys-libs/glibc-2.20-r2::gentoo failed (setup phase):
>  *   keeping your system alive, say thank you
> 
> 
> However, my kernel should be "fixed," right?
> 
> brick ~ # uname -a
> Linux brick 3.15.5-pentoo #1 SMP PREEMPT Mon Dec 8 03:53:48 EST 2014 i686
> Intel(R) Pentium(R) 4 CPU 2.20GHz GenuineIntel GNU/Linux
> 
> 
> ... or...?
pentoo-sources *is* hardened-sources with aufs added, so if hardened sources of the same version is broken, then pentoo-sources are broken too.
Comment 69 Larry the Git Cow gentoo-dev 2018-01-20 19:14:31 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e1643a784e0c0626933e93d60e6dc229deb0757e

commit e1643a784e0c0626933e93d60e6dc229deb0757e
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2018-01-20 19:14:07 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2018-01-20 19:14:23 +0000

    sys-libs/glibc: Re-add check for bug 279260, see bug 645016 comment 2
    
    Bug: https://bugs.gentoo.org/279260
    Bug: https://bugs.gentoo.org/645016
    Package-Manager: Portage-2.3.19, Repoman-2.3.6

 sys-libs/glibc/glibc-9999.ebuild | 6 ++++++
 1 file changed, 6 insertions(+)}