Fix “Cannot Allocate Memory” During an SLES System Upgrade

The SLES upgrade appears to be progressing, then a terminal, installer, or migration log reports “Cannot allocate memory.” The message does not by itself prove that the server needs more physical RAM. The failure could come from memory pressure, a virtual machine or service limit, missing or unusable swap, or the upgrade environment itself. First identify which process and upgrade phase produced the message; the safe fix depends on that detail.

Version matters. As of October 2026, SUSE’s SLES 16.0 major-version upgrade guide describes a distribution migration system that boots a dedicated live upgrade image, while SLES 15 service-pack migrations use the established YaST or Zypper migration workflow. Do not apply a fix intended for an online service-pack migration to a major-version upgrade without checking your release’s procedure. SUSE documents the current SLES 16 path in its SLES 16 upgrade guide.

1. Identify the failing phase before changing anything

Record the full error, timestamp, command or screen where it appeared, and whether the system has rebooted into an installer or migration image. “Cannot allocate memory” is a broad operating-system error, so the surrounding lines are often more useful than the message alone.

• Before the package transaction starts: a registration, repository, migration preparation, or installer process may be failing. Check system and process memory, then review the relevant service or migration log.
• While packages are being installed or removed: Zypper and RPM may already have changed the system. Do not kill the process, reboot, or start a second package manager just because progress looks slow. Check the console and logs, and allow the supported migration process to finish or reach a clear failure state.
• After a reboot into an upgrade image: the process may be running with a different resource environment from the original operating system. A swap area visible before reboot is not proof that the upgrade image can use it.

SUSE’s SLES 16 migration sequence prepares the migration environment, mounts filesystems, configures networking, prepares Zypper, upgrades packages, updates the boot loader, and reboots. The guide says that an error before the upgrade starts reverts the system to its original state; this does not mean every error during package replacement is harmless. Preserve logs and avoid manual recovery steps until you know which stage failed.

2. Check RAM, swap, and recent kernel messages

If the original SLES system is still running, or you have reached a recovery shell, start with read-only checks:

free -h
swapon --show
vmstat 1 5
ps -eo pid,comm,rss,%mem --sort=-rss | head -n 15

free -h summarizes memory and swap. Focus on the available memory and swap used, not just the “free” column: Linux uses otherwise idle RAM for caches. vmstat helps show whether the machine is continually paging. The process list can reveal a database, Java service, backup, or other workload consuming memory during the upgrade.

Look for kernel OOM records around the error time:

sudo journalctl -k --since "30 minutes ago" |
  grep -i -E 'out of memory|oom|killed process'

If the error happened earlier, change the time window. A kernel message naming a killed process is evidence of an out-of-memory event; no matching line does not rule out all allocation failures. If the upgrade is in a separate live environment, inspect that environment’s logs when available rather than relying only on the old system’s journal.

Also check whether a virtual machine, container, or systemd unit has a memory cap. A guest can have available memory on the host but still hit its own configured limit. On SLES 16, SUSE documents cgroups v2 as the default resource-control hierarchy and explains that systemd can apply resource limits. Review the relevant VM configuration or service’s MemoryMax setting instead of raising global kernel limits at random. See SUSE’s SLES 16 kernel control groups guide.

3. Reduce competing memory use and retry only at a safe point

If measurements show that a workload is using most of the available memory, schedule a maintenance window and stop nonessential services cleanly before retrying. Examples include memory-heavy application workers, analytics jobs, test databases, and backup processes. Do not stop storage, cluster, or application services blindly on a production host; use the application’s documented shutdown procedure and confirm that stopping it will not interrupt users or a recovery task.

For a virtual machine, compare the guest’s configured RAM with host capacity and other guests’ current demand. If the guest is under-sized, increase its assigned memory using the hypervisor’s supported method. Whether memory can be hot-added depends on the hypervisor, guest configuration, and workload; plan a reboot if required. In public cloud, verify the instance size and any provider-specific memory limits.

If the message persists while the machine has ample available RAM and no OOM record, investigate process limits. For a still-running process, inspect /proc/PID/limits using its actual process ID. For a systemd-managed upgrade helper, inspect the unit’s resource settings. A limit can constrain one process even when the host has free memory. Change a limit only if you can identify the applicable setting and understand its impact.

After addressing the identified constraint, resume or retry only through the upgrade method supported for your exact SLES release and upgrade path. For SLES 15 service-pack migration, use the documented YaST or Zypper migration workflow. For SLES 16 major-version migration, follow the SLES 16 distribution migration procedure. SUSE’s SLES 15 SP7 guide explains its service-pack workflow and supported rollback prerequisites in the online upgrade documentation.

4. Consider swap carefully; do not use it as a blind fix

Additional swap can give a system more virtual-memory headroom when the workload can page memory, but it is much slower than RAM. If the machine is already swapping heavily, adding more swap can make the upgrade extremely slow without solving an undersized VM or an isolated process limit. First confirm whether swap exists and whether it is being used with swapon --show and free -h.

Use SUSE’s procedure for your SLES version and filesystem if you need to add swap. Be especially careful with Btrfs: SUSE documents restrictions for swap files on Btrfs, and states that a snapshot cannot be created while a swap file in the source subvolume is active. Since SLES commonly relies on Snapper snapshots for system recovery, do not create and activate a generic swap file on the snapshotted root subvolume during an upgrade window. Prefer adding RAM or using a properly configured swap partition or supported location after checking the storage layout and recovery plan. The filesystem-specific details are in SUSE’s SLES 15 SP7 storage guide.

Do not change vm.overcommit_memory, disable the OOM killer, or run an arbitrary cleanup command as a first response. These changes can hide the symptom, destabilize workloads, or make recovery harder. Gather evidence first and use the setting-specific guidance from SUSE or your application vendor if the logs point to a specialized memory configuration.

5. Recover if the upgrade stopped after package changes began

Before deciding to rerun an upgrade, determine whether the package manager is still active and whether the migration tool has reported a final failure. If the upgrade stopped after package changes began, save the complete log output and check the release-specific recovery documentation. Do not run zypper dup, zypper migration, YaST migration, and RPM commands concurrently.

On SLES 15 SP7, SUSE documents service-pack rollback when the root filesystem is Btrfs and Snapper snapshots are enabled. The rollback procedure requires identifying and testing the pre-migration snapshot, then making the rollback permanent; it is not a universal fix for every upgrade error. SLES 16’s major-version migration follows a different workflow, so use its current upgrade and recovery instructions rather than assuming the SLES 15 procedure applies. If the system is business-critical, has no tested backup, or the migration fails during package replacement, open a SUSE support case before trying manual package repairs.

6. Verify the system before resuming normal service

Once the upgrade reports completion and the server boots normally, verify the operating-system release and registration, then check package consistency and the workload that originally exposed the issue:

cat /etc/os-release
sudo SUSEConnect --status
sudo zypper verify
free -h
swapon --show

Use the package-verification command supported by your SLES version; if zypper verify is not available or behaves differently on your release, consult zypper help and the release’s administration guide. Check application and kernel logs for new errors, confirm the intended services are healthy, and monitor memory and swap while load returns. Verify that the supported upgrade target was installed and that the server’s registration and repositories are in the expected state before closing the maintenance window.

A successful fix means more than a disappearing error message: the SLES migration completes using a supported path, the machine boots into the expected release, packages and registration check out, and normal workloads run without repeated OOM events. If “Cannot allocate memory” returns despite low memory pressure, adequate swap, and no resource cap, retain the precise log and process details—those clues distinguish an upgrade defect from a capacity problem.