On Tue, Jul 10, 2018 at 3:46 PM, Mark Stodola <[log in to unmask]> wrote:
> On 07/10/2018 02:58 PM, Mark Stodola wrote:
>> Do you have yum-conf-sl7x installed?

I do. I did find that on the SL FAQ page earlier. (
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.scientificlinux.org_documentation_faq_faq-2Dreleases_-23update-2Dlatest-2Drelease&d=DwIBaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=AVyza5gjVLj4FbiNcJFK3BBrXQF80QXNAdnC7uIYRIY&s=IQWUhCyOWbIhHkBj1gMUG0rrxrPb9mkC8n_AXf_JWKk&e=
)

>> What are the contents of:
>> /etc/yum/vars/releasever

7

>> /etc/yum/vars/slreleasever

7.3

>>
>> The newer kernels are generally available at each release version via the
>> sl-security repo, so it is not a good measure.

Ah, that's good to know. I had just assumed that the system always
tried to upgrade in sync.

> I forgot to provide a fix/solution for you...
>
> If you do not have yum-conf-sl7x install it.
> If it is installed, do a 'yum reinstall yum-conf-sl7x'.

This  reinstall seems to have been the fix. I had to spread checking
and updating/rebooting across two maintenance windows, but this is the
only actual change I made that hadn't been done before. After this I
did a 'yum clean all' and 'rm -rf /var/cache/yum' before another run
of 'yum check-update'. That time it found a list of 269 packages to be
updated and brought the system up to 7.5 when they were installed.

> yum-conf-sl7x and sl-release.  There is an rpm trigger to (hopefully) handle
> this gracefully.  See /var/libexec/sl-release/set-release.sh.

I didn't find that script on the system, or even that path. Some
poking with find and I came up with
/usr/libexec/sl-release/set-slrelease.sh which looks to do what you
describe.

Thank you very much for the help! I now have a fully updated and
patched server again.