mainline kernel now depends on libc6 2.33, non-installable in focal?

I’ve been happily installing 5.10 mainline kernels (from https://kernel.ubuntu.com/~kernel-ppa/mainline/) on my Ubuntu 20.04.

Trying to update to 5.10.33, I discovered an unwelcome dependency on libc >=2.33 (focal is at 2.31) for the -headers package (though not the image itself — but who wants to live without the headers).

AFAIK, libc6 is next to impossible to upgrade. Is this… it? Am I stuck at 5.10.32 unless I give up LTS? Do these folks even have a public-facing site where one can report bugs?

Update: This seems to be the main launchpad bug. A good thing that came out of it: tuxinvader has come up with a Docker container (source on Github: focal-mainline-builder) for building kernel mainline images and uploaded 5.10 – 5.12 packages to his PPAs:

Tip: To see all available linux packages for your chosen series / version range, after messing with PPAs and maybe Debian backports, xanmod etc (as I have) do something like

apt update
printf '%s\0' linux-{image-unsigned,headers,modules}-5.10.{32..40} |
  xargs -0 -n 1 apt-cache pkgnames | LC_ALL=C sort | less

Hopefully this problem will go away. But let’s face it, depending on the whims of the "kernel mainline PPA" (or whoever is behind it, I still don’t understand how these developers can be reached) for binaries has not been a pleasant experience.

Here is Solutions:

We have many solutions to this problem, But we recommend you to use the first solution because it is tested & true solution that will 100% work for you.

Solution 1

You can stay with LTS, but you will need to compile the mainline kernels yourself to overcome the new dependency issue.

The mainline compiler version used seems to have just changed:

[email protected]:~/temp-k-git/linux$ scripts/diffconfig .config-5.12.0-051200rc6-lowlatency .config-5.12.0-051200-lowlatency
 CC_VERSION_TEXT "gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0" -> "gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0"
 GCC_VERSION 100200 -> 100300
 LD_VERSION 23501 -> 23601
+DEBUG_INFO_BTF_MODULES y
+PAHOLE_HAS_SPLIT_BTF y

But if I just take the Ubuntu kernel configuration and compile myself, on my main 20.04 test server, it installs fine. I.E. the dependency is a function of the compiler version used not the kernel source code.

Not really relevant but here is the config difference for what I compiled:

[email protected]:~/temp-k-git/linux$ scripts/diffconfig .config-5.12.0-051200-lowlatency .config
-DEBUG_INFO_BTF y
-DEBUG_INFO_BTF_MODULES y
-DEBUG_INFO_COMPRESSED n
-DEBUG_INFO_DWARF4 y
-DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT n
-DEBUG_INFO_REDUCED n
-DEBUG_INFO_SPLIT n
-GDB_SCRIPTS y
-PAHOLE_HAS_SPLIT_BTF y
 CC_VERSION_TEXT "gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0" -> "gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0"
 DEBUG_INFO y -> n
 GCC_VERSION 100300 -> 90300
 LD_VERSION 23601 -> 23400
 SYSTEM_TRUSTED_KEYS "debian/canonical-certs.pem" -> ""

Solution 2

I was able to install 5.12 on Ubuntu 20.04 with libc6 2.31 using the mentioned ppa:

sudo add-apt-repository ppa:tuxinvader/lts-mainline

sudo apt install linux-image-unsigned-5.12.4-051204-generic linux-modules-5.12.4-051204-generic linux-headers-5.12.4-051204-generic

Solution 3

Here is how i made dkms modules generated with kernel 5.11.18 from ubuntu mainline-kernel.
I run Linux Mint 20.1 Cinnamon and use nvidia-driver-460 version 460.73.01-0ubuntu0.20.04.1 in dkms.
The gcc I use is version 10.3.
Everything worked fine with ver 5.11.16-generic but stopped when i tried 5.11.18.
So I tried to find the problem why dkms did not compiled the kernel modules.
This is what I did:

  1. Installed kernel 5.11.18-generic
  2. Found that in kernel headers program fixdep relates to glibc 2.33
  3. Found that in kernel headers program modpost relates to glibc 2.33
  4. Replaced /lib/modules/5.11.18-generic/build/scripts/basic/fixdep with the one in 5.11.16
  5. Replaced /lib/modules/5.11.18-generic/build/scripts/mod/modpost with the one in 5.11.16
  6. Ran dkms against kernel 5.11.18 (/usr/lib/dkms/dkms_autoinstaller start 5.11.18-051118-generic)
  7. Successfully generated nvidia kernel modules.
    Rebooted and it works ok.
    Even tried the same with kernel 5.12.1 and it worked.

Hope this helps.

Solution 4

Another easy option to stay with 5.10, without compiling, seems to be to use a custom kernel. Like xanmod. The thing is, they don’t seem to put much effort into "performance" improvements for the older LTS series, so I think one might be getting a pretty standard kernel. For example this is the log for xanmod 5.10.35.

Note: Use and implement solution 1 because this method fully tested our system.
Thank you 🙂

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply