Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#76247 - [glibc] Support for older kernels

Attached to Project: Arch Linux
Opened by Josh Bendavid (joshbendavid) - Wednesday, 19 October 2022, 11:51 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To freswa (frederik)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No



glibc doesn't work with kernels earlier than 4.4. Having support for 3.10 would be extremely useful for running arch-based containers on older systems. (In particular because of the discontinuing of Centos, many research institutions have stayed on Centos 7 longer than originally planned, so maintaining support in this transition period would be extremely useful.)

It's sufficient to just change the --enable-kernel configuration option.

Steps to reproduce:

Start an arch-based docker container on Centos 7 (or any system running a kernel older than 4.4)
This task depends upon

Comment by Doug Newgard (Scimmia) - Wednesday, 19 October 2022, 12:00 GMT
systemd requires a kernel newer than 3.10.
Comment by Josh Bendavid (joshbendavid) - Wednesday, 19 October 2022, 12:12 GMT
Yes but systemd is not needed in general if using arch as a docker container or similar.
Comment by Doug Newgard (Scimmia) - Wednesday, 19 October 2022, 12:24 GMT
systemd almost certainly is required, even if it's not used as init. As they set the absolute minimum at 3.15, it's hard to say what all wouldn't work with older kernels.
Comment by Josh Bendavid (joshbendavid) - Wednesday, 19 October 2022, 12:35 GMT
Things work fine in general for software development/scientific applications/etc when running a container with a rebuilt glibc (it's just a maintenance hassle to have to stay in sync and rebuild it)
Comment by freswa (frederik) - Wednesday, 19 October 2022, 13:30 GMT
The deprecation notice has been issued end of 2020. There have been more than 1.5 years transition period already. How long do we expect the migration to take?
Comment by Josh Bendavid (joshbendavid) - Wednesday, 19 October 2022, 13:37 GMT
End of maintenance updates for CentOS 7 is June 30, 2024 so this could be a reasonable end-point. (Most institutions I'm aware of still using CentOS 7 are aiming to upgrade to something else by then at the absolute latest.)
Comment by freswa (frederik) - Wednesday, 19 October 2022, 15:29 GMT
I'm not willng to put something in the distro repo for years that hasn't anything todo with Arch really. Though, if there are enough people interested in this "glibc-compat" thingy, I'm willing to put it in a private users repo.
Comment by Josh Bendavid (joshbendavid) - Wednesday, 19 October 2022, 17:30 GMT
Ok but is there any significant drawback to this? glibc itself still supports older kernels upstream just fine (and I think the default would even be to maintain more backwards compatibility).

Also there ARE official docker images for Arch on Docker Hub so this is a "supported" way of using arch somehow, just a question of how broad a range of host systems are supported.
Comment by freswa (frederik) - Wednesday, 19 October 2022, 19:38 GMT
If we'd officially support older kernels, we'd need to test them if issues occur. Linux 3.x is not in our repos, nor is it LTS according to
So there is more work required than just changing a configure parameter.

I can't state anything about the support of our docker images. Though I doubt that unsupported kernels is something we aim at.

Feel free to apply as Developer to help maintain glibc if the offered solution doesn't suit your needs.
Comment by Josh Bendavid (joshbendavid) - Wednesday, 19 October 2022, 22:12 GMT
Well just changing the parameter would already help users who are trying to use arch-based containers in this way with little or no drawback.
(Most other major distros seem to still support older kernels in their glibc builds, most likely for this reason)

Presumably the full combination of host systems/kernels for running containers is not really tested anyways (arch images work on RHEL8 or clones for example, but those have their own kernels etc etc)
Comment by Toolybird (Toolybird) - Thursday, 20 October 2022, 02:38 GMT
This is basically a dupe of  FS#69663 . The decision for 4.4 was made here [1]. The rationale back then was sound, but waters were somewhat muddied due to multiple issues being conflated. FWIW both Fedora/Debian appear to be using 3.2.

Back in the very old days, `--enable-kernel=x.y.z' could be used to cut out a lot of compatibility cruft. This made your glibc go faster! Looking at current `sysdeps/unix/sysv/linux/kernel-features.h' the macros impacted by the difference between 3.2 and 4.4 is not many, maybe 3 or so. Therefore, if we went back to 3.2, our glibc would be slower (but not by a noticeable amount I'm guessing).

Anyway, I vote for the status quo :)

Comment by freswa (frederik) - Thursday, 20 October 2022, 09:21 GMT
We're not "just changing parameters". If there are enough people interested in this, I'll consider a separate (private) repo to help with the migration.
But this is a no for the Arch repo from my side.