On 22/07/2022 17.53, Josh Boyer wrote: > 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. The explanation by Jason is really good and definitely worth reading for everyone who wants to know about the issue concerning Wireguard on RHEL 7 (and clones), RHEL 8 (and clones), and Stream 8. I on purpose listed all affected systems here to emphasize that this issue is not limited to CentOS Stream 8 but also concerns RHEL 7 and 8 (and any of its clones). >> 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. Usually I manage to update Wireguard quite fast. However I'm currently on vacation and hence the updated version has seen a delayed release on July 21st which is two days after kernel-4.18.0-408.el8 has been built in koji. Anyways, I'd be really happy to see more participation in the Kmods SIG to ensure timely updates of all provided kmod packages and to add further useful kmods. > 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 Thanks for opening a PR! Please see my comment there. I hope to finish the transition to GitLab shortly after I return from vacation and properly document it. > > josh > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel