Bug#1003844:

> Do you have the possiblity to test the most current 4.19.y version?

I'm currently attempting to do this following instructions on https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-building so I can get a .deb package that i can push up to one of my Kubernetes cluster nodes exhibiting the Cilium breakage.

However, I get stuck on `debian/rules orig` after running `debian/bin/genorig.py ./tarball` because several of the patches no longer apply cleanly and it's not clear how I should go about either viewing or resolving the patch conflicts. Got any advice as far as that goes? Or do you think it would be sufficient just to build a vanilla v4.19.228 kernel using the linux repo's built-in deb package building tools (assuming that still exists and works, it's been several years since i tried it)? My assumption so far has been that the best approach would be to build the kernel using the tooling and patches from the debian source.

On Tue, Feb 8, 2022 at 7:08 AM Salvatore Bonaccorso <carnil@debian.org> wrote:

Hi,

On Tue, Feb 08, 2022 at 01:11:47AM +0000, Wayne Warren wrote:
> Hey there, if I understand correctly this bug which definitely affects
> linux 4.19.208-1 was closed because it doesn't affect some other version?
> 5.10.40-1?

Right, and because the BTS can then close a bug in multiple versions.
We know thus that the issue is still present in buster and the
4.19.208-1 kernel.

> I'm asking because (maybe obviously) this bug is affecting my use of
> 4.19.208-1 in a Kubernetes cluster. I would just pin to
> 4.19.194-3/4.19.0-17-cloud-amd64 but am mildly concerned about the polkit
> CVE which, to my understanding, is addressed in 4.19.208-1 but not in
> 4.19.194-3.
>
> So I guess my question is -- does anyone involved with maintaining the
> Debian 4.19 image know if there is a fix in sight for this that will
> eventually be available, maybe for a 4.19.0-19-cloud-amd64 image or
> something like that? I don't really know how Debian kernel maintenance
> works. If it would be helpful I could test the latest 4.19 upstream kernel
> to verify any fixes that might have come through between 4.19.208 and
> 4.19.227 (the current upstream patch version). I may do it anyway, but it
> would be encouraging to know if there is some kind of Debian process for
> getting a new kernel out if my effort succeeds.

Yes that would be helpful, in particular because we try to rebase to
the latest 4.19.y version in each point release. So the next update
will be to at least 4.19.227. Even better though if we can identify
the fix itself.

As mentioned in https://bugs.debian.org/1003844#15 if the issue is
present in the most current 4.19.y stable version then the next step
would be to report it to upstream, keeping us ideally in the loop.

Do you have the possiblity to test the most current 4.19.y version?

Regards,
Salvatore