On 2022-03-04 10:22, Emilio Pozuelo Monfort wrote: > 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 > > > <car...@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: normal > > > > > > Hi, > > > > > > due to > > > > > https://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 earlier > > > > > kernels, 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, that > > > > > removing 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/yvaholtsb0nk0...@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 :)
Oops, sorry about that. > > 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 We disabled it at some point but we got strong pressure to re-enable it as it is the last version supported by OpenVZ. > 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? If we backport only [2], it means [1] doesn't work correctly as it assumes that the third version level is < 255, just like glibc internals. Aurelien > [1] > https://salsa.debian.org/glibc-team/glibc/-/commit/5452b62ded81132ebedf3db82577de5277479b27 > [2] > https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
