Issue during update from katello 3.16.0 to katello-3.16.1

Support
1

I have updated on CentOS 7. When I ran foreman-installer it failed with error. The installer logs shows:

[ERROR 2020-10-07T06:46:32 main] Errors encountered during run:
[ERROR 2020-10-07T06:46:32 main] foreman-maintain packages is-locked --assumeyes failed! Check the output for error!
[ERROR 2020-10-07T06:46:32 main]  /Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[foreman.example.com]: Could not evaluate: Proxy foreman.example.com cannot be retrieved: unknown erro
r (response 500)
[ERROR 2020-10-07T06:46:32 main] /usr/share/foreman-installer/modules/foreman/lib/puppet/provider/foreman_smartproxy/rest_v3.rb:7:in `proxy'
[ERROR 2020-10-07T06:46:32 main] /usr/share/foreman-installer/modules/foreman/lib/puppet/provider/foreman_smartproxy/rest_v3.rb:13:in `id'
[ERROR 2020-10-07T06:46:32 main] /usr/share/foreman-installer/modules/foreman/lib/puppet/provider/foreman_smartproxy/rest_v3.rb:17:in `exists?'
[ERROR 2020-10-07T06:46:32 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/property/ensure.rb:82:in `retrieve'

Verified the issue twice. I then restarted with foreman-maintain service restart and tried again and this time it worked. Everything seems to be working now. Do I have to worry?

2

I had the same error updating from 3.16.0 to 3.16.1 (tried twice to run foreman-installer). Doing a foreman-maintain service restart before like you mentioned allowed the update to finish without error.

3

FYI I had this exact same issue upgradring from 3.16 to 3.17.

The formeman-maintain service restart did the trick just like the posts above for earlier versions…

4

I have the same issue upgrading from 3.15 to either 3.16 or 3.17.
Restarting the Foreman suite does not work, because if you do that after you installed the newer version, and try to do say do a yum update, you get an error that foreman needs a db migrate first.
Foreman installer runs a bunch of puppet stuff and it does try to install things using yum, so then things will be broken, in my case while KT services are down.

How I get around it, is to identify what it wants to install, and then I do a yum install after installing the newer version repos, but before running the foreman-installer.
Which is how I was able to upgrade from 3.13 to 3.15.

I guess in my case, my Katello server is not registered with RH CDN or subscriptions website, it is standalone (registered with itself), and any package required via the RH repos, during the install, has to be pre-installed, while KT is up, otherwise, all the RH repos will be unavail.
Non-RH repos set up in yum, like epel, foreman, katello repos are ok, while KT is down.
My KT server has the RH subs in candlepin, and while Katello is running, it can download/sync with the CDN RH repos.

Foreman-installer in 3.16 and 3.17 is trying to do something fancy with a new yum plugin to lock packages, and that part is broken in the installer.
My issue is specifically here, which was fixed in foreman 2.3
https://projects.theforeman.org/issues/31135

But how am I supposed to upgrade to from 3.15 to 3.17 say if the installer is broken?
Can I instead of installing the foreman 2.2 repo, which Katello 3.17 use, install foreman 2.3 which has the fix in for the broken installer, and then upgrade to Katello 3.17?
The fix has not been backported to either katello 3.16 nor 3.17 so I can remain within the 2 version supported upgrade path, and I did not want to upgrade foreman to a higher version, which was not tested with a lower version of KT.
Ultimately I am ok stopping for now on KT 3.17 or 3.18.

I guess other way might be for me to temporarily register the Katello server with RH website direct and see if that solves my problems with the installer.

5

I didn’t suggest to restart after yum update and but before installer, but after the installer run because foreman-installer at that time did not always restart everything which was supposed to be started by installer. By now, I actually stop services before the installer run and let installer start everything back up again after is has been correctly configured.

From what you write it’s unclear to me if you were able to do this now for your installer run on 3.16.

Well, that is obviously always a problem and you need to take some precautions to handle this situation. If you have licenses available at redhat I think the easiest way to go about this would be to point the server to redhat for the upgrade at least during the installer run.

I would be careful to jump to conclusions. If I remember correctly, there were a couple of times when this packages is-locked error occured. It doesn’t have to be exactly this issue. And you don’t post the exact errors you have thus it’s impossible to tell the difference… I would recommend to post the necessary installer and production error logs in your other new topic you have started to find out if it is really exactly that issue you are running into or something else…