plesk / centos2alma

CentOS 7 to AlmaLinux 8 conversion tool
Apache License 2.0
36 stars 7 forks source link

centos7-els seems to cause failed upgrade #294

Open farisc1 opened 5 days ago

farisc1 commented 5 days ago

I just tried 1.3.2 on a system that had been updated to Plesk .62 with the Plesk ELS repos enabled and all updates, including those from the ELS repo, installed. I was happy to do so because the changelog mentions that Plesk ELS repos and now dealt with.

All went well until somewhere close to the last hurdle, at "Do: adopting repositories" when serious conflicts occurred because those repos were seemingly not disabled, and the script aborted. [Or maybe the disabling of the repos wasn't supposed to happen just yet, and the problem was actually caused by the fact that dnf could not download repomod.xml from any of them for some reason (see log)?]

e.g.

INFO - Problem 1: cannot install the best update candidate for package bind-32:9.11.36-14.el8_10.x86_64
INFO - - nothing provides policycoreutils-python needed by bind-33:9.11.4-26.P2.el7_9.15.tuxcare.els1.x86_64 from centos7-els
INFO - - nothing provides python-ply needed by bind-33:9.11.4-26.P2.el7_9.15.tuxcare.els1.x86_64 from centos7-els

The full feedback file is attached, but essentially at this stage the main things that go wrong can be seen in failure-log.txt

There are also issues shown in the log with icinga and grafana packages which are nothing to do with Plesk, but although those are my fault for not thinking about them, I don't think they are the direct cause of the failure - but of course I could be wrong.

At the point things failed, several repos relating to Centos 7 were still there and still enabled, despite the fact that we seem to be running Alma 8 and all the alma repos seem to be installed and enabled: centos7-els.repo centos7-els-rollout.repo CentOS-SCLo-scl.repo CentOS-SCLo-scl-rh.repo

I wasn't aware of those "scl" repos before I started the upgrade. I don't mean that they got added during the upgrade, I mean I didn't think to look to see what might be there and didn't take them into account before I started.

Anyway, I've restored from backup and all is well, but we are back on C7, obviously.

failure-log.txt

centos2alma_feedback.zip

farisc1 commented 4 days ago

I have repeated this with a "clean" Centos 7 system with Plesk ELS but with no icinga/grafana and no Centos-SCLo. Just the normal, expected repos and nothing extra.

Unfortunately I got the same result - upgrade failure due to conflicts (e.g. bind) when adapting repos.

Here's the feedback file for that one:

centos2alma_feedback2.zip

farisc1 commented 4 days ago

And finally....

I repeated the upgrade again on the second ("clean") system that had Plesk ELS, but this time I deleted the centos7-els.repo and centos7-els-rollout.repo before running centos2alma.

Now all went well, and the upgrade completed as expected.

Some oddities I noticed were:

The "screen" utility had been removed and not reinstalled.

The following el7 packages remained:

btrfs-progs.x86_64                          4.9.1-1.el7                                   @System
els-define.x86_64                           1-1.0.4.el7                                   @System
kernel.x86_64                               3.10.0-1160.118.1.el7                         @System
kernel.x86_64                               3.10.0-1160.119.1.el7                         @System
libdb4.x86_64                               4.8.30-13.el7                                 @System
yum-plugin-fastestmirror.noarch             1.1.31-54.el7_8  

els-define is part of the Plesk els thing. It says it is "CentOS Server els-release file".

I'm not sure why it left btrfs-progs, libdb4 or yum-plugin-fastestmirror.

I've removed fastestmirror and els-define, but I'm not sure about the libdb4 or btrfsprogs. They don't seem to have dependencies but maybe there was a reason for them to have remained.

Anyway, in conclusion, it would appear that 1.3.2 does not correctly handle systems with Plesk ELS installed, at least on the two systems I've now tried it on.

I'm not sure if it also can't handle systems with Centos-SClo repos either, but I've not tested that properly.

The workaround for ELS is to delete the centos7-els.repo and centos7-els-rollout.repo before running centos2linux, then removing the els-define package after the upgrade is complete.

With increasing numbers of people in panic mode, and with Plesk ELS being auto-installed on a lot of systems from now on, I strongly hope that this/these issue will get resolved quickly.

vizovitin commented 3 days ago

We've made some configuration changes on our service endpoints. So now the same 1.3.2 script version should work correctly.

However, there is a prerequisite:

  1. either wait for 1 day before trying to run the script;
  2. or run plesk daily UpgradeExtensions manually on the server before running the script.

In both cases you should see "TuxCare Extended Lifecycle Support" (tuxcare-els) in your Plesk extensions list as a result. Once you do, it should be safe to convert to AlmaLinux 8.

Please notify us if this helps you. Sorry for the previous inconvenience.

farisc1 commented 3 days ago

That's very good news. Thank you. I will give it a day or so and see if it appears.

vizovitin commented 1 day ago

@farisc1 , did you have a chance to check this?

farisc1 commented 7 hours ago

In progress right now.....

farisc1 commented 4 hours ago

OK. It does now work perfectly. Thank you.

Starting point: Centos 7, Plesk .62 Update 1, Plesk ELS installed, Plesk ELS showing in My Extensions, all OS and Plesk packages up to date, centos7 yum repo files changed to vault instead of mirror, mariadb 10.5 yum repo exists and enabled. epel (7) repo exists and enabled.

Stage 1: 9 mins Then about 27 minutes for the rest to complete to the point of final reboot and everything working as it was before, except that we are now on Alma 8.

After final reboot, there is still /root/tmp_leapp_py3/leapp3 left over.

The following el7 packages remain:

btrfs-progs.x86_64 4.9.1-1.el7 @System kernel.x86_64 3.10.0-1160.118.1.el7 @System kernel.x86_64 3.10.0-1160.119.1.el7 @System libdb4.x86_64 4.8.30-13.el7 @System yum-plugin-fastestmirror.noarch 1.1.31-54.el7_8 @System

"screen" utility is removed for some reason.

MOTD is shown twice when logging via ssh but not via console. I think one of the duplications comes from .plesk_banner which seems to be a new thing?

Speaking of MOTD, I think maybe it would be useful for MOTD tell you to install the NTP Timesync extension.

Everything in /etc/yum.repos.d/ seems to have been dealt with correctly.

I can't find the leapp logs that were referred to by the script during the upgrade process. I was looking for what it thought were the el7 packages left over, which was mentioned as being written to a leapp logfile that I can't seem to find at all.

But overall, we are now at a 100% success to all intents and purposes. Thank you for your excellent work. I hope no new issues appear in the next few days, as we have a full update of a live system to do late on the 9th/early on the 10th (UTC).

PLEASE start work on CloudLinux 8 to CloudLinux 9 next :-) Yes, 8 to 9.