On Thu, Jul 11, 2013 at 1:27 AM, Kelvin Chu <span dir="ltr"><<a href="mailto:yskchu@gmail.com" target="_blank">yskchu@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Hi guys, <br>
Have a question on red hat version and kernel version supportability.</p>
<p dir="ltr">I understand that each minor release comes with an updated kernel; for example, 6.2 comes with 2.6.32-220, and 6.3 comes with 2.6.32-279, and 6.4 comes with 32-358 and 6.0 originally came with 32-71.</p>
<p dir="ltr">Is using a old kernel for a newer release supported?</p></blockquote><div>It is _strongly_ recommended that you use the kernel build appropriate for the user space.</div><div><br></div><div>E.g., RHEL 6.4 userspace with 2.6.32-358[.y.z] (which are 6.4) [errata] kernels.</div>
<div><br></div><div>Yes, the RHEL kABI exists so many interfaces are mitigated against change throughout the entire RHEL lifecycle. That's so most IHV/ISV software and even kernel modules can remain unchanged, _if_ they are written to the kABI, and do not use structures outside of it (more on that in a bit).</div>
<div><br></div><div>However ... with each new Update (aka Point Release), in addition to Security Errata (RHSA) and limited Bugfix Errata (RHBA) that are normally released mid-Update (same Point Release), there are more Bugfix Errata (RHBA) and Enhancement Errata (RHEA) for the new Update (new Point Release). These additional changes -- especially Enhancements which are always by and for Customers -- may require newer and/or different userspace to support.</div>
<div><br></div><div>So ... coming back to IHV/ISVs who go "outside" the kABI ... is that why you're looking to stick with an old kernel on a new Update userspace?</div><div><br></div><div>E.g., RHEL 6.4 userspace with 2.6.32-279[.y.z] (6.3 series) [errata] kernel because your IHV or ISV requires the 6.3 kernel series for their modules?</div>
<div><br></div><div>If so ... you should get Extended Update Support (EUS) entitlement(s) for your system(s). [1]</div><div><br></div><div>EUS started out, and is also known as, the "Z-stream," where errata kernels (and select other packages, as required) are maintained for an older Update (Point Release) after a newer Update comes out. E.g., RHEL 6.3 EUS would continue to have newer 2.6.32-279.y.z kernels, even after 6.4 was released and 2.6.32-358[.y.z] builds now the "HEAD" tag. This Z-stream mitigates changes to select Security fixes and only required Bugfix errata to mitigate any changes to the kernel and its structures.</div>
<div><br></div><div>So ... EUS and its Z-stream mitigates problems with IHVs and ISVs that go outside the Red Hat kABI and modify other structures and interfaces. All the while EUS releases are still maintained as if the old Update was still the "HEAD" tag. It gives your IHV and ISV 18-24+ months to migrate to a newer Update, much longer than the typical Update cycle of 6-9 months. In fact, some IHV and ISVs virtually _never_ seem to even release during the "HEAD" update, so EUS is absolutely required to deal with such situations.</div>
<div><br></div><div><div>See the RHEL Lifecycle document for more information on typical release cycles, including EUS dates for RHEL6. [2]</div></div><div><br></div><div>EUS is very advantageous in Enterprises, and I've worked in several where policy _required_ all RHEL systems to be subscribed to the EUS channels unless there was an exception, or the solution itself always required the "HEAD" Update (latest Point Release). EUS and access to the Z-streams are a very minimal charge beyond a RHEL entitlement, and I highly recommend it to improve management and other aspects of your enterprise if you are finding you are deploying older Updates. Again, if you have troubling IHV and ISV solutions that require older Updates that are not receiving security updates like the "HEAD" Update, you really should get your enterprise on EUS.</div>
<div><br></div><div>Every single enterprise, and even some smaller shops, I've been at that went EUS have never wanted to go back, and cannot believe they didn't know about it before. ;)</div><div><br></div><div>
-- bjs</div><div><br></div><div>P.S. If you do _not_ have EUS, you _should_ be on the latest Update (latest Point Release), kernel and userspace. E.g., everyone without an EUS subscription should be on RHEL 6.4 (or RHEL 5.9 in the case of RHEL5 -- ignoring ELS for RHEL3/4, which is different than EUS). If not, then issues may arise and/or you may accidentally "re-cover ground" with Red Hat GSS that has already been addressed in the new Update, and would have solved your issue. I've seen this several times myself, hence why this is my strong, professional recommendation. YMMV.</div>
<div><br></div><div>[1] Extended Update Support</div><div> - <a href="http://www.redhat.com/products/enterprise-linux-add-ons/extended-update-support/">http://www.redhat.com/products/enterprise-linux-add-ons/extended-update-support/</a></div>
<div><br></div><div>[2] Red Hat Enterprise Linux Life Cycle</div><div> - <a href="https://access.redhat.com/support/policy/updates/errata/">https://access.redhat.com/support/policy/updates/errata/</a></div><div><br></div>
<div>"<span style="background-color:rgb(255,255,255);color:rgb(51,51,51);font-family:'Liberation Sans',Arimo,'Trebuchet MS','Bitstream Vera Sans',helvetica,verdana,arial,sans-serif;font-size:13px;line-height:18px">In Red Hat Enterprise Linux 6, EUS is available for the following minor releases:</span></div>
<div> - 6.0 (ends November 30, 2012)</div><div> - 6.1 (ends May 31, 2013)</div><div> - 6.2 (ends December 31, 2013)</div><div> - 6.3 (ends June 30, 2014)</div><div> - 6.4 (ends February 28, 2015)"</div><div><br></div>
<div><br></div><div>--</div></div>Bryan J Smith - Professional, Technical Annoyance<br>b.j.smith at <a href="http://ieee.org" target="_blank">ieee.org</a> - <a href="http://www.linkedin.com/in/bjsmith" target="_blank">http://www.linkedin.com/in/bjsmith</a><br>
<br>