Unable to generate Full Host Image after upgrading the operating system of Red Hat Satellite 6.16 to RHEL 9

Solution Verified - Updated

Environment

  • Red Hat Satellite 6.16
  • Red Hat Enterprise Linux 9

Issue

  • Full Host Image generation fails on a Red Hat Satellite 6.16 that was upgraded from RHEL 8 to RHEL 9 using leapp.

  • The same problem happens with a new subnet image generation as well.

Resolution

  • The issue was reported to Red Hat Engineering team via This content is not included.JIRA SAT-29987 and This content is not included.JIRA RHEL-50015 and a fix has been released via ERRATA RHBA-2025:0515 in RHEL 9.5.

  • A connected setup of Red Hat Satellite 6.16 would not be affected as long as the operating system is upgraded to RHEL 9.5.

  • In case of a disconnected setup, make sure to avail and use the latest baseos and appstream repository content of RHEL 9.5 release.

  • Existing affected users need to execute the following commands on the concerned Red Hat Satellite 6.16 instance:

       # alternatives --remove mkisofs /usr/bin/xorrisofs

   # dnf update xorriso --disableplugin=foreman-protector

  • Verify the genisoimage command execution shows something liks this i.e. 

    # genisoimage
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

usage : genisoimage [commands]
        More is told by command -help

  • Generate a new Full Host Image and continue with the system build process.

  • Reach out to the This content is not included.Red Hat Technical Support in case of any further concerns.

For more KB articles/solutions related to Red Hat Satellite 6.x Provisioning Issues, please refer to the Consolidated Troubleshooting Article for Red Hat Satellite 6.x Provisioning related Issues

Root Cause

  • On RHEL 8, The relevant binary comes from genisoimage package and depends on libusal library as well. The libusal library is no longer shipped in RHEL 9.

  • When using leapp to upgrade the operating system to RHEL 9, The package gets replaced by xorriso which has no dependancy on libusal library as well.

  • During the process, The xorriso package is installed first and then the genisoimage package is removed which does not remove the residual binaries due to the way their scriptlets are designed and the system ends up retaining the old /usr/bin/genisoimage binary that still depends on the non-existent libusal library.

    Logs from leapp-upgrade activity:

    2024-12-11 15:44:32.723 DEBUG    PID: 981 leapp.workflow.RPMUpgrade.dnf_upgrade_transaction:   Installing       : xorriso-1.5.4-4.el9.x86_64                         418/867 
2024-12-11 15:44:32.773 DEBUG    PID: 981 leapp.workflow.RPMUpgrade.dnf_upgrade_transaction:   Running scriptlet: xorriso-1.5.4-4.el9.x86_64                         418/867 
..
--
2024-12-11 15:46:27.612 DEBUG    PID: 981 leapp.workflow.RPMUpgrade.dnf_upgrade_transaction:   Cleanup          : libldb-2.8.0-1.el8_10.x86_64                       524/867 
2024-12-11 15:46:27.621 DEBUG    PID: 981 leapp.workflow.RPMUpgrade.dnf_upgrade_transaction:   Running scriptlet: genisoimage-1.1.11-39.el8.x86_64                   525/867 
2024-12-11 15:46:27.626 DEBUG    PID: 981 leapp.workflow.RPMUpgrade.dnf_upgrade_transaction: failed to link /usr/bin/genisoimage -> /etc/alternatives/mkisofs-genisoimage: /usr/bin/genisoimage exists and it is not a symlink
2024-12-11 15:46:27.631 DEBUG    PID: 981 leapp.workflow.RPMUpgrade.dnf_upgrade_transaction: failed to link /usr/share/man/man1/genisoimage.1.gz -> /etc/alternatives/mkisofs-genisoimageman: /usr/share/man/man1/genisoimage.1.gz exists and it is not a symlink
2024-12-11 15:46:27.637 DEBUG    PID: 981 leapp.workflow.RPMUpgrade.dnf_upgrade_transaction: 
2024-12-11 15:46:27.645 DEBUG    PID: 981 leapp.workflow.RPMUpgrade.dnf_upgrade_transaction:   Erasing          : genisoimage-1.1.11-39.el8.x86_64                   525/867 
--
2024-12-11 15:48:39.397 DEBUG    PID: 981 leapp.workflow.RPMUpgrade.dnf_upgrade_transaction:   Verifying        : libisoburn-1.5.4-4.el9.x86_64                       68/867 
2024-12-11 15:48:39.402 DEBUG    PID: 981 leapp.workflow.RPMUpgrade.dnf_upgrade_transaction:   Verifying        : python3-distro-1.5.0-7.el9.noarch                   69/867 
2024-12-11 15:48:39.406 DEBUG    PID: 981 leapp.workflow.RPMUpgrade.dnf_upgrade_transaction:   Verifying        : xorriso-1.5.4-4.el9.x86_64                          70/867

  • Due to this, the genisoimage command execution works while generating Full Host Image.

