On Tue, Jul 10, 2018 at 3:46 PM, Mark Stodola <stod...@pelletron.com> 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.