On Thu, Jul 21, 2022 at 3:51 PM Phil Perry <pperry at elrepo.org> wrote: > > On 21/07/2022 14:37, Josh Boyer wrote: > > On Thu, Jul 21, 2022 at 9:25 AM Phil Perry <pperry at elrepo.org> wrote: > >> > >> It is a shame that RH/Stream are unable to support the WireGuard CI. > >> > >> In addition to Oracle, you could also use RHEL or Alma or Rocky or any > >> other supported distro/kernel. > > > > In this case, I think CentOS Stream is actually catching things as we > > expect. The next RHEL release (and therefore Alma, Rocky, or any > > other rebuild) will have the same issues if the changes aren't made > > before then. There's a bug reported for this and the resolution was > > that the out of tree Wireguard module for EL8 needs to stop defining a > > particular function in a header. > > > > The issue is that the C8S kernel will not run on the WireGuard CI [1], > so WireGuard are unable/unwilling to address these issues upstream as > part of their continuous development (as they do for every other kernel > they backport to), _before_ they become an issue. If the C8S kernel ran > on the WireGuard CI, these issues would get fixed at source and you > would never see these filed bugs or mailing list threads. Thanks for the link to that post. I hadn't seen it. I think Jason did a good job of explaining the situation and was fair to all involved. > WireGuard filed numerous bugs [2,3] with patches with Red Hat to get the > Stream kernel running on the their CI, which Red Hat eventually declined > to accept (and I totally get the reasons why), so WireGuard eventually > gave up and dropped support for CentOS Stream. > > The next best solution (other than getting Stream running on WireGuard's > CI) would be for the kmod SIG (or some other 3rd party provider) to fix > the code and ship kmods for Stream, but obviously that takes time and > users are potentially left with a broken VPN each time a new kernel > update is pushed. But it looks like upstream have lost interest in > supporting Stream which is a shame. I do think it would be great if we could get more participation in the kmod SIG here. Building kmods for RHEL is indeed different than building for older upstream kernels as Jason highlighted, and it seems like handling that difference is exactly what the kmod SIG would be well positioned to do. Given that the recent build issue is something I already briefly looked at, I figured I'd go ahead and fix it. https://pagure.io/centos-sig-kmods/kmod-wireguard/pull-request/1 josh