glibc: maintenance update and support RHEL 6 -like kernels by vcunat · Pull Request #32954 · NixOS/nixpkgs

vcunat · 2017-12-21T21:02:57Z

Things done

Tested building simple packages and running them on a CentOS 6.9 VM.
Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)
- NixOS
- macOS
- other Linux distributions
Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
Tested execution of all binary files (usually in ./result/bin/)
Fits CONTRIBUTING.md.

I plan to merge in a few days.

We lost the support with 2.25 -> 2.26

lukateras

I think it would be better if configure patch was against configure.ac rather than its pre-generated artifact. Great that you handle 2.6.32 explicitly instead of just changing __LINUX_KERNEL_VERSION to a lower value!

vcunat · 2017-12-21T21:55:44Z

@yegortimoshenko: I patch both configure.ac and the generated configure.

lukateras · 2017-12-21T22:02:23Z

@vcunat Oh, correct. Then another nitpick: patch would be easier to read if hunks were separated with an empty line :-)

vcunat · 2017-12-21T22:22:16Z

I just ran git diff :-) Shall we report it upstream? (just kidding)

orivej · 2017-12-21T22:56:49Z

pkgs/development/libraries/glibc/common.nix

+        On major glibc updates we should check that the patched kernel supports
+        all the required features.  ATM it's verified up to glibc-2.26-115.
+        # HOWTO: check glibc sources for changes in kernel requirements
+        git log -p glibc-2.25.. sysdeps/unix/sysv/linux/x86_64/kernel-features.h sysdeps/unix/sysv/linux/kernel-features.h


Did you do git checkout release/2.26/master before git log? Is 115 the number of commits in that branch since glibc-2.26 tag? Shouldn't git log -p be called with glibc-2.26..?

I checked out the version I updated to:

$ git describe glibc-2.26-115-g633e2f7f3d

