MAS OpenShift Build Pod Evicted? How to Fix Ephemeral Storage Exhaustion During Addon Installation?

Have you ever kicked off a Maximo Application Suite addon installation only to watch it stall ,with the suite screen showing a cryptic build failure? If your OpenShift cluster is running low on ephemeral storage, this is a scenario you might face. In this post, we break down exactly what causes this error, what it means, and most importantly ,how to fix it step by step.

This guide is written for MAS administrators and OpenShift platform engineers who manage MAS 9.x environments. You should be comfortable running oc CLI commands and have access to your OCP cluster.

When an add on is installed in Maximo Application Suite, OpenShift triggers a container image build process. This build involves copying large Maximo directories into the container, which is both disk-intensive and memory-intensive. If the node running the build pod does not have enough ephemeral storage, OpenShift evicts the pod mid-build, causing the entire installation to fail.

This issue surfaces on the MAS Suite screen and causes the deployment to enter a continuous retry loop until the storage problem is manually resolved. Prerequisites for this guide:

• Access to the OCP cluster via oc CLI or OpenShift web console
• Sufficient permissions to view and delete image stream tags (istag)
• Basic familiarity with OpenShift pod and build concepts
• MAS 9.1 addon deployment in progress or recently failed

Understanding the Error

When addon installation fails due to insufficient storage, the following error message appears on the MAS Suite screen:

⚠️ Error Message: Message: Build Failed. --> 469071e5f863 [4/4] STEP 26/39: RUN mkdir -p /opt/IBM/SMP/writeable/maximo --> 78fd9fa01e23 [4/4] STEP 27/39: RUN cp -r /opt/IBM/SMP/maximo /opt/IBM/SMP/writeable Error: received unexpected terminate signal Reason: Failed Status: False

Important: This is not a Maximo application bug. The failure occurs during the container image build on OpenShift, not within MAS itself.

What Does Error Mean?

• Error: received unexpected terminate signal
• Reason: Evicted
• Message: node was low on resource: ephemeral-storage
• Your build was working fine
• It even completed: BUILD SUCCESSFUL

But then during this step:

cp -r /opt/IBM/SMP/maximo /opt/IBM/SMP/writeable    

• It needed more disk space
• Node ran out of disk space \
• Kubernetes killed (Evicted) the pod

Step-by-Step Resolution

Follow these steps in order to diagnose and resolve the storage issue.

Step 1: Connect to the OCP Console

Open your command prompt or PowerShell and connect to the OpenShift cluster.

Step 2: Log In to OpenShift (OCP)

Run the following login command:

oc login <cluster-url> 

If you do not have the cluster URL:

• Open OpenShift in a browser
• Click "Copy Login Command" from the top-right menu
• Paste it into your terminal

Step 3: Select Your Project (Namespace)

Switch to the namespace where your MAS add on is deployed:

oc project <your-project-name> 

# Example: 

oc project mas-mastest-manage 

Step 4: Identify the Failed Build Pod

List all pods to find the failed build pod:

oc get pods 

# Inspect the failed build pod: 

oc describe pod <admin-build-config-01-build> 

In the describe output, look for any of the following status indicators:

• Status: Failed
• Reason: Evicted
• Message: The node was low on resource: ephemeral-storage. Threshold quantity: 23938523083, available: 22071760Ki.

The describe output should confirm the root cause with a message similar to:

Status:   Failed 

Reason:   Evicted 

Message:  The node was low on resource: ephemeral-storage. 

          Threshold quantity: 23938523083, 

          available: 22071760Ki. 

Step 5: List All Existing Image Stream Tags

Check all build versions (image stream tags) stored in the cluster:

oc get istag 

# Sample output: 

mastest-main-admin:20260501 

mastest-main-admin:20260502 

mastest-main-admin:20260503 

mastest-main-admin:20260504

Note: These accumulated image tags consume significant ephemeral storage. Old, unused tags are the primary cause of the storage exhaustion.

Step 6: Decide Which Tags to Keep

Keep only: The latest tag (most recent date stamp).

Delete: All older image stream tags.

Step 7: Delete Old Image Stream Tags

Run the delete command for each old tag identified in Step 5:

oc delete istag mastest-main-admin:20260128T153913-9.1.296 

oc delete istag mastest-main-admin:20260224T092117-9.1.296 

# Repeat for all older tags...

Step 8: Trigger a New Build After Cleanup

Once old tags are deleted, manually start a fresh build:

oc start-build admin-build-config 

# Monitor the new build pod logs in real time: 

oc logs -f <new-pod-name> 

Step 9: Verify Add on Installation Completes

Once the build completes successfully, the MAS add on installation and deployment will proceed automatically. Monitor the Suite screen to confirm the deployment reaches a healthy state.

Key Takeaways

• The build failure is an OpenShift-level storage issue, not a MAS application defect.
• The root cause is node ephemeral storage exhaustion, confirmed by an Evicted pod status and a threshold message in oc describe.
• Accumulated old image stream tags (istag) are the primary storage consumer — deleting them frees up the space needed for the build.
• After cleanup, oc start-build restarts the build; the addon deployment resumes automatically on success.
• Proactive istag cleanup after each addon update prevents this issue from recurring.

Ephemeral storage exhaustion is a common operational challenge in OpenShift-based MAS deployments, especially as addon builds accumulate image tags over time. By understanding how to read build pod status, identify the eviction trigger, and clean up old image stream tags, you can quickly restore a healthy deployment pipeline.

As a next step, explore setting up automated OpenShift monitoring alerts for ephemeral storage thresholds, and consider scripting the istag cleanup as part of your regular MAS maintenance runbook.