On 07/23/2013 06:02 PM, Nico Kadel-Garcia wrote:
> On Tue, Jul 23, 2013 at 8:56 PM, Jeffrey Anderson <[log in to unmask]> wrote:
>>
>> On Tue, Jul 23, 2013 at 5:45 PM, Nico Kadel-Garcia <[log in to unmask]> wrote:
>>>
>>> the problem here is the switch from one OS, a CERN release, to an
>>> actual Scientific Linux release. That..... can be an adventure. I've
>>> done it for CentOS=>Scientific Linux, and for RHEL=>CentOS and
>>> CentOS=>RHEL. It's nasty, and I don't recommend it unless you're
>>> getting paid hourly.
>>
>>
>> Actually that is not quite the problem  I was trying to upgrade from the
>> CERN SL5 to the CERN SL6, and that apparently is not supported.  But neither
>> is a vanilla SL5 to vanilla SL6.
>>
>> The message I get from the official voices in this thread is that there is
>> no supported method of upgrading major versions, only minor point versions.
>> It's no big deal.  I just did a fresh install, then some cfengine magic and
>> am back up and running in a couple hours.  I was just surprised because
>> major version upgrades have been available for every version of SL and TUV
>> for the past 15+ years, and when the install media did not give me that
>> option here I wanted to make sure I wasn't overlooking something.
>>
>> Jeff
>
> I'm glad for you, and startled myself. Our favorite upstream vendor
> certainly supported doing updates from major OS versions to major OS
> versoins: you just couldn''t gracefully do it *live", because changing
> things like major versions of glibc and rpm while you're in the midst
> of using them to do the update is...... intriguingly problematic.
> (Tried it once: don't recommend it!)
>

One should never have to deal with the "intriguingly problematic" 
situation to which you allude, at least not with a properly engineered 
software system.  The upgrading runtime system (that which is actually 
executing to do the upgrade) should not depend upon any executable 
images from the system being upgraded, but should stand alone -- 
installing / overwriting to new executable images.  The only primary 
issue would be a power/hardware failure during the upgrade, possibly 
leaving the system in an unstable ("mixed" between incompatible 
executables) state.  Otherwise, upon completion of the upgrading 
environment (possibly executing from a "temp" area on the hard drive 
into some portion of main memory), the new standalone bootable system 
(with bootloader and boot files) would be installed, and the system 
should do a full reboot equivalent to a "cold" power-on.

The fact that you did need to deal with an "intriguingly problematic" 
situation seems to indicate a not very good upgrade implementation.  The 
same thing could happen with an update, depending upon which systems 
dependencies are changed (e.g., a new glibc that is not backward 
compatible with the one being used by the previous running image).

Yasha Karant