Skip to main content

Elevate AlmaLinux 8.10 to 9.x - Continued

Answered
celiac101

I'm continuing with this closed thread:
https://support.cpanel.net/hc/en-us/community/posts/40500502888087-Elevate-AlmaLinux-8-10-to-9-x

H have one question with regard to AI advice on it:

Is removing dracut-config-rescue on AlmaLinux 8 before ELevate a supported workaround for an EL9 kernel-core %posttrans failure involving missing bls.conf, or would that risk leaving the system without proper rescue kernel handling?

Comments

11 comments

Date Votes
  • cPRex Jurassic Moderator

    Hey hey!  I don't think so - dracut-config-rescue allows the system to automatically generate a rescue kernel and initramfs image during a kernel update.  So, while booting into rescue mode may be more complicated or may not have the latest tools available, I wouldn't expect it to completely not exist if that need arose.

    grubby --info ALL | grep rescue

    or

    ls -l /boot/*rescue*

    should show if you have a rescue kernel in place.

    0
  • celiac101

    Thanks. I checked, and I do have dracut-config-rescue installed and a rescue entry present:

    dracut-config-rescue-049-244.git20260529.el8_10.x86_64

    grubby --info=ALL | grep -i rescue shows:

    • kernel="/boot/vmlinuz-0-rescue-eb12798b7ab043259603e60aaf1d381a"
    • initrd="/boot/initramfs-0-rescue-eb12798b7ab043259603e60aaf1d381a.img"
    • title="AlmaLinux (0-rescue-eb12798b7ab043259603e60aaf1d381a) 8.9 (Midnight Oncilla)"

    The files are:

    • /boot/initramfs-0-rescue-eb12798b7ab043259603e60aaf1d381a.img — 46M, dated Oct 17 2018
    • /boot/vmlinuz-0-rescue-eb12798b7ab043259603e60aaf1d381a — 5.7M, dated Oct 17 2018
    • /boot/loader/entries/eb12798b7ab043259603e60aaf1d381a-0-rescue.conf — dated May 17 2024

    So a rescue entry exists, but it appears stale compared with the current AlmaLinux 8.10 system/kernel.

    Given that my ELevate failure happened during the EL9 kernel-core %posttrans step with:

    • 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

    would it be safer to regenerate the current AlmaLinux 8 rescue kernel/initramfs/BLS entry before attempting ELevate again, rather than removing dracut-config-rescue?

    If so, is there a cPanel-safe or AlmaLinux-safe command sequence to regenerate the rescue entry cleanly on AlmaLinux 8.10 before retrying ELevate?

    0
  • cPRex Jurassic Moderator

    Yes, if that was me I'd like to get a newer backup just in case.

    Since we don't handle the kernel or backup on our end I don't have a specific command you can run.  These steps certainly look good, although I didn't personally test them: https://oneuptime.com/blog/post/2026-03-04-create-minimal-rescue-image-dracut-rhel-9/view

    0
  • celiac101

    Thanks. I regenerated the rescue image for the current AlmaLinux 8.10 kernel, removed the stale old rescue files, and cleaned /boot.

    Current status:

    - Current/default kernel: 4.18.0-553.139.1.el8_10.x86_64
    - One fallback kernel remains: 4.18.0-553.137.1.el8_10.x86_64
    - Fresh rescue image now exists
    - /boot is now about 60% used with about 184M free
    - MariaDB/cPanel tracking shows mysql-version=10.11 and MariaDB 10.11 is running

    Given that the previous ELevate failure was:

    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

    is there anything else I should check or repair before attempting ELevate again?

    Specifically, does a freshly regenerated rescue image and cleaned /boot make this kernel-core/bls.conf failure less likely, or is that error more likely caused by something else in the EL9 kernel-core posttrans scriptlet that would not be affected by the AlmaLinux 8 rescue image?

    0
  • cPRex Jurassic Moderator

    I think your current work *should* make that less likely - I don't see anything else obvious that I would recommend before trying ELevate again.

    0
  • celiac101

    Today’s second ELevate attempt again failed at stage 4 during the AlmaLinux 9 kernel installation. The key error was:

    kernel-core-5.14.0-611.55.1.el9_7.x86_64 post-install scriptlet failed
/lib/modules/5.14.0-611.55.1.el9_7.x86_64/bls.conf: No such file or directory
    It also failed while attempting to create the rescue BLS entry inside the temporary installroot. I aborted the upgrade, ran the ELevate cleanup, restored the normal AlmaLinux 8 kernel/GRUB state, and repaired cPanel/Apache. The server is stable again. I have since removed dracut-config-rescue, which appears directly related to the rescue/BLS failure, but I have not attempted a third run.

    Any ideas?

    0
  • cPRex Jurassic Moderator

    Unfortunately both myself and the ELevate team are out of ideas on this one so it would be best to create a ticket.

    0
  • celiac101

    I created a ticket and your staff looked into this and their best assessment is that my /boot size was too small at 500MB. I have expanded it to 2G and have planned a 3rd upgrade attempt soon and will report the outcome here--hopefully they are correct.

    I guess my only complaint if your support team is correct in their assessment is why didn't your cPanel ELevate utility warn me about this? I got a green light both times to run Elevate, and each time I had arond 380MB free and a total /boot of 500MB.

    Do you understand the number of hours it took me--twice--to get my server back in working order after the failures? It seems like it would be a very simple check to add to your cPanel ELevate utility--a warning that /boot needs to be at least 1G, or 2G or whatever.

    Before I actually try a 3rd time, does a lack of boot space seem like the best answer? I'd really hate to to go through this again.

    0
  • cPRex Jurassic Moderator

    The support team would know far better than I would.  If that is indeed the case I agree we should have a check for ELevate to detect this.

    1
  • celiac101

    The 3rd attempt to upgrade worked!

    I wanted to follow up with what appears to have caused the repeated Stage 4 ELevate failures on this cPanel server.

    The server was AlmaLinux 8.10 and repeatedly failed during Stage 4 / Leapp upgrade. Initially, the suspected issue was insufficient /boot space, so I resized /boot from ~512MB to 2GB. That resolved the /boot capacity concern, but Stage 4 still failed the same way.

    The key issue turned out to be GRUB behavior. ELevate successfully created the temporary upgrade boot entry:

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

    and grubby set it as the default. However, /boot/grub2/grub.cfg was using:

    set default="0"

    because /etc/default/grub had:

    GRUB_DEFAULT=0

    As a result, after the Stage 4 reboot, the server kept booting the normal AlmaLinux 8 kernel at menu index 0 instead of the saved ELevate upgrade entry. ELevate then waited for the Leapp upgrade to complete, but the actual upgrade environment had never booted, so it reported Stage 4 failure.

    The workaround was:

    1. Change GRUB to use the saved entry:

    GRUB_DEFAULT=saved

    2. Rebuild GRUB:

    grub2-mkconfig -o /boot/grub2/grub.cfg

    3. Confirm grub.cfg showed:

    set default="${saved_entry}"

    4. Set the ELevate upgrade entry as default again:

    grubby --set-default /boot/vmlinuz-upgrade.x86_64

    5. Reboot with IPKVM attached.

    After that, the server actually booted into the ELevate-Upgrade-Initramfs environment, the Leapp transaction ran, Stage 4 completed, Stage 5 completed, and the server successfully upgraded to AlmaLinux 9.8.

    Current status:

    AlmaLinux release 9.8
    Kernel 5.14.0-687.29.1.el9_8.x86_64
    /scripts/elevate-cpanel --status reports: success
    httpd, MariaDB, cPanel, ea-php82-php-fpm, csf, and lfd are all active.

    So the root cause was not just /boot size. The real blocker was GRUB being hardcoded to boot index 0 instead of honoring the saved/default grubby entry that ELevate created.

    0
  • cPRex Jurassic Moderator

    I'm so glad we finally got there!!!

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post