FATAL: kernel too old ← how old is too old?

Bug #921078 reported by Nick Moffitt
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eglibc (Ubuntu)
Triaged
Medium
Unassigned
qemu-linaro (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

PPA buildds currently run Hardy, because they require Xen for VM security. This means that all builds of precise packages freak out because libc6 isn't upgradable in the build deps:

 Preparing to replace libc6 2.13-24ubuntu2 (using .../libc6_2.13-24ubuntu4_armel.deb) ...
 Unpacking replacement libc6 ...
 FATAL: kernel too old
 dpkg: warning: subprocess old post-removal script returned error exit status 1
 dpkg - trying script from the new package instead ...
 FATAL: kernel too old
 dpkg: error processing /var/cache/apt/archives/libc6_2.13-24ubuntu4_armel.deb (--unpack):
  subprocess new post-removal script returned error exit status 1
 FATAL: kernel too old
 dpkg: error while cleaning up:
  subprocess installed pre-installation script returned error exit status 1
 Errors were encountered while processing:
  /var/cache/apt/archives/libc6_2.13-24ubuntu4_armel.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)

As a result, nothing at all will build.

How old is too old? It would be good to list which minimum kernel revision to boot into, so we don't end up having to bisect through lots of kernels. We generally have to do a lot of mangling to try and make newer ones work with Xen.

Tags: patch
Revision history for this message
LaMont Jones (lamont) wrote :

There are two issues here:

1) For precise armel, we need glibc to support 2.6.24-30-xen as the minimum kernel revision in order for arm PPAs to work. If this presents serious performance issues, please describe them. Running that forward to the precise kernel should be an option in the Q timeframe.

2) The error message should be updated to say what the minimum kernel revision is.

lamont

Revision history for this message
Steve Langasek (vorlon) wrote :

The handling code in the libc6.preinst is as follows:

        # The GNU libc requires a >= 2.6.18 kernel, except on m68k where a
        # 2.6.32 kernel is needed.
        if [ "$realarch" != m68k ]
        then
            # Ubuntu buildd limitation: allow just 2.6.15, although 2.6.18 is required
            # for some patches
            #if linux_compare_versions "$kernel_ver" lt 2.6.18
            vmin=2.6.15
        else
            vmin=2.6.32
        fi
        if linux_compare_versions "$kernel_ver" lt ${vmin}
        then
            echo WARNING: this version of the GNU libc requires kernel version
            echo ${vmin} or later. Please upgrade your kernel before installing
            echo glibc.
            kernel26_help

            exit 1
        fi

So on architectures other than m68k (which is irrelevant for us), the minimum version is *supposedly* 2.6.15. The error message you're getting is triggered by this having been overridden in the source (debian/sysdeps/linux.mk) without updating the preinst script.

I'm updating the preinst script in bzr to match the values included in debian/sysdeps/linux.mk so that these are in sync. I don't know of any reason that arm *needs* to have a higher base version than other archs; it was bumped as part of a global bump, on the grounds that it's always better when eglibc can leverage new kernel features. So I'll lower this requirement as well. Matthias, if you know of any reason this is a problem, please speak up.

Ultimately, though, the version of the *host* kernel is actually completely irrelevant when you're talking about emulation, because the host kernel has nothing to do with the syscall interface that qemu exposes. So I think this is actually a bug in qemu-linaro as well, for not outputting a more suitable value for uname() under emulation by default. Maybe you can work around this by exporting QEMU_UNAME=2.6.32 in the build environment?

Revision history for this message
Steve Langasek (vorlon) wrote :

On second thought, since this *should* be fixed on the qemu side (either by changing the default behavior of uname() within qemu, or by setting an appropriate QEMU_UNAME value), and the latter seems to be straightforward to export globally (barring questions about how exactly to do this in the buildds), I would prefer to not lower the libc compat level on arm unless we have to.

Revision history for this message
Steve Langasek (vorlon) wrote :

Trivial patch to set 2.6.32 for the uname by default. I think this makes sense for us to apply in the package, but I'd like Nick to test to confirm that the eglibc 2.6.31 minimum doesn't result to more unimplemented syscall problems.

Changed in eglibc (Ubuntu):
importance: Undecided → Medium
Changed in qemu-linaro (Ubuntu):
importance: Undecided → Medium
Changed in eglibc (Ubuntu):
status: New → Triaged
Changed in qemu-linaro (Ubuntu):
status: New → Triaged
tags: added: patch
Revision history for this message
Nick Moffitt (nick-moffitt) wrote :

thanks, Steve! I'm shoving a new qemu package through our builders now, and I'll try building precise packages again once I get the base guest image upgraded.

Revision history for this message
Nick Moffitt (nick-moffitt) wrote :

