On Tue, Jul 26, 2011 at 5:16 PM, Connie Sieh <[log in to unmask]> wrote:
> On Tue, 26 Jul 2011, Yasha Karant wrote:
>
>> On 07/26/2011 12:48 PM, Troy Dawson wrote:
>>>
>>> On 07/21/2011 11:03 AM, Dormition Skete wrote:
>>>>
>>>> Hello.
>>>>
>>>> We already have a server using SL6.0. I see that 6.1 is probably
>>>> going to be coming out soon. If we just keep our server updated,
>>>> will it automatically "become" a 6.1 server, or do we need to
>>>> download a new 6.1 DVD when it comes out, and go through the upgrade
>>>> process to make the server 6.1?
>>>>
>>>> Any help with this will be appreciated.
>>>>
>>>>
>>>>
>>>
>>> Hi,
>>> This is one place where Scientific Linux differs from RHEL.
>>>
>>> The default setting for Scientific Linux is for you to "sit on a
>>> release". This means that you do not automatically update to the next
>>> release, unless you want to. So if you install SL 5.4, you will stay at
>>> SL 5.4, getting security updates, until you manually update to whichever
>>> release you want.
>>>
>>> If you want the same functionality as RHEL (your machine is
>>> automatically updated to the latest release) you need to install
>>> yum-conf-sl6x.
>>> yum-conf-sl6x
>>>
>>> Troy
>>
>> Will yum-conf-sl6x automatically update to the latest production release
>> (e.g., SL 6.1) but will not update to beta/testing/release candidates?
>
> It updates to the latest production release.
>
>> I assume that one can pick and choose -- for example, if one is running
>> a higher (later) revision kernel and kernel firmware than the production
>> release, one may simply skip the kernel portion of the update.
>
> Note that the kernel is never updated automatically.   This is controlled by
> the contents of the "EXCLUDE" line in /etc/sysconfig/yum-autoupdate .


That's not "never". That's "never updated automatically by default".
There are a stack of historical reasons, especially including systems
with manually applied device drivers or customized optimizations, and
the possibility of accidentally updating to a kernel incompatible with
the existing system. I've actually had that happen, not with default
kernels, but with locally "optimized" kernels and kernel developers
who were very careless of integrating their tweaks software with
package management, source control, or as far as I could tell, the
laws of thermodynamics.

Our favorite upstream vendor has been quite good about this, and about
keeping the distinct kernels available on the same system.