Bug#987266: preinst check for kernel release > 255 may no longer be needed

[Salvatore Bonaccorso <carnil@debian.org>]

Hi Aurelien,

On Sun, Sep 26, 2021 at 01:21:16PM +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2021-09-26 09:57, Salvatore Bonaccorso 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?
> 
> The bug has been reported with severity normal, and it seemed it was
> limited to a rather small range of users. Now if you thing it is a more
> widespread issue, feel free to raise the severity so that we can
> consider it from buster and bullseye. The fix has been in testing/sid
> for a few weeks, so this should be acceptable for older releases.
> 
> At least for bullseye, we have an update scheduled, currently being
> under review by the release team (bug #992693). But we won't be able to
> fix Raspbian ;-).

It is probalby not that widespread, because I guess  the case where
user install older custom kernel from 4.4.y and 4.9.y series on buster
and newer is not that frequent and at time of writing the stable
series supported are 4.4.285, 4.9.284, so the two problematic ones,
4.14.248, 4.19.208, 5.4.149, 5.10.69 and 5.14.8. But at some point
upstream will reach 256 minor version as well forthe 4.14.y, 4.19.y
and 5.10.y series.

So maybe it is worth of fixing this as for bullseye and buster point
releases (not the next ones).

So no I have no strong opinion but I stumbled over the above on the
stable list.

Regards,
Salvatore