Hmm, it still got https://staging.launchpad.net/~nick-moffitt/+archive/arm/+build/3206257 spitting out https://staging.launchpadlibrarian.net/92471525/buildlog_ubuntu-precise-armel.apturl_0.5.1ubuntu1_CHROOTWAIT.txt.gz to me. I wonder if this is because it's happening in the chroot update code that isn't actually armel code, but native chroot-building apt stuff outside...

Revision history for this message
Steve Langasek (vorlon) wrote :

Nick,

The precise eglibc on amd64 and armel has 2.6.24 as a minimum kernel version, so this should only be happening with the armel code when it sees a kernel < 2.6.31. Can I see the build log for the qemu package, to try to figure out why the setting isn't sticking?

Also, if you could run the armel 'uname -a' in an emulation environment, to see what it thinks the kernel version is, that would be good to confirm.

Revision history for this message
Nick Moffitt (nick-moffitt) wrote :

Picking an actual oneiric build chroot for linux-ti-omap:

(menkalinan)root@menkalinan:/home/buildd/build-3ef7062d83f8928431f66a0007c2517aca725dca/chroot-autobuild# chroot . uname -a
Linux menkalinan 2.6.24-30-xen #1 SMP Mon Jan 2 21:13:17 UTC 2012 armv7l armv7l armv7l GNU/Linux

Build log for qemu package attached. I just took your lucid backport and quiltified it to add the patch from the bug#906922.

Revision history for this message
Adam Conrad (adconrad) wrote :

The continued failure could simply be because the current ARM chroots aren't up-to-date with the more recently-relaxed libc6, and you need to chroot in and run apt-get to get a shinier one. I'll update both right now, and see if that helps you any (assuming staging is pulling chroots from production? If not, you'll need to copy them over, I guess).

Of course, the above is entirely orthogonal to Steve's fiddling with making qemu provide a different uname (but is that actually sane for binfmt emulation?)

Revision history for this message
Adam Conrad (adconrad) wrote :

Also, Steve's comment above that "The precise eglibc on amd64 and armel has 2.6.24 as a minimum kernel version" is demonstrably false. MIN_KERNEL_SUPPORTED in precise on arm* is still set to 2.6.31. In light of that, my above chroot-refreshing dance won't help Nick at all.

Other than "newer is better", has anyone actually made a cogent argument for why we want our non-x86 ports to have a higher MIN_KERNEL_SUPPORTED than amd64 and i386 do?

Revision history for this message
Steve Langasek (vorlon) wrote :

Ok, so the build log certainly shows the option being picked up but it sure isn't helping uname. Will dig deeper here.

> The continued failure could simply be because the current ARM chroots
> aren't up-to-date with the more recently-relaxed libc6,

No, the uname output shows that the qemu change is ineffective. Also, we haven't made any changes to libc6 to relax the version check, *because* it shouldn't be needed if qemu is DTRT.

> Also, Steve's comment above that "The precise eglibc on amd64 and armel
> has 2.6.24 as a minimum kernel version" is demonstrably false.

Sorry, I meant "amd64 and i386", not "amd64 and armel". Apparently armel has completely supplanted i386 in my mind.

> Other than "newer is better", has anyone actually made a cogent argument
> for why we want our non-x86 ports to have a higher MIN_KERNEL_SUPPORTED
> than amd64 and i386 do?

I'll leave that to Matthias. But the 2.6.24 is actually the exception rather than the rule here: amd64 and i386 have a lower compat level than Debian and the other Ubuntu archs to support the hardy build chroots in Ubuntu.

Revision history for this message
Steve Langasek (vorlon) wrote :

Oh bah. Turns out this failed because my patch only set the uname for the dynamically-linked qemu-user builds, not the static ones that we're using. :/ Attached is a slightly better (i.e., working) patch.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "qemu-linaro-921078.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qemu-linaro - 1.0.50-2012.02-0ubuntu1

---------------
qemu-linaro (1.0.50-2012.02-0ubuntu1) precise; urgency=low

  * New upstream release.
  * Pass --enable-uname-release=2.6.32 for the user emulation builds, so that
    we have a sensible baseline kernel value regardless of what the
    underlying host kernel is. This makes eglibc happier when running under
    emulation on a very old kernel for instance (whose host syscall ABI has
    nothing to do with what emulated syscalls are supported), and probably
    also lets us steer clear for the moment of code that has problem with
    the new kernel upstream versioning convention. LP: #921078.
  * debian/patches/define_AT_EMPTY_PATH.patch: make sure AT_EMPTY_PATH
    is defined. Thanks to Serge Hallyn <email address hidden>.
    Closes LP: #930181.
 -- Steve Langasek <email address hidden> Mon, 20 Feb 2012 17:32:06 -0800

Changed in qemu-linaro (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Nick Moffitt (nick-moffitt) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.