Skip to main content

Elevate AlmaLinux 8.10 to 9.x

celiac101

I attempted an ELevate upgrade from AlmaLinux 8.10 to AlmaLinux 9 on a cPanel server. The pre-check reported no known blockers, but the upgrade failed during stage 4.

The server has been recovered and is currently running normally again on AlmaLinux 8.10. I restored the default boot entry back to the normal AlmaLinux 8 kernel, restarted/re-enabled MariaDB, restored EasyApache/Apache, reloaded my EA4/PHP setup, restored CSF/LFD, and the site is back online.

Current recovered state:

OS: AlmaLinux 8.10
Kernel: 4.18.0-553.124.1.el8_10.x86_64
Default boot kernel: /boot/vmlinuz-4.18.0-553.124.1.el8_10.x86_64
MariaDB: 10.11.16, enabled and active; mysqladmin ping returns "mysqld is alive"
Apache: running
cPanel/WHM cpsrvd: running
Main site: back online and returning HTTP 200

The ELevate failure showed messages like:

"The command 'leapp upgrade' did not complete successfully."

"The elevation process failed during stage 4."

"The LEAPP upgrade process did not succeed."

After trying the suggested continue step, it still reported:

"Server is currently running AlmaLinux 8 after distro upgrade."

"Upgrade to AlmaLinux 9 did not succeed."

The Leapp logs also showed these boot/kernel-related messages:

"Error in POSTTRANS scriptlet in rpm package kernel-core"

"warning: %posttrans(kernel-core-5.14.0-611.54.3.el9.x86_64) scriptlet failed, exit status 2"

"Command ['/usr/sbin/grubby', '--remove-kernel', '/boot/vmlinuz-upgrade.x86_64'] failed with exit code 1"

"Could not remove /boot/vmlinuz-upgrade.x86_64 entry. May be ignored if the entry did not exist."

At one point the default boot entry had been changed to:

/boot/vmlinuz-upgrade.x86_64
ELevate-Upgrade-Initramfs

I manually set it back to the normal AlmaLinux 8 kernel after the failure.

One thing that concerns me is that the Leapp transaction output appeared to list important MariaDB packages under "Removing dependent packages," including:

MariaDB-compat
MariaDB-server

The Leapp report also flagged the MariaDB packages as third-party/non-distribution-signed packages.

This server is currently using MariaDB 10.11.16. I believe I may have upgraded to MariaDB 10.11 manually before cPanel officially included/defaulted to that version, so I am wondering if my MariaDB installation may not be in the expected cPanel-managed state for ELevate.

After the failed attempt, MariaDB was disabled/stopped, and Apache/EasyApache appeared partially removed or damaged. I had to restore the EA4 repo and reinstall/restore Apache/PHP pieces before the site would work again.

My questions:

  1. Is it expected/safe for Leapp/ELevate to show MariaDB-server and MariaDB-compat under "Removing dependent packages" during an AlmaLinux 8 to 9 upgrade on a cPanel server using MariaDB 10.11?

  2. Could my manually upgraded MariaDB 10.11 install be the reason ELevate failed or tried to remove MariaDB packages?

  3. Is the kernel-core/grubby/posttrans error likely the real blocker, or is it a secondary symptom?

  4. What steps should I take before attempting ELevate again?

Relevant logs available:

/var/log/elevate-cpanel.log
/var/log/leapp/leapp-upgrade.log
/var/log/leapp/leapp-report.txt
/var/log/leapp/leapp-report.json

I have not continued the ELevate process and have left the server recovered on AlmaLinux 8.10 for now.

Comments

14 comments