Diagnostic Steps

  • The following errors are captured in /var/log/foreman/production.log file when generating the Full Host Image for a system:

    2024-12-05T05:02:17 [W|app|88a1bd12] ERF42-8093 [Foreman::Exception]: ISO build failed
2024-12-05T05:02:17 [I|app|88a1bd12] Backtrace for 'ERF42-8093 [Foreman::Exception]: ISO build failed' error (Foreman::Exception): ERF42-8093 [Foreman::Exception]: ISO build failed
  88a1bd12 | /usr/share/gems/gems/foreman_bootdisk-21.2.3/app/services/foreman_bootdisk/iso_generator.rb:160:in `generate'
  88a1bd12 | /usr/share/gems/gems/foreman_bootdisk-21.2.3/app/services/foreman_bootdisk/iso_generator.rb:30:in `generate_full_host'
  88a1bd12 | /usr/share/gems/gems/foreman_bootdisk-21.2.3/app/controllers/foreman_bootdisk/disks_controller.rb:58:in `full_host'
  88a1bd12 | /usr/share/gems/gems/actionpack-6.1.7.8/lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'

  • Around the same time, the following errors related to iso generation were observed in the /var/log/messages file.

    Dec  5 05:02:16 mysatellite foreman[22249]: mkfs.fat 4.2 (2021-01-31)
Dec  5 05:02:17 mysatellite foreman[22255]: genisoimage: error while loading shared libraries: libusal.so.0: cannot open shared object file: No such file or directory

  • A manual execution of the genisoimage command fails as well. 

     # touch /tmp/test && genisoimage -o cd.iso /tmp/test
 genisoimage: error while loading scondition hared libraries: libusal.so.0: cannot open shared object file: No such file or directory

  • A bad alternative has been created for mkisofs which was supposed to be using the right binaries from the xorisso package.

     # /usr/sbin/alternatives --display mkisofs
 mkisofs - status is auto.
  link currently points to /usr/bin/xorrisofs
 /usr/bin/xorrisofs - priority 50
  follower mkisofs-genisoimage: /usr/bin/xorrisofs
  follower mkisofs-mkhybrid: (null)
  follower mkisofs-genisoimageman: /usr/share/man/man1/xorrisofs.1.gz
  follower mkisofs-mkhybridman: (null)
  follower mkisofs-mkisofsman: /usr/share/man/man1/xorrisofs.1.gz
 Current `best' version is /usr/bin/xorrisofs.

    • The null values are due to the presence of /usr/share/man/man1/genisoimage.1.gz and /usr/bin/genisoimage files from the older RHEL 8 installation.

      # ls -ld /usr/share/man/man1/genisoimage.1.gz /usr/bin/genisoimage
 -rwxr-xr-x. 1 root root 585376 Aug 12  2018 /usr/bin/genisoimage
 -rw-r--r--. 1 root root  29363 Aug 12  2018 /usr/share/man/man1/genisoimage.1.gz

      They are actually expected to be like this under working conditions:

        # ls -ld /usr/share/man/man1/genisoimage.1.gz /usr/bin/genisoimage
  lrwxrwxrwx. 1 root root 37 Nov 13 19:15 /usr/bin/genisoimage -> /etc/alternatives/mkisofs-genisoimage
  lrwxrwxrwx. 1 root root 40 Nov 13 19:15 /usr/share/man/man1/genisoimage.1.gz -> /etc/alternatives/mkisofs-genisoimageman
SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.