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

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

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?

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.

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.

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.

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...

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.

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.

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?)

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?

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.

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.

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.]

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

And there was much rejoicing: https://staging.launchpad.net/~nick-moffitt/+archive/arm/+build/3206390