Date Votes
  • celiac101

    PS - I upgraded this same server from Centos 7 to AlmaLinux 8 a while back and did not have any MariaDB issues.

    0
  • celiac101

    I had AI review those logs, and here is the output:

    Update: I reviewed the leapp-upgrade.log, and the clearest failure appears to be the EL9 kernel-core post-transaction scriptlet during the upgrade initramfs phase, not MariaDB as the proven primary cause.

    The key error was:

    cp: cannot stat '/lib/modules/5.14.0-611.54.3.el9_7.x86_64/bls.conf': No such file or directory

    followed by:

    Error in POSTTRANS scriptlet in rpm package kernel-core

    and:

    warning: %posttrans(kernel-core-5.14.0-611.54.3.el9_7.x86_64) scriptlet failed, exit status 2

    This occurred during Leapp’s upgrade_initramfs_generator step. Later, the DNF transaction check/test appears to have succeeded, and the ELevate upgrade boot entry was created, but after the reboot into stage 4, the upgrade did not complete and the system remained on AlmaLinux 8.

    I am still concerned that the transaction plan showed MariaDB-server and MariaDB-compat under packages to be removed, but based on the deeper log, the apparent hard failure seems to be the kernel-core / missing bls.conf / upgrade initramfs issue.

    Could cPanel confirm whether this kernel-core posttrans bls.conf failure is a known ELevate/Leapp issue, and whether the MariaDB removals are expected/safe on a cPanel server running MariaDB 10.11?

    0
  • William Del Piero cPanel Staff

    Hi,

     

    It is normal to see MySQL/MariaDB packages removed and re-installed when running ELevate. Since MariaDB 10.11 is supported by cPanel/WHM, having this version installed prior to ELevate shouldn't cause problems during the upgrade. Since you indicated the MariaDB upgrade was manual, I recommend ensuring that the mysql-version inside /var/cpanel/cpanel.config matches the installed version (10.11). This will help to ensure cPanel correctly recognizes the currently-installed MariaDB version.

     

    Regarding the kernel-core/bls.conf errors, I did not see any trend in recent tickets regarding ELevate failing due to this. Did the /var/log/elevate-cpanel.log mention any reasons near the end as to why the upgrade failed during stage 4?

    Lastly, I wanted to mention having snapshot backups available can be very useful during the ELevate process since stage 4 failures can often leave multiple services down. Being able to restore back to a clean snapshot can minimize downtime and help prevent further failures in the upgrade process due to a partially failed upgrade.

     

    0
  • celiac101

    Thank you. I checked /var/cpanel/cpanel.config and will make sure mysql-version matches the installed MariaDB version, 10.11, before any future attempt.

    The end of /var/log/elevate-cpanel.log was not very specific. It mainly reported:

    "The command 'leapp upgrade' did not complete successfully"
    "The elevation process failed during stage 4"
    "The LEAPP upgrade process did not succeed"

    The more specific error I found was in /var/log/leapp/leapp-upgrade.log during the upgrade initramfs/kernel stage:

    cp: cannot stat '/lib/modules/5.14.0-611.54.3.el9_7.x86_64/bls.conf': No such file or directory
    Error in POSTTRANS scriptlet in rpm package kernel-core
    warning: %posttrans(kernel-core-5.14.0-611.54.3.el9_7.x86_64) scriptlet failed, exit status 2

    The DNF transaction check/test appeared to succeed later, and the ELevate upgrade boot entry was created, but after rebooting into stage 4 the upgrade did not complete and the server remained on AlmaLinux 8.

    After the failed attempt, several services/packages needed manual recovery: MariaDB was stopped/disabled, Apache/EasyApache was partially missing, the EA4 repo had to be restored, and Apache/PHP had to be re-provisioned. The server is now stable again on AlmaLinux 8.10.

    Could you please advise what would cause the EL9 kernel-core posttrans scriptlet to fail because bls.conf was missing, and what corrective steps should be taken before attempting ELevate again?

    Also, even though you noted MariaDB removal/reinstall can be normal, could you confirm whether seeing MariaDB-server and MariaDB-compat listed under "Removing dependent packages" is expected for a cPanel-managed MariaDB 10.11 install?

    I understand the recommendation about snapshots. This is a dedicated server without an easy instant snapshot option, so I am trying to identify and correct the cause before considering another attempt.

    0
  • celiac101

    Any advice on how I can successfully run Elevate again would be highly appreciated!

    0
  • William Del Piero cPanel Staff

    Hi,

     

    Seeing MariaDB-server and MariaDB-compat being removed is expected during ELevate since those packages are removed then new MySQL/MariaDB packages are installed during the next steps when the process is able to complete. Since the ELevate process isn't progressing past stage 4, it can prevent the new packages from being installed which can lead to failed services afterward.

     

    Regarding the error you reported, we don't have any other reports of a similar error so this could be caused by something specific to your environment. In situations like this, having access to the server can be critical to diagnose the cause of failure. I'd recommend opening a ticket so the issue can be investigated with direct server access.

    0
  • celiac101

    0
  • cPRex Jurassic Moderator

    celiac101 - that would indicate your hosting provider would be your contact for the support ticket and not cPanel directly.  If they aren't able to resolve the issues for you they would escalate the problem to us.

    0
  • celiac101

    Since I am paying you a licensing fee for cPanel, which is now quite expensive, your answer is totally unsatisfactory.

    0
  • cPRex Jurassic Moderator

    I do have some more details about the licensing and support outlined here:

    https://support.cpanel.net/hc/en-us/community/posts/35919412082327-Confusion-around-Partner-Support-licenses-and-contacting-cPanel-support

    but the license provider is always the contact for support issues.

    0
  • celiac101

    The utter stupidity of cPanel's position on this, based on the fact that those who rent self hosted severs won't touch those servers so cannot and will not provide any such support for those severs--but if cPanel actually believes that their approach will drive paying customers like me to them, they are sadly mistaken. 

    0
  • cPRex Jurassic Moderator

    This isn't a recent change to the licensing model.  If your host is refusing to provider you with support, it might be time to look for a different host.  

    0
  • celiac101

    They are doing exactly what their contract with me says--providing me a server. Our agreement has not changed, and I've hosted with them for nearly 15 years. They are happy to migrate me to a new server, or load AlmaLinux 9 on my current server's disk, then let me handle things from there--it's a standard self hosting contract and you know that this is exactly how such contracts work.

    The cPanel license money I pay them goes directly to cPanel, and I have a license just like someone who bought that license directly from cPanel. It is cPanel who has the issue here, not my host. cPanel refuses to provide me, the customer, with support.

    Why would you try to put this on a server hosting company who rents UNMANAGED servers, and why would cPanel make me have to try to go through them to get support, thus creating a bizarre go between where the server hosting company has no business being caught in the middle?

    0
  • cPRex Jurassic Moderator

    celiac101 - I don't believe either of us our going to change each others minds here, so I'm just going to lock this thread now.

    0

Post is closed for comments.

Didn't find what you were looking for?

New post