From toracat at elrepo.org Mon Dec 1 14:30:21 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Mon, 1 Dec 2025 11:30:21 -0800 Subject: [elrepo] Announcement: EL8 Updated kernel-ml Package Set [6.17.10-1] Message-ID: Announcing the release of the kernel-ml-6.17.10-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.17.10 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-6.17.10-1.el8.elrepo.x86_64.rpm kernel-ml-core-6.17.10-1.el8.elrepo.x86_64.rpm kernel-ml-devel-6.17.10-1.el8.elrepo.x86_64.rpm kernel-ml-doc-6.17.10-1.el8.elrepo.noarch.rpm kernel-ml-headers-6.17.10-1.el8.elrepo.x86_64.rpm kernel-ml-modules-6.17.10-1.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-6.17.10-1.el8.elrepo.x86_64.rpm kernel-ml-tools-6.17.10-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-6.17.10-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.17.10-1.el8.elrepo.x86_64.rpm perf-6.17.10-1.el8.elrepo.x86_64.rpm python3-perf-6.17.10-1.el8.elrepo.x86_64.rpm nosrc kernel-ml-6.17.10-1.el8.elrepo.nosrc.rpm Please note that as of kernel-ml version 6.5.4 we are unable to continue providing the bpftool package. We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-8 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-8 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-8 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ From toracat at elrepo.org Mon Dec 1 14:28:41 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Mon, 1 Dec 2025 11:28:41 -0800 Subject: [elrepo] Announcement: EL10 Updated kernel-ml Package Set [6.17.10-1] Message-ID: Announcing the release of the kernel-ml-6.17.10-1.el10.elrepo package set into the EL10 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.17.10 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-6.17.10-1.el10.elrepo.x86_64.rpm kernel-ml-core-6.17.10-1.el10.elrepo.x86_64.rpm kernel-ml-cross-headers-6.17.10-1.el10.elrepo.x86_64.rpm kernel-ml-devel-6.17.10-1.el10.elrepo.x86_64.rpm kernel-ml-devel-matched-6.17.10-1.el10.elrepo.x86_64.rpm kernel-ml-headers-6.17.10-1.el10.elrepo.x86_64.rpm kernel-ml-modules-6.17.10-1.el10.elrepo.x86_64.rpm kernel-ml-modules-extra-6.17.10-1.el10.elrepo.x86_64.rpm kernel-ml-tools-6.17.10-1.el10.elrepo.x86_64.rpm kernel-ml-tools-libs-6.17.10-1.el10.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.17.10-1.el10.elrepo.x86_64.rpm libperf-6.17.10-1.el10.elrepo.x86_64.rpm libperf-devel-6.17.10-1.el10.elrepo.x86_64.rpm perf-6.17.10-1.el10.elrepo.x86_64.rpm python3-perf-6.17.10-1.el10.elrepo.x86_64.rpm rtla-6.17.10-1.el10.elrepo.x86_64.rpm rv-6.17.10-1.el10.elrepo.x86_64.rpm nosrc kernel-ml-6.17.10-1.el10.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-10 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-10 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-10 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ From toracat at elrepo.org Mon Dec 1 14:29:26 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Mon, 1 Dec 2025 11:29:26 -0800 Subject: [elrepo] Announcement: EL9 Updated kernel-ml Package Set [6.17.10-1] Message-ID: Announcing the release of the kernel-ml-6.17.10-1.el9.elrepo package set into the EL9 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.17.10 The following files are currently synchronising to our mirror sites: aarch64 [1] bpftool-6.17.10-1.el9.elrepo.aarch64.rpm kernel-ml-6.17.10-1.el9.elrepo.aarch64.rpm kernel-ml-core-6.17.10-1.el9.elrepo.aarch64.rpm kernel-ml-devel-6.17.10-1.el9.elrepo.aarch64.rpm kernel-ml-devel-matched-6.17.10-1.el9.elrepo.aarch64.rpm kernel-ml-doc-6.17.10-1.el9.elrepo.noarch.rpm kernel-ml-headers-6.17.10-1.el9.elrepo.aarch64.rpm kernel-ml-modules-6.17.10-1.el9.elrepo.aarch64.rpm kernel-ml-modules-extra-6.17.10-1.el9.elrepo.aarch64.rpm kernel-ml-tools-6.17.10-1.el9.elrepo.aarch64.rpm kernel-ml-tools-libs-6.17.10-1.el9.elrepo.aarch64.rpm kernel-ml-tools-libs-devel-6.17.10-1.el9.elrepo.aarch64.rpm perf-6.17.10-1.el9.elrepo.aarch64.rpm python3-perf-6.17.10-1.el9.elrepo.aarch64.rpm x86_64 bpftool-6.17.10-1.el9.elrepo.x86_64.rpm kernel-ml-6.17.10-1.el9.elrepo.x86_64.rpm kernel-ml-core-6.17.10-1.el9.elrepo.x86_64.rpm kernel-ml-devel-6.17.10-1.el9.elrepo.x86_64.rpm kernel-ml-devel-matched-6.17.10-1.el9.elrepo.x86_64.rpm kernel-ml-doc-6.17.10-1.el9.elrepo.noarch.rpm kernel-ml-headers-6.17.10-1.el9.elrepo.x86_64.rpm kernel-ml-modules-6.17.10-1.el9.elrepo.x86_64.rpm kernel-ml-modules-extra-6.17.10-1.el9.elrepo.x86_64.rpm kernel-ml-tools-6.17.10-1.el9.elrepo.x86_64.rpm kernel-ml-tools-libs-6.17.10-1.el9.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.17.10-1.el9.elrepo.x86_64.rpm perf-6.17.10-1.el9.elrepo.x86_64.rpm python3-perf-6.17.10-1.el9.elrepo.x86_64.rpm nosrc kernel-ml-6.17.10-1.el9.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-9 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-9 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-9 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [2] and, for our reference, to the ELRepo bug tracker [3]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] The ELRepo Project would like to thank the OSU Open Source Lab for their support with the aarch64 platform. [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From lfarkas at lfarkas.org Mon Dec 1 15:18:26 2025 From: lfarkas at lfarkas.org (Farkas Levente) Date: Mon, 1 Dec 2025 21:18:26 +0100 Subject: [elrepo] serious design flaw in network kmod rpms Message-ID: <9e59ad41-05af-46d9-b937-05310420f6b4@lfarkas.org> hi, I wrote an issue about it: https://elrepo.org/bugs/view.php?id=1572 and for me it was very clear it's a serious bug, but it seems I've to explain it more details. The problem: kmod-r8125 blacklist r8169 kmod. The bigger problem: It was not doing it on el 9.6 but do it on 9.7! Which cause if someone install kmod-r8125 on a system which has any other realtek network device it's stop working and no longer be able to access to the system remotely. So it's a serious regression! What's more can be solved only in place! Why it's so big problem? eg we've got a few thousands of server in a few dozens of country...and wouldn't like to travel... we keep the installed package list identical on all of our server, but of course the hardware is not exactly the same. of course i can solve this simple rebuild the buggy rpm, but imho it's a much larger problem. blacklist is for module for identical hardware eg nvidia and nouveau, but in this case kmod-r8125 blacklist r8169 which is a much larger set of hardware list. and the suggestion to install kmod-r8168 is not a solution or have to install to all kmod-r*. in case of i install ANY of the elrepo kmod the system still have to be usable and working (what's more should have to be better). this is not the case with kmod-r8125. So IMHO this move is very serious regression what's more these changes have to revert in all similar places. regards. -- Levente "Si vis pacem para bellum!" From amyagi at gmail.com Tue Dec 2 13:22:03 2025 From: amyagi at gmail.com (Akemi Yagi) Date: Tue, 2 Dec 2025 10:22:03 -0800 Subject: [elrepo] serious design flaw in network kmod rpms In-Reply-To: <9e59ad41-05af-46d9-b937-05310420f6b4@lfarkas.org> References: <9e59ad41-05af-46d9-b937-05310420f6b4@lfarkas.org> Message-ID: On Tue, Dec 2, 2025 at 2:14?AM Farkas Levente wrote: > > hi, > I wrote an issue about it: > https://elrepo.org/bugs/view.php?id=1572 > and for me it was very clear it's a serious bug, but it seems I've to > explain it more details. > > The problem: > kmod-r8125 blacklist r8169 kmod. > > The bigger problem: > It was not doing it on el 9.6 but do it on 9.7! Which cause if someone > install kmod-r8125 on a system which has any other realtek network > device it's stop working and no longer be able to access to the system > remotely. > So it's a serious regression! > What's more can be solved only in place! > > Why it's so big problem? eg we've got a few thousands of server in a few > dozens of country...and wouldn't like to travel... > we keep the installed package list identical on all of our server, but > of course the hardware is not exactly the same. > > of course i can solve this simple rebuild the buggy rpm, but imho it's a > much larger problem. > > blacklist is for module for identical hardware eg nvidia and nouveau, > but in this case kmod-r8125 blacklist r8169 which is a much larger set > of hardware list. and the suggestion to install kmod-r8168 is not a > solution or have to install to all kmod-r*. > in case of i install ANY of the elrepo kmod the system still have to be > usable and working (what's more should have to be better). this is not > the case with kmod-r8125. > > So IMHO this move is very serious regression what's more these changes > have to revert in all similar places. > > regards. > > -- > Levente "Si vis pacem para bellum!" Hi Levente , Thanks for the note. I suppose there is no "one-size-fit-all" solution to the issue. The original reason why r8169 was blacklisted was that, with the kmod-r8125 in RHEL 10, it still used the r8169 driver. Of course, when you have 2 NICs, the situation is not as simple as disabling one driver or the other. We'd like to get a good and reasonable solution but in the mean time, we could revert the change if that works as a temporary fix. Akemi From tqhoang at elrepo.org Tue Dec 2 22:48:22 2025 From: tqhoang at elrepo.org (Tuan Hoang) Date: Wed, 3 Dec 2025 03:48:22 +0000 (UTC) Subject: [elrepo] serious design flaw in network kmod rpms In-Reply-To: References: <9e59ad41-05af-46d9-b937-05310420f6b4@lfarkas.org> Message-ID: <966425953.367328.1764733702317@mail.yahoo.com> Hi Levente, As noted in the bug tracker, we have pushed out a new kmod-r8125 that removes the blacklist file.https://elrepo.org/bugs/view.php?id=1572 Note: That the kmod-r8168 will still retain the blacklist-r8169.conf. Tuan On Tuesday, December 2, 2025 at 01:28:28 PM EST, Akemi Yagi wrote: On Tue, Dec 2, 2025 at 2:14?AM Farkas Levente wrote: > > hi, > I wrote an issue about it: > https://elrepo.org/bugs/view.php?id=1572 > and for me it was very clear it's a serious bug, but it seems I've to > explain it more details. > > The problem: > kmod-r8125 blacklist r8169 kmod. > > The bigger problem: > It was not doing it on el 9.6 but do it on 9.7! Which cause if someone > install kmod-r8125 on a system which has any other realtek network > device it's stop working and no longer be able to access to the system > remotely. > So it's a serious regression! > What's more can be solved only in place! > > Why it's so big problem? eg we've got a few thousands of server in a few > dozens of country...and wouldn't like to travel... > we keep the installed package list identical on all of our server, but > of course the hardware is not exactly the same. > > of course i can solve this simple rebuild the buggy rpm, but imho it's a > much larger problem. > > blacklist is for module for identical hardware eg nvidia and nouveau, > but in this case kmod-r8125 blacklist r8169 which is a much larger set > of hardware list. and the suggestion to install kmod-r8168 is not a > solution or have to install to all kmod-r*. > in case of i install ANY of the elrepo kmod the system still have to be > usable and working (what's more should have to be better). this is not > the case with kmod-r8125. > > So IMHO this move is very serious regression what's more these changes > have to revert in all similar places. > > regards. > > -- > Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Si vis pacem para bellum!" Hi Levente , Thanks for the note. I suppose there is no "one-size-fit-all" solution to the issue. The original reason why r8169 was blacklisted was that, with the kmod-r8125 in RHEL 10, it still used the r8169 driver. Of course, when you have 2 NICs, the situation is not as simple as disabling one driver or the other. We'd like to get a good and reasonable solution but in the mean time, we could revert the change if that works as a temporary fix. Akemi _______________________________________________ elrepo mailing list elrepo at lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Wed Dec 3 04:04:58 2025 From: lfarkas at lfarkas.org (Farkas Levente) Date: Wed, 3 Dec 2025 10:04:58 +0100 Subject: [elrepo] serious design flaw in network kmod rpms In-Reply-To: References: <9e59ad41-05af-46d9-b937-05310420f6b4@lfarkas.org> Message-ID: <08e18542-5eca-4d58-a01a-0685c2580eec@lfarkas.org> anyway https://elrepo.org/ is no longer usable without user/pass (and even my user/pass is not working there). imho it's not by design:-) Levente "Si vis pacem para bellum!" On 12/2/25 20:17, Farkas Levente wrote: > Hi > > I already rebuilt the driver for ourself but imho it can be a serious > issue for others. And not just in this case but all other blacklisted > driver. What's more we have a? motherboard on which both driver needed. > In the last few decades there was not any such problem with elrepo. > IMHO in this case the solution is to provide a newer version of the > r8169 which do not provide those pci id's which provided by the r8125. > Blacklisted a much larger set of devices is not a solution. > Or try to find some kind of ordering between kernel modules when both > provide the same set of pci id's. Even a dirty trick alphabetical order > or something is better to choose your driver instead of the r8169. May > be ask someone in the core kernel team who knows some kind of trivial > solution. > > Regards > > ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" > > Akemi Yagi > ezt ?rta > (id?pont: 2025. dec. 2., Ke 19:28): > > On Tue, Dec 2, 2025 at 2:14?AM Farkas Levente > wrote: > > > > hi, > > I wrote an issue about it: > > https://elrepo.org/bugs/view.php?id=1572 bugs/view.php?id=1572> > > and for me it was very clear it's a serious bug, but it seems I've to > > explain it more details. > > > > The problem: > > kmod-r8125 blacklist r8169 kmod. > > > > The bigger problem: > > It was not doing it on el 9.6 but do it on 9.7! Which cause if > someone > > install kmod-r8125 on a system which has any other realtek network > > device it's stop working and no longer be able to access to the > system > > remotely. > > So it's a serious regression! > > What's more can be solved only in place! > > > > Why it's so big problem? eg we've got a few thousands of server > in a few > > dozens of country...and wouldn't like to travel... > > we keep the installed package list identical on all of our > server, but > > of course the hardware is not exactly the same. > > > > of course i can solve this simple rebuild the buggy rpm, but imho > it's a > > much larger problem. > > > > blacklist is for module for identical hardware eg nvidia and nouveau, > > but in this case kmod-r8125 blacklist r8169 which is a much > larger set > > of hardware list. and the suggestion to install kmod-r8168 is not a > > solution or have to install to all kmod-r*. > > in case of i install ANY of the elrepo kmod the system still have > to be > > usable and working (what's more should have to be better). this > is not > > the case with kmod-r8125. > > > > So IMHO this move is very serious regression what's more these > changes > > have to revert in all similar places. > > > > regards. > > > > -- > > Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"Si vis pacem para bellum!" > > Hi Levente , > > Thanks for the note. I suppose there is no "one-size-fit-all" solution > to the issue. The original reason why r8169 was blacklisted was that, > with the kmod-r8125 in RHEL 10, it still used the r8169 driver. Of > course, when you have 2 NICs, the situation is not as simple as > disabling one driver or the other. > > We'd like to get a good and reasonable solution but in the mean time, > we could revert the change if that works as a temporary fix. > > > Akemi > _______________________________________________ > elrepo mailing list > elrepo at lists.elrepo.org > http://lists.elrepo.org/mailman/listinfo/elrepo lists.elrepo.org/mailman/listinfo/elrepo> > From lfarkas at lfarkas.org Tue Dec 2 14:17:03 2025 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 2 Dec 2025 20:17:03 +0100 Subject: [elrepo] serious design flaw in network kmod rpms In-Reply-To: References: <9e59ad41-05af-46d9-b937-05310420f6b4@lfarkas.org> Message-ID: Hi I already rebuilt the driver for ourself but imho it can be a serious issue for others. And not just in this case but all other blacklisted driver. What's more we have a motherboard on which both driver needed. In the last few decades there was not any such problem with elrepo. IMHO in this case the solution is to provide a newer version of the r8169 which do not provide those pci id's which provided by the r8125. Blacklisted a much larger set of devices is not a solution. Or try to find some kind of ordering between kernel modules when both provide the same set of pci id's. Even a dirty trick alphabetical order or something is better to choose your driver instead of the r8169. May be ask someone in the core kernel team who knows some kind of trivial solution. Regards Levente "Si vis pacem para bellum!" Akemi Yagi ezt ?rta (id?pont: 2025. dec. 2., Ke 19:28): > On Tue, Dec 2, 2025 at 2:14?AM Farkas Levente wrote: > > > > hi, > > I wrote an issue about it: > > https://elrepo.org/bugs/view.php?id=1572 > > and for me it was very clear it's a serious bug, but it seems I've to > > explain it more details. > > > > The problem: > > kmod-r8125 blacklist r8169 kmod. > > > > The bigger problem: > > It was not doing it on el 9.6 but do it on 9.7! Which cause if someone > > install kmod-r8125 on a system which has any other realtek network > > device it's stop working and no longer be able to access to the system > > remotely. > > So it's a serious regression! > > What's more can be solved only in place! > > > > Why it's so big problem? eg we've got a few thousands of server in a few > > dozens of country...and wouldn't like to travel... > > we keep the installed package list identical on all of our server, but > > of course the hardware is not exactly the same. > > > > of course i can solve this simple rebuild the buggy rpm, but imho it's a > > much larger problem. > > > > blacklist is for module for identical hardware eg nvidia and nouveau, > > but in this case kmod-r8125 blacklist r8169 which is a much larger set > > of hardware list. and the suggestion to install kmod-r8168 is not a > > solution or have to install to all kmod-r*. > > in case of i install ANY of the elrepo kmod the system still have to be > > usable and working (what's more should have to be better). this is not > > the case with kmod-r8125. > > > > So IMHO this move is very serious regression what's more these changes > > have to revert in all similar places. > > > > regards. > > > > -- > > Levente "Si vis pacem para bellum!" > > Hi Levente , > > Thanks for the note. I suppose there is no "one-size-fit-all" solution > to the issue. The original reason why r8169 was blacklisted was that, > with the kmod-r8125 in RHEL 10, it still used the r8169 driver. Of > course, when you have 2 NICs, the situation is not as simple as > disabling one driver or the other. > > We'd like to get a good and reasonable solution but in the mean time, > we could revert the change if that works as a temporary fix. > > > Akemi > _______________________________________________ > elrepo mailing list > elrepo at lists.elrepo.org > http://lists.elrepo.org/mailman/listinfo/elrepo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Wed Dec 3 11:00:50 2025 From: lfarkas at lfarkas.org (Farkas Levente) Date: Wed, 3 Dec 2025 17:00:50 +0100 Subject: [elrepo] serious design flaw in network kmod rpms In-Reply-To: References: <9e59ad41-05af-46d9-b937-05310420f6b4@lfarkas.org> Message-ID: On Tue, Dec 2, 2025 at 7:28?PM Akemi Yagi wrote: > Hi Levente , > > Thanks for the note. I suppose there is no "one-size-fit-all" solution > to the issue. The original reason why r8169 was blacklisted was that, > with the kmod-r8125 in RHEL 10, it still used the r8169 driver. Of > course, when you have 2 NICs, the situation is not as simple as > disabling one driver or the other. > > We'd like to get a good and reasonable solution but in the mean time, > we could revert the change if that works as a temporary fix. > we just install a fresh almalinux 10.1 without any kind of external repo to computer which has 2 different realtek card: # lspci -nn|grep -i eth 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05) 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8161] (rev 15) and it's working fine with the original r8169 driver with 2.6Gb/s. so what was the reason for kmod-rr8125? 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) Subsystem: Gigabyte Technology Co., Ltd Device e000 Flags: bus master, fast devsel, latency 0, IRQ 18 I/O ports at 4000 [size=256] Memory at 42d00000 (64-bit, non-prefetchable) [size=64K] Memory at 42d10000 (64-bit, non-prefetchable) [size=16K] Capabilities: Kernel driver in use: r8169 Kernel modules: r8169 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) Subsystem: Realtek Semiconductor Co., Ltd. TP-Link TG-3468 v4.0 Gigabit PCI Express Network Adapter Flags: bus master, fast devsel, latency 0, IRQ 19 I/O ports at 3000 [size=256] Memory at 42c04000 (64-bit, non-prefetchable) [size=4K] Memory at 42c00000 (64-bit, non-prefetchable) [size=16K] Capabilities: Kernel driver in use: r8169 Kernel modules: r8169 -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From amyagi at gmail.com Wed Dec 3 12:45:33 2025 From: amyagi at gmail.com (Akemi Yagi) Date: Wed, 3 Dec 2025 09:45:33 -0800 Subject: [elrepo] serious design flaw in network kmod rpms In-Reply-To: <08e18542-5eca-4d58-a01a-0685c2580eec@lfarkas.org> References: <9e59ad41-05af-46d9-b937-05310420f6b4@lfarkas.org> <08e18542-5eca-4d58-a01a-0685c2580eec@lfarkas.org> Message-ID: On Wed, Dec 3, 2025 at 1:05?AM Farkas Levente wrote: > > anyway > https://elrepo.org/ > is no longer usable without user/pass (and even my user/pass is not > working there). imho it's not by design:-) "Si vis pacem para bellum!" Certainly not by design. :) I noticed some unwanted access to the homepage the other day and so tightened the security. Apparently I overdid it. This is now corrected. Thanks for letting us know. Akemi From amyagi at gmail.com Wed Dec 3 14:06:21 2025 From: amyagi at gmail.com (Akemi Yagi) Date: Wed, 3 Dec 2025 11:06:21 -0800 Subject: [elrepo] serious design flaw in network kmod rpms In-Reply-To: References: <9e59ad41-05af-46d9-b937-05310420f6b4@lfarkas.org> Message-ID: On Wed, Dec 3, 2025 at 9:02?AM Farkas Levente wrote: > > On Tue, Dec 2, 2025 at 7:28?PM Akemi Yagi wrote: >> >> Hi Levente , >> >> Thanks for the note. I suppose there is no "one-size-fit-all" solution >> to the issue. The original reason why r8169 was blacklisted was that, >> with the kmod-r8125 in RHEL 10, it still used the r8169 driver. Of >> course, when you have 2 NICs, the situation is not as simple as >> disabling one driver or the other. >> >> We'd like to get a good and reasonable solution but in the mean time, >> we could revert the change if that works as a temporary fix. > > > we just install a fresh almalinux 10.1 without any kind of external repo to computer which has 2 different realtek card: > # lspci -nn|grep -i eth > 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05) > 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8161] (rev 15) > > and it's working fine with the original r8169 driver with 2.6Gb/s. > so what was the reason for kmod-rr8125? Our kmod is built from the source downloaded from Realtek. The changelog has this: - Update to 9.016.01 - Disable fiber support You don't need this package is the original driver in the kernel is working fine. Akemi From tqhoang at elrepo.org Wed Dec 3 17:49:26 2025 From: tqhoang at elrepo.org (Tuan Hoang) Date: Wed, 3 Dec 2025 22:49:26 +0000 (UTC) Subject: [elrepo] serious design flaw in network kmod rpms In-Reply-To: References: <9e59ad41-05af-46d9-b937-05310420f6b4@lfarkas.org> Message-ID: <678589146.940337.1764802166385@mail.yahoo.com> Main reason for the Realtek OEM drivers is PTP and RSS support.? Tuan Sent from Yahoo Mail for iPhone On Wednesday, December 3, 2025, 2:07 PM, Akemi Yagi wrote: On Wed, Dec 3, 2025 at 9:02?AM Farkas Levente wrote: > > On Tue, Dec 2, 2025 at 7:28?PM Akemi Yagi wrote: >> >> Hi Levente , >> >> Thanks for the note. I suppose there is no "one-size-fit-all" solution >> to the issue. The original reason why r8169 was blacklisted was that, >> with the kmod-r8125 in RHEL 10, it still used the r8169 driver. Of >> course, when you have 2 NICs, the situation is not as simple as >> disabling one driver or the other. >> >> We'd like to get a good and reasonable solution but in the mean time, >> we could revert the change if that works as a temporary fix. > > > we just install a fresh almalinux 10.1 without any kind of external repo to computer which has 2 different realtek card: > # lspci -nn|grep -i eth > 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05) > 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8161] (rev 15) > > and it's working fine with the original r8169 driver with 2.6Gb/s. > so what was the reason for kmod-rr8125? Our kmod is built from the source downloaded from Realtek. The changelog has this: - Update to 9.016.01 - Disable fiber support You don't need this package is the original driver in the kernel is working fine. Akemi _______________________________________________ elrepo mailing list elrepo at lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From toracat at elrepo.org Thu Dec 4 00:20:12 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Wed, 3 Dec 2025 21:20:12 -0800 Subject: [elrepo] Announcement: EL8 Updated kernel-lt Package Set [5.4.302-1] (EOL) Message-ID: Announcing the release of the kernel-lt-5.4.302-1.el8.elrepo [EOL] package set into the EL8 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.302 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.4.302-1.el8.elrepo.x86_64.rpm kernel-lt-5.4.302-1.el8.elrepo.x86_64.rpm kernel-lt-core-5.4.302-1.el8.elrepo.x86_64.rpm kernel-lt-devel-5.4.302-1.el8.elrepo.x86_64.rpm kernel-lt-doc-5.4.302-1.el8.elrepo.noarch.rpm kernel-lt-headers-5.4.302-1.el8.elrepo.x86_64.rpm kernel-lt-modules-5.4.302-1.el8.elrepo.x86_64.rpm kernel-lt-modules-extra-5.4.302-1.el8.elrepo.x86_64.rpm kernel-lt-tools-5.4.302-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.302-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.302-1.el8.elrepo.x86_64.rpm perf-5.4.302-1.el8.elrepo.x86_64.rpm python3-perf-5.4.302-1.el8.elrepo.x86_64.rpm nosrc kernel-lt-5.4.302-1.el8.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-8 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-lt may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-lt packages in regular service. The packages are intentionally named kernel-lt so as not to conflict with the RHEL-8 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-8 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ From toracat at elrepo.org Sun Dec 7 12:06:21 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Sun, 7 Dec 2025 09:06:21 -0800 Subject: [elrepo] Announcement: EL10 Updated kernel-ml Package Set [6.17.11-1] Message-ID: Announcing the release of the kernel-ml-6.17.11-1.el10.elrepo package set into the EL10 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.17.11 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-6.17.11-1.el10.elrepo.x86_64.rpm kernel-ml-core-6.17.11-1.el10.elrepo.x86_64.rpm kernel-ml-cross-headers-6.17.11-1.el10.elrepo.x86_64.rpm kernel-ml-devel-6.17.11-1.el10.elrepo.x86_64.rpm kernel-ml-devel-matched-6.17.11-1.el10.elrepo.x86_64.rpm kernel-ml-headers-6.17.11-1.el10.elrepo.x86_64.rpm kernel-ml-modules-6.17.11-1.el10.elrepo.x86_64.rpm kernel-ml-modules-extra-6.17.11-1.el10.elrepo.x86_64.rpm kernel-ml-tools-6.17.11-1.el10.elrepo.x86_64.rpm kernel-ml-tools-libs-6.17.11-1.el10.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.17.11-1.el10.elrepo.x86_64.rpm libperf-6.17.11-1.el10.elrepo.x86_64.rpm libperf-devel-6.17.11-1.el10.elrepo.x86_64.rpm perf-6.17.11-1.el10.elrepo.x86_64.rpm python3-perf-6.17.11-1.el10.elrepo.x86_64.rpm rtla-6.17.11-1.el10.elrepo.x86_64.rpm rv-6.17.11-1.el10.elrepo.x86_64.rpm nosrc kernel-ml-6.17.11-1.el10.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-10 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-10 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-10 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ From toracat at elrepo.org Sun Dec 7 12:07:03 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Sun, 7 Dec 2025 09:07:03 -0800 Subject: [elrepo] Announcement: EL9 Updated kernel-ml [6.17.11-1] and kernel-lt [6.1.159-1] Message-ID: Announcing the release of the kernel-ml-6.17.11-1.el9.elrepo package set and the kernel-lt-6.1.159-1.el9.elrepo package set into the EL9 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml https://elrepo.org/wiki/doku.php?id=kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.17.11 https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.159 The following files are currently synchronising to our mirror sites: aarch64 [1] bpftool-6.17.11-1.el9.elrepo.aarch64.rpm kernel-ml-6.17.11-1.el9.elrepo.aarch64.rpm kernel-ml-core-6.17.11-1.el9.elrepo.aarch64.rpm kernel-ml-devel-6.17.11-1.el9.elrepo.aarch64.rpm kernel-ml-devel-matched-6.17.11-1.el9.elrepo.aarch64.rpm kernel-ml-doc-6.17.11-1.el9.elrepo.noarch.rpm kernel-ml-headers-6.17.11-1.el9.elrepo.aarch64.rpm kernel-ml-modules-6.17.11-1.el9.elrepo.aarch64.rpm kernel-ml-modules-extra-6.17.11-1.el9.elrepo.aarch64.rpm kernel-ml-tools-6.17.11-1.el9.elrepo.aarch64.rpm kernel-ml-tools-libs-6.17.11-1.el9.elrepo.aarch64.rpm kernel-ml-tools-libs-devel-6.17.11-1.el9.elrepo.aarch64.rpm perf-6.17.11-1.el9.elrepo.aarch64.rpm python3-perf-6.17.11-1.el9.elrepo.aarch64.rpm bpftool-6.1.159-1.el9.elrepo.aarch64.rpm kernel-lt-6.1.159-1.el9.elrepo.aarch64.rpm kernel-lt-core-6.1.159-1.el9.elrepo.aarch64.rpm kernel-lt-devel-6.1.159-1.el9.elrepo.aarch64.rpm kernel-lt-devel-matched-6.1.159-1.el9.elrepo.aarch64.rpm kernel-lt-doc-6.1.159-1.el9.elrepo.noarch.rpm kernel-lt-headers-6.1.159-1.el9.elrepo.aarch64.rpm kernel-lt-modules-6.1.159-1.el9.elrepo.aarch64.rpm kernel-lt-modules-extra-6.1.159-1.el9.elrepo.aarch64.rpm kernel-lt-tools-6.1.159-1.el9.elrepo.aarch64.rpm kernel-lt-tools-libs-6.1.159-1.el9.elrepo.aarch64.rpm kernel-lt-tools-libs-devel-6.1.159-1.el9.elrepo.aarch64.rpm perf-6.1.159-1.el9.elrepo.aarch64.rpm python3-perf-6.1.159-1.el9.elrepo.aarch64.rpm x86_64 bpftool-6.17.11-1.el9.elrepo.x86_64.rpm kernel-ml-6.17.11-1.el9.elrepo.x86_64.rpm kernel-ml-core-6.17.11-1.el9.elrepo.x86_64.rpm kernel-ml-devel-6.17.11-1.el9.elrepo.x86_64.rpm kernel-ml-devel-matched-6.17.11-1.el9.elrepo.x86_64.rpm kernel-ml-doc-6.17.11-1.el9.elrepo.noarch.rpm kernel-ml-headers-6.17.11-1.el9.elrepo.x86_64.rpm kernel-ml-modules-6.17.11-1.el9.elrepo.x86_64.rpm kernel-ml-modules-extra-6.17.11-1.el9.elrepo.x86_64.rpm kernel-ml-tools-6.17.11-1.el9.elrepo.x86_64.rpm kernel-ml-tools-libs-6.17.11-1.el9.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.17.11-1.el9.elrepo.x86_64.rpm perf-6.17.11-1.el9.elrepo.x86_64.rpm python3-perf-6.17.11-1.el9.elrepo.x86_64.rpm bpftool-6.1.159-1.el9.elrepo.x86_64.rpm kernel-lt-6.1.159-1.el9.elrepo.x86_64.rpm kernel-lt-core-6.1.159-1.el9.elrepo.x86_64.rpm kernel-lt-devel-6.1.159-1.el9.elrepo.x86_64.rpm kernel-lt-devel-matched-6.1.159-1.el9.elrepo.x86_64.rpm kernel-lt-doc-6.1.159-1.el9.elrepo.noarch.rpm kernel-lt-headers-6.1.159-1.el9.elrepo.x86_64.rpm kernel-lt-modules-6.1.159-1.el9.elrepo.x86_64.rpm kernel-lt-modules-extra-6.1.159-1.el9.elrepo.x86_64.rpm kernel-lt-tools-6.1.159-1.el9.elrepo.x86_64.rpm kernel-lt-tools-libs-6.1.159-1.el9.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-6.1.159-1.el9.elrepo.x86_64.rpm perf-6.1.159-1.el9.elrepo.x86_64.rpm python3-perf-6.1.159-1.el9.elrepo.x86_64.rpm nosrc kernel-ml-6.17.11-1.el9.elrepo.nosrc.rpm kernel-lt-6.1.159-1.el9.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-9 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-9 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-9 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [2] and, for our reference, to the ELRepo bug tracker [3]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] The ELRepo Project would like to thank the OSU Open Source Lab for their support with the aarch64 platform. [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From toracat at elrepo.org Sun Dec 7 12:07:48 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Sun, 7 Dec 2025 09:07:48 -0800 Subject: [elrepo] Announcement: EL8 Updated kernel-ml Package Set [6.17.11-1] Message-ID: Announcing the release of the kernel-ml-6.17.11-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.17.11 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-6.17.11-1.el8.elrepo.x86_64.rpm kernel-ml-core-6.17.11-1.el8.elrepo.x86_64.rpm kernel-ml-devel-6.17.11-1.el8.elrepo.x86_64.rpm kernel-ml-doc-6.17.11-1.el8.elrepo.noarch.rpm kernel-ml-headers-6.17.11-1.el8.elrepo.x86_64.rpm kernel-ml-modules-6.17.11-1.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-6.17.11-1.el8.elrepo.x86_64.rpm kernel-ml-tools-6.17.11-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-6.17.11-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.17.11-1.el8.elrepo.x86_64.rpm perf-6.17.11-1.el8.elrepo.x86_64.rpm python3-perf-6.17.11-1.el8.elrepo.x86_64.rpm nosrc kernel-ml-6.17.11-1.el8.elrepo.nosrc.rpm Please note that as of kernel-ml version 6.5.4 we are unable to continue providing the bpftool package. We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-8 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-8 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-8 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ From roger.sewell at cantab.net Mon Dec 8 06:51:38 2025 From: roger.sewell at cantab.net (Roger Sewell) Date: Mon, 08 Dec 2025 11:51:38 +0000 Subject: [elrepo] ELrepo and Alma Linux 10.1-v2 Message-ID: <20251208115138.7212@revelation.fritz.box> Akemi and friends, I note that RedHat have decided to make RHEL 10 only work on processors with v3 capability, but that Alma Linux have decided to make a modified version of their 10.1 clone that still works on processors with only v2 capability (called 10.1-v2). An issue that then arises is whether ELrepo kmods and other packages will work on v2 processors. Do you know whether or not they will ? Or whether the same source code will work if recompiled on a v2 machine ? Thanks, Roger. From toracat at elrepo.org Mon Dec 8 13:23:58 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Mon, 8 Dec 2025 10:23:58 -0800 Subject: [elrepo] Thank you ! Re: ELrepo and Alma Linux 10.1-v2 In-Reply-To: <20251208175948.4270@revelation.fritz.box> References: <20251208115138.7212@revelation.fritz.box> <20251208175948.4270@revelation.fritz.box> Message-ID: On Mon, Dec 8, 2025 at 10:07?AM Roger Sewell wrote: > > Akemi, > > > We have no plan to provide our kmods with v2 capability. ... > > > > If you'd like to build them for yourself, try the following command:... > > Thank you - that's very helpful. > > Best wishes, > Roger. Could you please let us know if the command worked for you? Thank you, Akemi From toracat at elrepo.org Mon Dec 8 12:29:28 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Mon, 8 Dec 2025 09:29:28 -0800 Subject: [elrepo] ELrepo and Alma Linux 10.1-v2 In-Reply-To: <20251208115138.7212@revelation.fritz.box> References: <20251208115138.7212@revelation.fritz.box> Message-ID: Hi Roger, We have no plan to provide our kmods with v2 capability. I understand that Alma offers EPEL packages for v2 for their users. Wonder if you could ask them to do the same with elrepo packages. If you'd like to build them for yourself, try the following command: $ rpmbuild --rebuild XXX.src.rpm --define "optflags $(rpm --eval %optflags) -march=x86_64-v2" (or use mock) Hope this helps, Akemi On Mon, Dec 8, 2025 at 3:52?AM Roger Sewell via elrepo wrote: > > > Akemi and friends, > > I note that RedHat have decided to make RHEL 10 only work on processors > with v3 capability, but that Alma Linux have decided to make a modified > version of their 10.1 clone that still works on processors with only v2 > capability (called 10.1-v2). > > An issue that then arises is whether ELrepo kmods and other packages > will work on v2 processors. > > Do you know whether or not they will ? Or whether the same source code > will work if recompiled on a v2 machine ? > > Thanks, > Roger. From toracat at elrepo.org Thu Dec 11 05:27:49 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Thu, 11 Dec 2025 02:27:49 -0800 Subject: [elrepo] Announcement: EL8 Updated kernel-lt Package Set [6.1.159-1] Message-ID: Announcing the release of the kernel-lt-6.1.159-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.159 The following files are currently synchronising to our mirror sites: x86_64 bpftool-6.1.159-1.el8.elrepo.x86_64.rpm kernel-lt-6.1.159-1.el8.elrepo.x86_64.rpm kernel-lt-core-6.1.159-1.el8.elrepo.x86_64.rpm kernel-lt-devel-6.1.159-1.el8.elrepo.x86_64.rpm kernel-lt-doc-6.1.159-1.el8.elrepo.noarch.rpm kernel-lt-headers-6.1.159-1.el8.elrepo.x86_64.rpm kernel-lt-modules-6.1.159-1.el8.elrepo.x86_64.rpm kernel-lt-modules-extra-6.1.159-1.el8.elrepo.x86_64.rpm kernel-lt-tools-6.1.159-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-6.1.159-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-6.1.159-1.el8.elrepo.x86_64.rpm perf-6.1.159-1.el8.elrepo.x86_64.rpm python3-perf-6.1.159-1.el8.elrepo.x86_64.rpm nosrc kernel-lt-6.1.159-1.el8.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-8 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-lt may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-lt packages in regular service. The packages are intentionally named kernel-lt so as not to conflict with the RHEL-8 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-8 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ From toracat at elrepo.org Fri Dec 12 04:37:26 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Fri, 12 Dec 2025 01:37:26 -0800 Subject: [elrepo] kernel-lt-6.1.159-1.el8 retracted Message-ID: We have retracted the kernel-lt-6.1.159-1.el8.elrepo package set because of multiple boot failure reports. Will investigate the cause. The ELRepo Team. From toracat at elrepo.org Fri Dec 12 18:44:55 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Fri, 12 Dec 2025 15:44:55 -0800 Subject: [elrepo] Announcement: EL8 Updated kernel-ml Package Set [6.18.1-1] Message-ID: Announcing the release of the kernel-ml-6.18.1-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.1 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-6.18.1-1.el8.elrepo.x86_64.rpm kernel-ml-core-6.18.1-1.el8.elrepo.x86_64.rpm kernel-ml-devel-6.18.1-1.el8.elrepo.x86_64.rpm kernel-ml-doc-6.18.1-1.el8.elrepo.noarch.rpm kernel-ml-headers-6.18.1-1.el8.elrepo.x86_64.rpm kernel-ml-modules-6.18.1-1.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-6.18.1-1.el8.elrepo.x86_64.rpm kernel-ml-tools-6.18.1-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-6.18.1-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.18.1-1.el8.elrepo.x86_64.rpm perf-6.18.1-1.el8.elrepo.x86_64.rpm python3-perf-6.18.1-1.el8.elrepo.x86_64.rpm nosrc kernel-ml-6.18.1-1.el8.elrepo.nosrc.rpm Please note that as of kernel-ml version 6.5.4 we are unable to continue providing the bpftool package. We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-8 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-8 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-8 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ From toracat at elrepo.org Fri Dec 12 18:43:11 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Fri, 12 Dec 2025 15:43:11 -0800 Subject: [elrepo] Announcement: EL10 Updated kernel-ml Package Set [6.18.1-1] Message-ID: Announcing the release of the kernel-ml-6.18.1-1.el10.elrepo package set into the EL10 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.1 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-6.18.1-1.el10.elrepo.x86_64.rpm kernel-ml-core-6.18.1-1.el10.elrepo.x86_64.rpm kernel-ml-cross-headers-6.18.1-1.el10.elrepo.x86_64.rpm kernel-ml-devel-6.18.1-1.el10.elrepo.x86_64.rpm kernel-ml-devel-matched-6.18.1-1.el10.elrepo.x86_64.rpm kernel-ml-headers-6.18.1-1.el10.elrepo.x86_64.rpm kernel-ml-modules-6.18.1-1.el10.elrepo.x86_64.rpm kernel-ml-modules-extra-6.18.1-1.el10.elrepo.x86_64.rpm kernel-ml-tools-6.18.1-1.el10.elrepo.x86_64.rpm kernel-ml-tools-libs-6.18.1-1.el10.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.18.1-1.el10.elrepo.x86_64.rpm libperf-6.18.1-1.el10.elrepo.x86_64.rpm libperf-devel-6.18.1-1.el10.elrepo.x86_64.rpm perf-6.18.1-1.el10.elrepo.x86_64.rpm python3-perf-6.18.1-1.el10.elrepo.x86_64.rpm rtla-6.18.1-1.el10.elrepo.x86_64.rpm rv-6.18.1-1.el10.elrepo.x86_64.rpm nosrc kernel-ml-6.18.1-1.el10.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-10 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-10 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-10 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ From toracat at elrepo.org Fri Dec 12 18:44:07 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Fri, 12 Dec 2025 15:44:07 -0800 Subject: [elrepo] Announcement: EL9 Updated kernel-ml Package Set [6.18.1-1] Message-ID: Announcing the release of the kernel-ml-6.18.1-1.el9.elrepo package set into the EL9 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.1 The following files are currently synchronising to our mirror sites: aarch64 [1] bpftool-6.18.1-1.el9.elrepo.aarch64.rpm kernel-ml-6.18.1-1.el9.elrepo.aarch64.rpm kernel-ml-core-6.18.1-1.el9.elrepo.aarch64.rpm kernel-ml-devel-6.18.1-1.el9.elrepo.aarch64.rpm kernel-ml-devel-matched-6.18.1-1.el9.elrepo.aarch64.rpm kernel-ml-doc-6.18.1-1.el9.elrepo.noarch.rpm kernel-ml-headers-6.18.1-1.el9.elrepo.aarch64.rpm kernel-ml-modules-6.18.1-1.el9.elrepo.aarch64.rpm kernel-ml-modules-extra-6.18.1-1.el9.elrepo.aarch64.rpm kernel-ml-tools-6.18.1-1.el9.elrepo.aarch64.rpm kernel-ml-tools-libs-6.18.1-1.el9.elrepo.aarch64.rpm kernel-ml-tools-libs-devel-6.18.1-1.el9.elrepo.aarch64.rpm perf-6.18.1-1.el9.elrepo.aarch64.rpm python3-perf-6.18.1-1.el9.elrepo.aarch64.rpm x86_64 bpftool-6.18.1-1.el9.elrepo.x86_64.rpm kernel-ml-6.18.1-1.el9.elrepo.x86_64.rpm kernel-ml-core-6.18.1-1.el9.elrepo.x86_64.rpm kernel-ml-devel-6.18.1-1.el9.elrepo.x86_64.rpm kernel-ml-devel-matched-6.18.1-1.el9.elrepo.x86_64.rpm kernel-ml-doc-6.18.1-1.el9.elrepo.noarch.rpm kernel-ml-headers-6.18.1-1.el9.elrepo.x86_64.rpm kernel-ml-modules-6.18.1-1.el9.elrepo.x86_64.rpm kernel-ml-modules-extra-6.18.1-1.el9.elrepo.x86_64.rpm kernel-ml-tools-6.18.1-1.el9.elrepo.x86_64.rpm kernel-ml-tools-libs-6.18.1-1.el9.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.18.1-1.el9.elrepo.x86_64.rpm perf-6.18.1-1.el9.elrepo.x86_64.rpm python3-perf-6.18.1-1.el9.elrepo.x86_64.rpm nosrc kernel-ml-6.18.1-1.el9.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-9 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-9 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-9 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [2] and, for our reference, to the ELRepo bug tracker [3]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] The ELRepo Project would like to thank the OSU Open Source Lab for their support with the aarch64 platform. [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From toracat at elrepo.org Fri Dec 19 13:00:21 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Fri, 19 Dec 2025 10:00:21 -0800 Subject: [elrepo] Announcement: EL10 Updated kernel-ml Package Set [6.18.2-1] Message-ID: Announcing the release of the kernel-ml-6.18.2-1.el10.elrepo package set into the EL10 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.2 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-6.18.2-1.el10.elrepo.x86_64.rpm kernel-ml-core-6.18.2-1.el10.elrepo.x86_64.rpm kernel-ml-cross-headers-6.18.2-1.el10.elrepo.x86_64.rpm kernel-ml-devel-6.18.2-1.el10.elrepo.x86_64.rpm kernel-ml-devel-matched-6.18.2-1.el10.elrepo.x86_64.rpm kernel-ml-headers-6.18.2-1.el10.elrepo.x86_64.rpm kernel-ml-modules-6.18.2-1.el10.elrepo.x86_64.rpm kernel-ml-modules-extra-6.18.2-1.el10.elrepo.x86_64.rpm kernel-ml-tools-6.18.2-1.el10.elrepo.x86_64.rpm kernel-ml-tools-libs-6.18.2-1.el10.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.18.2-1.el10.elrepo.x86_64.rpm libperf-6.18.2-1.el10.elrepo.x86_64.rpm libperf-devel-6.18.2-1.el10.elrepo.x86_64.rpm perf-6.18.2-1.el10.elrepo.x86_64.rpm python3-perf-6.18.2-1.el10.elrepo.x86_64.rpm rtla-6.18.2-1.el10.elrepo.x86_64.rpm rv-6.18.2-1.el10.elrepo.x86_64.rpm nosrc kernel-ml-6.18.2-1.el10.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-10 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-10 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-10 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ From toracat at elrepo.org Fri Dec 19 13:01:01 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Fri, 19 Dec 2025 10:01:01 -0800 Subject: [elrepo] Announcement: EL9 Updated kernel-ml Package Set [6.18.2-1] Message-ID: Announcing the release of the kernel-ml-6.18.2-1.el9.elrepo package set into the EL9 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.2 The following files are currently synchronising to our mirror sites: aarch64 [1] bpftool-6.18.2-1.el9.elrepo.aarch64.rpm kernel-ml-6.18.2-1.el9.elrepo.aarch64.rpm kernel-ml-core-6.18.2-1.el9.elrepo.aarch64.rpm kernel-ml-devel-6.18.2-1.el9.elrepo.aarch64.rpm kernel-ml-devel-matched-6.18.2-1.el9.elrepo.aarch64.rpm kernel-ml-doc-6.18.2-1.el9.elrepo.noarch.rpm kernel-ml-headers-6.18.2-1.el9.elrepo.aarch64.rpm kernel-ml-modules-6.18.2-1.el9.elrepo.aarch64.rpm kernel-ml-modules-extra-6.18.2-1.el9.elrepo.aarch64.rpm kernel-ml-tools-6.18.2-1.el9.elrepo.aarch64.rpm kernel-ml-tools-libs-6.18.2-1.el9.elrepo.aarch64.rpm kernel-ml-tools-libs-devel-6.18.2-1.el9.elrepo.aarch64.rpm perf-6.18.2-1.el9.elrepo.aarch64.rpm python3-perf-6.18.2-1.el9.elrepo.aarch64.rpm x86_64 bpftool-6.18.2-1.el9.elrepo.x86_64.rpm kernel-ml-6.18.2-1.el9.elrepo.x86_64.rpm kernel-ml-core-6.18.2-1.el9.elrepo.x86_64.rpm kernel-ml-devel-6.18.2-1.el9.elrepo.x86_64.rpm kernel-ml-devel-matched-6.18.2-1.el9.elrepo.x86_64.rpm kernel-ml-doc-6.18.2-1.el9.elrepo.noarch.rpm kernel-ml-headers-6.18.2-1.el9.elrepo.x86_64.rpm kernel-ml-modules-6.18.2-1.el9.elrepo.x86_64.rpm kernel-ml-modules-extra-6.18.2-1.el9.elrepo.x86_64.rpm kernel-ml-tools-6.18.2-1.el9.elrepo.x86_64.rpm kernel-ml-tools-libs-6.18.2-1.el9.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.18.2-1.el9.elrepo.x86_64.rpm perf-6.18.2-1.el9.elrepo.x86_64.rpm python3-perf-6.18.2-1.el9.elrepo.x86_64.rpm nosrc kernel-ml-6.18.2-1.el9.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-9 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-9 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-9 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [2] and, for our reference, to the ELRepo bug tracker [3]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] The ELRepo Project would like to thank the OSU Open Source Lab for their support with the aarch64 platform. [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From toracat at elrepo.org Fri Dec 19 13:01:39 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Fri, 19 Dec 2025 10:01:39 -0800 Subject: [elrepo] Announcement: EL8 Updated kernel-ml Package Set [6.18.2-1] Message-ID: Announcing the release of the kernel-ml-6.18.2-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.2 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-6.18.2-1.el8.elrepo.x86_64.rpm kernel-ml-core-6.18.2-1.el8.elrepo.x86_64.rpm kernel-ml-devel-6.18.2-1.el8.elrepo.x86_64.rpm kernel-ml-doc-6.18.2-1.el8.elrepo.noarch.rpm kernel-ml-headers-6.18.2-1.el8.elrepo.x86_64.rpm kernel-ml-modules-6.18.2-1.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-6.18.2-1.el8.elrepo.x86_64.rpm kernel-ml-tools-6.18.2-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-6.18.2-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.18.2-1.el8.elrepo.x86_64.rpm perf-6.18.2-1.el8.elrepo.x86_64.rpm python3-perf-6.18.2-1.el8.elrepo.x86_64.rpm nosrc kernel-ml-6.18.2-1.el8.elrepo.nosrc.rpm Please note that as of kernel-ml version 6.5.4 we are unable to continue providing the bpftool package. We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-8 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-8 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-8 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ From toracat at elrepo.org Wed Dec 24 12:46:02 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Wed, 24 Dec 2025 09:46:02 -0800 Subject: [elrepo] Announcement: EL9 Updated kernel-ml Package Set [6.18.2-2] Message-ID: Announcing the release of the kernel-ml-6.18.2-2.el9.elrepo package set into the EL9 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.2 The following files are currently synchronising to our mirror sites: aarch64 [1] bpftool-6.18.2-2.el9.elrepo.aarch64.rpm kernel-ml-6.18.2-2.el9.elrepo.aarch64.rpm kernel-ml-core-6.18.2-2.el9.elrepo.aarch64.rpm kernel-ml-devel-6.18.2-2.el9.elrepo.aarch64.rpm kernel-ml-devel-matched-6.18.2-2.el9.elrepo.aarch64.rpm kernel-ml-doc-6.18.2-2.el9.elrepo.noarch.rpm kernel-ml-headers-6.18.2-2.el9.elrepo.aarch64.rpm kernel-ml-modules-6.18.2-2.el9.elrepo.aarch64.rpm kernel-ml-modules-extra-6.18.2-2.el9.elrepo.aarch64.rpm kernel-ml-tools-6.18.2-2.el9.elrepo.aarch64.rpm kernel-ml-tools-libs-6.18.2-2.el9.elrepo.aarch64.rpm kernel-ml-tools-libs-devel-6.18.2-2.el9.elrepo.aarch64.rpm perf-6.18.2-2.el9.elrepo.aarch64.rpm python3-perf-6.18.2-2.el9.elrepo.aarch64.rpm x86_64 bpftool-6.18.2-2.el9.elrepo.x86_64.rpm kernel-ml-6.18.2-2.el9.elrepo.x86_64.rpm kernel-ml-core-6.18.2-2.el9.elrepo.x86_64.rpm kernel-ml-devel-6.18.2-2.el9.elrepo.x86_64.rpm kernel-ml-devel-matched-6.18.2-2.el9.elrepo.x86_64.rpm kernel-ml-doc-6.18.2-2.el9.elrepo.noarch.rpm kernel-ml-headers-6.18.2-2.el9.elrepo.x86_64.rpm kernel-ml-modules-6.18.2-2.el9.elrepo.x86_64.rpm kernel-ml-modules-extra-6.18.2-2.el9.elrepo.x86_64.rpm kernel-ml-tools-6.18.2-2.el9.elrepo.x86_64.rpm kernel-ml-tools-libs-6.18.2-2.el9.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.18.2-2.el9.elrepo.x86_64.rpm perf-6.18.2-2.el9.elrepo.x86_64.rpm python3-perf-6.18.2-2.el9.elrepo.x86_64.rpm nosrc kernel-ml-6.18.2-2.el9.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-9 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-9 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-9 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [2] and, for our reference, to the ELRepo bug tracker [3]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] The ELRepo Project would like to thank the OSU Open Source Lab for their support with the aarch64 platform. [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From toracat at elrepo.org Wed Dec 24 12:46:46 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Wed, 24 Dec 2025 09:46:46 -0800 Subject: [elrepo] Announcement: EL8 Updated kernel-ml Package Set [6.18.2-2] Message-ID: Announcing the release of the kernel-ml-6.18.2-2.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.2 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-6.18.2-2.el8.elrepo.x86_64.rpm kernel-ml-core-6.18.2-2.el8.elrepo.x86_64.rpm kernel-ml-devel-6.18.2-2.el8.elrepo.x86_64.rpm kernel-ml-doc-6.18.2-2.el8.elrepo.noarch.rpm kernel-ml-headers-6.18.2-2.el8.elrepo.x86_64.rpm kernel-ml-modules-6.18.2-2.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-6.18.2-2.el8.elrepo.x86_64.rpm kernel-ml-tools-6.18.2-2.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-6.18.2-2.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.18.2-2.el8.elrepo.x86_64.rpm perf-6.18.2-2.el8.elrepo.x86_64.rpm python3-perf-6.18.2-2.el8.elrepo.x86_64.rpm nosrc kernel-ml-6.18.2-2.el8.elrepo.nosrc.rpm Please note that as of kernel-ml version 6.5.4 we are unable to continue providing the bpftool package. We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-8 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-8 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-8 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/ From toracat at elrepo.org Wed Dec 24 12:45:20 2025 From: toracat at elrepo.org (Akemi Yagi) Date: Wed, 24 Dec 2025 09:45:20 -0800 Subject: [elrepo] Announcement: EL10 Updated kernel-ml Package Set [6.18.2-2] Message-ID: Announcing the release of the kernel-ml-6.18.2-2.el10.elrepo package set into the EL10 elrepo-kernel repository: https://elrepo.org/wiki/doku.php?id=kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.2 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-6.18.2-2.el10.elrepo.x86_64.rpm kernel-ml-core-6.18.2-2.el10.elrepo.x86_64.rpm kernel-ml-cross-headers-6.18.2-2.el10.elrepo.x86_64.rpm kernel-ml-devel-6.18.2-2.el10.elrepo.x86_64.rpm kernel-ml-devel-matched-6.18.2-2.el10.elrepo.x86_64.rpm kernel-ml-headers-6.18.2-2.el10.elrepo.x86_64.rpm kernel-ml-modules-6.18.2-2.el10.elrepo.x86_64.rpm kernel-ml-modules-extra-6.18.2-2.el10.elrepo.x86_64.rpm kernel-ml-tools-6.18.2-2.el10.elrepo.x86_64.rpm kernel-ml-tools-libs-6.18.2-2.el10.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-6.18.2-2.el10.elrepo.x86_64.rpm libperf-6.18.2-2.el10.elrepo.x86_64.rpm libperf-devel-6.18.2-2.el10.elrepo.x86_64.rpm perf-6.18.2-2.el10.elrepo.x86_64.rpm python3-perf-6.18.2-2.el10.elrepo.x86_64.rpm rtla-6.18.2-2.el10.elrepo.x86_64.rpm rv-6.18.2-2.el10.elrepo.x86_64.rpm nosrc kernel-ml-6.18.2-2.el10.elrepo.nosrc.rpm We provide these kernels for hardware testing in an effort to identify new/updated drivers which can then be targeted for backporting as kmod packages. Meanwhile, these kernels may provide interim relief to people with non-functional hardware. We stress that we consider such kernels as a last resort for those who are unable to get their hardware working using the RHEL-10 kernel with supplementary kmod packages. These packages are provided "As-Is" with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-10 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-10 configuration with added functionality enabled as appropriate. If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker [1] and, for our reference, to the ELRepo bug tracker [2]. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole. Thank you, The ELRepo Team. [1] https://bugzilla.kernel.org/ [2] https://elrepo.org/bugs/