Bug#987266: preinst check for kernel release > 255 may no longer be needed
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 <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: 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/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 :)
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
aurelien@aurel32.net http://www.aurel32.net
Reply to: