/
O2 Operating System Upgrade

O2 Operating System Upgrade

Owned by Gaby Rodriguez
Last updated: Jun 30, 2025 by Alex Truong

Table of Contents

Summary

We’re giving the O2 computing cluster an important update. The operating system (OS) that powers O2 is being upgraded from CentOS 7 to Red Hat Enterprise Linux 9 (RH9). This change is essential to keep the system secure, up-to-date, and capable of supporting modern research software.

While this upgrade brings many benefits, it will break many of your current software setups (like R packages, conda environments, or virtual environments). These will need to be rebuilt.

We know this may sound alarming - but don’t worry! We're here to guide you through what this means and how to prepare.

Why Are We Doing This?

CentOS 7, the current operating system for O2, is old and will no longer be supported after Thursday, June 26th. Upgrading to RH9 means:

  • ✅ Better support for new tools and programming languages

  • ✅ Improved security and system stability

  • ✅ A system that can grow with your research needs

How This Affects You

Many of you use custom workflows or software installations in your work. If you're using any of the following, action is required:

  • R packages installed in your home or lab directory

  • Python virtual environments

  • Conda environments

  • Scripts or programs you compiled from source code

  • Any software that "just worked” under CentOS 7

Unfortunately, after the upgrade, it is highly likely that these elements will not work as intended anymore and must be rebuilt or recreated under the new system.

In other words: If you created your environment or software while we were using CentOS 7, it probably won’t work on Red Hat 9.

Users should assume that their environment will be broken, but if a test succeeds, consider it an exception rather than the expectation. It may still be a better idea to rebuild the application or environment anyway to guarantee continued long term compatibility.

The RHEL9 Module List

A number of software available to load as modules have been removed or re-installed at their latest versions - this is an attempt by Research Computing to clean up previously unused software, based on relative popularity. If you had a workflow or environment that was reliant on a removed module, please update it to work with either an existing module, or with a conda-provided option. You may also choose to install it manually yourself (and we do have instructions on setting up your own custom modules at Local Software Installs | Creating Your Own Modules ). If your use case is more complex, or you feel more comfortable asking for assistance (or are otherwise uncertain), please contact rchelp@hms.harvard.edu. Research Computing is entertaining requests to globally (re-)install software on a case by case basis.

Presently, Research Computing is encouraging users that rely on software installed via pip3 (e.g., deeptools, MACS) to install these applications into conda or python virtual environments. This allows users to handle version updates in a timelier manner, as well as allowing for more flexible integration with other software (the previous modules hosted the applications in their own virtual environments, and you can only have one virtual environment active at a time).

What You Need To Do

Please make a plan to rebuild your environments or re-install your software after the upgrade. Here's some high-level guidance:

R Users

  • R packages installed in your personal folder will no longer work.

  • After the upgrade, load the new R module and re-install the packages you need using R’s install.packages() or Bioconductor’s install functions. For more information: O2 Operating System Upgrade | 4. Migrating R Environments

Conda & Python Users

Compiled Software

  • If you compiled your own software (e.g., using C, C++, or Fortran), you’ll need to recompile it under RH9.

Timeline

📅 RH9 migration: beginning at 9:00 AM on Monday, June 23, through 5:00 PM on Thursday, June 26

🧩 CentOS 7 legacy: limited availability after OS upgrade

🚫 CentOS 7 will eventually be retired completely

Preparing for Environment Migration

This guide helps users prepare and migrate their working environments (Conda, Python, R) to the new RHEL9 cluster. Follow these steps to ensure a smooth transition and avoid disruptions.

1. General Preparation

List Your Tools: Start by making a list of all the tools and environments you rely on.

2. Migrating Conda Environments

  1. Start an interactive job

srun -t 0-2 --pty -p interactive -c 1 --mem=8G bash

  1. Module Selection

If you used a Conda module before (e.g., miniconda3/23.1.0), load the new module:

module load conda/miniforge3

If using your local Conda install, reinstall it in a new location or consider using the module above.

  1. Clean Slate

Ensure no other Conda instances are active:

  • No “conda init” blocks in your $HOME/.bashrc

  • No currently active environments, including base

  1. Activate and Export

Activate the desired environment:

conda activate {/path/to/}nameofenv

Export it:

conda env export --from-history --no-builds > nameofenv.yml

  1. Create New Environment

Create the new environment in a dedicated directory (e.g., $HOME/rh9_envs/)

conda env create --file nameofenv.yml --prefix $HOME/rh9_envs/nameofenv

  1. Activate and Test

Activate the new environment:

conda activate $HOME/rh9_envs/nameofenv

Confirm everything works as expected.

  1. Optional: Replace Old Environments

Once confirmed, you may:

  • Replace the old environment by deleting/rebuilding at its original path

  • Continue working in your new, dedicated RH9 directory

  1. Repeat

Repeat steps 4-7 for each Conda environment.

Note: Depending on the complexity of the Conda environment, it may actually be worth confirming beforehand whether the environment in question is actually broken. To that end, you may attempt to leverage your old CentOS7-built environment against our RHEL9 module, and check via job submission to verify that your workflow is indeed broken (for a very small input - keep in mind the limited allocation request maxima allowed on this partition). If your workflow (and consequently, Conda environment) miraculously survives this test, you may want to wait for after the migration to try a test a full scale to validate the integrity of the environment.

3. Migrating Python Environments

  1. Start by launching an interactive session on a CentOS7 compute node (note that the centos partition will NOT be around forever - please do this as soon as possible):

srun -t 0-2 --pty -p centos -c 1 --mem=6G bash

  1. Determine How You Use Python

# Load all required modules module load gcc/9.2.0 python/3.9.14 # Activate the environment source /path/to/envname/bin/activate

  1. Export Package List

pip3 freeze > nameofenv.txt

the nameofenv.txt file is usually called requirements.txt, but since you’ll be doing this multiple times, it’s better to make the filename descriptive.

  1. Optional: Repeat

If you have more Python environments, you can deactivate an environment and source the next environment as follows:

deactivate source /path/to/nextenv/bin/activate

and repeat the process from the beginning (including keeping that interactive session on a CentOS7 compute node).

  1. Start a new interactive session in a standard partition:

srun -t 0-2 --pty -p interactive -c 1 --mem=6G bash

  1. Load the appropriate python module:

module load gcc/14.2.0 python/3.13.1

  1. Set up a new virtual environment

virtualenv /path/to/nameofenv source /path/to/nameofenv/bin/activate pip3 install -r nameofenv.txt

  1. Test and Confirm

  • After successful set-up, test that the environment performs as desired.

  • Then, either fully replace your old environment or keep the new arrangement.

  1. Troubleshooting: Version Issues

If at some point during the pip3 install step, you see some python version incompatibility (e.g., 3.13 is too new), you may need to consider creating a conda environment instead where you can install an older python version.

module load conda/miniforge3/24.11.3-0 conda create --prefix /path/to/envname python=3.10 # for example, 3.10 needed

at which point you can interact with it as normal:

conda activate /path/to/envname pip3 install -r requirements.txt

(or conda install -r requirements.txt if you’d prefer to stay in the conda ecosystem, which may be preferable for a given environment).

3a. Separated Python Libraries

Some users may have isolated python packages installed to non-standard locations, or even simply to $HOME/.local. Generally, HMS RC discourages this practice, though it is understandable that this can occur when blindly following installation instructions in README files, et cetera.

The libraries generally are not tied to existing virtual environments (or conda environments, in certain cases), and may be accessed across multiple environments depending on how your environment is configured (e.g., automatically if in $HOME/.local, or if the $PYTHONPATH was modified to include the custom path). These are the easiest to overlook, but might surprisingly also be the most resilient to this transition.

If you can recall relying on any python packages that are available to you in this state, it is highly recommended to confirm their function on RH9 and rebuild them within virtual or conda environments. This is because libraries that live in these globally accessible locations can cause version incompatibilities or strange errors when least expected. It is better for reproducibility (assuming you are adhering to the practice of generating an environment for each project) to have your list of required utilities and libraries in one location, so that you can be completely sure that this environment alone is sufficient to perform your workflow.

To re-install independent packages, you may first note the version installed, by typing the following:

pip3 show [nameofpackage]

Note: pip3 show works only if the package was installed via conventional means (e.g., without renaming the library, etc.). You may see output that looks like this:

$ pip3 show numpy Name: numpy Version: 1.19.5 Summary: NumPy is the fundamental package for array computing with Python. Home-page: https://www.numpy.org Author: Travis E. Oliphant et al. Author-email: None License: BSD Location: /home/HMSID/.local/lib/python3.6/site-packages Requires:

If the Location field does not point to an established environment, you should re-install this package into the relevant environment(s) with the pip3 install command, taking care to preserve the version in Version if necessary (e.g., pip3 install numpy==1.19.5 in this case). If the package was not installed via pip3, e.g., it was installed manually via python3 setup.py install or something similar, you will need to follow the instructions to install that package again, but do so with the relevant environment active beforehand.

When re-installing individual libraries, whether with pip3 or some custom procedure, make sure to ignore mentions of the --user flag (a pip3-specific flag), or any mention of --prefix or similar flag that specifies installation destination. Allow the package to install to the currently active environment.

4. Migrating R Environments

Export Currently Installed Packages

  1. Launch R and save your packages as a dataframe:

installed <- as.data.frame(installed.packages())

  1. Write the this to a CSV:

write.csv(installed, '/home/$USER/installed_previously.csv') 

Restore on RH9

  1. Start an R session in an interactive session:

srun --pty -p interactive -t 0-04:00 --mem 16G -c 1 bash module load gcc/14.2.0 R/4.4.2 R

  1. In R, load your package list:

installedPreviously <- read.csv('/home/$USER/installed_previously.csv')

  1. Then load packages already installed in R (these are system packages, we want to exclude them from reinstall):

baseR <- as.data.frame(installed.packages())

  1. Next, we make a list of all packages from the other R library that are also not found in 'baseR' (the system packages):

toInstall <- setdiff(installedPreviously, baseR) 

  1. Finally, install this list:

install.packages(toInstall)

Final Checklist

Document how you installed all critical packages or software.

Support

Reach out to us for help (rchelp@hms.harvard.edu) early - we’re happy to assist!

Digital Accessibility