OS Upgrade on Longleaf: RHEL8 -> RHEL9

Last updated: July 1, 2025

Longleaf default behavior will change from R8 to R9 begining 8am on July 15, 2025.

The Longleaf cluster is in process of being upgraded from Red Hat Enterprise Linux version 8 (RHEL8) to RHEL9. Some codes/workloads will run unaffected on either OS. Some will not. If you have compiled software on R8, we highly recommend recompiling for R9.

Open OnDemand will have a 2 hour maintenance outage from 8am to 10am on July 15 for its migration to R9.

Available versions of software, and default versions of software will be different. If your workloads are version specific, we highly recommend early testing.

Current configuration:

• All jobs submitted to slurm are (by default) directed to RHEL8 resources only.
• The majority of compute nodes are still RHEL8, however we are actively in process of moving at least 50% of the clister to RHEL9.
• Using submit script commands, it is possible to target either version explicitly.

Choosing RHEL8 or RHEL9

Compute node targeting in your submit script, SBATCH option

--constraint=rhel8 (or no constraint at all)
--constraint=rhel9

If neither are specified, jobs will land on RHEL8 resources

Login/Build hosts prior to July 15 2025

• ssh username@longleaf.its.unc.edu is RHEL8
• ssh username@longleaf-rhel9.its.unc.edu for R9

Login/Build hosts as of July 15 2025

• ssh username@longleaf.its.unc.edu is RHEL9
• ssh username@longleaf-rhel8.its.unc.edu for R8

It remains possible to explicity choose among {8 only, 9 only} using sbatch commands.

How long will RHEL8 systems remain available?

Compute nodes are in process of migrating to RHEL9. On July 15 2025, at least 50% of the cluster will be R9, and the R8 capacity will quickly dwindle down to 25% shortly thereafter. We will hold R8 at 25% of the cluster as we guage community need for the older OS, with desire to agressively END support for R8 entirely.

Please contact us asap to discuss if you are concerned about getting your codes running well on RHEL9.

Which RHEL am I on right now?

cat /etc/redhat-release

can be included in submit scripts

Building code

We recommend explicitly choosing a version of gcc using modules. As of May 2025, the default gcc module version (module load gcc) is 11.2.0 for RHEL8 and 12.2.0 for RHEL9 systems.

Modules

"module avail gcc" lists all available versions.

Many older versions of software will NOT be brought forward to R9. I you have a specific and hard requirement for an older version that is not in the Longleaf R9 environment, contact our helpdesk for assistance - we will do what we can to accomodate needs for older versions.

Troubleshooting tip

A clue that the R version you are attempting to use does not match the OS version of the host your job runs on is an error such as:

/nas/longleaf/apps/r/4.1.3/lib64/R/bin/exec/R: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory

Another problem one may encounter is when personally installed third-party packages for the application under a home folder. It is possible that the package was installed using a RHEL8 host but the job calling the third-party package runs on a RHEL9 host. Again, in the case of R, the error might look something like

Error: package or namespace load failed for ‘robustbase’ in dyn.load(file, DLLpath = DLLpath, ...): unable to load shared object '~/R/x86_64-pc-linux-gnu-library/4.1/robustbase/libs/robustbase.so': libgfortran.so.3: cannot open shared object file: No such file or directory

A quick fix is to add the "--constraint=rhel8" SBATCH option to the job submission to target only RHEL8 hosts. However, it will be important to address underlying issues and rebuild code/dependencies due to a diminishing set of RHEL8 resources as more nodes transition to version 9.

Just FYI:

• Help page for prior migration from RHEL7 to RHEL8