tag:blogger.com,1999:blog-73811288247875390462024-03-13T04:50:59.672-07:00The ELRepo Blog"For the community, by the community."toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.comBlogger35125tag:blogger.com,1999:blog-7381128824787539046.post-13448330618597154102023-06-13T15:50:00.000-07:002023-06-13T15:50:30.435-07:00In Loving Memory of Alan Bartlett<p> Alan Bartlett died unexpectedly of natural causes on May 31st, 2023.</p><p> It is with deep sorrow and profound sadness that we mourn the loss of Alan Bartlett, a brilliant computer expert, visionary, and the esteemed founder of the ELRepo Project [1]. He is also well known as 'burakkucat'. Alan passed away on May 31st, 2023, leaving a void in the world of Enterprise Linux that will be profoundly felt by all who benefited from his vast knowledge and contributions.<br /><br />Alan's innate curiosity and talent for computer programming became evident from an early age. He dedicated himself wholeheartedly to his work, pouring his energy into his passion for computer programming and the advancement of open-source software. Early on, Alan was a Unix user and later moved to Linux, along with many fellow enthusiasts, where his kernel presence became felt in the RHEL / CentOS 4 community. Alan, with three other individuals, founded the ELRepo Project for users of Red Hat Enterprise Linux and its derivatives [2].<br /><br />Alan's unwavering commitment and tireless efforts propelled the ELRepo Project to new heights, delivering kernel packages from kernel.org to countless users and organizations worldwide [3].<br /><br />Beyond his technical brilliance, Alan possessed a warm and generous spirit. He was always willing to lend a helping hand, providing guidance and support to fellow community members. Alan's kindness, patience, and willingness to share his knowledge endeared him to all who had the privilege of knowing him. He will be remembered not only for his technical expertise but also for his compassionate nature and genuine desire to make a positive difference in the lives of others.</p><p>Alan Bartlett's untimely departure leaves an indelible void in our hearts and in the world of technology. His passion, intellect, and unwavering dedication to his craft will forever be cherished and remembered. May his soul find eternal peace, and may his profound contributions to the field of open source communities continue to inspire and guide us in our pursuit of excellence.<br /><br />Respectfully,<br /><br />The ELRepo Team.<br /></p><p>[1] https://elrepo.org/<br />[2] https://blog.toracat.org/2009/06/<br />[3] http://lists.elrepo.org/pipermail/elrepo/2010-November/000382.html</p>toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-3830114845784889252022-03-01T15:47:00.001-08:002022-03-02T16:11:36.382-08:00ELRepo access stats: distributions<p> We have not done any statistics for a long time. Here's some recent data on the access to our mirrorlist files, comparing unique IPs across major distributions. </p><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgyGNSZssNcOstSoZPB8fDHgsEErLujMxeZKGY1RMpFsEraiQx4223lyfFpe7Tt1yvTezR4OTxqrXWpj7Koi3DQ0EhXs2fUPv6y4nPut0QqxyaHsH4CCN0CAqU7_LZUMaNGudxf6KfcOriPsvdMYgvHCUjYke7R7R2t_sID74L5u8bZfYU0yaq3mPGPLA=s629" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="442" data-original-width="629" height="481" src="https://blogger.googleusercontent.com/img/a/AVvXsEgyGNSZssNcOstSoZPB8fDHgsEErLujMxeZKGY1RMpFsEraiQx4223lyfFpe7Tt1yvTezR4OTxqrXWpj7Koi3DQ0EhXs2fUPv6y4nPut0QqxyaHsH4CCN0CAqU7_LZUMaNGudxf6KfcOriPsvdMYgvHCUjYke7R7R2t_sID74L5u8bZfYU0yaq3mPGPLA=w666-h481" width="666" /></a></div>[EDIT on 2022-03-02] We have added "CentOS Stream" to the graph. While the kmod packages are not built for CentOS Stream kernels, our kernel-ml/lt packages should work there.<br /><p><br /></p>toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com2tag:blogger.com,1999:blog-7381128824787539046.post-51325175156205919222021-01-18T15:21:00.002-08:002021-01-18T21:55:15.428-08:00ELRepo and CentOS Stream<p>As many of you are aware, Red Hat have chosen to discontinue CentOS Linux 8 at the end of 2021 and have proposed <i>CentOS Stream</i> as its replacement in many environments [1]. We are still in the phase of trying to figure out what these changes mean for us and how they will impact ELRepo users. </p><p> ELRepo has always taken the stance that we support RHEL, and by extention that includes all RHEL compatible rebuilds such as CentOS and Scientific Linux. The kmod standard that ELRepo uses to package and deliver drivers for RHEL is totally dependent on the stable kernel ABI (<b>kABI</b>) that RHEL affords [2]. Unfortunately for us, CentOS Stream, now being upstream of conventional RHEL releases, gets changes to the kernel which are scheduled for the next RHEL minor point release (their kernels diverge). These changes often break kABI compatibility and may cause ELRepo packages to no longer work. </p><p>So what does this mean for ELRepo users in practice? Well, preliminary testing of the first kernel update to EL8.3 in CentOS Stream indicates that 13 out of 44 kmod packages tested were broken by the kernel update.
It is simply not possible (for ELRepo) to deliver kmod packages against a constantly moving target such as the CentOS Stream kernel, and even if we could, these newly fixed packages would likely no longer be compatible with RHEL. We would be looking at a whole new repository or project for ELRepo-Stream and we do not have the resources to do that. </p><p>Therefore, for now, ELRepo are <i>unable to officially support</i> CentOS Stream kernels. In reality your package may continue to work but if/when it breaks, we will not be able to officially support it. Hopefully CentOS will be able to offer a solution that allows ELRepo packages to continue to work on CentOS Stream. </p><p>ELRepo also offers <b>kernel-ml</b> and <b>kernel-lt</b> packages for EL8 and these can be used on CentOS-Stream to provide a modern kernel (mainline or longterm) with native support for the legacy hardware Red Hat removed. These newer kernels may provide a convenient solution for some users whose hardware is not natively supported on CentOS Stream. </p><p>[1] <a href="https://blog.centos.org/2020/12/future-is-centos-stream">https://blog.centos.org/2020/12/future-is-centos-stream</a>/ </p><p>[2] <a href="https://elrepo.org/tiki/FAQ#What_is_a_kABI-tracking_kmod">https://elrepo.org/tiki/FAQ#What_is_a_kABI-tracking_kmod</a>/</p>toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-11764432176439480172020-12-14T08:12:00.000-08:002020-12-14T08:12:09.708-08:00RHEL6 is Now End of Life<p><b>RHEL6</b> reached end of life (<b>EOL</b>) on 30th November 2020.</p><p>As a consequence, the ELRepo Project has likewise ended support for el6. All el6 related packages (<i>except </i>for elrepo-release) have been removed from the repository.</p><p><b>RHEL6</b> customers on extended update support (<b>EUS</b>) wishing to continue to access our content may do so through the archives but this content will not be maintained nor supported.</p><p>The ELRepo team would like to thank all of our users for their support throughout the ten years of existence of <b>RHEL6</b>.</p><p>Going forwards, we continue to support both <b>RHEL7</b> and <b>RHEL8</b> until those products reach their scheduled end of life.</p><p>Any rebuild project(s) of the above <b>Red Hat</b> operating systems are also welcome to consume our products.</p><p>As always, we build our products on <b>RHEL</b> systems <i>for</i> users of <b>RHEL</b> systems.<br /></p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-4602107314810806402020-10-01T15:30:00.000-07:002020-10-01T15:30:48.541-07:00A Brief Guide on How to Access the ELRepo Project Repositories<p>Welcome to ELRepo, an RPM repository for Enterprise Linux packages. ELRepo supports Red Hat Enterprise Linux (RHEL) and its derivatives (Scientific Linux, CentOS & others).</p><p>The ELRepo Project focuses on hardware related packages to enhance your experience with Enterprise Linux. This includes filesystem drivers, graphics drivers, network drivers, sound drivers, webcam and video drivers.</p><p><u>How to Get Started</u></p><p>Import the public key:</p><p>rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org</p><p><u>To Install ELRepo for RHEL-8 or CentOS-8:</u></p><p>yum install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm</p><p><u>To Install ELRepo for RHEL-7, SL-7 or CentOS-7:</u></p><p>yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm</p><p>To make use of our mirror system, please also install yum-plugin-fastestmirror.</p><p><u>To Install ELRepo for RHEL-6, SL-6 or CentOS-6:</u></p><p>yum install https://www.elrepo.org/elrepo-release-6.el6.elrepo.noarch.rpm</p><p>To make use of our mirror system, please also install yum-plugin-fastestmirror.</p><p><u>The Repository Contents</u></p><p>ELRepo contains four channels.</p><p><b>elrepo</b> This is the main channel and is enabled by default. As this channel should not contain packages also present in the distribution, it should be safe to run a 'yum update' with this repository channel enabled.</p><p>For example, to install kmod-r8168 (Realtek r8168 NIC driver):</p><p>yum install kmod-r8168</p><p>Depending on the package being installed or the repository setup, it might be necessary to disable non-elrepo repositories:</p><p>yum --disablerepo=\* --enablerepo=elrepo install kmod-nvidia</p><p><b>elrepo-extras</b> The elrepo-extras channel provides packages and their dependencies that replace/update RHEL distribution packages. It may be enabled in the /etc/yum.repos.d/elrepo.repo file or used with 'yum --enablerepo=elrepo-extras'.</p><p><b>elrepo-testing</b> The elrepo-testing channel provides packages yet to be released to the main channel and is disabled by default. It may be enabled in the /etc/yum.repos.d/elrepo.repo file or used with 'yum --enablerepo=elrepo-testing'.</p><p><b>elrepo-kernel</b> The elrepo-kernel channel provides both the long-term support kernels (which have been configured for RHEL-7 and RHEL-6) and the latest stable mainline kernels (which have been configured for RHEL-8 and RHEL-7) using sources available from the Linux Kernel Archives. This channel may be enabled in the /etc/yum.repos.d/elrepo.repo file or used with 'yum --enablerepo=elrepo-kernel'.<br /></p>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-7381128824787539046.post-43753095292159535432019-08-27T16:04:00.001-07:002020-09-05T09:51:24.114-07:00RHEL 8.0 and support for removed adaptersIn RHEL 8.0, support for a good number of hardware devices has been removed. A list of removed adapters with their device IDs can be found in <a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/hardware-enablement_considerations-in-adopting-rhel-8#removed-adapters_hardware-enablement">this RHEL documentation</a>. We provide support for some of those that are still fairly commonly used today. You can check your devices's IDs (as shown by <i>lspci -nn</i>) against our list of <a href="http://elrepo.org/tiki/DeviceIDs">supported devices</a>.<br />
<br />
(1) Installation of the OS requires a driver for your hardware. We offer <b>driver update disk</b>s (DUD). You can download them from <a href="https://elrepo.org/linux/dud/el8/x86_64/">here</a> or the corresponding directory of our mirror sites. Each DUD image contains a driver in the form of a kmod package. The installer is supposed to find the driver. If this does not happen, you need to append the <b>inst.dd</b> option to the boot command line. For details please see <a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_an_advanced_rhel_installation/updating-drivers-during-installation_installing-rhel-as-an-experienced-user#performing-an-assisted-driver-update_updating-drivers-during-installation">Performing an assisted driver update</a>. Also, a <a href="https://youtu.be/4fOAuXiynYM" target="_blank">tutorial video</a> that demonstrates how to use ELRepo's DUD is available. <br />
<br />
(2) The installation process installs the kmod package for your adapter. Normally, because of the <a href="https://elrepoproject.blogspot.com/2016/02/kabi-tracking-kmod-packages.html" target="_blank">kABI-tracking </a>nature of kmod, there is no need to reinstall the driver upon each new kernel update. However, it was found that the current version of <b>dracut</b> in RHEL 8.0 has a <b>bug</b> and the initramfs image of a new kernel does not contain the kernel module from the installed kmod package. As a result, the new kernel <b>fails to boot</b>. (This is no longer an issue. See the [Update] below.)<br />
<br />
As an interim solution for the problem in (2), we provide a dracut package with a <a href="https://github.com/dracutdevs/dracut/pull/614">patch that fixes the bug</a> here:<br />
<br />
<a href="http://elrepo.org/people/akemi/testing/el8/dracut/" target="_blank"> http://elrepo.org/people/akemi/testing/el8/dracut/</a><br />
<br />
Install this version of dracut and then update the kernel. The system now should boot normally.<br />
<br />
[UPDATE] dracut-049-10.git20190115.el8_0.1 released on Oct 29, 2019 has the patch that fixes the issue.<br />
<br />
[UPDATE2] When updating the OS from 8.0 to 8.1, ELRepo's kmod packages must be updated to their .el8_1 version for the system to boot the 8.1 kernel.<br />
<br />
[Note for <b>CentOS-8</b> users] If you have switched to the centosplus kernel (<b>kernel-plus</b>) while on 8.0, you may want to uninstall the kmod package and no further action is required when updating to 8.1.<br />
<br />
[Note for users who wish to install remotely] There is an excellent <a href="https://arrfab.net/posts/2020/Sep/05/remotely-reinstalling-a-node-on-centos-8-with-dud-driver-disk-update-kernel-module-for-nichba/">blog post</a> written by <a href="https://arrfab.net/about/">Arrfab</a>.toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com28tag:blogger.com,1999:blog-7381128824787539046.post-71569940668881484402018-11-19T16:14:00.000-08:002019-08-28T16:20:52.357-07:00yum-plugin-elrepoWith almost every new RHEL point release, we hear from users that yum fails with errors. In most cases, this is because the kernel of their distribution has not been updated to the updated version in RHEL. Our <b>yum-plugin-elrepo</b> package takes care of this issue. The details are in our <a href="http://lists.elrepo.org/pipermail/elrepo/2018-November/004559.html" target="_blank">release announcement </a>copied below<br />
<br />
=+=+=+=+=+=+=+=+=+=+=+=+=+=+<br />
<span class="il">yum</span>-<span class="il">plugin</span>-<span class="il">elrepo</span>-7.5.1-1.el7.<span class="il">elrepo</span>.noarch.rpm<br />
<br />
<span class="il">yum</span>-<span class="il">plugin</span>-<span class="il">elrepo</span> provides a <span class="il">yum</span> <span class="il">plugin</span> to exclude kmod packages from the <span class="il">yum</span> transaction set which require kernels that are not yet available.<br />
<br />
<span class="il">Elrepo</span>.org provide kmod packages for RHEL and compatible distros. RHEL point releases sometimes break <a href="https://elrepoproject.blogspot.com/2016/02/kabi-tracking-kmod-packages.html" target="_blank">kABI compatibility</a> requiring a rebuild of the kmod package against the latest RHEL kernel.<br />
<br />
When this occurs at a RHEL point release, compatible distros such as CentOS and Scientific Linux often have yet to release their corresponding kernels which causes unresolved dependency errors in <span class="il">yum</span>.<br />
<br />
This <span class="il">plugin</span> seeks to determine the kernel version that any given kmod package is built against and then determine if the corresponding kernel is available. If the corresponding kernel is not available, the kmod <br />
package will be excluded from the <span class="il">yum</span> transaction set until the required kernel becomes available.<br />
<br />
Note: CentOS users will need to enable the CentOS Vault repositories to make previous kernels available to <span class="il">yum</span> otherwise older kmod packages may be excluded.<br />
=+=+=+=+=+=+=+=+=+=+=+=+=+=+toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-33554049031287949962017-01-03T17:36:00.001-08:002017-01-03T17:36:39.445-08:00ELRepo statistics 2017Happy New Year!<br />
<br />
It's been almost 8 years since we established The ELRepo Project. And 3 years since we last showed the statistics of our site.<br />
<br />
As you can see below, the number of ELRepo users have continuously grown. We now have over 1 million users (1,146,783 IPs) using the repositories. EL5 will be EOL'd in 3 months. We would expect EL7 to catch and ultimately surpass EL6, although EL7's growth is not as fast as that of EL6's.<br />
<br />
Our kernels, kernel-ml and kernel-lt, are popular. They are doubling every year the past 2 years. We have seen 187,785 users (IPs) in the last year, and ~18%
of ELRepo's userbase have installed one duing the last 12 months. <br />
<br />
Although not shown in the graphs, we see that the most popular download in all EL5, 6 and 7 was the Nvidia package which is followed by DRBD. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-InQQKDJzv_U/WGxHQkT9gBI/AAAAAAAABdY/6WJbzXa2zFkrAIVDPpxekTo5a7-4JxoRgCLcB/s1600/elrepostats20170103.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-InQQKDJzv_U/WGxHQkT9gBI/AAAAAAAABdY/6WJbzXa2zFkrAIVDPpxekTo5a7-4JxoRgCLcB/s1600/elrepostats20170103.jpg" /></a></div>
<br />toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-12046251457240996982016-02-10T09:57:00.004-08:002021-11-27T17:46:54.439-08:00kABI-tracking kmod packagesOur kmod packages are "kABI-tracking". The drivers they provide will work across all Enterprise Linux (EL) kernel releases, meaning there is no need to reinstall them upon each kernel update. But what is the kABI?<br />
<br />
The Kernel Application Binary Interface (kABI) is a set of in-kernel
symbols used by drivers and other kernel modules. Each major and minor RHEL kernel release has a set of in-kernel symbols that are whitelisted. A kABI-tracking kmod package contains a kernel module that is compatible with a given kABI, that is, for a given major and minor release of the EL kernel.<br />
<br />
However, in some cases the drivers use symbols that are <i>not</i> whitelisted in the RHEL kernel and these kernel symbols can change between releases. If a driver uses such kernel symbols, then the driver will <i>not</i> be backward compatible with older, previously released kernels.<br />
<br />
How can we check if a kmod package uses non-whitelisted kABI symbols? In EL-6, EL-7, and EL8, install the following two packages:<br />
<span style="background-color: #fce5cd;"><span style="font-family: "courier new" , "courier" , monospace;"><br /></span></span><span style="font-family: "courier new" , "courier" , monospace;">yum install kernel-abi-whitelists ksc</span><br />
<br />
Locate the module file (*.ko) and run the command:<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">ksc -k <module_name>.ko</span><br />
<br />
For example:<br />
<pre><code>
</code></pre>
<span style="font-family: "courier new" , "courier" , monospace;">$ ksc -k /lib/modules/2.6.32-358.el6.x86_64/extra/it87/it87.ko <br />Checking against architecture x86_64 <br />Total symbol usage: 45 Total Non white list symbol usage: 4 <br />Score: 91.11% <br /><br />A copy of the report is saved in /home/bob/ksc-result.txt</span><br />
<br />
In the above example, user "bob" has performed the check.<br />
<br />
[Note] Due to a bug in the ksc package, it will not work for EL 6.7. More details and an easy fix can be found in <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1272348" target="_blank">Red Hat bug #1272348</a>.<code>
</code>toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-53752852255860197142015-09-24T13:25:00.000-07:002015-09-24T13:44:52.029-07:00Kernel-lt and RHEL6A recent posting [1] to our <i>general mailing list</i> [2] reminded us that the <br />
linux-3.10.X branch of the kernel source code will soon be reaching end-of-life status upstream, at the <b>Linux Kernel Archives</b> website. [3]<br />
<br />
As a consequence, we now have to decide which source code branch should be used to build our <b>kernel-lt</b> package set for <b>RHEL6</b> (and its clones, <b>CentOS 6 </b>& <b>Scientific Linux 6</b>).<br />
<br />
Remembering that our slogan is <i>"For the community, by the community."</i>, you are invited to take part in the discussion [4] to select the new linux source code branch that will be used to build our <b>EL6 kernel-lt </b>package set. That discussion has now begun on our <i>development mailing list</i> [5].<br />
<br />
[1] http://lists.elrepo.org/pipermail/elrepo/2015-September/002746.html<br />
[2] http://lists.elrepo.org/mailman/listinfo/elrepo<br />
[3] https://www.kernel.org/<br />
[4] http://lists.elrepo.org/pipermail/elrepo-devel/2015-September/000613.html<br />
[5] http://lists.elrepo.org/mailman/listinfo/elrepo-develUnknownnoreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-49533765305908745852014-02-12T10:24:00.003-08:002014-02-12T10:24:50.133-08:00kernel-ml and Nvidia driverAs you know, ELRepo provides the <a href="http://elrepo.org/tiki/kmod-nvidia" target="_blank">Nvidia driver</a> for EL kernels but not for <a href="http://elrepo.org/tiki/kernel-ml" target="_blank">kernel-ml</a> or <a href="http://elrepo.org/tiki/kernel-lt" target="_blank">kernel-lt</a>. People running kernel-ml/lt can install the driver by downloading it directly from the Nvidia site. However, kernel version 3.13, as currently offered by <b>kernel-ml</b>, is known to have a problem with the latest Nvidia drivers. Fortunately, there is a fix for this issue. The detailed instructions are posted by CentOS developer <b>Johnny Hughes</b> on his <a href="http://centosnow.blogspot.com/2014/02/kernel-ml-nvidia-drivers-and-313x-kernel.html" target="_blank">blog</a>.<br />
<br />
Thanks, Johnny!toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-75874311315149547722013-10-24T18:51:00.001-07:002013-10-24T19:03:32.886-07:00Kernel-lt Package Sets -- What to Expect for EL5 and EL6<pre>We have recently released [1] the latest update to the <b>kernel-lt</b>
package sets, for both EL5 and EL6.
Those of you who regularly monitor the front page of the <b>Linux Kernel</b>
<b>Archives</b> website [2] will have observed that the linux-3.0.X branch
has now been transitioned to EOL status following the release of the
linux-3.0.101 sources [3]. This action is in full accord with the
information contained within the '<i>Longterm</i> <i>release kernels</i>' table, as
shown on the '<i>Active kernel releases</i>' page [4].
As a preparation for this event, the ELRepo Project previously asked
for comments [5] as to which Linux source branch should then be used
for the basis of the <b>kernel-lt</b> package sets. The final decision [6]
was that <b>kernel-lt</b> for <b>EL5</b> will be built using the linux-3.2.X branch
and <b>kernel-lt</b> for <b>EL6</b> will be built using the linux-3.10.X branch.
All users who make regular use the <b>kernel-lt</b> packages should be
prepared for the transition that will thus occur with the next update
to the <b>kernel-lt</b> package sets.</pre>
<pre> </pre>
<pre>[1] <a href="http://lists.elrepo.org/pipermail/elrepo/2013-October/002014.html">http://lists.elrepo.org/pipermail/elrepo/2013-October/002014.html</a> </pre>
<pre>[2] <a href="https://www.kernel.org/">https://www.kernel.org/</a></pre>
<pre>[3] <a href="https://lkml.org/lkml/2013/10/22/125">https://lkml.org/lkml/2013/10/22/125</a></pre>
<pre>[4] <a href="https://www.kernel.org/category/releases.html">https://www.kernel.org/category/releases.html</a></pre>
<pre>[5] <a href="http://lists.elrepo.org/pipermail/elrepo/2013-August/001863.html">http://lists.elrepo.org/pipermail/elrepo/2013-August/001863.html</a></pre>
<pre>[6] <a href="http://lists.elrepo.org/pipermail/elrepo/2013-August/001890.html">http://lists.elrepo.org/pipermail/elrepo/2013-August/001890.html</a></pre>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-10151305062265674312013-08-11T11:04:00.002-07:002013-08-11T11:05:39.708-07:00ELRepo Statistics (beginning to July 2013)<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-PU57wLKbpio/UgfR7tmravI/AAAAAAAAArE/UWzt-UwlBis/s1600/stat2013Aug1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-PU57wLKbpio/UgfR7tmravI/AAAAAAAAArE/UWzt-UwlBis/s1600/stat2013Aug1.jpg" /></a></div>
<br />toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-58080780611174154712013-08-05T15:17:00.000-07:002013-08-11T11:19:46.944-07:00Kernel-lt and the Future.The ELRepo Project has regularly released a <b>kernel-lt</b> (long term supported) <br />
package set for both enterprise Linux 5 & 6. These kernels have been based <br />
on the linux-3.0.X stable branch.<br />
<br />
The linux-3.0.X stable branch will be reaching end of life this coming <br />October [1][2] and a decision will have to be made with regards to the <br />future of the <b>kernel-lt</b> package sets that we provide.<br />
<br />
There are a number of options available, the most radical being to stop<br />building and providing such <b>kernel-lt</b> package sets. However no decision<br />has yet been made.<br />
<br />A thread has been started on the ELRepo users' mailing list [3] where<br />subscribers have been asked to assist the Project's administrators in<br />making a decision.<br /> <br />If you would like to be part of the decision making process, please<br />contribute to that mailing list thread.<br />
<br />
<pre>[1] <a href="https://www.kernel.org/category/releases.html">https://www.kernel.org/category/releases.html</a>
[2] <a href="http://en.wikipedia.org/wiki/Linux_kernel#Maintenance">http://en.wikipedia.org/wiki/Linux_kernel#Maintenance</a>
[3] <a href="http://lists.elrepo.org/pipermail/elrepo/2013-August/001863.html">http://lists.elrepo.org/pipermail/elrepo/2013-August/001863.html</a></pre>
Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-7381128824787539046.post-67819140972729482992013-07-16T14:28:00.000-07:002013-08-06T11:18:44.750-07:00RHEL 5.10 Beta releasedRed Hat has just announced the Beta release of Red Hat Enterprise Linux 5.10. At ELRepo, we should get busy testing our packages against this release. toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-21073573835578698932013-04-13T17:12:00.000-07:002013-04-16T06:27:49.730-07:00Where Are The Kernel-lt-3.0.73-1.el6.elrepo Packages?A week ago, we reported that the <b>kernel-lt-3.0.72-1.elX.elrepo</b> package sets (both el5 & el6) could not be built due to a bug introduced into the then just released <i>linux-3.0.72</i> source tarball.<br />
<br />
A week on and the <i>linux-3.0.73</i> source tarball has been released. The appropriate files were submitted to the build systems and the expected <b>kernel-lt-3.0.73-1.el5.elrepo</b> packages were created. They have been signed, uploaded to the main mirror and their availability announced.<br />
<br />
But what about the <b>kernel-lt-3.0.73-1.el6.elrepo</b> packages, you ask? Unfortunately the inability to test the patches so submitted has resulted in the presence of a different bug in the <i>linux-3.0.73</i> source tarball. That bug only affects the 32-bit build of the kernel with the el6 configuration.<br />
<br />
<blockquote class="tr_bq">
arch/x86/mm/numa_32.c:107: error: redefinition of 'alloc_remap'<br />
include/linux/bootmem.h:144: note: previous definition of 'alloc_remap' was here<br />
make[2]: *** [arch/x86/mm/numa_32.o] Error 1<br />
make[1]: *** [arch/x86/mm] Error 2<br />
make: *** [arch/x86] Error 2</blockquote>
<br />
Two successive buggy tarballs have now been released . . . We wonder what the next tarball (<i>linux-3.0.74</i>) will bring? A kick up the rear for the creators, applied by <b>Linus Torvalds</b>, perhaps?<br />
<br />
<u>Update (2013-04-15).</u> By making a change to the configuration for the el6 kernel (namely CONFIG_NUMA disabled for 32-bit), we have been able to build and release the package set. If you are inconvenienced by this configuration change, please let us know and -- most importantly -- refer to this bug at bugzilla.kernel.org Hopefully you will not be ignored.Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-7381128824787539046.post-34709128258555837422013-04-06T14:46:00.000-07:002013-04-07T12:55:02.188-07:00Where Are The Kernel-lt-3.0.72-1.elX.elrepo Packages?<i>Question: </i>The long-term support linux-3.0.72 source tarball was released on 2013-04-05. When will the <b>kernel-lt-3.0.72-1.elX.elrepo</b> packages, built for both EL5 and EL6, be available please?<br />
<br />
<i>Answer (short):</i> Never.<br />
<br />
<i>Answer (longer):</i> Never, because the source tarball is defective. A freshly introduced bug brings the 32-bit build to an abrupt halt during the module building phase.<br />
<br />
<blockquote class="tr_bq">
ERROR: "__udivdi3" [fs/ext4/ext4.ko] undefined!<br />
make[1]: *** [__modpost] Error 1<br />
make: *** [modules] Error 2</blockquote>
<br />Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-7381128824787539046.post-19332095226490740152013-02-27T14:50:00.002-08:002013-02-27T14:50:44.311-08:00RHEL 6.4 and ELRepoRHEL 6.4 was released on February 21th, 2013. We have tested our packages against this release and identified a couple of issues. Below is a digest of <a href="http://lists.elrepo.org/pipermail/elrepo/2013-February/001674.html" target="_blank">our note</a> sent to the ELRepo mailing list. <span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"> </span></span><br />
<br />
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">1. The current <b>OpenAFS</b> kmod package in elrepo (kmod-openafs-1.6.1-2.el6.elrepo) does not weak<span style="font-size: small;">-</span>link against the new 6.4 kernel. Jack Neely rebuilt the kmod against the new 6.4 kernel (kmod-openafs-1.6.1-5.el6.elrepo) but that package does not in
turn weak<span style="font-size: small;">-</span>link against earlier kernels. So users of 6.3 should continue to use the package in the main repository (kmod-openafs-1.6.1-2.el6.elrepo). When you are ready to
update to 6.4, also update kmod-openafs (kmod-openafs-1.6.1-5.el6.elrepo) from the elrepo testing repository at
the same time. </span></span><span style="font-family: Arial,Helvetica,sans-serif;"></span><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"> </span></span><br />
<br />
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">2. Red Hat updated the wireless stack in RHEL 6.4. As a result, there now exists a file level conflict between the kernel-firmware package and the <b>rt2860-firmware</b> and <b>rt2870-firmware</b> packages from elrepo, both providing the same file(s). Users of these devices are advised to uninstall the elrepo drivers and firmware for these devices and revert to the kernel drivers now these
devices are supported by the distro.</span></span><br />
<span style="font-family: Arial,Helvetica,sans-serif;"><br /></span>
<br />toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com6tag:blogger.com,1999:blog-7381128824787539046.post-5629271485977228602013-02-19T21:45:00.001-08:002013-02-19T22:03:41.492-08:00Kernel-ml-3.8.0-1.el6.elrepoHaving received a system-generated message that the mainline <b>linux-3.8</b> tarball was available at the <a href="http://kernel.org/" rel="nofollow" target="_blank">Linux Kernel Archives</a>, it was downloaded and fed into the <b>ELRepo Project</b>'s build system.<br />
<br />
After the dispatch of one e-mail in-box full of messages and an evening meal, the build status was checked. The expected message was duly seen --<br />
<blockquote class="tr_bq">
<i>All packages have been built.</i></blockquote>
So just three steps remained -- package signing, uploading to the <b>elrepo-kernel</b> repository and <a href="http://lists.elrepo.org/pipermail/elrepo/2013-February/001659.html" target="_blank">announcing</a> the release of this package set to our mailing-list.<br />
<br />
By now our mirror-sites will be synchronising with this latest <b>kernel-ml</b> release and so it is all over -- until the next tarball is released.<br />
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-5275088434636457272013-01-05T16:25:00.002-08:002013-01-05T16:25:16.809-08:00ELRepo statistics - Year 2012Here's the number of yum users for the year 2012.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-RA1Z9K8pFAg/UOjD67RD1oI/AAAAAAAAASs/7ieaHW0mLOA/s1600/ELRepo-yum-users-2013.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-RA1Z9K8pFAg/UOjD67RD1oI/AAAAAAAAASs/7ieaHW0mLOA/s1600/ELRepo-yum-users-2013.jpg" /></a></div>
<br />toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-22992849095473927312012-11-21T08:36:00.000-08:002012-11-21T08:36:35.996-08:00kernel-lt and kernel-mlAnd Nux! said "Let there be light" and there was kernel-l(igh)t.<br />
<br />
Actually the <b>'lt</b>' in kernel-lt stands for <i>long term</i>. That is, the <a href="http://elrepo.org/tiki/kernel-lt"><b>kernel-lt</b></a> package set is based on the long-term, stable branch from the <a href="http://kernel.org/" target="_blank">Linux Kernel Archives</a> as opposed to the mainline branch, upon which the <b><a class="wiki " href="http://elrepo.org/tiki/kernel-ml" title="kernel-ml">kernel-ml</a></b> package set is based.<br />
<br />
All this started with an innocent-looking <a href="http://lists.elrepo.org/pipermail/elrepo/2012-October/001441.html">request</a> on the ELRepo mailing list:<br />
<blockquote class="tr_bq">
<pre>"Guys, is there a possibility to have the TLS kernels in their own repo
or would it be just spreading too thin? Maybe some hardlinks as to not
waste space.. I'm not using the lts kernel but I'm thinking many do and
they don't want to have the lts kernel updated by the "latest" one."</pre>
</blockquote>
After a long discussion (of nearly 40 posts) it was decided that the ELRepo Project would provide a long-term kernel, as 'kernel-lt', from the elrepo-kernel repository. Currently the following kernel versions are available:<br />
<br />
<pre><b>EL6</b>
kernel-ml 3.6.x
kernel-lt 3.0.x
<b>EL5</b>
kernel-lt 3.0.x</pre>
<pre></pre>
In conclusion we must state our usual disclaimer:<br />
<blockquote class="tr_bq">
We provide these kernels for hardware testing in an effort to identify<br />
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<br />
hardware working using the RHEL-{5|6} kernel with supplementary kmod packages.<br />
<br />
These packages are provided "As-Is" with no implied warranty or<br />
support. Using the kernel-lt may expose your system to security,<br />
performance and/or data corruption issues. Since timely updates may<br />
not be available from the ELRepo Project, the end user has the<br />
ultimate responsibility for deciding whether to continue using the<br />
kernel-lt packages in regular service.<br />
<br />
The packages are intentionally named kernel-lt so as not to conflict<br />
with the RHEL-{5|6} kernels and, as such, they may be installed and<br />
updated alongside the regular kernel. The kernel configuration is<br />
based upon a default RHEL-{5|6} configuration with added functionality enabled as appropriate.<br />
<br />
If a bug is found when using these kernels, the end user is encouraged<br />
to report it upstream to the Linux Kernel bug tracker [1] and, for our<br />
reference, to the ELRepo bug tracker [2]. By taking such action, the<br />
reporter will be assisting the kernel developers, Red Hat and the Open<br />
Source Community as a whole.</blockquote>
<blockquote class="tr_bq">
[1] <a href="http://bugzilla.kernel.org/" target="_blank">http://bugzilla.kernel.org/</a><br />
[2] <a href="http://elrepo.org/bugs/" target="_blank">http://elrepo.org/bugs/</a> </blockquote>
toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com1tag:blogger.com,1999:blog-7381128824787539046.post-55225998666984861292012-08-05T11:29:00.000-07:002012-08-05T13:37:56.431-07:00ELRepo statistics - August 2012Here's the entire history of ELRepo as of August 2012:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-p_ZW_0C9alk/UB67OJQxTcI/AAAAAAAAAGA/ba_acZcnlBc/s1600/elrepostat2012JulyAll2.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><br /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-SZ41HLPU-TY/UB7ZkROLpZI/AAAAAAAAAGQ/7T1zza-j-cU/s1600/elrepostat2012Aug0.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-SZ41HLPU-TY/UB7ZkROLpZI/AAAAAAAAAGQ/7T1zza-j-cU/s1600/elrepostat2012Aug0.jpg" /></a></div>
<a href="http://1.bp.blogspot.com/-p_ZW_0C9alk/UB67OJQxTcI/AAAAAAAAAGA/ba_acZcnlBc/s1600/elrepostat2012JulyAll2.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><br /></a><br />
<br />
<br />
<br />toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-21849225123802165712012-06-07T13:27:00.002-07:002012-06-07T14:01:48.532-07:00ELRepo archivesAt ELRepo, we prune older packages to save disk space and keep the repo size from growing forever. Then, from time to time we receive requests for the ones that have been removed.<br />
<br />
In response to those requests, we have created a new repository "<b>archive</b>". Any packages in the <b>elrepo</b> and <b>extras</b> repositories that are older than <b>21</b> day old are duplicated there. Not all mirrors carry the archive repo. Currently there are 4 mirrors and they are marked on the mirror list found on our <a href="http://elrepo.org/tiki/Download" target="_blank">Download page</a>.toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com4tag:blogger.com,1999:blog-7381128824787539046.post-80099604293184414222012-04-24T10:50:00.000-07:002012-04-25T09:58:02.891-07:00RHEL 6.3 beta announcedRed Hat announced the release of <a href="https://www.redhat.com/archives/rhelv6-list/2012-April/msg00030.html" target="_blank">RHEL 6.3 beta</a> today. We, at ELRepo, must now get busy testing out our kmod and other packages.toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0tag:blogger.com,1999:blog-7381128824787539046.post-20515370539462949272012-04-11T12:33:00.001-07:002012-04-11T13:09:09.209-07:00Nvidia driver that fixes a security vulnerability releasedNvidia announced today a release of an updated version (295.40) of the Nvidia Unix driver that fixes a security vulnerability (see <a href="http://www.nvnews.net/vbulletin/showthread.php?t=178006" target="_blank">http://www.nvnews.net/vbulletin/showthread.php?t=178006</a> and <a href="http://nvidia.custhelp.com/app/answers/detail/a_id/3109" target="_blank">Nvidia knowledgebase</a> for details). Here is a brief description:<br />
<br />
"The vulnerability makes it possible for attackers with read/write access
to the GPU device nodes to access arbitrary system memory, NVIDIA recommends that users of the NVIDIA Linux, Solaris, and FreeBSD drivers with Geforce 8 or newer, G80 Quadro or newer, or any Tesla GPU update their drivers to version <b>295.40</b> or later."<br />
<br />
We (Phil Perry, maintainer of the nvidia driver packages) released the ELRepo packages with this driver version <b>295.40</b> for both EL5 and EL6.<br />
<br />
*EL5*<br />
kmod-nvidia-295.40-1.el5.<wbr></wbr>elrepo.i686.rpm<br />
<div id=":1qs">
kmod-nvidia-PAE-295.40-1.el5.<wbr></wbr>elrepo.i686.rpm<br />
kmod-nvidia-295.40-1.el5.<wbr></wbr>elrepo.x86_64.rpm<br />
nvidia-x11-drv-295.40-1.el5.<wbr></wbr>elrepo.i386.rpm<br />
nvidia-x11-drv-295.40-1.el5.<wbr></wbr>elrepo.x86_64.rpm<br />
nvidia-x11-drv-32bit-295.40-1.<wbr></wbr>el5.elrepo.x86_64.rpm<br />
<br />
*EL6*<br />
kmod-nvidia-295.40-1.el6.<wbr></wbr>elrepo.i686.rpm<br />
kmod-nvidia-295.40-1.el6.<wbr></wbr>elrepo.x86_64.rpm<br />
nvidia-x11-drv-295.40-1.el6.<wbr></wbr>elrepo.i686.rpm<br />
nvidia-x11-drv-295.40-1.el6.<wbr></wbr>elrepo.x86_64.rpm<br />
nvidia-x11-drv-32bit-295.40-1.<wbr></wbr>el6.elrepo.x86_64.rpm<br />
<br />
</div>
<div id=":1qs">
</div>
<div id=":1qs">
All Nvidia driver users are advised to update to this version as soon as possible. </div>toracathttp://www.blogger.com/profile/15469972681528977676noreply@blogger.com0