Re: [CentOS] [EXT] Re: Kmods SIG in RHEL
On 21/09/2022 12.02, Fabian Arrotin wrote: On 21/09/2022 11:51, Fabian Arrotin wrote: On 21/09/2022 08:32, Thomas Stephen Lee wrote: Hi, Is https://sigs.centos.org/kmods/ a part of RHEL 9? If yes, what is the repository name? If not, when can we expect it to be included? Thanks --- Lee No, it's not part of RHEL9 , and it's built and maintained by the Kmods SIG (see https://sigs.centos.org/kmods/) as a community project. They were building it first for Stream 9 and later asked to also build for/against RHEL9 kernel when it was available (see https://pagure.io/centos-infra/issue/786) Kind Regards, Oups, realizing that I replied with same URL you gave and (I'll blame lack of coffee effect :-) ) my brain translated initially to artifacts/rpms that can be found on http://mirror.stream.centos.org/SIGs/9/kmods/ ... But answer is still correct but now more complete as you see where built/signed pkgs are landing too (even if that was in the infra tracker ticket) In addition to what Fabian already mentioned: The Kmods SIG does by now provide all packages it provides for Stream 9 also for RHEL9. However, there is no easy way for you to enable the Kmods SIG's repositories on RHEL9 (yet) as SIGs can not (yet) provide centos-release-* packages for RHEL9 (and its clones) [1]. In case you want to use any package provided by the Kmods SIG for RHEL9 you have to manually add its repositories for now, e.g. by copying [2] to /etc/yum.repos.d/centos-kmods.repo Note that you also need to copy the Kmods SIG's GPG key [3] to /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Kmods We hope to be able to provide a centos-release-kmods package soon which should then allow you to consume the Kmods SIG's content after a simple dnf install https://mirror.stream.centos.org/... command similar to how you can easily enable EPEL. [1]: https://pagure.io/centos-infra/issue/643 [2]: https://gitlab.com/CentOS/kmods/rpms/centos-release-kmods/-/raw/c9/centos-kmods.repo [3]: https://www.centos.org/keys/RPM-GPG-KEY-CentOS-SIG-Kmods ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [EXT] c9s: CPU ISA level lower than required
On 07/02/2022 17.40, Alessio wrote: On Mon, 2022-02-07 at 16:58 +0100, Peter Georg wrote: On 07/02/2022 16.28, Alessio wrote: On Mon, 2022-02-07 at 16:20 +0100, Peter Georg wrote: glibc-2.34-20 includes a fix to more reliable detect CPU compatibility. See Bug https://bugzilla.redhat.com/show_bug.cgi?id=2040657 Does your CPU support x86-64-v2? The KVM version I'm using doesn't support that? Could it be? Possible. What is your configured KVM CPU model? A first step might be to check the output of /proc/cpuinfo in your VM. Just to be sure, the host CPU does support x86-64-v2? If this method [0] is correct, the host CPU supports x86-64-v2, x86-64- v3 and x86-64-v4 While inside the VM, the result is "CPU supports x86-64-v1" In this case your VM is misconfigured. Please check your configured KVM CPU model. A list of all CPU models and support x86-64 levels can be found here: https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html [0] https://itectec.com/unixlinux/how-to-check-if-the-cpu-supports-x86-64-v2/ Thanks, A. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [EXT] c9s: CPU ISA level lower than required
On 07/02/2022 16.28, Alessio wrote: On Mon, 2022-02-07 at 16:20 +0100, Peter Georg wrote: glibc-2.34-20 includes a fix to more reliable detect CPU compatibility. See Bug https://bugzilla.redhat.com/show_bug.cgi?id=2040657 Does your CPU support x86-64-v2? The KVM version I'm using doesn't support that? Could it be? Possible. What is your configured KVM CPU model? A first step might be to check the output of /proc/cpuinfo in your VM. Just to be sure, the host CPU does support x86-64-v2? However I was able to install CentOS Stream 9 from the ISO in this VM. So it wasn't supposed to work? I do not know when/how the checks for x86-64-v2 are done. Thanks, A. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [EXT] c9s: CPU ISA level lower than required
On 07/02/2022 16.01, Alessio wrote: Hello. I had a CentOS Stream 9 installation in a KVM VM. Today a "dnf upgrade" lead to an unusable system: dnf, rpm commands complain that "glibc cpu does not support x86-64-v2" or "CPU ISA level is lower than required". The updates leading to this state seem to be: python3 3.9.10-1, glibc 2.34-21, rpm 4.16.1.3-10 What happened? glibc-2.34-20 includes a fix to more reliable detect CPU compatibility. See Bug https://bugzilla.redhat.com/show_bug.cgi?id=2040657 Does your CPU support x86-64-v2? CentOS Stream for AMD and Intel 64-bit architectures requires at least x86-64-v2. See [1] for some background. [1]: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level#architectural_considerations_for_rhel_9 Thanks, A. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS-docs] Request Wiki page for proposed kmods SIG description
Dear all, I'd like to request the creation of a Wiki page for the "kmods" SIG I proposed recently on the centos-devel mailing list. Similar to pages for other SIGs, the proposed subject is "kmods SIG" and the proposed location is: https://wiki.centos.org/SpecialInterestGroup/Kmods My username is: PeterGeorg Please let me know in case you need any further information. Thanks! Peter ___ CentOS-docs mailing list CentOS-docs@centos.org https://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS] [EXT] Re: https://blog.centos.org/2020/12/future-is-centos-stream/
On 09/12/2020 18.10, Brendan Conoboy wrote: On Wed, Dec 9, 2020 at 7:21 AM Phil Perry wrote: On 09/12/2020 03:26, Brendan Conoboy wrote: On Tue, Dec 8, 2020 at 4:19 PM Pete Biggs wrote: On Tue, 2020-12-08 at 17:54 -0500, Matthew Miller wrote: On Tue, Dec 08, 2020 at 03:15:17PM +, Pete Biggs wrote: "CentOS will become the developer playground" This one is categorically not the case. Even Fedora isn't a developer playground. Everything landing in CentOS Stream is actually *planned* (with emphasis intentional) to go in a future RHEL release. It's all the talk of SIGs and developing and testing and that Stream will be the centerpiece of that. That's what I meant. I don't know if I'd call SIGs a playground, but they're certainly an important venue for communities to explore variations. Previously, all the development around RHEL releases was done in secret, in the Red Hat black box. Now it's out of the box and can be watched. There may be some launch pains, but I expect the average quality of an update hitting CentOS Stream to be very high. I don't get that from the documents released today. If Stream is *not* a test-bed, then surely the code that appears in Stream must be fully formed in secret behind the scenes first. Yes, it will appear piecemeal rather than in one big chunk, but it has been categorically denied that Stream is not a RHEL 8.n+1 beta and is more a RHEL 8.n+1 RC/rolling release. I think maybe some of the nervousness about CentOS Stream comes from RHEL seeming opacity on its development model. As one of the architects of our development process I'd be happy to field questions. I'll start by making a two points in case they're in any way unclear: 1. Everything that goes into RHEL lands upstream first, then the patches are backported into the RHEL releases. 2. Most of the work we do or plan on doing is in bugzilla.redhat.com. If you go into the RHEL8 product queue today and file a bug you'll see "CentOS Stream" as a "Version" where an issue is encountered. I think what a lot of people are concerned about is the rolling-release aspect of this. There will be no definitive versioning of CentOS in the future - all you will be able to say is "fully updated" and it won't be possible to slot a CentOS system in to exactly match a RHEL version. Will third party RPMs built against RHEL 8.x be installable on a CentOS 8 Stream system? The answer is surely "it depends", but there are a lot of hardware vendors that target drivers to RHEL releases, which may well make CentOS non-viable for hardware that doesn't have drivers built in to the kernel. Generally if they follow the ABI guidelines I would expect it to work. Those are here: https://access.redhat.com/articles/rhel8-abi-compatibility For loadable kernel modules there's a kernel ABI. Hi Brendan, This point is *critical*, so I apologise in advance for the lengthy post, *you* are breaking the kernel ABI between RHEL8 and Stream. One of the main unique selling points of RHEL is the stability of it's kernel ABI. No other distro provides this. The very nature of rolling kernel updates in Stream breaks the kernel ABI and breaks compatibility between RHEL8 and Stream. What works on RHEL8 may not work on Stream. At the kernel level, the two products diverge in fundamental compatibility and are not compatible, are no longer the same. How bad is this divergence / breakage? Well, we know the kernel ABI will change from time to time, almost exclusively at new point releases due to the massive backporting work that goes into the RHEL kernel. And this is fine, we know it's coming, we know when it's coming, and we can plan for it's impact. It's a price well worth paying. To put this in context, at elrepo I currently help maintain around 50 3rd party kernel driver packages for RHEL8. When RH released RHEL8.3, every single package in our repository broke due to changes in the kernel ABI in the 6 month period between RHEL8.2 and RHEL8.3. It's not ideal, but we accept it as a price we pay for the otherwise excellent stability of the kernel ABI during the proceeding 6 months. As I said above, we know it's coming, we know when it's coming, and we can plan for it. Now contrast that with Stream. Every kernel update in Stream has the potential to break the kernel ABI causing packages built for RHEL to break. We don't know when that may happen (only that it will), we don't know how often it will happen, we have no idea which packages it will break. and we have no way to fix it. Consequently, elrepo has been unable to support Stream kernels. It is not just elrepo's users that the Stream kernels will affect. All OEM hardware manufacturers releasing 3rd party driver rpms as part of Red Hat's Driver Update Programme or otherwise will be similarly affected, and their driver updates will not be applicable to or compatible with CentOS Stream. In fact, RHEL's own driver update packages will likely need rebuilding