I wanted to re-check since 2.25, as the kernel support was bumped between 2.25 and 2.26 (and on 2.26.. they probably wouldn't do such large changes anyway). EDIT: of course, in future it's enough to check since the last checked commit.

vcunat · 2017-12-22T09:01:23Z

BTW, you may test with a few tools that are in binary cache already: https://hydra.nixos.org/build/66404678#tabs-buildsteps – just nix-store --realize those paths...

vcunat · 2017-12-22T11:15:45Z

/cc @grahamc for ^^
@GrahamcOfBorg eval

edolstra · 2017-12-22T12:36:58Z

pkgs/development/libraries/glibc/common.nix

+        for glibc to accept 2.6.32 and to tag the ELFs as 2.6.32-compatible
+        (otherwise the loader would refuse libc).
+        Note that glibc will fully work only on their heavily patched kernels
+        and we lose early mismatch detection on 2.6.32.


What does it mean to "lose early mismtach detection"?

@edolstra: when glibc detects an old kernel, it dies with a readable message (kernel too old). That gets disabled for 2.6.32 in this PR, so if someone used that version without the RHEL patches, it would be hard to debug – she wouldn't get any readable message and instead, some glibc functions would be failing (ENOSYS etc.)

I didn't want to make the in-source comment too long, but perhaps I've cut it down too much.

edolstra · 2017-12-22T12:37:49Z

Adding gzipped patch files to the Nixpkgs tree doesn't seem very nice. Can't that patch be fetched from somewhere else?

vcunat · 2017-12-22T13:03:45Z

@edolstra: I would be very grateful if a better solution was found – I had spent quite a lot of time on it and only came with this. Upstream doesn't make maintenance releases (i.e. tarballs), fetching a hundred patches from git is cumbersome, and all is further hindered by glibc taking part in bootstrapping.

vcunat · 2017-12-22T13:07:34Z

If you prefer using fetchgit during stdenv bootstrapping, that would seem another not-too-bad choice, but I might be missing some complications.

lukateras · 2017-12-22T13:49:32Z

@vcunat: could you perhaps use this script?

#!/usr/bin/env nix-shell
#! nix-shell -i sh -p git

version=2.26

cd $(mktemp -d)

echo "{ fetchpatch }: ["

git clone git://sourceware.org/git/glibc.git .
git fetch origin release/$version/master
git checkout release/$version/master

for commit in $(git log glibc-$version..release/$version/master | grep ^commit | cut -d' ' -f 2); do
    name="$commit.patch"
    url="https://sourceware.org/git/?p=glibc.git;a=patch;h=$commit"
    sha256=$(nix-prefetch-url --name "$name" "$url")
    cat <<EOF
(fetchpatch {
  url = "$url";
  sha256 = "$sha256";
  name = "$name";
})
EOF
done

echo "]"

It generates list of patches, fetched via fetchpatch, given glibc version. If fetchpatch is not available during bootstrap, it could use fetchurl instead.

You can also set glibc patch prefix just by counting these patches.

vcunat · 2017-12-22T13:52:44Z

I had tried that approach first (generate fetchpatch invocations via a script) but I dropped it in the end. IIRC it had to do with the complexity of making fetchpatch available during bootstrapping, or something similar.

lukateras · 2017-12-22T13:59:59Z

It is enough to just remove the last line of every patch (it points to git version). This could be done via head -n -1. I think it is feasible to implement a very small fetchpatch that is just like fetchurl except it has postFetch where it filters out the last line.

vcunat · 2017-12-22T14:04:28Z

Yes, I suppose that should cover almost all the changes cheaply. I've seen also the @@ parts changing on git version changes, but that seems unlikely to happen often.

lukateras · 2017-12-22T14:08:24Z

I think so, perhaps then we'll have proper fetchpatch during boostrap. Can I work on this and then push it to your branch?

dezgeg · 2017-12-22T14:15:59Z

At least on GitHub it's possible to have a range of commits squashed into one diff: https://github.com/NixOS/nixpkgs/compare/master...dezgeg:arm-work.diff so there's no need to generate dozens of fetchpatch invocations.

It doesn't solve the patch nondeterminism problem though.

lukateras · 2017-12-22T14:17:46Z

@dezgeg: 115 fetchpatch invocations is useful to determine glibc patchlevel. It also properly dedupes artifacts in Nix store. Also, I don't think GitWeb supports this.

edolstra · 2017-12-22T14:24:06Z

Can't we just push this version of Glibc to GitHub and use fetchFromGitHub? I think that should work during stdenv bootstrap but I'm not sure.

lukateras · 2017-12-22T14:25:36Z

@edolstra That incurs additional maintenance, with fetchpatch approach we would be able to update glibc to new patchlevel automatically, just by running a script.

edolstra · 2017-12-22T15:01:15Z

How does it incur more maintenance? It's less work to just update a commit hash.

vcunat · 2017-12-22T15:13:16Z

I suspect he meant you have to update the repo as well, but what about this GitLab auto-updating mirror? The source would be obtainable through fetchzip like from GitHub.

lukateras · 2017-12-22T15:15:06Z

Yes, that and also origin would have to be manually checked out anyway to determine the new patchlevel, which also has to be updated.

vcunat · 2017-12-22T15:18:02Z

Number of patches with overview: https://gitlab.com/vcunat/glibc/compare/glibc-2.26...release/2.26/master (EDITed to beautify the URL)

lukateras · 2017-12-22T15:19:21Z

It shows one patch more (116) than the actual patchlevel (115) and the number that I get when I checkout locally. Strange...

vcunat · 2017-12-22T15:19:57Z

One patch was pushed very recently upstream.

lukateras · 2017-12-22T15:42:17Z

BTW, glibc derivation can only fetch using built-in Nix fetchurl that doesn't handle postFetch, and I don't think fetchzip is available during bootstrap, so it should probably just fetch tarball from https://gitlab.com/vcunat/glibc/repository/5da0de4de5e8b9576475432b94fa0a486fd9389f/archive.tar.gz via fetchurl. It's not really deterministic, though, I'm not sure how to fix that.

Great that GitLab supports auto-updating mirrors!

(fetchpatch scripts, for reference: patch-glibc.tar.gz)

grahamc · 2017-12-22T16:16:20Z

Let's try this again:
@GrahamcOfBorg eval

dtzWill · 2017-12-22T19:59:57Z

I've had great success with this so far (using 87acb2b) on my RHEL6-esque machine, thank you!

I know there are some details to be sorted but thought I'd let you know it's working great so far functionality-wise 👍

vcunat · 2017-12-26T13:22:36Z

Right, now I remember why I dropped the attempts. In bootstrapping, at the point when glibc is built, I see no easy way to get any fetch of a file with unstable hash (generated tarball or patches).

I now tried also fetchTarball wrapped in a fixed-output derivation, but for some reason it always re-fetches even if the fixed-output derivation is in the store already (insufficient laziness?). BTW, the auto-updating feature got stuck in the meantime (http 503 if I try to unstuck it), though it's hopefully just a transient problem.

I assumed the update part would be the clear one and we may focus on the RHEL patch, but it's the other way. Unless you bring any idea how to do this without postFetch or you bring code adding the necessary stuff to linux boostrapping, I'm merging this as it is in a couple days.

lukateras · 2017-12-26T13:52:55Z

Right, that's what I've thought, the only fetcher available (one built into Nix) doesn't support postFetch. This can be fixed by relying on continuous deployment to create stable archives: https://docs.travis-ci.com/user/deployment

I don't think that Travis CI supports GitLab releases, but GitLab has its own CI: https://docs.gitlab.com/ce/ci/

lukateras · 2017-12-30T16:51:39Z

@vcunat: do you think .tar archives without compression could be more deterministic? https://gitlab.com/vcunat/glibc/repository/5da0de4de5e8b9576475432b94fa0a486fd9389f/archive.tar

vcunat · 2017-12-30T17:09:27Z

I don't know how these are created exactly, but man git-archive suggests that it uses the current time for timestamps of all files, unless retrieved via a tag...

vcunat added 2 commits December 20, 2017 15:31

glibc: maintenance 2.26-75 -> 2.26-115

a139613

glibc: support RHEL 6 -like kernels again

87acb2b

We lost the support with 2.25 -> 2.26

vcunat added the 1.severity: mass-rebuild label Dec 21, 2017

vcunat added this to the 18.03 milestone Dec 21, 2017

vcunat mentioned this pull request Dec 21, 2017

glibc-2.26-75 #28622

Merged

lukateras approved these changes Dec 21, 2017

View reviewed changes

dtzWill mentioned this pull request Dec 21, 2017

bootstrap-tools needs to be updated #32782

Open

orivej reviewed Dec 21, 2017

View reviewed changes

edolstra reviewed Dec 22, 2017

View reviewed changes

vcunat merged commit 87acb2b into NixOS:staging Dec 29, 2017

vcunat added a commit that referenced this pull request Dec 29, 2017

Merge #32954: glibc: patch update and support RHEL 6

90803b9

vcunat deleted the p/rhel6 branch December 29, 2017 09:05

vcunat mentioned this pull request Jul 25, 2018

[fatal urgent buggy] nix openjdk 8 can't run on Linux 2.6.32-431.el6.x86_64 #44070

Closed

Uh oh!

Conversation

vcunat commented Dec 21, 2017

Things done

Uh oh!

lukateras left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vcunat commented Dec 21, 2017

Uh oh!

lukateras commented Dec 21, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vcunat commented Dec 21, 2017

Uh oh!

orivej Dec 21, 2017

Choose a reason for hiding this comment

Uh oh!

vcunat Dec 21, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vcunat commented Dec 22, 2017

Uh oh!

vcunat commented Dec 22, 2017

Uh oh!

edolstra Dec 22, 2017

Choose a reason for hiding this comment

Uh oh!

vcunat Dec 22, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vcunat Dec 22, 2017

Choose a reason for hiding this comment

Uh oh!

edolstra commented Dec 22, 2017

Uh oh!

vcunat commented Dec 22, 2017

Uh oh!

vcunat commented Dec 22, 2017

Uh oh!

lukateras commented Dec 22, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vcunat commented Dec 22, 2017

Uh oh!

lukateras commented Dec 22, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vcunat commented Dec 22, 2017

Uh oh!

lukateras commented Dec 22, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dezgeg commented Dec 22, 2017

Uh oh!

lukateras commented Dec 22, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

edolstra commented Dec 22, 2017

Uh oh!

lukateras commented Dec 22, 2017

Uh oh!

edolstra commented Dec 22, 2017

Uh oh!

vcunat commented Dec 22, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lukateras commented Dec 22, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vcunat commented Dec 22, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lukateras commented Dec 22, 2017

Uh oh!

vcunat commented Dec 22, 2017

Uh oh!

lukateras left a comment •

edited

Loading

lukateras commented Dec 21, 2017 •

edited

Loading

vcunat Dec 21, 2017 •

edited

Loading

vcunat Dec 22, 2017 •

edited

Loading

lukateras commented Dec 22, 2017 •

edited

Loading

lukateras commented Dec 22, 2017 •

edited

Loading

lukateras commented Dec 22, 2017 •

edited

Loading

lukateras commented Dec 22, 2017 •

edited

Loading

vcunat commented Dec 22, 2017 •

edited

Loading

lukateras commented Dec 22, 2017 •

edited

Loading

vcunat commented Dec 22, 2017 •

edited

Loading

lukateras commented Dec 22, 2017 •

edited

Loading

vcunat commented Dec 26, 2017 •

edited

Loading

lukateras commented Dec 26, 2017 •

edited

Loading

lukateras commented Dec 30, 2017 •

edited

Loading

vcunat commented Dec 30, 2017 •

edited

Loading