SCIENTIFIC-LINUX-USERS Archives

October 2017

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, 3 Oct 2017 12:35:24 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (59 lines)
On Tue, Oct 3, 2017 at 9:03 AM, Vladimir Mosgalin
<[log in to unmask]> wrote:
> Hi Takashi ichihara!
>
>  On 2017.10.03 at 11:28:46 +0900, Takashi ichihara wrote next:
>
>> We have several SL7.3 nodes installed with yum-conf-sl7x.
>> Today I noticed that some of them cannot be updated
>> from SL7.3 to SL7.4 by the foll wing simple steps.
>>
>> # yum clean all
>> # yum yum install.
>>
>> With several trials, I noticed that following procedure
>> works fine to update from SL7.3 to SL7.4.
>>
>> # yum remove yum-conf-sl7x
>> # yum install yum-conf-sl7x
>> # yum clean all
>> # yum update
>
> Systems that couldn't be upgrade were probably release-locked to 7.3.
> You can check it by doing
> $ cat /etc/yum/vars/slreleasever
> 7.3
>
> If it says 7.3 there - it's release-locked. Just do
> # echo 7.4 > /etc/yum/vars/slreleasever
>
> and next "yum update" will update the version (and will be locked to it). Or you can do
> # echo 7x > /etc/yum/vars/slreleasever
>
> and you will have unlocked version that will get all next releases
> automatically as well. Which is what reinstalling yum-conf-sl7x actually
> does, because it ships with "7x" in that "/etc/yum/vars/slreleasever".
>
> But yum-conf-sl7x package is designed such way so it won't release lock
> on systems where it was activated. In other words, if "7.3" was manually
> written to that file before, update of that package won't put "7x"
> there. But removing and installing package anew effectively defeats that
> logic.
>
> Release lock is designed so that some random systems won't upgrade
> overnight without your actions. However, given that most serious updates from 7.4
> like glibc or kernel arrive as security updates for 7.3 in a big pack
> anyway, I can't say that it's terribly useful.

There are many ways around this. If you're manually locking your
release, yes, you get what asked to get: a lockdown of your base OS
and update repositories, one that you'lll have to release.

Other issues include confusion with sl7x or third party repositories,
such as EPEL, that may not have every possible upgrade configuration
locked down. It's often helpful to get the "yum check-update" list of
packages, and try updating only one or two packages at a time when
confusion occurs. It can help isolate the problem and figure out which
upgrades are interlocking badly, or if an obsolete package dependency
needs to be deleted or worked around.

ATOM RSS1 RSS2