SCIENTIFIC-LINUX-USERS Archives

July 2016

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:
Sat, 16 Jul 2016 16:10:10 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (67 lines)
On Sat, Jul 16, 2016 at 3:34 PM, John Pilkington <[log in to unmask]> wrote:
> Now that SL 6.8 has been released, many packages in the sl6x-related repos
> are shown as upgradeable, but the release announcement still includes the
> warning that:
>
> There should be no expectation that a "yum" upgrade to SL 6.8 will work.
> A new install is the recommended method to move from "sl6rolling" and the
> released SL 6.8.

Unless you've been using some pretty odd repositories, it's actually a
pretty good working assumption that installing in place will just
work. The RHEL upstream yum repositories are written exactly this way:
they don't publish yum repositories that are factored out by release,
and haven't done so since Red Hat 9. It's not like the old days of Red
Hat 7.0, 7.1, 7.2, 7.3, each with its own update repositories nad you
had to pick carefully. Our favorite upstream vendor is doing a very
good job of keeping the updates of all base packages upgradeable from
all minor releases. So this kind of in place "yum update" has been
working pretty well, at least the last several hundred times *I've*
done it for different flavors of RHEL, CentOS, and Scientific Linux.

A problem can creep in now and then, especially if you don't update
regularly, and or you don't you refuse to update particular hosts in a
shared environment, or you have poorly integrated third party software
that has no published well written RPM's.

Also, rebooting and activating kernels can be a bit of an adventure.
If you have custom installed hardware drivers that are not well
integrated like VirtualBox or the atrpms kernel drivers, well,
adventures may ensue. And if you haven't rebooted a box in a year,
don't be surprised if it wants to do an fsck of your file systems even
if you didn't ask for one, and that man make the update take *much*
longer than expected on a bulky system.

> Does this still apply?  When I first saw it I assumed that it referred
> specifically to the RCs, but it's still there, post-release.  I'm pretty
> sure I didn't do a fresh install for 6.6 > 6.7
>
> Thanks,
>
> John Pilkington

RC's are an adventure, and may have components of "newer" revision
that are incompatible with the stock system. Be prepared to delete or
"yum downgrade" those packages, and be prepared for pain sorting out
the dependencies if those have been modified. And be prepared to
reinstall simply to switch to a more supported standard filesystem:
some very odd things get tried out in RC's, and some of them cannot be
managed by RPM replacement. The chnages in SELinux configs are my
rcent favorites there.

"yum list extras" can be your real friend when updating or migrationg.
And my old favorite "yum reinstall" is invaluable for replacing
packages that happen to have the same version and release number, but
come from another repository.

In fact, I used to use "yum reinstall" to swap systems from CentOS to
Scientieific Linux to RHEL and every combination of the three, to deal
with licensing and company mandates to switch supported operating
systems. That..... took some extra work, and serious manipulation of
yum configurations to block the old repositories and activate the new
ones. I don't recommend it for the faint of heart, but it is in fact
possible. It does take as much as a whole day to reinstall
*everything* to be sure of having the right distribution provided RPM,
and I'd really, really urge setting up an internal yum mirror to
reduce wasted bandwidth and speed up the process.

ATOM RSS1 RSS2