Skip to main content

Comments

7 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

Please sign in to leave a comment.

Didn't find what you were looking for?

New post