[UPS-421] MySQL 5.7.36 -> 5.7.37 upgrade failed due to GPG keys, causing upcp/rpmup failure warning email
Received an email that upcp had an issue on a number of servers due to rpmup failing, after running this manually it's due to the mysql 5.7.36 -> 5.7.37 upgrade failing, errors below:
warning: /var/cache/yum/x86_64/7/mysql57-community/packages/mysql-community-libs-compat-5.7.37-1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 3a79bd29: NOKEY
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql
The GPG keys listed for the "MySQL 5.7 Community Server" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.
Failing package is: mysql-community-libs-compat-5.7.37-1.el7.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql
I'd imagine this will be a pretty widespread issue so any comment appreciated.
-
Seeing the same here on DNSONLY servers. Not seeing the issue on CloudLinux enabled servers at this stage when running /usr/local/cpanel/scripts/rpmup 0 -
Hi There, Same issue here. Around 6 servers affected. 0 -
Failing package is: mysql-community-libs-compat-5.7.37-1.el7.x86_64 GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql I'd imagine this will be a pretty widespread issue so any comment appreciated.
I had the same problem with two DNS-ONLY servers. I edited the /etd/yum.repos.d/Mysql57.repo file and changed all the "gpgcheck=1" lines to "gpgcheck=0" Then I executed yum update Then I edited the /etd/yum.repos.d/Mysql57.repo file and changed all the "gpgcheck=0" lines back to "gpgcheck=1" Finally, I updated the cPanel software. Jim0 -
I had the same problem with two DNS-ONLY servers. I edited the /etd/yum.repos.d/Mysql57.repo file and changed all the "gpgcheck=1" lines to "gpgcheck=0" Then I executed yum update Then I edited the /etd/yum.repos.d/Mysql57.repo file and changed all the "gpgcheck=0" lines back to "gpgcheck=1" Finally, I updated the cPanel software. Jim
I would not do that unless you personally know that is valid package and not a compromised drop in. This may be just a simple omission but signing keys are there for a reason.0 -
Same issue on CloudLinux v7.9.0. 0 -
I've also tried [CODE=bash]cp /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql{,.bak} wget -O /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql https://repo.mysql.com/RPM-GPG-KEY-mysql rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql /usr/local/cpanel/scripts/rpmup
But it didn't solve the issue. Moreover after noticing the huge filesize different between the original and the just downloaded GPG key I did moved the original key back. [CODE=bash]mv /etc/pki/rpm-gpg/RPM-GPG-KEY-{mysql.bak,mysql} rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql0 -
The GPG keys for the new release has been changed. See this for further info: Once adjusted, run the update once more: /usr/local/cpanel/scripts/upcp For new installations you can import the key before running the installer: rpm --import | apt-key add - ------------- 0 -
I'd hope this will be something that cPanel push out as part of the update cycle rather than requiring every customer to do. 0 -
Not sure if it was updated, but the support article says there is an auto-fixer, so it "should" correct itself tonight or tomorrow night. 0 -
Not sure if it was updated, but the support article says there is an auto-fixer, so it "should" correct itself tonight or tomorrow night.
Yep that's an update as it didn't say that earlier today, I have just tested the manual method running /scripts/autorepair mysql_gpg_key then an rpmup on a dev system and it's worked without issue so assuming it does fire correctly it should resolve the issue. Actually further to that I've ran a upcp on an affected system and that has correctly completed without any manual intervention required so it appears it should auto-resolve once nightly upcp runs so should be solved.0 -
Hello! The GPG keys for the official MySQL repository have expired preventing installation or update of MySQL packages. Andrew provided the correct article with the autofixer script. We are keeping track in UPS-421 and I will update this thread once resolved. 0 -
Hello @cPanelAnthony, every time the autorepair command (UPS-423) is run, "-2022" string is added to the repo files. You must have forgotten to write a control for it. 0 -
Further to previous update unfortunately this doesn't appear to have resolved the issue via automatic nightly upcp's, not sure if it's due to timeouts being hit but on servers notably with more packages to update the automatic upcp has continued to fail, however manually running an rpmup has resolved for failing servers. 0 -
Hi, automatic upcp still shows failure as of 6 hours ago. Fortunately manually running /usr/local/cpanel/scripts/upcp resolved this issue. 0 -
Hello I am having this same issue, can someone please point me in the right direction and tell me where to find /scripts/autorepair mysql_gpg_key to slove this problem 0 -
This issue is solved for me, the update worked last night. 0 -
The GPG keys for the new release has been changed. See this for further info: Once adjusted, run the update once more: /usr/local/cpanel/scripts/upcp For new installations you can import the key before running the installer: rpm --import | apt-key add - -------------
HUGE thank you for this!0 -
So only solved one of my problems. I am installing WHM from Marketplace and did it twice now and still the same error. Update from within WHM: [2022-02-03 16:48:41 +0000] E The install encountered a fatal error: (XID fvg83b) The system failed to determine the "mysqld" version. => Log closed Thu Feb 3 16:48:41 2022 [2022-02-03 16:48:41 +0000] E Running `/usr/local/cpanel/scripts/updatenow --upcp --log=/var/cpanel/updatelogs/update.4218.113619.1643905781.log` failed, exited with code 2 (signal = 0) => Log closed Thu Feb 3 16:48:41 20220 -
Can you let me know which vendor that installation was attempted on? 0
Please sign in to leave a comment.
Comments
21 comments