SCIENTIFIC-LINUX-USERS Archives

July 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Tue, 23 Jul 2013 20:45:35 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (69 lines)
On Tue, Jul 23, 2013 at 7:15 PM, Yasha Karant <[log in to unmask]> wrote:
> Will "yum upgrade" upgrade in place only the applications/files that come
> stock with SL without touching existing partitions or systems configuration
> folders (e.g., network information, password, shadow, and the like)?
>
> I was repeatedly told on both this and the CentOS list that TUV
> configuration no longer permitted this sort of operation (at one time, TUV
> provided production -- not just Fedora "beta" -- binaries, and during that
> epoch, the TUV installer had an "upgrade" option).

Yasha, you're mixing fruit carts and delivery trucks. "yum update"
talks to the yum repositories *for your current release*. It's written
into the /etc/yum.repos.d/*.repo files, everywhere it says
$releasever. Now, our favorite upstream vendor has been trying to
convince people that all point releases, such as 6.0, 6.1, 6,2, etc.,
should all point to one actively maintained update repository, and
that the updates should be done regularly, and thus any changes will
be automatically propagated and machines kept up to sink with even
machines installed from scratch from 6.4 media. In real life..... this
seldom happens.

For switching to a major OS update, such as between 5.6 and 6.4, from
the same vendor, the installation media usually include the tools in
"anaconda" software to handle other requirements. Packages may be
renamed, other packages may be no longer supported and cause
dependency issues, and mixing those with circular dependencies or
shifts from publishing tools as "i386" to "noarch" can cause
dependency hell. So the update DVD does a reasonable job.

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.

     * Build a local repository of all packages from the *matching* or
slightly newer release of the same major version, such as SL 5.9 if
you're switching a CentOS 5.6 box. (I'll use that as my example.).
     * Put that local repo on your local filesystem of your host,
because the updates are very likely to screw up networking in the
process if you try this live.
      * Collect a list of all existing RPM packages for reference:
               * rpm -qa --qf '%{name}.%{arch}\n'
      * Point to the new, local repository in your yum setup.
               * Turn off all other repositories: you can do this at
every command line, but it's much faster to just have them all
disabled.
        * Review the packages that are in one list, and not the other,
in particular whatever provides "/etc/redhat-release".
                 * Extract that RPM with any necessary overrides
                        * rpm -e --nodeps centos-release
                 * Install the alternate version from local disk,
because until this is back, network based is not going to work.
                         * yum install --disablerepo=*
sl-release-[whatever].noarch.rpm.
       * Update *everything* to the new repository versions.
        * Use "yum list extras" to identify mismatched names or
version confusion, and resolve the discrepancies.
        * Reinstall *ALL* packages, even the  that have the same name
and versions and releases, just to make sure you got the copy from the
new OS release..
                * This works much better with CentOS=>Scientific Linux
because ".sl" comes well after ".centos" in the alphabet. But it can
still get tricky.


Then, and only then, can you safely update in place from SL 5.x to SL
6.x with the normal installation media.

ATOM RSS1 RSS2