From ajb at elrepo.org Wed Oct 6 11:03:58 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 6 Oct 2021 16:03:58 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-lt Package Set [5.4.151-1] Message-ID: Announcing the release of the kernel-lt-5.4.151-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.151 The following files are currently synchronising to our mirror sites: x86_64 kernel-lt-5.4.151-1.el7.elrepo.x86_64.rpm kernel-lt-devel-5.4.151-1.el7.elrepo.x86_64.rpm kernel-lt-doc-5.4.151-1.el7.elrepo.noarch.rpm kernel-lt-headers-5.4.151-1.el7.elrepo.x86_64.rpm kernel-lt-tools-5.4.151-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.151-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.151-1.el7.elrepo.x86_64.rpm perf-5.4.151-1.el7.elrepo.x86_64.rpm python-perf-5.4.151-1.el7.elrepo.x86_64.rpm nosrc kernel-lt-5.4.151-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Wed Oct 6 11:04:03 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 6 Oct 2021 16:04:03 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-lt Package Set [5.4.151-1] Message-ID: Announcing the release of the kernel-lt-5.4.151-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.151 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.4.151-1.el8.elrepo.x86_64.rpm kernel-lt-5.4.151-1.el8.elrepo.x86_64.rpm kernel-lt-core-5.4.151-1.el8.elrepo.x86_64.rpm kernel-lt-devel-5.4.151-1.el8.elrepo.x86_64.rpm kernel-lt-doc-5.4.151-1.el8.elrepo.noarch.rpm kernel-lt-headers-5.4.151-1.el8.elrepo.x86_64.rpm kernel-lt-modules-5.4.151-1.el8.elrepo.x86_64.rpm kernel-lt-modules-extra-5.4.151-1.el8.elrepo.x86_64.rpm kernel-lt-tools-5.4.151-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.151-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.151-1.el8.elrepo.x86_64.rpm perf-5.4.151-1.el8.elrepo.x86_64.rpm python3-perf-5.4.151-1.el8.elrepo.x86_64.rpm nosrc kernel-lt-5.4.151-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 ajb at elrepo.org Thu Oct 7 10:29:44 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Thu, 7 Oct 2021 15:29:44 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-ml Package Set [5.14.10-1] Message-ID: Announcing the release of the kernel-ml-5.14.10-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.10 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-5.14.10-1.el7.elrepo.x86_64.rpm kernel-ml-devel-5.14.10-1.el7.elrepo.x86_64.rpm kernel-ml-doc-5.14.10-1.el7.elrepo.noarch.rpm kernel-ml-headers-5.14.10-1.el7.elrepo.x86_64.rpm kernel-ml-tools-5.14.10-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.10-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.10-1.el7.elrepo.x86_64.rpm perf-5.14.10-1.el7.elrepo.x86_64.rpm python-perf-5.14.10-1.el7.elrepo.x86_64.rpm nosrc kernel-ml-5.14.10-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Thu Oct 7 10:29:48 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Thu, 7 Oct 2021 15:29:48 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-ml Package Set [5.14.10-1] Message-ID: Announcing the release of the kernel-ml-5.14.10-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.10 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.14.10-1.el8.elrepo.x86_64.rpm kernel-ml-5.14.10-1.el8.elrepo.x86_64.rpm kernel-ml-core-5.14.10-1.el8.elrepo.x86_64.rpm kernel-ml-devel-5.14.10-1.el8.elrepo.x86_64.rpm kernel-ml-doc-5.14.10-1.el8.elrepo.noarch.rpm kernel-ml-headers-5.14.10-1.el8.elrepo.x86_64.rpm kernel-ml-modules-5.14.10-1.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-5.14.10-1.el8.elrepo.x86_64.rpm kernel-ml-tools-5.14.10-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.10-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.10-1.el8.elrepo.x86_64.rpm perf-5.14.10-1.el8.elrepo.x86_64.rpm python3-perf-5.14.10-1.el8.elrepo.x86_64.rpm nosrc kernel-ml-5.14.10-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-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 ajb at elrepo.org Sat Oct 9 11:07:42 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Sat, 9 Oct 2021 16:07:42 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-lt Package Set [5.4.152-1] Message-ID: Announcing the release of the kernel-lt-5.4.152-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.152 The following files are currently synchronising to our mirror sites: x86_64 kernel-lt-5.4.152-1.el7.elrepo.x86_64.rpm kernel-lt-devel-5.4.152-1.el7.elrepo.x86_64.rpm kernel-lt-doc-5.4.152-1.el7.elrepo.noarch.rpm kernel-lt-headers-5.4.152-1.el7.elrepo.x86_64.rpm kernel-lt-tools-5.4.152-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.152-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.152-1.el7.elrepo.x86_64.rpm perf-5.4.152-1.el7.elrepo.x86_64.rpm python-perf-5.4.152-1.el7.elrepo.x86_64.rpm nosrc kernel-lt-5.4.152-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Sat Oct 9 11:07:46 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Sat, 9 Oct 2021 16:07:46 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-lt Package Set [5.4.152-1] Message-ID: Announcing the release of the kernel-lt-5.4.152-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.152 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.4.152-1.el8.elrepo.x86_64.rpm kernel-lt-5.4.152-1.el8.elrepo.x86_64.rpm kernel-lt-core-5.4.152-1.el8.elrepo.x86_64.rpm kernel-lt-devel-5.4.152-1.el8.elrepo.x86_64.rpm kernel-lt-doc-5.4.152-1.el8.elrepo.noarch.rpm kernel-lt-headers-5.4.152-1.el8.elrepo.x86_64.rpm kernel-lt-modules-5.4.152-1.el8.elrepo.x86_64.rpm kernel-lt-modules-extra-5.4.152-1.el8.elrepo.x86_64.rpm kernel-lt-tools-5.4.152-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.152-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.152-1.el8.elrepo.x86_64.rpm perf-5.4.152-1.el8.elrepo.x86_64.rpm python3-perf-5.4.152-1.el8.elrepo.x86_64.rpm nosrc kernel-lt-5.4.152-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 ajb at elrepo.org Sat Oct 9 11:07:49 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Sat, 9 Oct 2021 16:07:49 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-ml Package Set [5.14.11-1] Message-ID: Announcing the release of the kernel-ml-5.14.11-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.11 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-5.14.11-1.el7.elrepo.x86_64.rpm kernel-ml-devel-5.14.11-1.el7.elrepo.x86_64.rpm kernel-ml-doc-5.14.11-1.el7.elrepo.noarch.rpm kernel-ml-headers-5.14.11-1.el7.elrepo.x86_64.rpm kernel-ml-tools-5.14.11-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.11-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.11-1.el7.elrepo.x86_64.rpm perf-5.14.11-1.el7.elrepo.x86_64.rpm python-perf-5.14.11-1.el7.elrepo.x86_64.rpm nosrc kernel-ml-5.14.11-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Sat Oct 9 11:07:53 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Sat, 9 Oct 2021 16:07:53 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-ml Package Set [5.14.11-1] Message-ID: Announcing the release of the kernel-ml-5.14.11-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.11 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.14.11-1.el8.elrepo.x86_64.rpm kernel-ml-5.14.11-1.el8.elrepo.x86_64.rpm kernel-ml-core-5.14.11-1.el8.elrepo.x86_64.rpm kernel-ml-devel-5.14.11-1.el8.elrepo.x86_64.rpm kernel-ml-doc-5.14.11-1.el8.elrepo.noarch.rpm kernel-ml-headers-5.14.11-1.el8.elrepo.x86_64.rpm kernel-ml-modules-5.14.11-1.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-5.14.11-1.el8.elrepo.x86_64.rpm kernel-ml-tools-5.14.11-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.11-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.11-1.el8.elrepo.x86_64.rpm perf-5.14.11-1.el8.elrepo.x86_64.rpm python3-perf-5.14.11-1.el8.elrepo.x86_64.rpm nosrc kernel-ml-5.14.11-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-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 j.eitel at cox.net Mon Oct 11 04:27:23 2021 From: j.eitel at cox.net (Jim Eitel) Date: Mon, 11 Oct 2021 01:27:23 -0700 Subject: [elrepo] using rpm for installation driver update Message-ID: Recent Linux releases from RedHat, CentOS and Fedora do not include the forcedeth driver which I need for my motherboard ethernet ports. There is supposed to be a way to set up a driver file on a device like a USB drive, CD or DVD that can be made available to the Anaconda installation program. With this in mind, I downloaded your kmod-forcedeth-0.0-6.el8_4.elrepo.x86_64.rpm. I have looked at several articles put out by CentOS and RedHat but can't come up with anything that works. It appears that the Anaconda installation program expects something in .iso format but I am not sure. The main issue is how do you take an RPM file and use it to create something the installer will work with. Just thought you might have some suggestions. -- Jim Eitel -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfy at nobugconsulting.ro Mon Oct 11 04:43:50 2021 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 11 Oct 2021 11:43:50 +0300 Subject: [elrepo] using rpm for installation driver update In-Reply-To: References: Message-ID: On October 11, 2021 11:27:23 AM GMT+03:00, Jim Eitel wrote: >Recent Linux releases from RedHat, CentOS and Fedora do not include the >forcedeth >driver which I need for my motherboard ethernet ports. There is >supposed to be a way >to set up a driver file on a device like a USB drive, CD or DVD that >can be made available >to the Anaconda installation program. With this in mind, I downloaded >your >kmod-forcedeth-0.0-6.el8_4.elrepo.x86_64.rpm. I have looked at several >articles put out >by CentOS and RedHat but can't come up with anything that works. It >appears that the >Anaconda installation program expects something in .iso format but I am >not sure. > >The main issue is how do you take an RPM file and use it to create >something the >installer will work with. > >Just thought you might have some suggestions. > Place it on an USB stick, label the stick OEMDRV and use createrepo to create a yum repository on the stick. wolfy > From c.elliot at pobox.com Mon Oct 11 04:46:59 2021 From: c.elliot at pobox.com (chuck elliot) Date: Mon, 11 Oct 2021 09:46:59 +0100 Subject: [elrepo] using rpm for installation driver update In-Reply-To: References: Message-ID: <44c3e8be-b533-b328-2667-8b417f4551eb@pobox.com> You need the DUD (driver update disk) https://elrepoproject.blogspot.com/2019/08/rhel-80-and-support-for-removed-adapters.html On 10/11/21 9:27 AM, Jim Eitel wrote: > Recent Linux releases from RedHat, CentOS and Fedora do not include > the forcedeth > driver which I need for my motherboard ethernet ports. There is > supposed to be a way > to set up a driver file on a device like a USB drive, CD or DVD that > can be made available > to the Anaconda installation program. With this in mind, I downloaded your > kmod-forcedeth-0.0-6.el8_4.elrepo.x86_64.rpm. I have looked at several > articles put out > by CentOS and RedHat but can't come up with anything that works. It > appears that the > Anaconda installation program expects something in .iso format but I > am not sure. > > The main issue is how do you take an RPM file and use it to create > something the > installer will work with. > > Just thought you might have some suggestions. > > -- > Jim Eitel > > _______________________________________________ > elrepo mailing list > elrepo at lists.elrepo.org > http://lists.elrepo.org/mailman/listinfo/elrepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at elrepo.org Mon Oct 11 06:25:23 2021 From: phil at elrepo.org (Phil Perry) Date: Mon, 11 Oct 2021 11:25:23 +0100 Subject: [elrepo] using rpm for installation driver update In-Reply-To: References: Message-ID: <3a66be62-e26f-f6aa-d4d7-08115083139f@elrepo.org> On 11/10/2021 09:43, Manuel Wolfshant wrote: > On October 11, 2021 11:27:23 AM GMT+03:00, Jim Eitel wrote: >> Recent Linux releases from RedHat, CentOS and Fedora do not include the >> forcedeth >> driver which I need for my motherboard ethernet ports. There is >> supposed to be a way >> to set up a driver file on a device like a USB drive, CD or DVD that >> can be made available >> to the Anaconda installation program. With this in mind, I downloaded >> your >> kmod-forcedeth-0.0-6.el8_4.elrepo.x86_64.rpm. I have looked at several >> articles put out >> by CentOS and RedHat but can't come up with anything that works. It >> appears that the >> Anaconda installation program expects something in .iso format but I am >> not sure. >> >> The main issue is how do you take an RPM file and use it to create >> something the >> installer will work with. >> >> Just thought you might have some suggestions. >> > Place it on an USB stick, label the stick OEMDRV and use createrepo to create a yum repository on the stick. > > wolfy > As Wolfy says above, you will need to create a Driver Update Disk (DUD) image from the latest kmod-forcedeth rpm package, as we do not currently provide one for the forcedeth driver. To assist in that process, we have published the script we use to create driver disks here: https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh Regards, Phil From ajb at elrepo.org Wed Oct 13 10:40:36 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 13 Oct 2021 15:40:36 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-lt Package Set [5.4.153-1] Message-ID: Announcing the release of the kernel-lt-5.4.153-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.153 The following files are currently synchronising to our mirror sites: x86_64 kernel-lt-5.4.153-1.el7.elrepo.x86_64.rpm kernel-lt-devel-5.4.153-1.el7.elrepo.x86_64.rpm kernel-lt-doc-5.4.153-1.el7.elrepo.noarch.rpm kernel-lt-headers-5.4.153-1.el7.elrepo.x86_64.rpm kernel-lt-tools-5.4.153-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.153-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.153-1.el7.elrepo.x86_64.rpm perf-5.4.153-1.el7.elrepo.x86_64.rpm python-perf-5.4.153-1.el7.elrepo.x86_64.rpm nosrc kernel-lt-5.4.153-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Wed Oct 13 10:40:40 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 13 Oct 2021 15:40:40 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-lt Package Set [5.4.153-1] Message-ID: Announcing the release of the kernel-lt-5.4.153-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.153 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.4.153-1.el8.elrepo.x86_64.rpm kernel-lt-5.4.153-1.el8.elrepo.x86_64.rpm kernel-lt-core-5.4.153-1.el8.elrepo.x86_64.rpm kernel-lt-devel-5.4.153-1.el8.elrepo.x86_64.rpm kernel-lt-doc-5.4.153-1.el8.elrepo.noarch.rpm kernel-lt-headers-5.4.153-1.el8.elrepo.x86_64.rpm kernel-lt-modules-5.4.153-1.el8.elrepo.x86_64.rpm kernel-lt-modules-extra-5.4.153-1.el8.elrepo.x86_64.rpm kernel-lt-tools-5.4.153-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.153-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.153-1.el8.elrepo.x86_64.rpm perf-5.4.153-1.el8.elrepo.x86_64.rpm python3-perf-5.4.153-1.el8.elrepo.x86_64.rpm nosrc kernel-lt-5.4.153-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 ajb at elrepo.org Wed Oct 13 10:40:45 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 13 Oct 2021 15:40:45 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-ml Package Set [5.14.12-1] Message-ID: Announcing the release of the kernel-ml-5.14.12-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.12 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-5.14.12-1.el7.elrepo.x86_64.rpm kernel-ml-devel-5.14.12-1.el7.elrepo.x86_64.rpm kernel-ml-doc-5.14.12-1.el7.elrepo.noarch.rpm kernel-ml-headers-5.14.12-1.el7.elrepo.x86_64.rpm kernel-ml-tools-5.14.12-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.12-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.12-1.el7.elrepo.x86_64.rpm perf-5.14.12-1.el7.elrepo.x86_64.rpm python-perf-5.14.12-1.el7.elrepo.x86_64.rpm nosrc kernel-ml-5.14.12-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Wed Oct 13 10:40:49 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 13 Oct 2021 15:40:49 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-ml Package Set [5.14.12-1] Message-ID: Announcing the release of the kernel-ml-5.14.12-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.12 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.14.12-1.el8.elrepo.x86_64.rpm kernel-ml-5.14.12-1.el8.elrepo.x86_64.rpm kernel-ml-core-5.14.12-1.el8.elrepo.x86_64.rpm kernel-ml-devel-5.14.12-1.el8.elrepo.x86_64.rpm kernel-ml-doc-5.14.12-1.el8.elrepo.noarch.rpm kernel-ml-headers-5.14.12-1.el8.elrepo.x86_64.rpm kernel-ml-modules-5.14.12-1.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-5.14.12-1.el8.elrepo.x86_64.rpm kernel-ml-tools-5.14.12-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.12-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.12-1.el8.elrepo.x86_64.rpm perf-5.14.12-1.el8.elrepo.x86_64.rpm python3-perf-5.14.12-1.el8.elrepo.x86_64.rpm nosrc kernel-ml-5.14.12-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-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 james-p at moving-picture.com Sat Oct 16 06:57:23 2021 From: james-p at moving-picture.com (James Pearson) Date: Sat, 16 Oct 2021 10:57:23 +0000 Subject: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC Message-ID: I'm trying to install CentOS 7.9 via PXE on a Lenovo P620 that has a single Aquantia 10Gb NIC The installer (Anaconda) fails to start and the installer kernel reports: atlantic: Bad FW version detected: 4020028 Installing the box by adding a 2nd NIC works fine and lspci reports: 01:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] [1d6a:07b1] (rev 02) After a bit of googling, it looks like Lenovo PCs with this NIC use/require 'version 4' of the firmware - which is not supported by the EL 7.9 atlantic driver (not supported until EL 8.4) Lenovo provide Linux driver source which builds fine on EL 7.9 - and I can insmod the new kernel module fine and it finds the NIC etc However, I'm struggling to build an installer driver disk image and get the CentOS 7.9 installer to use it I've created my own 'kmod-atlantic' RPM - based on other similar ElRepo SRPMS and it appears the installer attempts to use it - but it gives warnings like: [ 11.087251] atlantic: loading out-of-tree module taints kernel. [ 11.090231] atlantic: module verification failed: signature and/or required key missing - tainting kernel but doesn't seem to use the newer module? Can anyone give me some pointers to what I need to do to get the newer kernel module to load in the installer? Thanks James Pearson From phil at elrepo.org Sat Oct 16 07:52:13 2021 From: phil at elrepo.org (Phil Perry) Date: Sat, 16 Oct 2021 12:52:13 +0100 Subject: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC In-Reply-To: References: Message-ID: <08ba6cd6-35a6-00f0-e96f-a7ab9930913a@elrepo.org> On 16/10/2021 11:57, James Pearson wrote: > I'm trying to install CentOS 7.9 via PXE on a Lenovo P620 that has a single Aquantia 10Gb NIC > > The installer (Anaconda) fails to start and the installer kernel reports: > > atlantic: Bad FW version detected: 4020028 > > Installing the box by adding a 2nd NIC works fine and lspci reports: > > 01:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] [1d6a:07b1] (rev 02) > > After a bit of googling, it looks like Lenovo PCs with this NIC use/require 'version 4' of the firmware - which is not supported by the EL 7.9 atlantic driver (not supported until EL 8.4) > > Lenovo provide Linux driver source which builds fine on EL 7.9 - and I can insmod the new kernel module fine and it finds the NIC etc > > However, I'm struggling to build an installer driver disk image and get the CentOS 7.9 installer to use it > > I've created my own 'kmod-atlantic' RPM - based on other similar ElRepo SRPMS and it appears the installer attempts to use it - but it gives warnings like: > > [ 11.087251] atlantic: loading out-of-tree module taints kernel. > [ 11.090231] atlantic: module verification failed: signature and/or required key missing - tainting kernel > This messaging is perfectly normal - it's basically just telling you that you've loaded a 3rd party module and that it either isn't signed for Secure Boot or that the key it has been signed with hasn't been imported on your system. > but doesn't seem to use the newer module? > > Can anyone give me some pointers to what I need to do to get the newer kernel module to load in the installer? > To load the module during installation, you need to create a Driver Update Disk (DUD) from your kmod package. This takes the form of an ISO image you can burn to CD/DVD or USB stick and pass to the installer (anaconda). We have written a script that we use to do the job (below) which you are welcome to use: https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh Simply run the script from the same dir that contains your kmod RPM and SRPM. Note you should build your kmod RPM against the same kernel version that is used on the installation media. This video explains how to use a Driver Update Disk (DUD) when installing CentOS/RHEL: https://www.youtube.com/watch?v=4fOAuXiynYM > Thanks > > James Pearson From phil at elrepo.org Sat Oct 16 08:03:59 2021 From: phil at elrepo.org (Phil Perry) Date: Sat, 16 Oct 2021 13:03:59 +0100 Subject: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC In-Reply-To: <08ba6cd6-35a6-00f0-e96f-a7ab9930913a@elrepo.org> References: <08ba6cd6-35a6-00f0-e96f-a7ab9930913a@elrepo.org> Message-ID: On 16/10/2021 12:52, Phil Perry wrote: > On 16/10/2021 11:57, James Pearson wrote: >> I'm trying to install CentOS 7.9 via PXE on a Lenovo P620 that has a >> single Aquantia 10Gb NIC >> >> The installer (Anaconda) fails to start and the installer kernel reports: >> >> ? atlantic: Bad FW version detected: 4020028 >> >> Installing the box by adding a 2nd NIC works fine and lspci reports: >> >> ?? 01:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 >> NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] [1d6a:07b1] (rev 02) >> >> After a bit of googling, it looks like Lenovo PCs with this NIC >> use/require 'version 4' of the firmware - which is not supported by >> the EL 7.9 atlantic driver (not supported until EL 8.4) >> >> Lenovo provide Linux driver source which builds fine on EL 7.9 - and I >> can insmod the new kernel module fine and it finds the NIC etc >> >> However, I'm struggling to build an installer driver disk image and >> get the CentOS 7.9 installer to use it >> >> I've created my own 'kmod-atlantic' RPM - based on other similar >> ElRepo SRPMS and it appears the installer attempts to use it - but it >> gives warnings like: >> >> ? [?? 11.087251] atlantic: loading out-of-tree module taints kernel. >> ? [?? 11.090231] atlantic: module verification failed: signature >> and/or required key missing - tainting kernel >> > > This messaging is perfectly normal - it's basically just telling you > that you've loaded a 3rd party module and that it either isn't signed > for Secure Boot or that the key it has been signed with hasn't been > imported on your system. > >> but doesn't seem to use the newer module? >> Forgot to add/ask - is SecureBoot enabled on your system? If so, then the module will be prevented from loading if it isn't signed with a SB key and that key imported into your system. Running 'modinfo' on the driver module will tell you the full filename path of the driver in use. If it contains 'extra' or weak-updates' in the path then it's your module that's loaded, e.g: /lib/modules/3.10.0-1160.45.1.el7.x86_64/weak-updates/module_name/module_name.ko If it contains '/kernel/drivers/' in the path then it's the distro kernel driver that is in use. The depmod .conf file is used to override the default kernel module with your 3rd party kmod module. >> Can anyone give me some pointers to what I need to do to get the newer >> kernel module to load in the installer? >> > > To load the module during installation, you need to create a Driver > Update Disk (DUD) from your kmod package. This takes the form of an ISO > image you can burn to CD/DVD or USB stick and pass to the installer > (anaconda). > > We have written a script that we use to do the job (below) which you are > welcome to use: > > https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh > > Simply run the script from the same dir that contains your kmod RPM and > SRPM. Note you should build your kmod RPM against the same kernel > version that is used on the installation media. > > This video explains how to use a Driver Update Disk (DUD) when > installing CentOS/RHEL: > > https://www.youtube.com/watch?v=4fOAuXiynYM > >> Thanks >> >> James Pearson > > > _______________________________________________ > elrepo mailing list > elrepo at lists.elrepo.org > http://lists.elrepo.org/mailman/listinfo/elrepo From james-p at moving-picture.com Sat Oct 16 16:08:42 2021 From: james-p at moving-picture.com (James Pearson) Date: Sat, 16 Oct 2021 20:08:42 +0000 Subject: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC In-Reply-To: <08ba6cd6-35a6-00f0-e96f-a7ab9930913a@elrepo.org> References: <08ba6cd6-35a6-00f0-e96f-a7ab9930913a@elrepo.org> Message-ID: Thanks for the info - however, I would like the driver disk to be obtained from the tftp server along with the kernel/initrd images The RHEL 6 install docs seems to suggest this is possible - but I can't find similar info in the RHEL 7 install docs, so I'm guessing this isn't possible with EL 7 ? Do I have to hack the install initrd image to add the new driver? Thanks James Pearson ________________________________________ From: elrepo-bounces at lists.elrepo.org on behalf of Phil Perry Sent: 16 October 2021 12:52 To: elrepo at lists.elrepo.org Subject: Re: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC On 16/10/2021 11:57, James Pearson wrote: > I'm trying to install CentOS 7.9 via PXE on a Lenovo P620 that has a single Aquantia 10Gb NIC > > The installer (Anaconda) fails to start and the installer kernel reports: > > atlantic: Bad FW version detected: 4020028 > > Installing the box by adding a 2nd NIC works fine and lspci reports: > > 01:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] [1d6a:07b1] (rev 02) > > After a bit of googling, it looks like Lenovo PCs with this NIC use/require 'version 4' of the firmware - which is not supported by the EL 7.9 atlantic driver (not supported until EL 8.4) > > Lenovo provide Linux driver source which builds fine on EL 7.9 - and I can insmod the new kernel module fine and it finds the NIC etc > > However, I'm struggling to build an installer driver disk image and get the CentOS 7.9 installer to use it > > I've created my own 'kmod-atlantic' RPM - based on other similar ElRepo SRPMS and it appears the installer attempts to use it - but it gives warnings like: > > [ 11.087251] atlantic: loading out-of-tree module taints kernel. > [ 11.090231] atlantic: module verification failed: signature and/or required key missing - tainting kernel > This messaging is perfectly normal - it's basically just telling you that you've loaded a 3rd party module and that it either isn't signed for Secure Boot or that the key it has been signed with hasn't been imported on your system. > but doesn't seem to use the newer module? > > Can anyone give me some pointers to what I need to do to get the newer kernel module to load in the installer? > To load the module during installation, you need to create a Driver Update Disk (DUD) from your kmod package. This takes the form of an ISO image you can burn to CD/DVD or USB stick and pass to the installer (anaconda). We have written a script that we use to do the job (below) which you are welcome to use: https://url.avanan.click/v2/___https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh___.YXAzOnRlY2huaWNvbG9yOmE6bzozOTIxZjRkYzc1NTgwODllZTU5YTkyOGUwOGRlYjcyODo1OjUzY2Y6ZTMzOGJlMGUzZmEyMzNkMTViNTA2ZmQyZDNiYmQwYmQyNTc3ODdhMTJlYWYxMWJjYTRlYWY5MzViZDBhMzc3Nzpw Simply run the script from the same dir that contains your kmod RPM and SRPM. Note you should build your kmod RPM against the same kernel version that is used on the installation media. This video explains how to use a Driver Update Disk (DUD) when installing CentOS/RHEL: https://url.avanan.click/v2/___https://www.youtube.com/watch?v=4fOAuXiynYM___.YXAzOnRlY2huaWNvbG9yOmE6bzozOTIxZjRkYzc1NTgwODllZTU5YTkyOGUwOGRlYjcyODo1OjBlYTU6MTdhYTgwMzUxZDkyOWVhYTlkOTlhNjFhN2I1YTQ0MDM4NjBmMjdjYWYyOGVlYWUwYTYxZDM0YmYzNzA0MDU0Mzpw > Thanks > > James Pearson _______________________________________________ elrepo mailing list elrepo at lists.elrepo.org https://url.avanan.click/v2/___http://lists.elrepo.org/mailman/listinfo/elrepo___.YXAzOnRlY2huaWNvbG9yOmE6bzozOTIxZjRkYzc1NTgwODllZTU5YTkyOGUwOGRlYjcyODo1OjIzMDU6Njc4M2I0YzRkOTQzNDNmM2U1YWM2NTA5YjE5YzIzYTliZjNlYmEyMTI5Yjk3ZTRjZTY5MWNmMmEwMzM3MjYyOTpw From wolfy at nobugconsulting.ro Sat Oct 16 16:40:55 2021 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 16 Oct 2021 23:40:55 +0300 Subject: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC In-Reply-To: References: <08ba6cd6-35a6-00f0-e96f-a7ab9930913a@elrepo.org> Message-ID: <4E3A1D63-9553-4256-B5E0-C6F80DA72135@nobugconsulting.ro> On October 16, 2021 11:08:42 PM GMT+03:00, James Pearson wrote: >Thanks for the info - however, I would like the driver disk to be obtained from the tftp server along with the kernel/initrd images > >The RHEL 6 install docs seems to suggest this is possible - but I can't find similar info in the RHEL 7 install docs, so I'm guessing this isn't possible with EL 7 ? > >Do I have to hack the install initrd image to add the new driver? > As far as I know, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/sect-preparing_an_initial_ram_disk_update-x86 still works >Thanks > >James Pearson >________________________________________ >From: elrepo-bounces at lists.elrepo.org on behalf of Phil Perry >Sent: 16 October 2021 12:52 >To: elrepo at lists.elrepo.org >Subject: Re: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC > >On 16/10/2021 11:57, James Pearson wrote: >> I'm trying to install CentOS 7.9 via PXE on a Lenovo P620 that has a single Aquantia 10Gb NIC >> >> The installer (Anaconda) fails to start and the installer kernel reports: >> >> atlantic: Bad FW version detected: 4020028 >> >> Installing the box by adding a 2nd NIC works fine and lspci reports: >> >> 01:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] [1d6a:07b1] (rev 02) >> >> After a bit of googling, it looks like Lenovo PCs with this NIC use/require 'version 4' of the firmware - which is not supported by the EL 7.9 atlantic driver (not supported until EL 8.4) >> >> Lenovo provide Linux driver source which builds fine on EL 7.9 - and I can insmod the new kernel module fine and it finds the NIC etc >> >> However, I'm struggling to build an installer driver disk image and get the CentOS 7.9 installer to use it >> >> I've created my own 'kmod-atlantic' RPM - based on other similar ElRepo SRPMS and it appears the installer attempts to use it - but it gives warnings like: >> >> [ 11.087251] atlantic: loading out-of-tree module taints kernel. >> [ 11.090231] atlantic: module verification failed: signature and/or required key missing - tainting kernel >> > >This messaging is perfectly normal - it's basically just telling you >that you've loaded a 3rd party module and that it either isn't signed >for Secure Boot or that the key it has been signed with hasn't been >imported on your system. > >> but doesn't seem to use the newer module? >> >> Can anyone give me some pointers to what I need to do to get the newer kernel module to load in the installer? >> > >To load the module during installation, you need to create a Driver >Update Disk (DUD) from your kmod package. This takes the form of an ISO >image you can burn to CD/DVD or USB stick and pass to the installer >(anaconda). > >We have written a script that we use to do the job (below) which you are >welcome to use: > >https://url.avanan.click/v2/___https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh___.YXAzOnRlY2huaWNvbG9yOmE6bzozOTIxZjRkYzc1NTgwODllZTU5YTkyOGUwOGRlYjcyODo1OjUzY2Y6ZTMzOGJlMGUzZmEyMzNkMTViNTA2ZmQyZDNiYmQwYmQyNTc3ODdhMTJlYWYxMWJjYTRlYWY5MzViZDBhMzc3Nzpw > >Simply run the script from the same dir that contains your kmod RPM and >SRPM. Note you should build your kmod RPM against the same kernel >version that is used on the installation media. > >This video explains how to use a Driver Update Disk (DUD) when >installing CentOS/RHEL: > >https://url.avanan.click/v2/___https://www.youtube.com/watch?v=4fOAuXiynYM___.YXAzOnRlY2huaWNvbG9yOmE6bzozOTIxZjRkYzc1NTgwODllZTU5YTkyOGUwOGRlYjcyODo1OjBlYTU6MTdhYTgwMzUxZDkyOWVhYTlkOTlhNjFhN2I1YTQ0MDM4NjBmMjdjYWYyOGVlYWUwYTYxZDM0YmYzNzA0MDU0Mzpw > >> Thanks >> >> James Pearson > > >_______________________________________________ >elrepo mailing list >elrepo at lists.elrepo.org >https://url.avanan.click/v2/___http://lists.elrepo.org/mailman/listinfo/elrepo___.YXAzOnRlY2huaWNvbG9yOmE6bzozOTIxZjRkYzc1NTgwODllZTU5YTkyOGUwOGRlYjcyODo1OjIzMDU6Njc4M2I0YzRkOTQzNDNmM2U1YWM2NTA5YjE5YzIzYTliZjNlYmEyMTI5Yjk3ZTRjZTY5MWNmMmEwMzM3MjYyOTpw >_______________________________________________ >elrepo mailing list >elrepo at lists.elrepo.org >http://lists.elrepo.org/mailman/listinfo/elrepo From james-p at moving-picture.com Sat Oct 16 17:03:20 2021 From: james-p at moving-picture.com (James Pearson) Date: Sat, 16 Oct 2021 21:03:20 +0000 Subject: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC In-Reply-To: <4E3A1D63-9553-4256-B5E0-C6F80DA72135@nobugconsulting.ro> References: <08ba6cd6-35a6-00f0-e96f-a7ab9930913a@elrepo.org> <4E3A1D63-9553-4256-B5E0-C6F80DA72135@nobugconsulting.ro> Message-ID: I did try it - but couldn't get it to work - although I don't have access to the PC at the moment (I'm testing using a VM - which, of course, doesn't have the NIC in question) - but once the installer is booted in the VM, I can't find the new kernel module in the install instance ? I'm probably doing something wrong - but I guess in the meantime, I'll see if using a USB stick with the update driver ISO image works ... Thanks James Pearson ________________________________________ From: Manuel Wolfshant Sent: 16 October 2021 21:40 To: EL Repo General Mailing List; James Pearson; elrepo at lists.elrepo.org Subject: Re: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC On October 16, 2021 11:08:42 PM GMT+03:00, James Pearson wrote: >Thanks for the info - however, I would like the driver disk to be obtained from the tftp server along with the kernel/initrd images > >The RHEL 6 install docs seems to suggest this is possible - but I can't find similar info in the RHEL 7 install docs, so I'm guessing this isn't possible with EL 7 ? > >Do I have to hack the install initrd image to add the new driver? > As far as I know, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/sect-preparing_an_initial_ram_disk_update still works >Thanks > >James Pearson >________________________________________ >From: elrepo-bounces at lists.elrepo.org on behalf of Phil Perry >Sent: 16 October 2021 12:52 >To: elrepo at lists.elrepo.org >Subject: Re: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC > >On 16/10/2021 11:57, James Pearson wrote: >> I'm trying to install CentOS 7.9 via PXE on a Lenovo P620 that has a single Aquantia 10Gb NIC >> >> The installer (Anaconda) fails to start and the installer kernel reports: >> >> atlantic: Bad FW version detected: 4020028 >> >> Installing the box by adding a 2nd NIC works fine and lspci reports: >> >> 01:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] [1d6a:07b1] (rev 02) >> >> After a bit of googling, it looks like Lenovo PCs with this NIC use/require 'version 4' of the firmware - which is not supported by the EL 7.9 atlantic driver (not supported until EL 8.4) >> >> Lenovo provide Linux driver source which builds fine on EL 7.9 - and I can insmod the new kernel module fine and it finds the NIC etc >> >> However, I'm struggling to build an installer driver disk image and get the CentOS 7.9 installer to use it >> >> I've created my own 'kmod-atlantic' RPM - based on other similar ElRepo SRPMS and it appears the installer attempts to use it - but it gives warnings like: >> >> [ 11.087251] atlantic: loading out-of-tree module taints kernel. >> [ 11.090231] atlantic: module verification failed: signature and/or required key missing - tainting kernel >> > >This messaging is perfectly normal - it's basically just telling you >that you've loaded a 3rd party module and that it either isn't signed >for Secure Boot or that the key it has been signed with hasn't been >imported on your system. > >> but doesn't seem to use the newer module? >> >> Can anyone give me some pointers to what I need to do to get the newer kernel module to load in the installer? >> > >To load the module during installation, you need to create a Driver >Update Disk (DUD) from your kmod package. This takes the form of an ISO >image you can burn to CD/DVD or USB stick and pass to the installer >(anaconda). > >We have written a script that we use to do the job (below) which you are >welcome to use: > >https://url.avanan.click/v2/___https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh___.YXAzOnRlY2huaWNvbG9yOmE6bzozOTIxZjRkYzc1NTgwODllZTU5YTkyOGUwOGRlYjcyODo1OjUzY2Y6ZTMzOGJlMGUzZmEyMzNkMTViNTA2ZmQyZDNiYmQwYmQyNTc3ODdhMTJlYWYxMWJjYTRlYWY5MzViZDBhMzc3Nzpw > >Simply run the script from the same dir that contains your kmod RPM and >SRPM. Note you should build your kmod RPM against the same kernel >version that is used on the installation media. > >This video explains how to use a Driver Update Disk (DUD) when >installing CentOS/RHEL: > >https://url.avanan.click/v2/___https://www.youtube.com/watch?v=4fOAuXiynYM___.YXAzOnRlY2huaWNvbG9yOmE6bzozOTIxZjRkYzc1NTgwODllZTU5YTkyOGUwOGRlYjcyODo1OjBlYTU6MTdhYTgwMzUxZDkyOWVhYTlkOTlhNjFhN2I1YTQ0MDM4NjBmMjdjYWYyOGVlYWUwYTYxZDM0YmYzNzA0MDU0Mzpw > >> Thanks >> >> James Pearson > > >_______________________________________________ >elrepo mailing list >elrepo at lists.elrepo.org >https://url.avanan.click/v2/___http://lists.elrepo.org/mailman/listinfo/elrepo___.YXAzOnRlY2huaWNvbG9yOmE6bzozOTIxZjRkYzc1NTgwODllZTU5YTkyOGUwOGRlYjcyODo1OjIzMDU6Njc4M2I0YzRkOTQzNDNmM2U1YWM2NTA5YjE5YzIzYTliZjNlYmEyMTI5Yjk3ZTRjZTY5MWNmMmEwMzM3MjYyOTpw >_______________________________________________ >elrepo mailing list >elrepo at lists.elrepo.org >https://url.avanan.click/v2/___http://lists.elrepo.org/mailman/listinfo/elrepo___.YXAzOnRlY2huaWNvbG9yOmE6bzoxOTQwM2ZjNTllM2E0MTRiYWZiYjg2ODZlMzY3MWU2Yjo1OmYwYzY6ZWMyZmM0OThhYzdhODFmZjk0Y2Y1MWJkYTAzNjA3OWIyYmJkMjBmNzc4NTk1MTdlMjdlNzM5YjYyYzczZjZhZjpw From wolfy at nobugconsulting.ro Sat Oct 16 19:00:53 2021 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sun, 17 Oct 2021 02:00:53 +0300 Subject: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC In-Reply-To: References: <08ba6cd6-35a6-00f0-e96f-a7ab9930913a@elrepo.org> <4E3A1D63-9553-4256-B5E0-C6F80DA72135@nobugconsulting.ro> Message-ID: <89e11ec0-9987-f968-76c7-52b60fb67c92@nobugconsulting.ro> On 10/17/21 12:03 AM, James Pearson wrote: > I did try it - but couldn't get it to work - although I don't have access to the PC at the moment (I'm testing using a VM - which, of course, doesn't have the NIC in question) - but once the installer is booted in the VM, I can't find the new kernel module in the install instance ? The logs should include references to the attempt of loading the driver even if it is not needed and therefore not used > > I'm probably doing something wrong - but I guess in the meantime, I'll see if using a USB stick with the update driver ISO image works ... > DUD on a stick certainly works. when done right . > Thanks > > James Pearson > ________________________________________ > From: Manuel Wolfshant > Sent: 16 October 2021 21:40 > To: EL Repo General Mailing List; James Pearson; elrepo at lists.elrepo.org > Subject: Re: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC > > > On October 16, 2021 11:08:42 PM GMT+03:00, James Pearson wrote: >> Thanks for the info - however, I would like the driver disk to be obtained from the tftp server along with the kernel/initrd images >> >> The RHEL 6 install docs seems to suggest this is possible - but I can't find similar info in the RHEL 7 install docs, so I'm guessing this isn't possible with EL 7 ? >> >> Do I have to hack the install initrd image to add the new driver? >> > As far as I know, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/sect-preparing_an_initial_ram_disk_update still works > > >> Thanks >> >> James Pearson >> ________________________________________ >> From: elrepo-bounces at lists.elrepo.org on behalf of Phil Perry >> Sent: 16 October 2021 12:52 >> To: elrepo at lists.elrepo.org >> Subject: Re: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC >> >> On 16/10/2021 11:57, James Pearson wrote: >>> I'm trying to install CentOS 7.9 via PXE on a Lenovo P620 that has a single Aquantia 10Gb NIC >>> >>> The installer (Anaconda) fails to start and the installer kernel reports: >>> >>> atlantic: Bad FW version detected: 4020028 >>> >>> Installing the box by adding a 2nd NIC works fine and lspci reports: >>> >>> 01:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] [1d6a:07b1] (rev 02) >>> >>> After a bit of googling, it looks like Lenovo PCs with this NIC use/require 'version 4' of the firmware - which is not supported by the EL 7.9 atlantic driver (not supported until EL 8.4) >>> >>> Lenovo provide Linux driver source which builds fine on EL 7.9 - and I can insmod the new kernel module fine and it finds the NIC etc >>> >>> However, I'm struggling to build an installer driver disk image and get the CentOS 7.9 installer to use it >>> >>> I've created my own 'kmod-atlantic' RPM - based on other similar ElRepo SRPMS and it appears the installer attempts to use it - but it gives warnings like: >>> >>> [ 11.087251] atlantic: loading out-of-tree module taints kernel. >>> [ 11.090231] atlantic: module verification failed: signature and/or required key missing - tainting kernel >>> >> This messaging is perfectly normal - it's basically just telling you >> that you've loaded a 3rd party module and that it either isn't signed >> for Secure Boot or that the key it has been signed with hasn't been >> imported on your system. >> >>> but doesn't seem to use the newer module? >>> >>> Can anyone give me some pointers to what I need to do to get the newer kernel module to load in the installer? >>> >> To load the module during installation, you need to create a Driver >> Update Disk (DUD) from your kmod package. This takes the form of an ISO >> image you can burn to CD/DVD or USB stick and pass to the installer >> (anaconda). >> >> We have written a script that we use to do the job (below) which you are >> welcome to use: >> >> https://url.avanan.click/v2/___https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh___.YXAzOnRlY2huaWNvbG9yOmE6bzozOTIxZjRkYzc1NTgwODllZTU5YTkyOGUwOGRlYjcyODo1OjUzY2Y6ZTMzOGJlMGUzZmEyMzNkMTViNTA2ZmQyZDNiYmQwYmQyNTc3ODdhMTJlYWYxMWJjYTRlYWY5MzViZDBhMzc3Nzpw >> >> Simply run the script from the same dir that contains your kmod RPM and >> SRPM. Note you should build your kmod RPM against the same kernel >> version that is used on the installation media. >> >> This video explains how to use a Driver Update Disk (DUD) when >> installing CentOS/RHEL: >> >> https://url.avanan.click/v2/___https://www.youtube.com/watch?v=4fOAuXiynYM___.YXAzOnRlY2huaWNvbG9yOmE6bzozOTIxZjRkYzc1NTgwODllZTU5YTkyOGUwOGRlYjcyODo1OjBlYTU6MTdhYTgwMzUxZDkyOWVhYTlkOTlhNjFhN2I1YTQ0MDM4NjBmMjdjYWYyOGVlYWUwYTYxZDM0YmYzNzA0MDU0Mzpw >> From sysops at starbursthosting.com Sun Oct 17 00:42:14 2021 From: sysops at starbursthosting.com (Starburst Hosting SysOp's) Date: Sun, 17 Oct 2021 00:42:14 -0400 Subject: [elrepo] Kernel updated to 5.4.154? Message-ID: Did an updated on the servers tonight, and 6 updated to Kernel 5.4.154. While 2 others updated to 5.4.153, which is listed on kernel.org at the latest kernel version. Just curious why the different Kernel versions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at elrepo.org Sun Oct 17 07:52:50 2021 From: phil at elrepo.org (Phil Perry) Date: Sun, 17 Oct 2021 12:52:50 +0100 Subject: [elrepo] Kernel updated to 5.4.154? In-Reply-To: References: Message-ID: <9d9dcf62-c30b-3089-8cef-815487946629@elrepo.org> On 17/10/2021 05:42, Starburst Hosting SysOp's via elrepo wrote: > Did an updated on the servers tonight, and 6 updated to Kernel 5.4.154. > > While 2 others updated to 5.4.153, which is listed on kernel.org at the > latest kernel version. > > Just curious why the different Kernel versions. > > Hi, Kernel 5.4.154 has only just been released and will still be syncing out to some mirror sites. If you update those other 2 systems again in a short while, they will almost certainly then pick up the latest 5.4.154 version. Regards, Phil From james-p at moving-picture.com Sun Oct 17 08:00:30 2021 From: james-p at moving-picture.com (James Pearson) Date: Sun, 17 Oct 2021 12:00:30 +0000 Subject: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC In-Reply-To: <89e11ec0-9987-f968-76c7-52b60fb67c92@nobugconsulting.ro> References: <08ba6cd6-35a6-00f0-e96f-a7ab9930913a@elrepo.org> <4E3A1D63-9553-4256-B5E0-C6F80DA72135@nobugconsulting.ro> <89e11ec0-9987-f968-76c7-52b60fb67c92@nobugconsulting.ro> Message-ID: OK, I think I now have what I need working The docs at got me part of the way - but I also had to add 'inst.dd=/dd.iso' to the PXE config 'append' line - i.e. something like (using the above RHEL 6 docs example): label el7-dd kernel el7/vmlinuz append initrd=el7/initrd.img,el7/dd.img inst.dd=/dd.iso ... (dd.img is a gzip'd cpio archive containing just dd.iso at the top level directory) I actually found out about this by accident, when one of my test installs dropped me into a dracut shell and I noticed my 'dd.iso' in the root directory ... However, it does seem strange that there is no mention of using a driver disk via PXE boot installs in the RHEL 7 install docs ? Thanks James Pearson ________________________________________ From: Manuel Wolfshant Sent: 17 October 2021 00:00 To: EL Repo General Mailing List; James Pearson Subject: Re: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC On 10/17/21 12:03 AM, James Pearson wrote: > I did try it - but couldn't get it to work - although I don't have access to the PC at the moment (I'm testing using a VM - which, of course, doesn't have the NIC in question) - but once the installer is booted in the VM, I can't find the new kernel module in the install instance ? The logs should include references to the attempt of loading the driver even if it is not needed and therefore not used > > I'm probably doing something wrong - but I guess in the meantime, I'll see if using a USB stick with the update driver ISO image works ... > DUD on a stick certainly works. when done right . > Thanks > > James Pearson > ________________________________________ > From: Manuel Wolfshant > Sent: 16 October 2021 21:40 > To: EL Repo General Mailing List; James Pearson; elrepo at lists.elrepo.org > Subject: Re: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC > > > On October 16, 2021 11:08:42 PM GMT+03:00, James Pearson wrote: >> Thanks for the info - however, I would like the driver disk to be obtained from the tftp server along with the kernel/initrd images >> >> The RHEL 6 install docs seems to suggest this is possible - but I can't find similar info in the RHEL 7 install docs, so I'm guessing this isn't possible with EL 7 ? >> >> Do I have to hack the install initrd image to add the new driver? >> > As far as I know, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/sect-preparing_an_initial_ram_disk_update still works > > >> Thanks >> >> James Pearson From ajb at elrepo.org Sun Oct 17 08:06:42 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Sun, 17 Oct 2021 13:06:42 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-lt Package Set [5.4.154-1] Message-ID: Announcing the release of the kernel-lt-5.4.154-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.154 The following files are currently synchronising to our mirror sites: x86_64 kernel-lt-5.4.154-1.el7.elrepo.x86_64.rpm kernel-lt-devel-5.4.154-1.el7.elrepo.x86_64.rpm kernel-lt-doc-5.4.154-1.el7.elrepo.noarch.rpm kernel-lt-headers-5.4.154-1.el7.elrepo.x86_64.rpm kernel-lt-tools-5.4.154-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.154-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.154-1.el7.elrepo.x86_64.rpm perf-5.4.154-1.el7.elrepo.x86_64.rpm python-perf-5.4.154-1.el7.elrepo.x86_64.rpm nosrc kernel-lt-5.4.154-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Sun Oct 17 08:06:46 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Sun, 17 Oct 2021 13:06:46 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-lt Package Set [5.4.154-1] Message-ID: Announcing the release of the kernel-lt-5.4.154-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.154 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.4.154-1.el8.elrepo.x86_64.rpm kernel-lt-5.4.154-1.el8.elrepo.x86_64.rpm kernel-lt-core-5.4.154-1.el8.elrepo.x86_64.rpm kernel-lt-devel-5.4.154-1.el8.elrepo.x86_64.rpm kernel-lt-doc-5.4.154-1.el8.elrepo.noarch.rpm kernel-lt-headers-5.4.154-1.el8.elrepo.x86_64.rpm kernel-lt-modules-5.4.154-1.el8.elrepo.x86_64.rpm kernel-lt-modules-extra-5.4.154-1.el8.elrepo.x86_64.rpm kernel-lt-tools-5.4.154-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.154-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.154-1.el8.elrepo.x86_64.rpm perf-5.4.154-1.el8.elrepo.x86_64.rpm python3-perf-5.4.154-1.el8.elrepo.x86_64.rpm nosrc kernel-lt-5.4.154-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 ajb at elrepo.org Sun Oct 17 08:06:50 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Sun, 17 Oct 2021 13:06:50 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-ml Package Set [5.14.13-1] Message-ID: Announcing the release of the kernel-ml-5.14.13-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.13 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-5.14.13-1.el7.elrepo.x86_64.rpm kernel-ml-devel-5.14.13-1.el7.elrepo.x86_64.rpm kernel-ml-doc-5.14.13-1.el7.elrepo.noarch.rpm kernel-ml-headers-5.14.13-1.el7.elrepo.x86_64.rpm kernel-ml-tools-5.14.13-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.13-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.13-1.el7.elrepo.x86_64.rpm perf-5.14.13-1.el7.elrepo.x86_64.rpm python-perf-5.14.13-1.el7.elrepo.x86_64.rpm nosrc kernel-ml-5.14.13-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Sun Oct 17 08:06:54 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Sun, 17 Oct 2021 13:06:54 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-ml Package Set [5.14.13-1] Message-ID: Announcing the release of the kernel-ml-5.14.13-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.13 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.14.13-1.el8.elrepo.x86_64.rpm kernel-ml-5.14.13-1.el8.elrepo.x86_64.rpm kernel-ml-core-5.14.13-1.el8.elrepo.x86_64.rpm kernel-ml-devel-5.14.13-1.el8.elrepo.x86_64.rpm kernel-ml-doc-5.14.13-1.el8.elrepo.noarch.rpm kernel-ml-headers-5.14.13-1.el8.elrepo.x86_64.rpm kernel-ml-modules-5.14.13-1.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-5.14.13-1.el8.elrepo.x86_64.rpm kernel-ml-tools-5.14.13-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.13-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.13-1.el8.elrepo.x86_64.rpm perf-5.14.13-1.el8.elrepo.x86_64.rpm python3-perf-5.14.13-1.el8.elrepo.x86_64.rpm nosrc kernel-ml-5.14.13-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-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 wolfy at nobugconsulting.ro Sun Oct 17 18:37:16 2021 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 18 Oct 2021 01:37:16 +0300 Subject: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC In-Reply-To: References: <08ba6cd6-35a6-00f0-e96f-a7ab9930913a@elrepo.org> <4E3A1D63-9553-4256-B5E0-C6F80DA72135@nobugconsulting.ro> <89e11ec0-9987-f968-76c7-52b60fb67c92@nobugconsulting.ro> Message-ID: On 10/17/21 3:00 PM, James Pearson wrote: > OK, I think I now have what I need working > > The docs at got me part of the way - but I also had to add 'inst.dd=/dd.iso' to the PXE config 'append' line - i.e. something like (using the above RHEL 6 docs example): > > label el7-dd > kernel el7/vmlinuz > append initrd=el7/initrd.img,el7/dd.img inst.dd=/dd.iso ... > > (dd.img is a gzip'd cpio archive containing just dd.iso at the top level directory) > > I actually found out about this by accident, when one of my test installs dropped me into a dracut shell and I noticed my 'dd.iso' in the root directory ... > > However, it does seem strange that there is no mention of using a driver disk via PXE boot installs in the RHEL 7 install docs ? It's a bit hidden unless you know what to look for but it exists https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-driver-updates-performing-x86 wolfy -- > > Thanks > > James Pearson > ________________________________________ > From: Manuel Wolfshant > Sent: 17 October 2021 00:00 > To: EL Repo General Mailing List; James Pearson > Subject: Re: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC > > On 10/17/21 12:03 AM, James Pearson wrote: >> I did try it - but couldn't get it to work - although I don't have access to the PC at the moment (I'm testing using a VM - which, of course, doesn't have the NIC in question) - but once the installer is booted in the VM, I can't find the new kernel module in the install instance ? > The logs should include references to the attempt of loading the driver > even if it is not needed and therefore not used > > >> I'm probably doing something wrong - but I guess in the meantime, I'll see if using a USB stick with the update driver ISO image works ... >> > DUD on a stick certainly works. when done right . > > >> Thanks >> >> James Pearson >> ________________________________________ >> From: Manuel Wolfshant >> Sent: 16 October 2021 21:40 >> To: EL Repo General Mailing List; James Pearson; elrepo at lists.elrepo.org >> Subject: Re: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC >> >> >> On October 16, 2021 11:08:42 PM GMT+03:00, James Pearson wrote: >>> Thanks for the info - however, I would like the driver disk to be obtained from the tftp server along with the kernel/initrd images >>> >>> The RHEL 6 install docs seems to suggest this is possible - but I can't find similar info in the RHEL 7 install docs, so I'm guessing this isn't possible with EL 7 ? >>> >>> Do I have to hack the install initrd image to add the new driver? >>> >> As far as I know, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/sect-preparing_an_initial_ram_disk_update still works >> >> >>> Thanks >>> >>> James Pearson From james-p at moving-picture.com Mon Oct 18 06:47:38 2021 From: james-p at moving-picture.com (James Pearson) Date: Mon, 18 Oct 2021 10:47:38 +0000 Subject: [elrepo] CentOS 7.9 driver for Lenovo P620 NIC In-Reply-To: References: <08ba6cd6-35a6-00f0-e96f-a7ab9930913a@elrepo.org> <4E3A1D63-9553-4256-B5E0-C6F80DA72135@nobugconsulting.ro> <89e11ec0-9987-f968-76c7-52b60fb67c92@nobugconsulting.ro> Message-ID: Manuel Wolfshant wrote: >> >> However, it does seem strange that there is no mention of using a driver disk via PXE boot >> installs in the RHEL 7 install docs ? > > It's a bit hidden unless you know what to look for but it exists > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-driver-updates-performing-x86 I think that's the problem - if you know what to look for, then you could probably infer what is needed ... but it doesn't explicitly state how to specify the argument to inst.dd when the driver update disk is supplied via pxelinux ... which was the bit that was missing for me :-) Thanks James Pearson From ajb at elrepo.org Wed Oct 20 11:35:09 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 20 Oct 2021 16:35:09 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-lt Package Set [5.4.155-1] Message-ID: Announcing the release of the kernel-lt-5.4.155-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.155 The following files are currently synchronising to our mirror sites: x86_64 kernel-lt-5.4.155-1.el7.elrepo.x86_64.rpm kernel-lt-devel-5.4.155-1.el7.elrepo.x86_64.rpm kernel-lt-doc-5.4.155-1.el7.elrepo.noarch.rpm kernel-lt-headers-5.4.155-1.el7.elrepo.x86_64.rpm kernel-lt-tools-5.4.155-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.155-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.155-1.el7.elrepo.x86_64.rpm perf-5.4.155-1.el7.elrepo.x86_64.rpm python-perf-5.4.155-1.el7.elrepo.x86_64.rpm nosrc kernel-lt-5.4.155-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Wed Oct 20 11:35:12 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 20 Oct 2021 16:35:12 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-lt Package Set [5.4.155-1] Message-ID: Announcing the release of the kernel-lt-5.4.155-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.155 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.4.155-1.el8.elrepo.x86_64.rpm kernel-lt-5.4.155-1.el8.elrepo.x86_64.rpm kernel-lt-core-5.4.155-1.el8.elrepo.x86_64.rpm kernel-lt-devel-5.4.155-1.el8.elrepo.x86_64.rpm kernel-lt-doc-5.4.155-1.el8.elrepo.noarch.rpm kernel-lt-headers-5.4.155-1.el8.elrepo.x86_64.rpm kernel-lt-modules-5.4.155-1.el8.elrepo.x86_64.rpm kernel-lt-modules-extra-5.4.155-1.el8.elrepo.x86_64.rpm kernel-lt-tools-5.4.155-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.155-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.155-1.el8.elrepo.x86_64.rpm perf-5.4.155-1.el8.elrepo.x86_64.rpm python3-perf-5.4.155-1.el8.elrepo.x86_64.rpm nosrc kernel-lt-5.4.155-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 ajb at elrepo.org Wed Oct 20 11:35:16 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 20 Oct 2021 16:35:16 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-ml Package Set [5.14.14-1] Message-ID: Announcing the release of the kernel-ml-5.14.14-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.14 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-5.14.14-1.el7.elrepo.x86_64.rpm kernel-ml-devel-5.14.14-1.el7.elrepo.x86_64.rpm kernel-ml-doc-5.14.14-1.el7.elrepo.noarch.rpm kernel-ml-headers-5.14.14-1.el7.elrepo.x86_64.rpm kernel-ml-tools-5.14.14-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.14-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.14-1.el7.elrepo.x86_64.rpm perf-5.14.14-1.el7.elrepo.x86_64.rpm python-perf-5.14.14-1.el7.elrepo.x86_64.rpm nosrc kernel-ml-5.14.14-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Wed Oct 20 11:35:19 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 20 Oct 2021 16:35:19 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-ml Package Set [5.14.14-1] Message-ID: Announcing the release of the kernel-ml-5.14.14-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.14 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.14.14-1.el8.elrepo.x86_64.rpm kernel-ml-5.14.14-1.el8.elrepo.x86_64.rpm kernel-ml-core-5.14.14-1.el8.elrepo.x86_64.rpm kernel-ml-devel-5.14.14-1.el8.elrepo.x86_64.rpm kernel-ml-doc-5.14.14-1.el8.elrepo.noarch.rpm kernel-ml-headers-5.14.14-1.el8.elrepo.x86_64.rpm kernel-ml-modules-5.14.14-1.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-5.14.14-1.el8.elrepo.x86_64.rpm kernel-ml-tools-5.14.14-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.14-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.14-1.el8.elrepo.x86_64.rpm perf-5.14.14-1.el8.elrepo.x86_64.rpm python3-perf-5.14.14-1.el8.elrepo.x86_64.rpm nosrc kernel-ml-5.14.14-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-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 ajb at elrepo.org Wed Oct 27 11:18:09 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 27 Oct 2021 16:18:09 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-lt Package Set [5.4.156-1] Message-ID: Announcing the release of the kernel-lt-5.4.156-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.156 The following files are currently synchronising to our mirror sites: x86_64 kernel-lt-5.4.156-1.el7.elrepo.x86_64.rpm kernel-lt-devel-5.4.156-1.el7.elrepo.x86_64.rpm kernel-lt-doc-5.4.156-1.el7.elrepo.noarch.rpm kernel-lt-headers-5.4.156-1.el7.elrepo.x86_64.rpm kernel-lt-tools-5.4.156-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.156-1.el7.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.156-1.el7.elrepo.x86_64.rpm perf-5.4.156-1.el7.elrepo.x86_64.rpm python-perf-5.4.156-1.el7.elrepo.x86_64.rpm nosrc kernel-lt-5.4.156-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Wed Oct 27 11:18:12 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 27 Oct 2021 16:18:12 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-lt Package Set [5.4.156-1] Message-ID: Announcing the release of the kernel-lt-5.4.156-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-lt The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.156 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.4.156-1.el8.elrepo.x86_64.rpm kernel-lt-5.4.156-1.el8.elrepo.x86_64.rpm kernel-lt-core-5.4.156-1.el8.elrepo.x86_64.rpm kernel-lt-devel-5.4.156-1.el8.elrepo.x86_64.rpm kernel-lt-doc-5.4.156-1.el8.elrepo.noarch.rpm kernel-lt-headers-5.4.156-1.el8.elrepo.x86_64.rpm kernel-lt-modules-5.4.156-1.el8.elrepo.x86_64.rpm kernel-lt-modules-extra-5.4.156-1.el8.elrepo.x86_64.rpm kernel-lt-tools-5.4.156-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-5.4.156-1.el8.elrepo.x86_64.rpm kernel-lt-tools-libs-devel-5.4.156-1.el8.elrepo.x86_64.rpm perf-5.4.156-1.el8.elrepo.x86_64.rpm python3-perf-5.4.156-1.el8.elrepo.x86_64.rpm nosrc kernel-lt-5.4.156-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 ajb at elrepo.org Wed Oct 27 11:18:16 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 27 Oct 2021 16:18:16 +0100 Subject: [elrepo] Announcement: EL7 Updated kernel-ml Package Set [5.14.15-1] Message-ID: Announcing the release of the kernel-ml-5.14.15-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.15 The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-5.14.15-1.el7.elrepo.x86_64.rpm kernel-ml-devel-5.14.15-1.el7.elrepo.x86_64.rpm kernel-ml-doc-5.14.15-1.el7.elrepo.noarch.rpm kernel-ml-headers-5.14.15-1.el7.elrepo.x86_64.rpm kernel-ml-tools-5.14.15-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.15-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.15-1.el7.elrepo.x86_64.rpm perf-5.14.15-1.el7.elrepo.x86_64.rpm python-perf-5.14.15-1.el7.elrepo.x86_64.rpm nosrc kernel-ml-5.14.15-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Wed Oct 27 11:18:20 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 27 Oct 2021 16:18:20 +0100 Subject: [elrepo] Announcement: EL8 Updated kernel-ml Package Set [5.14.15-1] Message-ID: Announcing the release of the kernel-ml-5.14.15-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The upstream changelog: https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.15 The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.14.15-1.el8.elrepo.x86_64.rpm kernel-ml-5.14.15-1.el8.elrepo.x86_64.rpm kernel-ml-core-5.14.15-1.el8.elrepo.x86_64.rpm kernel-ml-devel-5.14.15-1.el8.elrepo.x86_64.rpm kernel-ml-doc-5.14.15-1.el8.elrepo.noarch.rpm kernel-ml-headers-5.14.15-1.el8.elrepo.x86_64.rpm kernel-ml-modules-5.14.15-1.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-5.14.15-1.el8.elrepo.x86_64.rpm kernel-ml-tools-5.14.15-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-5.14.15-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.14.15-1.el8.elrepo.x86_64.rpm perf-5.14.15-1.el8.elrepo.x86_64.rpm python3-perf-5.14.15-1.el8.elrepo.x86_64.rpm nosrc kernel-ml-5.14.15-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-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 ajb at elrepo.org Sun Oct 31 19:07:23 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Sun, 31 Oct 2021 23:07:23 +0000 Subject: [elrepo] Announcement: EL7 New kernel-ml Release [5.15.0-1] Message-ID: Announcing the release of the kernel-ml-5.15.0-1.el7.elrepo package set into the EL7 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The following files are currently synchronising to our mirror sites: x86_64 kernel-ml-5.15.0-1.el7.elrepo.x86_64.rpm kernel-ml-devel-5.15.0-1.el7.elrepo.x86_64.rpm kernel-ml-doc-5.15.0-1.el7.elrepo.noarch.rpm kernel-ml-headers-5.15.0-1.el7.elrepo.x86_64.rpm kernel-ml-tools-5.15.0-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-5.15.0-1.el7.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.15.0-1.el7.elrepo.x86_64.rpm perf-5.15.0-1.el7.elrepo.x86_64.rpm python-perf-5.15.0-1.el7.elrepo.x86_64.rpm nosrc kernel-ml-5.15.0-1.el7.elrepo.nosrc.rpm Note: As a consequence of the upstream decision [1] to raise the minimum required version of gcc to 4.9, the distribution compiler can no longer be used in the kernel build process. We now use gcc-9, which is available from the devtoolset-9 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-7 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-7 kernels and, as such, they may be installed and updated alongside the regular kernel. The kernel configuration is based upon a default RHEL-7 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ec4476ac82512f09c94aff5972654b70f3772b2 [2] https://bugzilla.kernel.org/ [3] https://elrepo.org/bugs/ From ajb at elrepo.org Sun Oct 31 19:07:29 2021 From: ajb at elrepo.org (Alan Bartlett) Date: Sun, 31 Oct 2021 23:07:29 +0000 Subject: [elrepo] Announcement: EL8 New kernel-ml Release [5.15.0-1] Message-ID: Announcing the release of the kernel-ml-5.15.0-1.el8.elrepo package set into the EL8 elrepo-kernel repository: https://elrepo.org/tiki/kernel-ml The following files are currently synchronising to our mirror sites: x86_64 bpftool-5.15.0-1.el8.elrepo.x86_64.rpm kernel-ml-5.15.0-1.el8.elrepo.x86_64.rpm kernel-ml-core-5.15.0-1.el8.elrepo.x86_64.rpm kernel-ml-devel-5.15.0-1.el8.elrepo.x86_64.rpm kernel-ml-doc-5.15.0-1.el8.elrepo.noarch.rpm kernel-ml-headers-5.15.0-1.el8.elrepo.x86_64.rpm kernel-ml-modules-5.15.0-1.el8.elrepo.x86_64.rpm kernel-ml-modules-extra-5.15.0-1.el8.elrepo.x86_64.rpm kernel-ml-tools-5.15.0-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-5.15.0-1.el8.elrepo.x86_64.rpm kernel-ml-tools-libs-devel-5.15.0-1.el8.elrepo.x86_64.rpm perf-5.15.0-1.el8.elrepo.x86_64.rpm python3-perf-5.15.0-1.el8.elrepo.x86_64.rpm nosrc kernel-ml-5.15.0-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-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/