On 04/03/2022 09:50, Aurelien Jarno wrote:
On 2022-03-04 09:19, Emilio Pozuelo Monfort wrote:Hi, On Sun, 26 Sep 2021 09:57:02 +0200 Salvatore Bonaccorso <carnil@debian.org> wrote:Hi Aurelien, On Tue, Apr 20, 2021 at 06:36:33PM +0200, Andras Korn wrote:Package: libc6 Version: 2.31-11 Severity: normalHi, due tohttps://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f (a commit from 2004) the preinst script for glibc checks whether the "z" in the "x.y.z" of the kernel version is less than 255. If yes, the package refuses to install.I hit this problem on a box with a custom 4.9.266 kernel. Based on this lkml thread:https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/, the check is no longer needed because the kernel caps the version code it reports to 255, even if uname prints a higher number.Of course, you could conceivably still hit the problem with earlierkernels, so I suppose the logic of the check should be modified, not removed entirely, to be technically correct.If forced at gunpoint to make a guess, I would guess, though, thatremoving the check would have very little actual impact; it also doesn't protect the user from installing a kernel with an unsupported version number after having installed glibc.Prompted by https://lore.kernel.org/stable/YVAhOlTsb0NK0BVi@kroah.com/T/#t and given this was addressed with https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900 is this something we should do consider as well for the older releases where it is not acutally needed for people compiling their own custom kernels?Another stretch user brought this up [1]. I suppose there are and as time passes (with current stable kernel versions getting higher) there will be more users affected by this in buster and bullseye. Have you further considered including this fix in a proposed-update?Yep I have submitted #1005906 for bullseye, and I have committed the fix to the buster branch, but not yet submitted the bug.
I was wondering what docker had to do with all this, until I realized you meant #1005949 :)
Stretch is going to be more complicated as we still support 2.6.32 kernels, which means the third version level actually still makes sense.
I'm surprised we support that. However in any case we wouldn't need to backport [1], we could just backport [2] and support both 2.6.32 as well as e.g. 4.14.264. Wouldn't that work?
Cheers, Emilio[1] https://salsa.debian.org/glibc-team/glibc/-/commit/5452b62ded81132ebedf3db82577de5277479b27 [2] https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900