Centos 7 Upgrade to AlmaLinux 8 Failed at stage 4 - Resolved
Any Idea on how to fix?
Issue starts by :
* 2024-05-26 09:02:11 (8501) [INFO] * Starting stage 4 of 5
* 2024-05-26 09:02:11 (8502) [INFO] *
* 2024-05-26 09:02:11 (8503) [INFO] ******************************************************************************************
* 2024-05-26 09:02:11 (8473) [INFO] Stage 4: skipping component:RpmDB:post_leapp (already run)
* 2024-05-26 09:02:11 (8473) [INFO] Stage 4: skipping restore_cpanel_services (already run)
* 2024-05-26 09:02:11 (8473) [INFO] Stage 4: skipping component:Imunify:post_leapp (already run)
* 2024-05-26 09:02:11 (8448) [DEBUG] Running 'post_leapp' from EA4 component.
* 2024-05-26 09:02:11 (8473) [INFO] Stage 4: skipping Elevate::Components::EA4::_restore_ea4_profile (already run)
* 2024-05-26 09:02:11 (8473) [INFO] Stage 4: skipping Elevate::Components::EA4::_restore_ea_addons (already run)
* 2024-05-26 09:02:11 (6499) [INFO] Running: /usr/bin/dnf -y install ea-php56 ea-php56-build ea-php56-libc-client ea-php56-pear ea-php56-php-bcmath ea-php56-php-bz2 ea-php56-php-calendar ea-php56-php-cli ea-php56-php-common ea-php56-php-curl ea-php56-php-dba ea-php56-php-devel ea-php56-php-enchant ea-php56-php-exif ea-php56-php-fileinfo ea-php56-php-fpm ea-php56-php-ftp ea-php56-php-gd ea-php56-php-gettext ea-php56-php-gmp ea-php56-php-iconv ea-php56-php-imap ea-php56-php-intl ea-php56-php-ldap ea-php56-php-litespeed ea-php56-php-mbstring ea-php56-php-mysqlnd ea-php56-php-odbc ea-php56-php-opcache ea-php56-php-pdo ea-php56-php-pgsql ea-php56-php-posix ea-php56-php-process ea-php56-php-pspell ea-php56-php-soap ea-php56-php-sockets ea-php56-php-tidy ea-php56-php-xml ea-php56-php-zip ea-php56-runtime ea-php74-php-redis ea-php80-php-redis
# -------------------------> [ERROR] # Upgrade process failed at stage=4 ; Running: tail -f /var/log/elevate-cpanel.log
* 2024-05-26 09:02:13 (6513) [INFO] Error: Unable to find a match: ea-php56 ea-php56-build ea-php56-libc-client ea-php56-pear ea-php56-php-bcmath ea-php56-php-bz2 ea-php56-php-calendar ea-php56-php-cli ea-php56-php-common ea-php56-php-curl ea-php56-php-dba ea-php56-php-devel ea-php56-php-enchant ea-php56-php-exif ea-php56-php-fileinfo ea-php56-php-fpm ea-php56-php-ftp ea-php56-php-gd ea-php56-php-gettext ea-php56-php-gmp ea-php56-php-iconv ea-php56-php-imap ea-php56-php-intl ea-php56-php-ldap ea-php56-php-litespeed ea-php56-php-mbstring ea-php56-php-mysqlnd ea-php56-php-odbc ea-php56-php-opcache ea-php56-php-pdo ea-php56-php-pgsql ea-php56-php-posix ea-php56-php-process ea-php56-php-pspell ea-php56-php-soap ea-php56-php-sockets ea-php56-php-tidy ea-php56-php-xml ea-php56-php-zip ea-php56-runtime ea-php74-php-redis ea-php80-php-redis
* 2024-05-26 09:02:13 (6530) [INFO]
-
I'd suggest opening a cPanel support ticket. In a nutshell it's trying to install PHP V5.6 and the minimum version of PHP available on Alma V8 is going to be 7.2.
1 -
Sorry, my bad, would not repeat history again.
Well, good news i got it fix and it worked, not sure if it would be the same for everyone but my solutions was to followed as mentioned in https://support.cpanel.net/hc/en-us/articles/5946421721623-How-to-upgrade-from-CentOS-7-to-AlmaLinux-8-or-CloudLinux-7-to-CloudLinux-8-with-cPanel-ELevate
To take note: i had already uninstall imunify360 and purged it before applying the above method as read online (can't recall the exact link ) , that i360 could cause issue during upgrade despite showing no blockers found.
Status on following the guide via the link mentioned above which was: [INFO] There are no known blockers to start the elevation process.
You can consider running:
/scripts/elevate-cpanel --startSo thinking all was good, i went ahead with /scripts/elevate-cpanel --start , all were good till stage 4 then again i notice the same error which lead to a particular command ( /usr/dnf -y install )
Then tracked and noticed the command ( /usr/bin/dnf -y install ) which was only found for imnuify related packages so the fix that worked for me was: i modified the elevate-cpanel script by:
removing quite a decent amount in line of codes as mentioned below and ran the /scripts/elevate-cpanel --continue , and everything went smooth, but still curious on why it was still detecing i360 as old packages to be reinstalled when it didnt even exist in the system.
So yes it worked for me, could work for someone else facing the similar situation as i did.
line 45: $INC{'Elevate/Components/Imunify.pm'} = 'script/elevate-cpanel.PL.static'; ]
from line 3519: # --- BEGIN lib/Elevate/Components/Imunify.pm
till line 3797: # --- END lib/Elevate/Components/Imunify.pm , covering the whole section of imunify0 -
It means the Inmunify-360 could block the elevation process?. Do you recommend uninstall it?
Please, some CPanel member can confirm this point?.
I have not read this in the guide: https://cpanel.github.io/elevate/blockers/
0 -
Mise - can you get me more details on where you're seeing that error?
0 -
no error yet. I ask because I should do the elevation process in coming weeks, and I have Inmunify360 installed.
Is it better uninstalling I360 before the elevation?.
0 -
I'm not aware of any issues with Imunify at this time. We say the following on our blockers page at https://cpanel.github.io/elevate/blockers/
If you have installed Imunify 360, it can provide hardened PHP for versions 5.1 through 7.1 on AlmaLinux 8 as well as CentOS 7. We now detect these hardened PHP versions and allow an elevation with them to proceed.
0 -
Hi Team,
Back with another problem on another server, would be great if can advise the fix: same stuck at stage 4
(6590) [INFO] Running: /usr/bin/dnf -y install ea-php81-php-redis
(6591) [INFO]
(6604) [INFO] Last metadata expiration check: 0:14:05 ago on Sat Jun 15 02:52:27 2024.
(6604) [INFO] No match for argument: ea-php81-php-redis
(6604) [INFO] Error: Unable to find a match: ea-php81-php-redis
(6621) [INFO]
(6512) [INFO] Sending notification: Failed to update to AlmaLinux 80 -
Any idea on how to bypass this and continue
0 -
just to share more in-depth, we have restored the server with our image backup and checked thoroughly and we confirm we had not installed the php extension stated below furthermore, we are only using the cpanel default profile in EA4, so how come the elevate script is prompting for this particular extension to be installed for no reason ??
ea-php81-php-redis
0 -
same stuck, caused by ea-php74-php-redis.
no issue at elevation checking proses
can we doing something to skip the missing package?0 -
Well, now everything seems messed up:
EA4 doesn't seem to save the changes and now seem to have no PHP & apache at allUnable to open log file “/usr/local/apache/logs/error_log” - No such file or directory at /usr/local/cpanel/Cpanel/HttpUtils/ApRestart.pm line 300.
0 -
Well, I managed to fix the Apache and now all seems to work but still on C7.9, so I went to EA4 and selected default Cpanel profile and saved the profile and tried 1 more time to to run the elevate --check, no blockers , so i started the elevate --start, and again on the same issue but noticed --target-os=CentOS_8 , instead of --target-os=AlmaLinux_8, not sure if that is a cause but the issue still remains, seriously need some advice on why this is happening when we have not used redis for anything and not found in any of our servers ??
(6590) [INFO] Running: /usr/bin/dnf -y install ea-php81-php-redis
(6591) [INFO]
(6604) [INFO] Last metadata expiration check: 0:14:05 ago on Sat Jun 15 02:52:27 2024.
(6604) [INFO] No match for argument: ea-php81-php-redis
(6604) [INFO] Error: Unable to find a match: ea-php81-php-redis
(6621) [INFO]
(6512) [INFO] Sending notification: Failed to update to AlmaLinux 8* 2024-06-15 11:15:23 [INFO] Checking EasyApache profile compatibility with AlmaLinux 8.
* 2024-06-15 11:15:23 [INFO] Running: /usr/local/bin/ea_current_to_profile --target-os=CentOS_8 --output=/tmp/17XDN5X9_g/ea_profile.json
* 2024-06-15 11:15:24 [INFO] Backed up EA4 profile to /tmp/17XDN5X9_g/ea_profile.json
* 2024-06-15 11:15:26 [INFO] There are no known blockers to start the elevation process.0 -
Care to shed some light on this, please?
0 -
Hi Mise
To reply your question on is it better uninstalling I360 before the elevation? Ans: it's very safe to have it running while performing the elevation.
Actually my issue was due to unsupported PHP that was installed via EA4 , so I believe the elevate script checked and try to reinstall the same thinking it's from the harden PHP which it isn't, so in short you can run your elevation with i360 unless you have outdated PHP installed via EA4, then you might face the same fate as mine, which I learnt the hard way.
Hope this clears your doubt!
0 -
yes, very useful reading. Also I have deprecated PHP versions. Thanks!
0 -
Update:
To resolve this, I provisioned a new EA4 profile without PHP 8.1 and also noted the following code in the elevate file as shown belowSuspecting that the problem was related to Hardened PHP, I removed it and then ran
elevate --start. The upgrade process went smoothly after these changes.Solution Summary:
- Create a New EA4 Profile: Exclude the problematic PHP version (in this case, PHP 8.1).
- Remove Hardened PHP from Imunify360: This step may help if the upgrade fails due to PHP issues.
This workaround resolved my issue, and it might be useful for others experiencing similar problems.
"ea4_imunify_packages": [ "ea-php81-php-redis" ]
0
Please sign in to leave a comment.
Comments
17 comments