OS Upgrade on Longleaf: RHEL8 -> RHEL9

Last updated: August 8, 2025

Longleaf default behavior changed from R8 to R9 on July 15, 2025.

We are rapidly working to eliminate RHEL8 from Longleaf.

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.

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 RHEL9 resources only.
• The majority of compute nodes are RHEL9, and we are actively in process of moving more of the cluster to RHEL9.
• Using submit script commands, it is possible to target either version explicitly.

Choosing RHEL8 or RHEL9

NOTE 1: When using --constraint, it is necessary that it is supplied as a parameter on the sbatch command, and NOT a #SBATCH entry in the slurm submit script.

NOTE 2: If you are crossing OS versions, i.e. submitting from a login host with one verison of RHEL but targeting a different version for a job, you MUST load all modules in the job submission script, and NOT rely on any modules saved in your environment.

Compute node targeting

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

If neither are specified, jobs will land on RHEL9 resources

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?

All compute nodes are in process of migrating to RHEL9. We will hold RHEL8 around 10% to 25% of the cluster as we guage community need for the older OS, with desire to agressively END support for R8 entirely.

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